Web Services, ebXML and UN/CEFACT

I'd like to make some general comments and speculations about the
relationship between Web services and the work going on in OASIS and
UN/CEFACT, particularly ebXML Messaging.   Anything I say here may be
tainted by various misunderstandings, and I hope people will help me out
if they are.  Another issue may be whether these comments are "in scope"
for this WG.  I think that it is at least in scope to discuss, although
I'm not quite sure exactly what output is expected.  One might be at
least some understanding of alignment issues between ebXML and Web
services - both where they exist and whether the consequences of
misalignments are significant in a practical sense.

It seems to me that Web services and ebXML messaging have a fairly
significant area of overlap in function.  So, how does one position them
with respect to each other?  Are these competing technologies and one
will "win" and drive the other out of existence?  I think this is very
unlikely.  Both seem to be developing significant market share and
momentum, but the focus of the market shares seem to be somewhat
different.  As a specific example that I use simply because I know quite
a bit about it, Microsoft has a very strong emphasis on using Web
services more or less internally.  I can't imagine them saying, "Oops,
let's rip out all that stuff and use ebXML messaging".  On the other
hand, as I understand it there are a number of industries that are
starting to implement ebXML solutions in order to take advantage of the
relatively heavyweight business functions incorporated.  For example, I
understand that there are efforts under way in the travel industry.
Once these get in place, are they likely to say, "Oops, let's do the
same thing with Web services"?  Seems real unlikely to me.

On the other hand, as I understand it we are talking about a choice
here.  One does not use BOTH ebXML and Web services for the same
operation.  It's one or the other.  Incidentally, I am obviously talking
about Web services in the sense of the WSA reference architecture, which
involves SOAP and WSDL.  EbXML messaging is pretty clearly a good
example of a Web service, in the larger sense, that does not conform to
the WSA reference architecture.  No crime here, but there might be
consequences if the ebXML architecture is significantly different from
the WSA architecture.

So ebXML and WS are alternatives.  Why did ebXML not use SOAP and WSDL?
Apparently because there were business functions needed that were not
offered by the WS protocols.  So perhaps we should look at ebXML as a
business-heavy Web service and WSA as a lighter protocol, in the
business sense, that can have considerable performance advantages and
possibly more flexibility of some sorts.  This seems to be supported by
ebXML usage itself, which I believe actually recommends using WSA for
some operations that essentially are single (probably stateless) data
fetches or perhaps writes, as opposed to the heavy business conversation
that is the core of ebXML.  I think that WSA potentially has both
performance advantages and potentially lower development overhead
because ebXML may carry baggage around that is not necessary for simple
operations.

Another distinction that is probably very clear (I think) is that ebXML
is ALL early bound (VERY bound) whereas many people in WSA are quite
interested in late bound scenarios.

OK, so ebXML and WS seem to have different flavors, but there are
probably circumstances where you might think of doing either.  In fact,
somewhat ironically I think that both of the major use cases in our
current Usage Scenarios document (Travel Agent and EDI-Like Purchasing)
may be areas where ebXML is currently actually being used and building
momentum.  So one question we might ask is if we need different Use
Cases.

Another class of questions, however, revolves around the issue of
whether one might be able to swap out a WSA for an ebXML service or vice
versa.  If there are significant architectural differences this might be
more difficult than one might like.  For example, if as seems likely
there are significant differences in the way these approaches partition
functions into the messaging and application layers, swapping one for
the other might require complex modifications to the applications.
Could be a bummer.  Another might be if one protocol allows operations
that are either impossible or bad practice in the other.  I'm
corresponding with Duane Nickull about a particular issue that I suspect
might be such an example.  More later if it is.  But is it ever likely
that anybody would ever want to do such a swap?  I'm really unclear on
that.  It seems to me that if one had an idea of why one might want to
do that one might more clearly understand if misalignments make any
practical difference.

Finally, if one does accept the general idea that ebXML is the business
heavyweight, it might make sense intentionally to keep some aspects of
the WSA relatively lightweight, particularly functions involving
managing long-running business conversations which is, I think, the
heart of ebXML.

I'm sorry this is all so general.  I'm trying to get my arms around the
framework in which we are doing these things.  If I've got things
grossly wrong above I'd really appreciate it if someone would straighten
me out.