Why rethink the Java SOAP stack ?

Steve Loughran and Edmund Smith, from HP Labs, published a paper on "Rethinking the Java SOAP Stack". The paper examines JAX-RPC programming model for Web services. Here I post my comments on the article.

Marc Hadley posted his comments last week. And I agree with Marc that the paper is based upon JAX-RPC 1.1 and ignored the advances made in JAX-WS (Java API for XML Web Services, nee JAX-RPC 2.0). Again, it is mainly focused on XML <-> Object mapping and have mentioned about interoperability concerns at multiple places as well.

I've been with the JAX-RPC team since it's inception (phew, that's almost 4 yrs now) and so have a strong sense of belonging (read passion) for the technology. I used JAX-RPC 1.0 implementation for SOAPBuilders interoperability testing. I also represent Sun in WS-I Sample Applications Working Group and have used JAX-RPC 1.1 implementation (SI, available in Java Web Services Developer Pack and Sun Java System Application Server) for interoperability testing there. This implementation has been tested for interoperability with all the major players including IBM, Microsoft, Oracle, BEA, and SAP. Most of  the vendors are in different time zones, using different operating systems, using different platforms, and using different language and fully interoperate with each other. For folks not familiar with the sample applications, read this. A short summary is that the WS-I Sample Applications consists of 8 different Web services that enables potentially 8 vendor to be able to demonstrate interoperability with each other. 

Key Message: Production-quality and interoperable JAX-RPC standard implementation is available for past 3 years. We've tested it pretty hard for full compliance with Basic Profile 1.1, Simple SOAP Binding Profile 1.0, Attachment Profile 1.0.

Lets clarify some of the points mentioned in the paper.

1. Section, Part A, bullet 1 talks about accurately modeling an XSD type hierarchy in a Java class hierarchy. I think the issue is more to do with schema validation rather than representing in a Java class hierarchy. I don't know of any SOAP processor that validate the schemas (at least by default) for performance reasons.

2. Section I, Part A, bullet 2 says: 
   
   The dispatch of operations to Java methods, Enterprise Java Bean methods or other destinations is generally implemented by specific handlers, making the handler chain the foundation for the rest of the system.

   Neither the JAX-RPC 1.1 specification, nor the JAX-RPC reference implementation require using handlers for dispatching operations to Java methods. Anybody is free to make their own proprietary dispatching mechanism based upon handlers and thus mandating the dispatch handler on the service endpoint. Here are couple of quotes from Chapter 12 of JAX-RPC 1.1 spec:

   A typical use of a SOAP message handler is to process the SOAP header blocks as part of the processing of an RPC request or response.

   The dispatching information exists in the body, so wonder how handlers can be used for that purpose at all.

   SOAP message handlers are tied to web service endpoints (either on client or server) and are used to provide additional SOAP message processing facility as an extension to these components.

   The keyword is "additional". Handlers do not provide the core information like which method to dispatch. 

3. Section, Part II, bullet 3 says:
   
   The defect would only show up in interoperability testing.
   
   WS-I Sample Applications does use enumerations and yes, JAX-RPC mapping of enumerations is fully interoperable with other language/platform/operating systems.

4. Section II, Part A, bullet 4 says:
   
   If both client and server are in the UTC time zone all works well, but if either of them are in a different location, hours appear to get added or removed. Clearly a different expectation regarding time processing is at work.

   This is an insidious defect as it is not apparent on any testing which takes place in the same time zone, or between Java implementations. It is only apparent when remote callers, using different platforms, attempt to use the service.
   
   Again, WS-I Sample Applications use xsd:dateTime in their LoggingFacility Web service, and as you expect, it is fully interoperable in spite of multiple time zones, multiple operating systems and multiple languages.

5. Section II, Part A, bullet 6 says:

   We therefore believe that future versions of JAX-RPC will address this problem by way of the annotation facility recently added to the Java language.

   JAX-WS 2.0 is doing exactly that for past one year and this paper was written quite recently only.

6. Section II, Part A, bullet 7 says:

   When a message is received, the serialised form is generated and passed to the handlers for processing.

   I think this statement relies from the assumption that handlers are used for message dispatching. But as I mentioned earlier, that is not the recommended programming model in JAX-RPC 1.1.

7. Section II, Part A, bullet 8 says:

   Any O/X mappings which may exist for data within this piece of the message are now inaccessible: all that is left is the low-level JAXM API.

   I believe this is better than dealing everything in raw XML. And all SAAJ (not JAXM) elements are now accessible as DOM elements so if you really want to play with XML, it's all for you. Rather JAX-RPC 1.1 SI allows you to turn off data binding so that all method parameters are indeed bound to SOAPElement instead of JAX-RPC defined data binding.

8. Section II, Part A, bullet 9 says:
   
   In our opinion, the only sensible approach for working with faults in JAX-RPC is to have services throw pure SOAP faults and leave it to the recipient to process them.

   I agree that Web service developer should have some knowledge of XML, but here we are asking the developer to be intimately familiar with understanding the SOAP fault structure and know the SOAP processing rules regarding faults. In that case who takes care of Basic Profile conformance, the developer ?

9. Section II, Part B talks about long-haul connections and asynchronous communication:

   While this works, it provides the programmer no way to give the user effective feedback or control over the communications. There is no way to receive progress notifications or cancel an active call, despite the face that the underlying transport code invariably permits such features.

   JAX-WS 2.0 introduces client-side asynchrony. Read Doug Kohlert's blog entry for detailed list of new features in JAX-WS 2.0 and a code sample of how to achieve asynchronous communication. It allows a user to poll whether an operation has been completed on the service endpoint and also allow to cancel the execution of the current task as well.

10. Section III, says:

    JAX-RPC makes it harder to write true, interoperable SOAP services.

    I feel that any Web service developed using JAX-RPC is interoperable since interoperability is baked into JAX-RPC specification since JAX-RPC 1.1 requires conformance with WS-I Basic Profile.

    Have a look at the Sun's WS-I Sample Application source code bundled with JWSDP. If you ignore the business logic part of the Web service, I think it's really simple to write a SOAP-based Web service, which by the fact that it is developed using JAX-RPC, is interoperable. In JAX-WS 2.0, this programming model is made really intuitive and further simplified to write a SOAP-based Web service, and of course by the fact it is developed using JAX-WS, is interoperable by default. JAX-WS 2.0 source code repository is available here. Check out Doug's blog on how to check out the repository. Once you check out the repository go to the samples directory and have a look at some of the simple samples. I plan to check in many more samples later this week.

There are many points that I don't like about the "Alpine" proposal but my big ones are

1. Section IV, Part A says:

   If a WSDL/XSD description of an Alpine-hosted service is required, the user will be required to write it

   It's hard to believe the paper expects the developer to understand all the WSDL intricacies and subtleties of XSD. Web services is not meant for the privileged few. I don't think we could have made the progress in Web services if everybody would have been hand editing all their WSDL/XSD.

2. It further says:

   Developers will be expected to use XPath specifications to work with contents of the message

   As if WSDL/XSD was not sufficient, XPath syntax adds to all of it.

3. Who takes care of interoperability with different WS-I profiles ?

I believe, Web services should be for anybody and everybody irrespective of whether they know XML or not. JAX-RPC hides all these plumbing details from you. JAX-WS 2.0 further leverages that to ease the development of a Web service and invoke an already existing one. JAX-WS 2.0 EA2 bits will be available in next few weeks (before JavaOne) with bunch of samples and hopefully you'll enjoy playing with them.

Let me repeat the key message: Production-quality and interoperable JAX-RPC standard implementation is available for past 3 years. We've tested it pretty hard for full compliance with Basic Profile 1.1, Simple SOAP Binding Profile 1.0, Attachment Profile 1.0. JAX-WS 2.0 standard implementation will be available in the next version of Sun Java System Application Server 9.0, expected to go final next year.

JAX-WS is developed as JSR 224 in the Java Community Process and the Expert Group consists of a wide variety of representation from the developer community. They have done their due diligence to produce a feature-loaded, useful and interoperable specification to support XML (and thus a subset, SOAP) Web Services in the Java platform. Why rethink the Java SOAP stack ?