XML Protocols
May 10, 2000
The area of XML protocols is vying with B2B vocabularies for the most heavily press-released topic in XML today. It would have been difficult to miss the recent announcement of SOAP 1.1 by Microsoft, IBM, et al. Yet as Microsoft's Henrik Frystyk Nielsen observed, SOAP is "still only a child protocol." Despite the hype, there is no current official activity within the W3C concentrating on XML protocols.
That may soon change, however. Over the last few months the W3C has been investigating this area, with a view to a possible Activity, which may ultimately lead to a Recommendation. The W3C's announcement explains the rationale:
We've been under pressure from many sources, including the advisory board, to address the threat of fragmentation of and investigate the exciting opportunities in the area of XML protocols. It makes sense to address this now because the technology is still early in its evolution and more resources for development will be available as XSL-FO and XML Schemas near completion.
Since then, the road has not been easy. A public input session at XTech 2000 earlier this year showed that there was a great deal of confusion as to what exactly an "XML protocol" was and what it should do. There was a lurking distrust of SOAP, because of its Microsoft heritage, and little shared vision among participants.
What did emerge from XTech 2000, though, was an impetus to define the problem more clearly, along with existing solutions in that area. Eric Prud'hommeaux of the W3C has been busy since then documenting and describing technologies such as SOAP, XML-RPC, and XMI in a matrix. He has been ably assisted by Ken Macleod, maintainer of several XML protocol software packages, and creator of the Lightweight Protocols home page.
One valuable achievement of Prud'hommeaux and the members of the xml-dist-app mailing list has been the identification of the facets of XML protocol technologies. These include such things as having a serialization format for data types, having a mechanism for machine interface discovery, enabling remote procedure calls, and security provisions. For a full list, refer to the protocol matrix.
Thanks to this activity it would seem that we are some way closer to understanding the problem space. Next week, at the 9th World Wide Web conference in Amsterdam, there will be an "XML Protocols Shakedown" panel discussion. Several points for the agenda have already been raised on the xml-dist-app list, and the discussion is likely to be lively.
SOAP Submission
This week, the SOAP 1.1 specification has been accepted by the W3C as a "Note." Although this implies no endorsement from the W3C, the purpose of the Note would be to act as an input document for a potential W3C Activity.
Coming as it does just before the WWW9 panel, the glare of PR and marketing around the SOAP submission applies some degree of commercial pressure to the XML protocols process.
Not everybody is happy with SOAP, and this isn't just an anti-Microsoft thing. Some people have raised the issue of the potential consequences of messaging and RPC through HTTP on port 80. Larry Masinter summed up some of the issues nicely on the SOAP list, warning of the dangers of transparent proxies on port 80 and the misuse of the http: protocol prefix.
Another questioner of the SOAP approach, Keith Moore, has submitted an Internet Draft, On the use of HTTP as a Substrate for Other Protocols, which explores Masinter's issues and others in detail. Although adding more protocol layers on HTTP is convenient using today's tools (such as Java Server Pages), the implications of this approach merit deeper consideration.
An interesting political factor is that SOAP was originally being pursued as an IETF Internet Draft, but the focus now seems to have shifted to the W3C. There are some who hold the view that the process should be conducted within the IETF, which has a considerable body of experience with protocol design. Although never entirely happy bedfellows, the W3C and IETF do work together in certain areas, such as XML Signatures. Protocols could well be another candidate for a cooperation.
So, although SOAP is causing a lot of excitement in the industry, clearly it's not going to be a "drop-in" solution for the W3C. If a W3C Protocols Activity is commenced, it will likely be a year or so before a Recommendation is issued. What will happen in the meantime? It looks like we're set for a repeat of the schemas scenario, where Microsoft XML tools shipped with their XDR schema solution, with promises to move to XML Schema when it is available.
The Microsoft factor will mean that, now out of the bag, SOAP won't go away in a hurry, W3C and IETF notwithstanding.
Check the Foundations
Various people with knowledge about protocols have already raised the potential issues with HTTP, port 80, and so on. But what about the XML issues? SOAP uses W3C XML Schemas, so that's OK, right?
SOAP is firmly in the XML-for-data camp, rather than the document-centric camp. Whatever your personal position on this, it has consequences for the Web. Point-to-point SOAP communications encourage the hiding of application semantics rather than the promotion of openly specified interfaces. This is, of course, deemed necessary by those wanting a close tie-in to their code, and it also provides a means to protect one's business. However, writ large it may be a retrograde step, eroding the openness won by the XML specification and community at large.
Of more concern are the claims for SOAP's interoperability in a "decentralized, distributed environment." Basing SOAP on XML means there is the expectation that anybody's SOAP implementation will work with anybody else's. Sadly, this isn't true.
The current disparity in basic XML parser interoperability, demonstrated by David Brownell in this week's issue, means that if I send requests from a Xerces-based SOAP implementation to a Microsoft SOAP implementation, I have no solid guarantee of my data being received as I intended (this seems especially likely where non-Western languages are in use). And this is aside from any SOAP-level conformance issues.
We can't afford to keep building layers on top of an infrastructure that is not yet proved sound. Please Microsoft, put effort into ensuring your parser is XML conformant. Please OASIS, expand and revise your work with XML 1.0 conformance testing.
A plea for the W3C as well: at this point we may be seeing some of the defects in the W3C's model of membership (for a fuller discussion of issues surrounding standards bodies, see Liora Alschuler's article this week). The W3C's announcement about embarking on the XML protocols investigation, which I quoted at the top of this article, mentions being "under pressure" to pursue the topic.
Of great import to XML interoperability in general is the concept of "XML packaging," i.e., some way of describing what resources and functionality an XML processor will require to handle an XML document. The absence of this functionality means, for instance, that XML processors are free to either process or not process external parsed entities at will, when not validating. A fuller discussion of these issues is available in Filling in the Gaps, published in April this year.
The W3C has been notably quiet in this area, despite its having been a hot topic for well over a year. It is well known that the W3C has been suffering from resource issues, but if resources are available, then surely this basic infrastructural problem is worthy of attention before higher level applications are pursued. Please, W3C.
In Conclusion
Despite the hype, SOAP is just a beginning. The XML protocols issue is a large and complex one, and if it is to be conducted through standard bodies rather than news wires, it will take some time to resolve.
Most importantly, vendors and standards bodies alike need to refocus their attention on ensuring that the platform on which we all build, XML, is completely sound.