RE: SOAP and ebXML

[Henry Lowe <hlowe@omg.org>]

David,

Good answer.  

I've copied this to the ebXML list as they may be interested.

Best regards,
Henry
------------------------------------
At 04:46 PM 12/06/2000 -0800, you wrote:
>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.
>
>