RE: SOAP and ebXML

David,

Great summary, thanks for posting.  IMHO, SOAP and ebXML can both
potentially share equal importance in the development of Web Services as
Bosak has apparently suggested in his talk (a point which I hope he
clarifies in greater detail in response to your invitation for him to join
this discussion), and as a point of fact, I see very little reason why these
two processes cannot be merged into a single effort at some point in the not
to distant future.

There is, however, a tendency to minimalize 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 it's 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.

Now, granted, SOAP is most likely to be used in small, simple RPC-style web
services that do not require the definition of complex ebusiness processes.
And ebXML is most likely to be used in situations where complex ebusiness
processes are involved.  This is the point that I believe Bosak was trying
to make.  This point, however, does not exclude SOAP (combined with various
extensions to SOAP) from being able to address the complex ebusiness
processes.

Now, I'm sure that you (David) are aware of this, so I want to clarify that
I'm not directing these comments at you, yet rather as comments to the
discussion as a whole.

As for the convergence that you speak of.  Obviously, that is the most
desirable approach and should be a top priority as things move forward.
What I would LIKE to see emerge would be a small, flexible, simple Envelope
format similar to SOAP and a standard defined set of extensions to that
envelope that address each of the issues that ebXML addresses.  If the
Envelope format is called XP, then the extensions can be called ebXP ;-).
In any case, Bosak is right to say that SOAP and ebXML can very easily
coexist; I just think that it is a little misleading to say that SOAP is
only really targeted at "simple" web services.

- James Snell

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Wednesday, December 06, 2000 4:46 PM
To: 'Michael Champion'; xml-dist-app@w3.org
Subject: RE: SOAP and ebXML


Michael

I think discussion of the roles of SOAP and ebXML are important ones. To
help the process, I would like to highlight some of the main requirements
for ebXML messaging.

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".

"Secure" means that the data must be capable of being digitally signed and,
if necessary encrypted, so that the authenticity of the sender is known and
the privacy of the data protected. This includes document/content encryption
to ensure data privacy through any nodes in the network the message might
pass through.

"Reliable" means that the message must be capable of "once and only once"
delivery with optional positive confirmation of the delivery of the message
by its final recipient and notification of failure that the message could
not be delivered. Reliability should also work if the message passes through
multiple nodes using different transport protocols.

"Any data" means that XML, binary data, in fact any "arbitrary content"
could be transported equally easily without changing it. It also means that
if the data had been digitally signed before being sent, the messaging
protocol would ensure that the integrity of the signature was preserved by
not changing the data in any way.

"Over any network" means that all of the above should work equally well
whether you were using "unreliable" protocols such as HTTP, SMTP, TCP/IP or
"reliable" protocols such as IBM's MQ series.

Note that the all the above are optional this means that ebXML couldalso be
used for the "unsecure, unreliable sending of messages".

So really ebXML's approach is to start with a larger (for want of a better
word) problem than SOAP/XP and provide optionality 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.

In fact ebXML looked long and hard at using SOAP as the outer wrapper for
its messages but the SOAP specifications available at the time did not
support attachments and MIME which made encryption impossible and also made
it difficult to transport aribtrary content without base 64 encoding it.

Either way I think that ebXML has done a lot of thinking around many of the
issues that XP will want to address, we should therefore aim for the
convergence that I know many of the people working on ebXML hope to achieve.

Regards

David
PS See you all next week.

-----Original Message-----
From: Michael Champion [mailto:mchamp@mediaone.net]
Sent: Wednesday, December 06, 2000 4:15 PM
To: xml-dist-app@w3.org
Subject: SOAP and ebXML


I noticed the article on XMLHACK about Jon Bosak's presentation at XML
2000 -- see http://xmlhack.com/read.php?item=935

" the distinction between SOAP, the technology of choice for simple
services, and ebXML, required to perform more mission-critical transactions,
was made clear by Bosak.

The final architecture of Bosak's vision is then:
-XML as a core technology
-UDDI to find the services we need
-SOAP to perform the simple ones
-ebXML for the most complex ones "

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.

I realize that this opens up a can of worms, but it's an issue that I'm
sincerely trying to make sense out of.

Received on Thursday, 7 December 2000 02:40:41 UTC