RE: SOAP and ebXML

Larry,

XP has in its scope statement and evolving requirements discussion accepted
that protocol extensibility is a core requirement.  I could envision
building a request/response protocol with response caching at intermediaries
on top of XP by inventing a new set of headers in a new namespace and
specifying appropriate actors as intermediaries.  I don't think this can be
done in any straightforward way on top of ebXML.  Similarly for reliable
*ordered* delivery of streams of async messages, etc.

Am I wrong?

Satish

-----Original Message-----
From: Larry Cable [mailto:larry.cable@sfbay.sun.com]
Sent: Thursday, December 07, 2000 2:34 PM
To: Satish Thatte
Cc: 'David E. Cleary'; Michael Champion; xml-dist-app@w3.org
Subject: Re: SOAP and ebXML


Satish Thatte wrote:

> 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 tend to agree with this.

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

h'mmmm now I disagree with this, what aspect of ebXML (as it is current
(un)specified)
precludes it from solving any of the problem spaces that XP (as it is
currently
(un)specified).

I frankly see little difference in either the specs or capabilities of
either
of these protocols!

Rgds

- larry

>
>
> 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 19:55:13 UTC