Originally posted by Chris Nappin:
I'd appreciate some advice from anyone who has had to develop Java-based web services that can be deployed on a wide range of J2EE Application Servers. I'm using a WSDL-first approach with document/literal WS-Basic Profile style services, because interoperability is important to us.
In my judgment the problem is that you are trying to solve two entirely different problems with one joint solution and the existence of that joint solution may not even be mandated by the J2EE/JAX-RPC spec. You are looking for:
A web service component that is deployable on all J2EE servers. A web service that is interoperable. Both of these goals do not necessarily meet. Using document-literal, WSDL-first approach (which includes designing the exchanged XML-document (schemas)) is a great step towards interoperability - at the web service interface level. However there is nothing in the J2EE / JAX-RPC spec that will ultimately force identical Java-to-XML and XML-to-Java translations to be generated by all the different tools that are associated with the different application servers - yes, there are some basic rules that have to be followed, but as your XML-documents become more complex the generated Java-equivalents will begin to diverge. Basically the J2EE/JAX-RPC spec gives each application server the tools to deal with "interoperable web service definitions" but there is no guarantee that each of these application servers will use the facilities in exactly the same way.
So if in fact you do actually need a web service component that is deployable on all J2EE servers, that has one unified Java interface, then you will need to find one tool that generates output that can be accommodated by all the application servers - rather than using each of the application server's own tools. This may very well lead you down the path writing your own
servlet that is your web service component, that obeys your WSDLs and XSDs. You may be able to use JAXB for the (common) generated Java-to-XML and XML-to-Java Mappings, and you may be able to find a SOAP-library to support you in all things SOAP. All-in-all it may be a bit of work to meet your goal of a generally deployable web service component that obeys an interoperable web service contract.
[ August 09, 2006: Message edited by: Peer Reynders ]