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 Wednesday, 6 December 2000 19:55:41 UTC