Shaken, But Not That Stirred

The panel, chaired by Dan Connolly (XML Activity Lead, W3C), consisted of some of the main protagonists in the XML protocols arena, including authors and implementors of SOAP and XML-RPC. Connolly introduced the panel session by noting the submission to the W3C of several XML protocol specifications as Notes (including ICE and SOAP1.1), and mentioning that there was a feeling that there may be scope for a standardization process in this area.

The SOAP 1.1 submission certainly brought with it a higher level of vendor consensus than we have seen before -- six companies adding their names to those of author companies Microsoft, IBM, DevelopMentor, and UserLand. The 1.1 revision, separating out the data encoding from the RPC, has even penetrated the skeptical firewall of Sun Microsystems. While not endorsing SOAP, Sun appears at least to be able to live with the most recent version.

For the most part, the panel served as a useful summary of the positions expressed over recent weeks on the xml-dist-app mailing list.

Goals

The W3C has a diverse membership, and understanding the perspectives of the member companies sheds some light on their positions with regard to XML protocols, and SOAP in particular. Some companies--notably Sun--come from a more enterprise-based angle, concerned about scalability and issues such as latency. Other companies, coming from the PC world (UserLand Software, and to a certain extent, Microsoft), are concerned more with application and operating system integration, using XML-over-HTTP to achieve this over the Internet.

It is not at all clear that there is agreement on the goals of an XML protocols activity. While the encoding aspects of the SOAP proposal received broad approbation, the notion that RPC should be a key part of an XML protocol was the subject of much disagreement. The RPC approach, advocated by UserLand Software (an enthusiastic deployer of XML-RPC), has too many shortcomings to satisfy the broader requirements of many other companies. Issues such as network latency and risk of lock-in were raised by panel members.

Noah Mendelsohn, representing Lotus and IBM, highlighted the tensions within this area. At one end of the spectrum, an application might simply want to fetch a stock-quote, while at the other end lay high-volume robust e-commerce applications. Analyzing the situation, he advocated that the W3C should seek to provide a common infrastructure that would support the construction of solutions to both these requirements. At the basic level, what is required is an enveloping and encoding solution, which applications can then build on top of. RPC-only approaches seem to close down these options too early. Ken Macleod, an independent consultant and implementor of lightweight protocols, agreed that the generic enveloping and encoding scheme proposed by SOAP was a good thing. He observed that the infrastructure provided by current line-based interchanges (FTP, HTTP, SMTP, etc.) was not really expressive enough, and a structured container for protocol exchanges would be of benefit.

Both Sun and IBM indicated that a lightweight XML protocol only solved certain problems, and did not provide the complete infrastructure that industrial-strength electronic business required. Both these companies are participants in the ebXML initiative, which will address these higher level concerns. There seemed to be a certain amount of optimism that a lightweight XML protocol might form the substrate upon which more heavyweight machinery could be built.

Alan Kotok's report from the recent ebXML meeting, published in XML.com this week, shows that SOAP 1.1 hasn't been actively considered yet by the ebXML transport, routing, and packaging team, but it must surely be a good candidate for a foundation layer. It is to be expected that SOAP will form a key part of Microsoft's BizTalk systems.

Microsoft's Henrik Frystk Nielsen, referring to the RPC argument, noted that a programming model wasn't the issue at hand, but that a Web-like enabling technology was required--one that would enable programmers to add on modules, and use it for what they want. He took the view that drawn-out standardization and invention processes (surely not a reference to ebXML?) placed unnecessary barriers to innovation for developers who wanted to create new distributed applications. However, the contention of the XML protocol conservatives is that it's precisely this freedom--familiar to those who have programmed in a PC environment--that allows many bad things as well as good creations to happen.

Declarative Approach Should Be Preserved

Henry Thompson, co-editor of the XML Schema specification, provided an alternative view on the problem. He presented an idea for business exchanges conducted via two connected monologues where instead of exchanging messages, the participants updated documents which the other party read. While his idea was admittedly purely in the research stage, it served as a useful platform to remind us that preserving the declarative and self-describing nature of machine-to-machine exchanges was important. This helps avoid proprietary lock-in and poor design.

Encouraging lock-in and fragmentation was an accusation leveled at the RPC approach to XML protocols -- vendor A will invent their API and all subsequent vendors must either conform or reinvent. However, it is equally a danger even if RPC is not considered. The temptation presented by the serialization model of SOAP is for developers simply to take the literal serialization of their internal data structures as their message format. This drives application semantics into the processing application and out of the public gaze.

Such points again reinforce that, for general inter-enterprise exchanges, a lightweight XML protocol is not enough, and requires the addition of higher-level constraints. Where such a protocol is sufficient, though, is in application integration for private applications communicating over the Internet (an example of this sufficiency is UserLand's web site editing system, Manila & Pike, where the editor application retrieves content from a remote web site using XML-RPC).

However, HTTP-enabling hitherto machine- or LAN-bound applications is one of the factors giving rise to security worries with XML protocols. Although there is nothing inherently insecure about the SOAP or XML-RPC specifications, neither is there any security baseline or implementation recommendations. Such matters would be left to implementors. While it can be argued that the protocols are no more or less secure than CGI scripts, the expected deployment of XML protocols is much more pervasive than that of CGIs. Nobody ritually exposes their entire applications to the world at large through the Web, but careless integration of SOAP or XML-RPC could do just that.

SOAP Still the Front Runner

How They Stand on SOAP Microsoft: Enthusiastic promoters of SOAP from the start. Expected to base their next generation Windows architecture on XML and SOAP technology. IBM: Joined as co-authors in most recent draft. Have already made a freely available SOAP implementation, which is expected to be donated to the open-source Apache XML project. Also involved in ebXML. Pragmatists. Sun: Not overly enthusiastic about SOAP, but will selectively deploy it and donate programmer time to support IBM in an open-source SOAP effort. Pushing ebXML as a more robust alternative in serious e-commerce situations.

So, now that the arguments have been thoroughly rehearsed by the concerned parties, where do we stand? Microsoft is still pressing ahead with their SOAP deployment, the technology likely to find its way deep into their new products. Thus, anyone wanting to communicate with their systems will find SOAP an irresistible force. At a higher level, the ebXML effort is expected to deliver a more wide-ranging solution to meet the needs of electronic business, but not for at least 12 months. If the W3C were to undertake an activity on XML protocols, it is highly likely they would take that amount of time (or more) as well. The W3C Advisory Committee meets this week and will probably make a recommendation as to whether the W3C should pursue the issue.

SOAP is definitely here for the short and medium term, regardless of any other activity undertaken by standards bodies. The many issues of security, scalability, and interoperability remain to be discovered by implementors.

As with XML schemas a year or so ago, there's no "silver bullet" solution from Day One. There are several existing protocols that you can choose from, and ultimately there will be some consolidation--either by standardization, or by market forces.