Re: SOAP and ebXML

Satish Thatte wrote:

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

Nope good point, at this point I think that this is the only significant
differentiator
between XP and ebXML ...

Thanks

- Larry

>
>
> 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 Friday, 8 December 2000 12:37:54 UTC