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.