It’s the XML, Stupid!

In the early days of SOAP and WSDL, while doing the conference rounds I would often be asked, “What’s the most important thing about Web services?” I would always say “XML, XML, and XML.”
Not everyone agrees with me, but this very fundamental question has recently come up again in the important new paper about the shortcomings of JAX-RPC and other related topics. (If you haven’t read it yet I strongly encourage you to do so.) One of the authors, Edmund Smith, elaborated on some of the thinking behind the article in this interview posted yesterday.
Edmund is correct that it is not as convenient for programmers to deal with the XML as a separate and distinct language but this is inevitably the right approach. It may seem like a benefit to view XML entirely through a Java (or any other language) filter, using native data types and generated classes, but the XML is what’s important, not the Java code that processes it.
The world has changed, get over it!
A sea of virtual ink has been spilled in the blogosphere over this debate and a related debate about the suitability of WSDL for a description language. The complaint in this area seems to be more about tool support of WSDL and how classes and objects are generated from it rather than about WSDL itself (which is, after all, just XML).
Don Box is among those who have reinforced the main thrust of the article, adding that the problem needs to be fixed at the endpoints.
A lot is said about endpoints, and moving integration logic toward the endpoints away from the hub is indeed the correct direction. But what is an endpoint? It’s an application to which a bit of code has been added that understands XML, and how to map (or transform) the XML into and out of it. It is not an application server, EAI broker, or even a Web server.
Tim Ewald who is listed in the paper’s acknowledgements as one of the paper’s reviewers, adds the point that unless Java gets its treatment of XML right, other languages are likely to come to the fore. It’s already happening.
To see where things seem to go wrong, let’s start with the definition of a Web service. It’s the action of sending an XML document to a receiving system that understands how to parse the XML and map it to an underlying execution environment, and optionally receiving a reply, also in the form of an XML document.
I don’t usually tend to quote myself, but on page 2 of Understanding Web Services, I say that:

Web services are Extensible Markup Language (XML) applications mapped to programs, objects, or databases or to comprehensive business functions. Using an XML document created in the form of a message, a program sends a request to a Web service across the network, and, optionally, recieves a reply, also in the form of an XML document.

On page 11 I introduce the RPC-oriented and document-oriented interaction styles found in SOAP and WSDL. Originally I had placed these in the reverse order, that is, I wanted to explain document oriented Web services first, because the technology is a much better fit to asynchronous messaging systems than it is to RPC based systems. One of the manuscript reviewers pointed out that the RPC oriented style is more popular, and therefore I should explain it first. I said ok but in retrospect I shouldn’t have. The document oriented style is much more important, and my acquiescence has probably added to the confusion.
In the couple of years I spent as an editor of the W3C Web services architecture specification the working group spent a lot of time discussing the definition of a Web service. In the end we produced something that I would characterize as vaguely interesting but not really that useful (at least not as the independent, industry-wide definition of a Web service and its associated architecture I was hoping we’d produce).
One thing I managed to gain consensus on however was separating the concept of the Web service from its execution, as in Section 1.4.1:

A Web service is an abstract notion that must be implemented by a concrete agent.
. . . The agent is the concrete piece of software or hardware that
sends and receives messages, while the service is the resource characterized
by the abstract set of functionality that is provided. To illustrate this
distinction, you might implement a particular Web service using one agent one
day (perhaps written in one programming language), and a different agent the
next day (perhaps written in a different programming language) with the same
functionality. Although the agent may have changed, the Web service remains
the same.

In other words, the XML applications comprising a Web service exist independently from any programming language that processes them. A Web service must exist independently of any programming language’s view of it. If It didn’t, we would not achieve the benefit of universal interoperability. And they are not RPCs, despite the fact that it is possible to represent and interpret an XML document as an RPC signature.
As the simplest and most abstract form of Web services, the document oriented style has the advantage of preserving more of the characteristics of XML that make it so helpful – namely its independence from any one particular programming language and it’s unique type system. Because XML can be used as an independent data type system, it can be used to solve one of the biggest problems in integration and interoperabilty, data type compatibilty.
Of course those of you working to transparently map XML data types to language specific data types will no doubt mention how hard this is (reference again the “Rethinking” paper for why it isn’t a good idea in the first place). But again this is missing the point of XML. And of course the early interop tests from SOAPBuilders (some of the result links at the bottom of the page are still valid) showed that the more complex the data types, the harder interoperability is to achieve, especially for the RPC style.
The document oriented style is more abstract and preserves the most important characteristics of XML, meaning that although it take a bit more effort to deal with, the benefits of doing so are proportionately greater as well.
Don’t get me wrong about JAX-RPC. We support JAX-RPC in our products and it is a useful spec, especially for the Java to XML mappings it provides. And it looks like the next version will be a big improvement.
But until the whole industry learns that document oriented Web services are where it’s at, we will continue to struggle to achieve the value of Web services, and we will continue to wrestle with fundamentally unresolvable incompatibilities with existing RPC technologies.
Nor can I accept the REST proposition of fixed interfaces as the solution since I need to know what program or queue to hand the XML message to for processing when I recieve it. That’s part of the definition of a Web service, that the endpoint knows how to find the program the data maps into and out of, and you need a custom interface (or queue) name to do it effeciently.
And yes, WSDL is hard to read and understand. It was really the hardest chapter to write, and I’m still not sure I got it right. But WSDL is not really broken, either (except for the include function I guess). It can stand some improvement, but it is doing the job.
WSDL is (like a SOAP message) XML. And you can parse XML. You can transform XML. You can interpret XML and aggregate XML and split up XML, and of course process only what you can understand (and if there’s something you don’t understand just ignore it).
The whole thing really has to start and end with the XML, not the Java or the C# or the Perl or the Python or the COBOL, SQL, or whatever. Until we all learn this we are going to continue to endure these endless debates.

Advertisements

10 responses to “It’s the XML, Stupid!

  1. Eric, nice essay. Since 2001 when I was working on early Web services platform technology (then at HP), I was frustrated by the fact that SOAP toolkits were trying so hard to be like, well, CORBA. HP SOAP (kinda ironic) was a good example of this, as was Apache SOAP, JAX-RPC, etc.
    The paper is a bit dated. The JAX-RPC group has tried to make some progress in this direction, as came up in a recent serverside thread (http://www.theserverside.com/news/thread.tss?thread_id=34579). The trouble with XML in Java, .NET, etc. is that its suboptimal to work with directly as a programmer. Perhaps work like E4X will lead to a more manageable model for programming XML? That seems to be what we need most these days.
    Greg

  2. “Nor can I accept the REST proposition of fixed interfaces as the solution since I need to know what program or queue to hand the XML message to for processing when I recieve it. That’s part of the definition of a Web service, that the endpoint knows how to find the program the data maps into and out of, and you need a custom interface (or queue) name to do it effeciently.”
    Yes, the endpoint definitely has to know which program to pass the document to, but that’s fixed before you get started in part of the process of “putting your app on the Web”. A single backend program may require multiple endpoints, each with its own URI. For example when putting a monolithic banking app on the Web, it might export one URI per bank account.
    Anyhow, for that to work, you don’t need a specific interface, even to be efficient. You just need to provide the client sufficient information in order to decide which URI a document should be sent to. For example; &ltbank:BankAccount xlink:href=”http://mybank.example.org/acct/2394839434/”>

  3. Totally agree with you Eric. I wrote an article on this matter for Business Integration Journal (see http://www.bijonline.com/Article.asp?ArticleID=1149&DepartmentId=9), pointing out that RPC style does not fit with the service oriented paradigm which is becoming mainstream. Of course the same goes for REST services.
    I think that future proof web services are document style in general, comply with the WS-I spec and use a message router pattern to allow for overloading and router of different messages.

  4. I think that that one of the reasons we’re in this sorry state is that designers start from the premise that XML Web Services were simply CORBA/DCOM/DCE/RMI “in the wide”. I think: it’s a document – stupid! is a fair assessment of the approach they don’t take and it’s a shame most of the more popular vendors today don’t take a step back and re-evaluate.
    I also think that most of the problems we’re seeing with JAX-WS (which are continuations of problems we’ve seen over the years) are similar to those we saw in the heyday of CORBA: people taking the “individual object as endpoint” approach. If you go that route, you inevitably end up trying to push the language/deployment architecture down into the communication architecture, which is bad on so many different levels. What’s at the endpoints shouldn’t matter. We eventually got that story across in CORBA, but we’re nowhere near that point yet in Web Services.
    To be honest, if you want to implement RPC-style distributed systems that simply exchange XML, then you may as well use CORBA or RMI. It’s faster and more efficient, since the XML processing takes place where it needs to: at the application level.
    BTW, I’ve said before, but I think that the other “most important” thing about Web Services is universal adoption because of HTTP. Now I know you can have Web Services that don’t use HTTP, but I think because that was the initial carrier binding, it really helped to move things along in terms of adoption.

  5. Loek,
    “Of course the same [MB: that they’re unsuitable] goes for REST services. I think that future proof web services are document style in general”
    Those two statements are in direct contradiction. You can’t get any more “document style” than REST.

  6. Mark is right that REST is completely document oriented. In fact you could say that the purpose of REST is to exchange documents between points on the network and represent in those documents the results of any state changes.
    I think the real bone of contention between REST and Web services (Mark please correct me if I’m wrong) is the inclusion of non-application state in the XML. In particular the SOAP header part of the XML document format is the problem since it contains things like the address and the associated action (i.e. dispatch point for the service) whereas in REST the XML is meant to contain application level information only.
    This is another old debate in messaging, of course, as to whether the message should contain metadata about the message, or whether that metadata should be associated in some other way with the message (e.g. in Mark’s comment the URL). On the Internet it’s not possible (or practical I should say) to associate metadata with the message so it has to go inside it.
    So for this reason things like a transaction context, security context, reliability context etc. can’t go into a REST document. REST documents are obviously much simpler because of that, but developers don’t get as much helpful information in a standardized format.

  7. Hi Eric. Hmm, well I don’t think that’s a problem in the general case; SOAP headers are fine and their use needn’t break REST or HTTP. It all depends what use is made of that data. For example, the use of a header like wsa:Action is not RESTful because it turns a document exchange into a procedure invocation. Similarly, as you say there, if some string is placed in the header in such a way that it references some data, and the meaning of the message depends on that data (rather than just depending on the string), then that’s not RESTful since it’s stateful, not stateless. REST places other restrictions on the use of headers too via its layering constraint. But most of the usual header examples you see are fine by REST. For example, routing, reply-to, security, encryption, etc..
    FWIW though, I believe you *can* be document oriented while using stateful messaging. But I don’t think you can be document oriented while using custom application interfaces.

  8. Mark, Eric, poor phrasing in my first comment, the point I was trying to make is that i.m.o. REST web services have little value in a service oriented scenario.

  9. WSDL 1.1 Service Description Comparison for SOAP Finishing Up

  10. WSDL 1.1 Service Description Comparison for SOAP Finishing Up