ebXML Ropes in SOAP
The Electronic Business XML (ebXML) project released three
more technical specifications for review on 28 March, including a new draft
document on messaging services. This part of ebXML -- formerly known as
transport, routing, and packaging -- had made more early progress than the other
technical features, but it also came under more pressure to include the work of
other initiatives, specifically the Simple Object Access Protocol (SOAP).
Enhancements to the original SOAP specification made it easier for ebXML to join
forces. But it also marked something of a change in operation for ebXML, now
more willing to make accommodations with other related initiatives in order
achieve its goal of a single worldwide e-business standard.
SOAP in a Nutshell
SOAP provides a simple and lightweight
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.