Climb every mountain?

I finally got around to reading the paper on Alpine, "Rethinking the Java SOAP Stack", by Steve Loughran and Edmund Smith of HP Labs.

It offers a rather scathing critique of JAX-RPC and JAX-M with regards their suitability as programming models for Web services. I happen to agree with much of their critique.

From the abstract:

This paper examines the current SOAP APIs in Java, and in particular the Java API for XML-based RPC, commonly known as JAX-RPC, which is effectively the standard API for SOAP on the Java platform. We claim that JAX-RPC, and indeed any SOAP API that relies upon a perfect twoway mapping between XML data and native language objects is fundamentally flawed. Furthermore, we claim that the attempt JAX-RPC makes to extend the remote method invocation metaphor to SOAP services is counterproductive.

We base our argument both upon experience with JAX-RPC and SOAP, and upon experience of previous distributed computing technologies. We argue that JAX-RPC is not capable of delivering on the SOAP design goals, but conclude by suggesting an alternate system, Alpine, which is free from many known flaws of existing systems, and should prove better able to deliver upon the promise of SOAP.

The authors propose development of a new SOAP stack, one that avoids the mistakes made in the development of the JAX-RPC and JAX-M APIs that has the following design goals:

1. Stay in the XML space as much as possible.
2. Take advantage of as much leading edge infrastructure
   as we can.
3. Adopt the the handler chain pattern of Axis/JAX-RPC.
4. Target SOAP 1.2 (POST) only, WS-I Basic Profile 1.1
5. Document/literal mssages only, not RPC/encoded.
6. Support XSD and Relax NG schemas.
7. Run server-side, client-side, and as an intermediary.
8. No support for JAX-RPC or JAX-M/SAAJ APIs.
9. Configurable procedurally, through the Java Management
   API (JMX).
10. Permit dynamic handler chain configuration during message
    processing.
11. One supported parser.
12. Run on Java 1.5 and later.
13. No provision of side features such as a built in HTTP
    server, or a declarative configuration mechanism. These
    are delegated to other products.

They conclude the design goals section with:

We believe the core of this design is likely to resemble
JAX-M/SAAJ in in terms of classes, integrated with a handler
chain based on the JAX-RPC/Axis model.

This is about right, although I do have a few nits to pick with their choices of design goals.

• Targetting only SOAP1.2 may be a mistake, as most SOAP stacks support SOAP1.1, not SOAP1.2. This state of affairs is likely to remain the case until WSDL2.0 is completed and vendors start to fold the two into their products. Fortunately, the differences between SOAP1.1 (as profiled by the WS-I Basic Profile) and SOAP1.2 are nearly inconsequential. It should be a trivial matter to support both.
• Support for only the HTTP POST binding is a mistake, IMO. I would dearly like to see support for the HTTP GET binding as defined for SOAP1.2 as I think that that opens up a wealth of potential. Furthermore, I would like to see support not only for HTTP GET retrieving SOAP, but also for HTTP GET and POST that return POX (plain old XML) ala XMLHttpRequest.
• I'm curious as to how they reconcile support for both XSD and RelaxNG with the other design goal that they will support a single parser. Frankly, I am not sure that I understand where they are coming from here. Maybe they have in mind use of Sun's MSV to translate XSD into RelaxNG?
• Finally, what about support for MTOM/XOP and/or SwA? I would think it a mistake not to provide support for attachments. Since both are MIME-based, it should be fairly straight forward to support both. MTOM/XOP support could be effected via a handler. Other attachments support could be effected via a URI resolver that was aware of the MIME package.

Overall though, I think that this project will be very interesting to follow.