Re: SOAP and ebXML

I'd like to respond to a number of points that have been 
raised in this discussion [1], in my capacity as vice-lead
of the ebXML TR&P project team. I feel that it is important 
that there be a clear understanding of the work we're doing 
in ebXML.

The first point I'd like to address is the comment
made by Satish Thatte [2] on the issue of protocol extensibility 
as being a key differentiator between SOAP and ebXML.

ebXML TR&P has *always* had a requirement to address extensibility
of the protocol. This is clearly articulated in our requirements 
and overview document (section 4.9 of [3]) published in May 2000. 
The TR&P team has been working to a phased delivery schedule in 
which we scoped our work efforts. The fact that the current
draft of the specification (v0.8) [3] does not include an explicitly
defined extension mechanism is merely an artifact of this
delivery schedule, not a shortcoming of the protocol.

Extensibility of the ebXML headers is currently being addressed 
by the TR&P team and will be formally added to the draft version 
of the v1.0 ebXML Message Service specification in the next couple of weeks.

The second point I'd like to address is a comment in John Ibbotson's
email [4] regarding disposition of the ebXML specifications
w/r/t standards ratification. UN/CEFACT, one of the 
co-sponsors of ebXML, is one of only 4 organizations on the planet 
that can set de jure standards. It is my understanding that
the ebXML specifications, upon completion, will likely be fast 
tracked through the UN/CEFACT process, establishing them as 
international, de jure standards.

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. 

I am wondering whether Dick Brook's role as liaison between 
ebXML TR&P and the XP WG is being misinterpreted. My understanding 
of his role was to ensure that both efforts were working along tracks 
that at one stage might converge. In this regard, I think that 
Dick is serving both groups well in his capacity as liaison.

The third point I'd like to comment on is the assertion
that ebXML is somehow unsuitable for lightweight
messaging as I believe has been suggested in a couple of
the emails, because it is "only suitable for heavyweight,
B2B messaging". While David Burdett has addressed this 
point in [5], I just wanted to be sure that his point 
is not missed.

ebXML TR&P message protocol addresses different qualities 
of service, ranging from lightweight messaging (as with XP/SOAP) 
to business quality messaging (suitable for purchase order 
handling between companies) which incorporates security, reliability 
and other key features.

Quality of service is a real engineering concept, not an abstract
notion. QoS applies to all manner of services, whether they
be characterized as lightweight or otherwise. One of the
fundamental objectives of ebXML is to avail these very qualities
of service to any use to which TR&P might be applied.

Finally, 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. Krishna Sankar's recent note [6] makes an exellent
point. 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 eachother.

Cheers,

Chris

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0090.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0109.html
[3] http://ebxml.org/project_teams/transport/transport.htm
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0112.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0105.html
[6] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0128.html