RE: SOAP and ebXML

I want to respond to a number of emails in one.

Firstly James Snell said that ... "There is, however, a tendency to
minimalize SOAP into nothing more than a simple XML RPC mechanism that gives
the appearance that ... it is not a suitable mechanism for mission critical,
complex business applications."

I have never thought this. What is mission critical to one person is not to
another, and I completely understand and accept that a lightweight protocol
might be absolutely essential as the only way for some applications to work.

Secondly I would disagree with Satish when he says ... "I can think of many
missions for which a lightweight XML-based protocol would be required and
built on top of XP and ebXML/TRP would be altogether a failure in that
"mission critical" role."

The key thing about ebXML/TRP is that it starts by trying to solve a larger
problem and then making parts of the soloution optional if they are not
needed. If you were to use ebXML/TRP in its most minimalist way, you would
end up with something that is not that much different in complexity and
scope than SOAP, the main difference would be that the "body" in a SOAP
message would always be in a separate MIME part in ebXML.

This is good news in that it ought to mean that the work of the two groups
should be able to converge. It is also might be bad news in that unless we
are careful we might re-invent the wheel yet again.

Either way as long as we are aware of this risk we should be able to work
out something that works for everyone.

Regards

David

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Thursday, December 07, 2000 12:36 PM
To: 'David E. Cleary'; Michael Champion; xml-dist-app@w3.org
Subject: RE: SOAP and ebXML


David,

You are absolutely right.  BizTalk Framework started with the same general
requirements as ebXML/TRP including

1.  Transport independence
2.  Ability to carry arbitrary content
3.  Reliable delivery
4.  Message level security

Although early versions of BizTalk Framework were designed from scratch
without reference to SOAP, in the 2.0 version we were able to rebase the
framework completely to build on SOAP.  In so far as XP plans to provide an
extensible protocol framework in the SOAP tradition, there is absolutely no
reason why we cannot use XP to build a protocol that fulfills the set of
requirements ebXML's transport/routing/packaging work is based on.

I don't think it is meaningful to talk in terms of "mission critical" vs
"non mission critical".  What is mission critical obviously depends on the
mission.  I can think of many missions for which a lightweight XML-based
protocol would be required and built on top of XP and ebXML/TRP would be
altogether a failure in that "mission critical" role.  The point is that XP
enables a much wider class of mission critical protocols, whereas ebXML
focuses on a more specific B2B mission reflected in its specific
requirements.

Satish

-----Original Message-----
From: David E. Cleary [mailto:davec@progress.com]
Sent: Thursday, December 07, 2000 8:02 AM
To: Michael Champion; xml-dist-app@w3.org
Subject: RE: SOAP and ebXML


> 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?)

I agree with the notion that ebXML is not appropriate for every uses case,
and that SOAP is a better choice for many applications. What I do not agree
with is that SOAP can not be the base upon which something such as ebXML
could be built. A perfect example of this is BizTalk. It has the same
requirements as ebXML, but is built on top of SOAP.

So, in conclusion, my point is that XP can be used for mission critical work
if you build the required services on top of it.

David Cleary
Progress Software

Received on Thursday, 7 December 2000 17:30:56 UTC