In their "Rethinking the Java SOAP Stack" paper, HP scientists Steve Loughran and Edmund Smith are throwing down the gauntlet. Their intent of creating Alpine, an open-source SOAP stack heavily based on XML, is viable, yet somewhat clumsy. Some opinions have immediately been voiced in favor and against Loughran's and Smith's proposal. Moreover, people like Joseph B. Ottinger and former JAX-RPC partisan Richard Monson-Haefel are not really tender either and recently wrote incendiary blog entries against both JAX-RPC and the Alpine alternative. In order to federate all these discussions, Floyd Marinescu has opened the debate on TSS and is asking for feedback. All this fluff proves one thing for sure: ground-breaking changes are needed urgently!!!

As far as I'm concerned, I'm really skeptikal about people willing to deal that much with XML for getting that kind of job done. Personally, I think that dealing directly with XML is counterproductive in some cases and I like having a 3G programming language like Java or C# doing all the XML chores for me. It's not that I don't know XML. In the contrary, I know XML too well for realizing that I don't want to have to deal with it directly all the time. Most of the paper is centered around the fact that the Object-to-XML (O/X) mapping is not a trivial task. This is undeniable and I do agree with that (the development of JSR 31 took more than three years to complete). As a side note, the WATER folks think they have THE solution with their WATER language, which is some kind of XML programming language (or so they think). In adequation with the official XML goals, I have never been of the opinion that XML has been designed for becoming a programming language and when I see horrible things like this I'm even more convinced. Side note closed. The bottom line is that XML is becoming more and more complex everyday with the 100+ specifications out there and simplifications are much desired.

One of the greatest omissions in this paper is the lack of reference to the freshly rebaptized JAX-WS (ex JAX-RPC 2.0) specification, which has been jointly developed with JAXB 2.0 and whose goal is to drastically ease the development of Java web services. It is worth pointing out that Loughran recently gave in that they lacked experience with the new specification, and thus, didn't want to comment on it. As JAX-WS spec co-lead Marc Hadley legitimately pointed out in his blog:

However the JAX-WS EG recognized that in some (or many, depending on your perspective) cases working at the XML layer is useful/desirable and so we added a couple of XML-centric APIs that completely bypass the XML<->Object layer of the stack: Dispatch and Provider.
Dispatch is the client side API and uses the generic functionality introduced in J2SE 5.0 to offer an API that allows the developer to choose their abstraction. Developers can work with entire messages or message payloads either using XML APIs or using pre-cooked JAXB classes.

What this says to me is that JAX-WS already fulfills Alpine's first design goal, which is to "Stay in the XML space as much as possible", while still giving developers the choice to switch to Java binding solutions whenever they feel the need to. When you come to think about it, this is a very flexible approach. As everyone knows, there is no silver bullet, any problem can be solved both efficiently and inefficiently, and thus, it is up to the developer to decide whether XML is more appropriate than Java binding for solving the problem at hand. JAX-RPC 1.1 was on one extreme where Java binding and tons of other bad stuff were required. Alpine goes on the other extreme in that it only allows developers to work on the XML layer. And now, JAX-WS bridges the two approaches by letting the developers choose which solution is best for them in a given context. In my opinion, giving the developers the responsibility of choosing which solution is the most appropriate is a very good thing. Moreover, it requires the developers to really think about what they are doing instead of simply relying on the underlying tools generating the not-always-that-efficient plumbing code.

Another claim the authors make is that basically WSDL is too complicated to use. This was true for WSDL 1.1. However, WSDL 2.0 is not far away with its load of improvements and novelties. Moreover, by using annotations from JSR 181: Web Services Metadata for the Java^TM Platform, such as the golden @WebService, web services developers will have much more power over the WSDL generation process. Just have a look at Frank Sommers' Three Minutes to a Web Service and Recent JDK Features Ease Web Service Development articles on Artima.com to get a feel of how easy it will be to develop web services.

Another great improvement that JAX-WS will provide is the support for client-side asynchronous operations using the Java 5 Concurrency API Future interface. This interface should help Steve and Edmund take care of their multi-megabyte CAD file transfer issues ;)

No hard feelings guys :) Just remember that everything is neither black nor white, there is always a gray shade solution inbetween that will solve your problem.