ebXML Ropes in SOAP

SOAP in a Nutshell

SOAP provides a simple and lightweight method for exchanging structured data. It defines the message package, offers encoding guidelines for data used in applications connected by these messages, and provides rules for representing remote procedure calls (RPCs), a type of online interaction in a distributed environment. The authors (from Microsoft Corp., IBM and its Lotus Development subsidiary, DevelopMentor, and Userland Software) submitted version 1.1 of SOAP to the W3C as a Note in May 2000.

SOAP's importance extends beyond its definition of an XML-based message protocol. Several other e-business specifications based on XML -- most notably BizTalk and Universal Description, Discovery and Integration (UDDI) -- use SOAP for its messaging functions.

SOAP messages are XML documents defined in a mandatory SOAP envelope. Within the envelope are a SOAP header and body. SOAP messages must have a body, but the header is not required in all instances. The XML namespace, http://schemas.xmlsoap.org/soap/envelope/ is used for the envelope. Namespaces allow access of multiple document type definitions (DTDs) or schemas in an XML document by providing a unique prefix that prevents duplication of element or attribute names.

The SOAP envelope serves as the first element in the document and thus identifies it as a SOAP message. The SOAP body contains the information transmitted to the receiver. Each message must have a body, so there cannot be an empty SOAP message. If the message has a SOAP header, it appears as the first child element in the envelope, and before the body.

The SOAP header allows the sender to add management or control information in the message, important for routing, security, or proper handling by the recipient. This element has very few rules of its own, but relies on XML namespaces identified by the sender for its semantics.

Reversing an Earlier Decision

Including SOAP in the messaging specifications reversed an earlier decision by the ebXML messaging project team to develop its own message structure. The team had originally proposed an enveloping format combining Multipurpose Internet Mail Extensions (MIME) for the overall message envelope as well as header and body containers. In the original plan, the header container written in MIME would have XML data providing identification and description of the message.

At the August 2000 ebXML meeting in San Jose, California, Rik Drummond of The Drummond Group and chair of the ebXML Transport-Routing-Packaging (messaging) project team, announced the results of its review of SOAP. The review predicted that with the high production volumes often encountered in e-business, SOAP's all-XML messaging could overwhelm most XML validators. On the other hand, the combination of MIME and XML headers proposed for ebXML messaging would likely provide more robust support. (See ebXML: Assembling the Rubik's Cube, XML.Com, 16 August 2000).

SOAP in its original form also did not support non-XML attachments. Some e-business messages, however, will carry non-XML binary files, such as digitized engineering drawings or patient X-rays. The messaging project team recommended the MIME multipart/related media type for the overall ebXML envelope in part for its ability to attach these binary files.

At the Data Interchange Standards Association (DISA) e-business conference on 8 March, Drummond explained some of the reasons for this change in outlook about SOAP, and he gave a high-level view of how the pieces would fit together. He noted that new enhancements to SOAP, including the addition of MIME support, helped meet ebXML requirements, specifically the SOAP With Attachments specification. This document, submitted to the W3C as a Note in December 2000, defines a SOAP package that combines the SOAP 1.1 message with a MIME envelope to include direct attachments or references.

This combination of SOAP messaging in XML and MIME allowed the ebXML messaging team to specify an outside MIME envelope and subsidiary MIME parts for header and body containers. At the DISA conference, Drummond illustrated how it would work.

• The ebXML header container consists of a SOAP message with a SOAP header and SOAP body. The SOAP header includes the traditional functions found in business message headers, such as identification of the parties to the transaction (sender, receiver, copies).
• The SOAP body -- still within the overall message header container -- carries data cataloging the message contents, which is called a manifest in ebXML parlance.
• The ebXML body container carries the payload that can be in XML or any other digitized format.

Intellectual property issues

EbXML faced more than just technical issues with SOAP. A key property of ebXML often cited by its supporters is its openness, both in its development process and its promise to make its documents freely available. For example, the ebXML requirements specification issued in May 2000 includes the following under its general business requirements:

• An open development process with no barriers to entry
• Open, readily accessible, perpetually free technical specifications and standards

SOAP, on the other hand, is a product of a small group of vendors. Representatives of four companies developed SOAP, and while other companies have endorsed it, SOAP was not the product of an open consensus-based process required for accredited standards.

Licensing restrictions imposed by the original developers also opened issues that appear to conflict with these requirements. On 8 March, Microsoft and IBM issued statements clarifying the intellectual property issues on SOAP 1.1 and SOAP With Attachments that ebXML relayed in a press announcement. Microsoft said it will grant a license to the intellectual property rights for these specifications but only for the purpose of compliance with the specifications. The company also issued a disclaimer that users accepted the specifications as-is and would not be subject to actions resulting from consequences of their use. IBM issued a shorter statement granting a non-exclusive license to its intellectual property in SOAP upon written request.

End game strategy for ebXML emerges

The technical architecture specifications approved by the ebXML plenary at its mid-February meeting in Vancouver, Canada, provide a technical map for the other ebXML project teams in developing the details of the technology. The document also provides a look ahead into the end game for the initiative.

Part of that strategy includes the critical ebXML registry specifications. Companies will have most of their early encounters with ebXML through the registries, as companies download business processes, list their capabilities to conduct e-business, and search for potential trading partners. At the same time as the release of the messaging specifications, ebXML also released for review two draft specifications for registries: one for the registry services and the other for the registry information model. The registry services document spells out the functions and operations of ebXML registries, while the information model details how registries organize and index the data they represent.

Also on 28 March ebXML released for review the draft trading partner profile and agreement specifications. The ebXML specifications carve out specific technically-oriented functions for trading partner information stored in registries (profiles) and the rules of the road for conducting e-business (agreements). As a result, ebXML uses the terms collaboration-protocol profiles and collaboration-protocol agreements to distinguish them from the more comprehensive trading partner profiles and agreements that contain much more than technical details.

EbXML expects to finish its technical specifications in May 2000 at its last meeting in Vienna, Austria. At that time, the participants plan to take up the business process and core components specifications, the last two pieces of the technology still in development.

Reactions to the announcement of ebXML integrating SOAP into its specifications drew general applause from industry watchers, with headlines on the major IT news sites and even a story on the Reuters news wire. The episode did serve as a reminder that competing e-business standards need to consolidate if they hope to succeed, even if it means a certain loss of innocence in making those accommodations.