RE: Announcement: WWW9 Panel on XML and Protocols, 17 May 2000

Henryk said ...

>>>The real question is therefore whether SOAP allows you to build such
applications while remaining as simple and straight
forward as possible.<<<

I think it probably does. The key thing is that we recognize what the total
requirement is (or will likely be) in the area of messaging so that we can
be more sure that it can be met in its entirety.

David

-----Original Message-----
From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
Sent: Tuesday, April 11, 2000 2:18 PM
To: David Burdett; 'Eric Prud'hommeaux'; Ken MacLeod
Cc: xml-dist-app@w3.org; Janet Daly
Subject: Re: Announcement: WWW9 Panel on XML and Protocols, 17 May 2000


> I've had a quick look at your architecture document (LOTP) and
understand
> why you want to model it on SOAP. However there is a whole class of
problems
> that *need* to be addressed for successful B2B that SOAP in it's
current
> form does not address. I posted an email to the SOAP list on this
which said

... snip ...

> This resulted in extensive discussion on SOAP(RPC) vs Messaging that
> concluded that what you really needed was SOAP **AND** messaging.
>
> How do you think support for these requirements fits in with your
plans for
> LOTP. Currently they are all being addressed by ebXML Transport
Routing and
> Packaging Working Group and I want to find a way to avoid re-inventing
the
> wheel.

I think it is worth to point out the layering model in SOAP. SOAP is
intended as "the thing in the middle" between applications above and
transports below. In itself, it doesn't talk much about the transport
below and it doesn't talk much about the applications above.

For this discussion, it doesn't matter that HTTP and SMTP are not
transports but application level protocols - you can apply the argument
of layering to true transports like TCP and SSL etc. Please also don't
get too hooked up on the RPC/messaging differences - as the thing in the
middle, SOAP doesn't really say much about what you use it for. Elements
like headers are for example not very RPC'ish and it is possible to
think of SOAP is one-way scenarios either with or without HTTP.

As such, it is not strictly fair to apply requirements to SOAP for which
it intentionally has nothing to say. I do not argue that the
requirements that you mention are not important but you also mention
that they are applicable to a specific set scenarios that may not be
globally valid. The real question is therefore whether SOAP allows you
to build such applications while remaining as simple and straight
forward as possible.

Henrik Frystyk Nielsen,
mailto:frystyk@microsoft.com

Received on Tuesday, 11 April 2000 18:17:58 UTC