Very interesting paper from Steve Loughran about Alpine, his propoal for a Java SOAP stack to replace JAX-RPC.
It's very interesting to look at the design direction they're taking this stack. It's fundamentally a shove-the-angle-brackets-in-your-face sort of thing:
If Alpine succeeds, it will be a SOAP stack that requires an understanding of XML before it can be used. This might appear to be a barrier to the widespread adoption of the tool, and perhaps it will prove so. Unlike commercial SOAP vendors, we have no financial incentive to make our product broadly usable. We will, however, have a SOAP implementation which all its users should be able to understand and maintain. Furthermore, we believe that a good understanding of XML is needed to develop any robust web service, and that by forcing developers to acquire that skill early on in the development process, we help them avoid being forced to learn it just before their shipping deadlines are missed.
That's a very interesting position to take. On one hand, it's a very purist approach to building services. And it does allow them to sidestep some of the harder (but by no means impossible) problems in XML serialization (or O/X mapping or whatever you want to call it). But as someone who as an implicit interest in broad adoption, I hope there's a middle ground between the "no XML at all" and "XML-in-your-face" approaches.
Steve raises a lot of very good points in Section II of his document - a lot of which are about solving the XSD/Object impedence mismatch. These are not unique to Java. In fact, Indigo ran up against most of these issues as well. Problem is, even though our Data Contract system is a purely XSD-based solution, there's no Java solution out there that understands the semantics of the schemas we use to solve them. This makes it hard to talk to folks...
However, Doug Purdy is blogging about how Indigo tackled these problems here and here...
