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
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.