This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Web Services and the fly likes JAX-RPC to JAX-WS (Client impact) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "JAX-RPC to JAX-WS (Client impact)" Watch "JAX-RPC to JAX-WS (Client impact)" New topic
Author

JAX-RPC to JAX-WS (Client impact)

Taariq San
Ranch Hand

Joined: Nov 20, 2007
Posts: 192
We're 'stuck' for a while with JAX-RPC, OracleAS does not yet support JAX-WS.
I've just started with the POC to explore various issues we're concerned about, like authentication and binding, but for the moment it seems we might have to develop our 1st few web-services using JAX-RPC and later upgrade.

The impact on the client bothers me a little, banks tend to be reluctant to upgrade. There's a chance that Oracle will release 11g before the code goes into production, if that happens and we'll give the clients some new WSDLs that I imagine are mostly the same with different soap versions.
Long story slightly shorter, if our service is RPC and we move along to JAX-WS, is the impact on the client limited to downloading some new jars and generating a new proxy or will things like binding throw us a curveball or two?
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Taariq San:
The impact on the client bothers me a little, banks tend to be reluctant to upgrade.


Why would they need to upgrade? Are you supplying Java API stubs to them? If they are simply using your WSDL then design a WSDL that can be serviced by your current JAX-RPC implementation and existing JAX-WS implementations (like Java SE 6 or the JAX-WS RI) - it simply means that you are stuck with WSDL 1.1/SOAP 1.1 and a document/literal messaging style.

The main source of problems (from the client perspective) in a JAX-RPC to JAX-WS transition is that "contract-last" development , i.e. Java-to-WSDL, can lead to some very different WSDLs. That problem is eliminated if you switch to contract first, i.e. WSDL-to-Java development because you keep the WSDL (the interface) stable.

By designing the WSDL to be compatible which both technologies your clients don't even have to know that you are switching from JAX-RPC to JAX-WS. Once the switch is made and you want to use some of the newer features that are available under JAX-WS you can simply publish new endpoints with the new features for new clients or clients that are willing to switch.
Taariq San
Ranch Hand

Joined: Nov 20, 2007
Posts: 192
Originally posted by Peer Reynders:


Why would they need to upgrade? Are you supplying Java API stubs to them? If they are simply using your WSDL then design a WSDL that can be serviced by your current JAX-RPC implementation and existing JAX-WS implementations (like Java SE 6 or the JAX-WS RI) - it simply means that you are stuck with WSDL 1.1/SOAP 1.1 and a document/literal messaging style.

The main source of problems (from the client perspective) in a JAX-RPC to JAX-WS transition is that "contract-last" development , i.e. Java-to-WSDL, can lead to some very different WSDLs. That problem is eliminated if you switch to contract first, i.e. WSDL-to-Java development because you keep the WSDL (the interface) stable.

By designing the WSDL to be compatible which both technologies your clients don't even have to know that you are switching from JAX-RPC to JAX-WS. Once the switch is made and you want to use some of the newer features that are available under JAX-WS you can simply publish new endpoints with the new features for new clients or clients that are willing to switch.


Nice news Peer, thanks for the insight.
 
wood burning stoves
 
subject: JAX-RPC to JAX-WS (Client impact)