Steve Loughran on JAX-RPC and SOAP

>Especially important is the observation that the POX/REST/AJAX crowd are just as susceptible to the O/X problems of JAXB and friends as SOAP is

The Object<->XML problems come from the complexity of WSDL and XSD. So far I haven't seen any POX/REST applications that make the mistake of burdening themselves with WSDL/XSD. When it comes to AJAX, I've seen a bunch that don't even communicate with XML (they use JSON instead) let alone adding the complexity of WSDL/XSD.

Dare,

If a POX or REST endpoint exposed an XML schema, what would happen?

Would Java programmers ignore it, or would they point their JAXB importer at it and wind up more or less where the JAXRPC-ers are at?

DB

yeah, if you use JAXB or castor to go from XML to Java classes, you end with something just as brittle.

I think the difference is there is no vendor of REST systems that says "write your native classes, we will export them as RESTy things". Which is exactly what both our first generations of mainstream SOAP stacks said. As blackadder says, "the plan had one tiny flaw; it was bollocks"

I didnt lay into XSD or WSDL in the paper; Ed pushed me away from it. They are the biggest barriers to interface-first design, IMO. And with Alpine, you'd have to understand the XML at the far end too.

This paper attempts to throw the bathwater out and save the baby, but it is unsure of which is which. XML parsing within C# or Java code is a difficult, error-prone process that yields unsightly code. Its absurd to deny these powerful languages the ability to map XML messages into their native type systems. Serialization is the closest thing we have to an ability to #include an XML schema definition into our code. Once we can do that, we get two enormous benefits: compile time assistance in XML parsing, and Intellisense / auto-complete at code creation time. Next to these gains, we have to pay the minor price of adding a few constraints to our XML schema design.

The baby is an interoperable way to exchange strongly-typed well defined messages across language, system, and network boundaries. The bathwater is the incredible and needelss complexity of the XML-Schema / WSDL stack and the inability of the distributed systems developers to reign in the XML document-centric-semantic-web-wannabe-architecture types.

I'm taking a break from the Day Job task of summarizing WebData XML's experiences with XML Schema for...

Don Box hints that type system convergence and dynamic type support may be coming to a .Net langauge near you.

Now, why'd you have to go and ruin a perfectly good post with that hippie crap at the end?

That the problem of working with XML in languages goes beyond SOAP is indeed an important point. I wonder, however, if the problem isn't in the languages, but instead in XML itself. The Infoset is a complex and unwieldy beast, as evidenced by even the W3C's reluctance to centre itself on one data model for XML. Perhaps something simpler is needed?

More heresies:
http://www.mnot.net/blog/2004/05/12/on_infosets
http://www.mnot.net/blog/2004/05/28/other_data_models
http://www.mnot.net/blog/2004/08/05/document_oriented
http://www.mnot.net/blog/2005/03/02/decision_tree

P.S. Comments in your blog are underlined, at least in Safari; it makes them very hard to read.

Sorry. Wasn't impressed with their paper. Haven't they read: "Using String to Represent an XML Document in a Service Interface", by Sean Brydon, Smitha Kangath, Sameer Tyagi. Whatever happened to KISS?

Also, having used Axis extensively over the last few months their knowledge of it seems weak.

James -

Using string; you mean escaping the XML document? We call that a failure mode of an XML messaging protocol. I used to base-64 encode XML payloads in XMLRPC four years ago, but the world has moved on.

The key way the world has moved on is all those little soap headers written by other people. If you want to integrate with all those specs, you can't go to every WS-* standards group and say "please inline your header as a string". No, you need an easy way to extract WS-A info, WS-RF operations, whatever. And you need a better way of signalling faults than JAX-RPC, at least if the service stands a chance of failing.

Finally, on the comment that we have weak knowledge of Axis. I know I have not been an active committer on the project for a few months, but I think you will find my fingerprints in lots of the codebase, from the servlet chain and the fault handling to happyaxis.jsp.

Maybe, and I hesitate to say this, your own knowledge of it could be improved. Examine, for example the implementation class MessageElement, underpinnings of everything.Perhaps then you would understand the rationale of the paper better.

Steve - Don’t hesitate :-) I didn't mean to offend. So accept my apologies if I did. Glad to get your feedback though.

Base 64? No. that's not what I meant, nor IMO the reference. Basically the concept is to pretty much extract the XSD out of the XML. Such that, in the WSDL, the operation takes a simple string type. However, what's getting passed in as the string is in fact a more specific / complicated type defined in an external XSD.

It's a cheat - controlling the frameworks deserialisation like this - but it just makes things simpler / easier. In that it enables you to do validation in the pivot meaning you can cache the XSD's grammar. Meaning you get a faster throughput becouse, at least to me, it looks like the handlers in the Axis chain get created for each request. Not only do you get a faster throughput but you also get 'nicer' validation failure messages rather than those thrown (and injected straight out) from the deserializer's for when stuff that breaks the XSD comes in.

As a committer hopefully you could contradict me. But I found the Axis handler chain a cool idea in concept but not practical in reality for a moderately high throughput service that needs to do 'meaningful' incoming / outgoing validation.

I could also rant and rave on about the crap that Axis's wsdl2java is, perhaps uniquely, capable of generating for perfectly valid (at least to other tools - including .Net's wsdl.exe) WSDL - but as a committer you'll know all about that as well. Sorry, that's just me being bitter!

I don't know Dylan well enough to quote him, and others in this thread, why can't things be simpler? At least with the approach outlined above I can some way control the deserialisation and do things I want rather than what the framework – be it SOAP or AXIS - wants.

James, I've had this argument many times - passing the XML as a string is an attempt at a solution that shows a lack of understanding of the problem.

Sorry, that merits some elaboration. Essentially, the main argument is that the programming model of one of your communication parties - regardless of whether it's the client/consumer or server/provider - should *never* have any influence on the contract. These are two totally different issues. If you have to change the contract to achieve loose coupling, your programming model still sucks.

I would not base any architectural decision such as "escape XML to a string" based on your bad experience with AXIS - find better (and simpler) toolkit and make contracts (WSDL mainly) simple ...

<a href="http://radio.javaranch.com/val/2005/06/08/1118236863771.html">HP's "Rethinking the Java SOAP stack" should be rethought</a>

So who makes Alpine? Does HP make Alpine? I just am wondering if the authors have a conflict of interest with denoucing JAX-RPC in favor of something that they are trying to promote.

Alpine is not a product; its more of a philosophy "alpine-style" as opposed to himalalayan style (ask a mountaineer). There is a very raw prototype hosted on sourceforge under the smartfrog project, exploring how much effort it really takes to do a XML-centric SOAP stack. The answer is: not much, but you do force the developers to work with your object model at the far end, and in the Java-era languages, that's pretty painful.

Do I have a conflict of interest? No, I just think that JAXRPC and JAX-WS are mistakes. If there was something better that I didnt have to code and test myself, I'd use it.