Converging Protocols

ebXML and SOAP

During his recent XML 2000 keynote, Jon Bosak outlined a vision of the future of web services, which was summarized by Eric van der Vlist as

• XML as a core technology
• UDDI to find the services we need
• SOAP to perform the simple ones
• ebXML for the most complex ones

For readers not familiar with the projects Bosak cites, some pointers might be useful.

Universal Description, Discovery and Integration, UDDI is a discovery mechanism for finding e-commerce businesses and their services. ebXML is an e-commerce framework, describing protocols and processes for conducting electronic transactions. The ebXML framework consists of several components, notably a messaging layer (Transport, Routing and Protocol) and a Registry and Repository system. The relationship of ebXML to UDDI was discussed in a recent XML.org feature, "Understanding ebXML, UDDI and XML/edi".

SOAP is the XML messaging protocol, grown out of XML-RPC, and was one impetus for formation of the W3C Protocol Activity, known as "XP." For those wanting additional information, a useful comparison article on developerWorks summarizes current XML Messaging projects.

Wanting to explore Bosak's vision further, Michael Champion invited comment from members of the W3C xml-dist-app mailing list.

I'm wondering if participants here agree with the notion that SOAP is for simple services and ebXML for mission critical transactions. If so, what about ebXML makes it more suitable for mission critical work? (Transaction processing support, maybe?)

What about the objectives of the XML Protocols activity? I don't see anything in the Activity Statement or Charter one way or the other that would reflect on this issue.

Agreeing that discussion of the relative roles of SOAP and ebXML is important, David Burdett attempted to highlight the requirements behind the ebXML messaging layer.

So what's the problem space that ebXML messaging is addressing. To sum up I would say that the goal of ebXML was to enable "the secure, reliable delivery of any data over any network".

Burdett noted that many aspects of ebXML messaging are optional, allowing it to be used for "[in]secure, unreliable sending of messages" also. Burdett further contrasted the focus of ebXML's design from that of SOAP and XP.

So really ebXML's approach is to start with a larger (for want of a better word) problem than SOAP/XP and provide option[s] so that all the features do not need to be used unless they are required. By comparison, XP seems to be adopting more of a minimalist approach on which addtional functionality such as security and reliability can be layered.

Either approach is viable although you could argue that a minimalist approach might provide a better "layering" of the protocols.

James Snell suggested that SOAP is frequently undervalued as a messaging system and could be extended to fulfill a role similar to ebXML.

There is, however, a tendency to minim[ize] SOAP into nothing more than a simple XML RPC mechanism that gives the appearance that, while the architecture is indeed simple, that it is not a suitable mechanism for mission critical, complex business applications. On the contrary, it is SOAP's fundamental simplicity and extensibility that gives it [its] strength.

While ebXML is primarily geared towards business-to-business communication, SOAP is capable of bending towards many different purposes, including those that ebXML is exclusively designed to address. As far as I can see, the only real difference between ebXML and SOAP is that ebXML has more features cooked into the architecture than does SOAP. Whereas the ebXML specification includes MIME support, the SOAP specification is flexible enough to allow for it. Whereas the ebXML specification includes reliable messaging, the SOAP specification can support the definition of reliable messaging requirements through it's extensible header structure.

Convergence

There's no doubt that Bosak was considering more than just messaging when outlining his vision for web services. However the XML Protocol community seems to agree that convergence is required at the lowest level. (Jon Ibbotson described it as a "no-brainer" ). David Cleary was among several contributors who voiced support, while drawing parallels with BizTalk.

I agree with the notion that ebXML is not appropriate for every uses case, and that SOAP is a better choice for many applications. What I do not agree with is that SOAP can not be the base upon which something such as ebXML could be built. A perfect example of this is BizTalk. It has the same requirements as ebXML, but is built on top of SOAP.

So [...] my point is that XP can be used for mission critical work if you build the required services on top of it.

Satish Thatte also contrasted the relationship between BizTalk/SOAP and ebXML/XP:

Although early versions of BizTalk Framework were designed from scratch without reference to SOAP, in the 2.0 version we were able to rebase the framework completely to build on SOAP. In so far as XP plans to provide an extensible protocol framework in the SOAP tradition, there is absolutely no reason why we cannot use XP to build a protocol that fulfills the set of requirements ebXML's transport/routing/packaging work is based on.

Thatte later observed that the layered approach that XP is adopting enables a greater degree of flexibility.

...XP is approaching the layering problem the right way, by building an enabling protocol framework with a general model for extensibility, composition, intermediaries, and so on, rather than a closed protocol for a fixed requirement set.

Brian Eisenberg described the prospect of convergence between messaging applications as a welcome turning point in the process.

It's great to finally be working towards convergence. I truly believe that we can accomplish this within the XP activity. The key to interoperability, as John mentioned[,] is to architect an XP that is extensible and able to support the needs of both communities. I think we've finally reached a critical turning point in the overall XML messaging game. I've been waiting for this to happen for a while now, and I'd just like to say that it's through discussions like this that we are able to come to a common understanding and work together to move things forward.

Making It Happen

Convergence, and its consequent simplifications, is something of a happy prospect considering the risk of proliferation of competing standards. So how and when will convergence take place? Krishna Sankar said that XP may replace the ebXML Transport, Routing and Protocol (TRP) layer, but not until Phase 2 of the ebXML process.

As XP is extensible, nothing stops us from implementing the ebXML TRP over XP. And we can use the rest of the ebXML stack ... I think the XP deliverable and the Phase II of ebXML might coincide and there is a chance for synergy.

ebXML Phase 1 is due for delivery around May 2001, while the XP process is not likely to bear fruit until 2002, hence the cautious estimate. As Sankar noted, attempting to converge earlier would involve a great deal of effort.

In short, at a pragmatic level, we can look for alignment and cross-pollination now ... and a possible convergence somewhere in the middle of next year. For anything else, we would need to overcome huge inertia - including promised deliverables by the various groups.

Dick Brooks believed it is important to avoid impeding the progress of either effort.

I don't believe XP [or] ebXML should cease working toward their deadlines/milestones. Convergence efforts will have to work in parallel with the main efforts of each group.

Timing seems to be the critical factor: there is a great deal of industry pressure behind the delivery of both XML messaging as well as the ebXML and BizTalk frameworks, both of which initially rejected SOAP as a messaging layer due to its perceived immaturity. However, BizTalk now uses a SOAP-based framework, and ebXML appears to be looking towards its probable successor as a future foundation. This kind of leap-frogging is a good way to boot-strap into a framework so long as change control, interoperability, and standardization are well-managed. There is already a good degree of cross-pollination of people and ideas between the projects, avoiding needless reinvention of ideas, and achieving broad understanding of requirements.

The last word on the discussion should go to Chris Ferris, the ebXML Vice Chair, who welcomed feedback from others on the ebXML effort.

It is heartening to see that the ebXML TR&P requirements are being seriously considered by the XP WG. This will certainly help to further the likelihood that we might achieve convergence once the XP WG has delivered its specification as a W3C Recommendation.

...ebXML is a big effort involving hundreds of participants across five continents, operating under international rules. TR&P is just one of the activities. A convergence solution should respect the prerogatives as well as the hard work of both organizations...Those of us working on ebXML would gladly invite the members of the XP WG to review, provide feedback and/or contributions to our work. I believe that there is much which we can learn from each other.