RE: SOAP and the Web (was RE: Late binding)

>The other major reason why we can't proceed this way, is that many
>aspects of the architecture, and the extensions that we define, will
>depend upon the architectural style in use.  For example, see HTTPR as
>a proposed solution for reliability.  It completely disregards the
>state transfer based architecture of the Web, and as a result, is a
>really poor solution for it.

I agree with Mike in the approach we need to take to this problem.  

Regarding this text, let's be sure not to confuse technology selections with architectural statements and requirements.  HTTPR may be a bad solution, but that doesn't invalidate the architectural requirement for reliable messaging.  Nor does the existence of HTTPR either validate or invalidate Web architecture...  Let's be sure to keep our concepts separated.

Eric


-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Monday, July 01, 2002 11:39 AM
To: Champion, Mike
Cc: www-ws-arch@w3.org
Subject: Re: SOAP and the Web (was RE: Late binding)



On Mon, Jul 01, 2002 at 09:01:31AM -0600, Champion, Mike wrote:
>   Am I missing something?  Is
> there any reason we can't move ahead with a SOAP-based mechanism to define
> the WSA?

Yes.  HTTP GET.  It can't carry SOAP envelopes or headers.  So
WS-Security, for example, can only be used to secure a SOAP response to
an HTTP GET.  It's therefore not a complete solution, because the GET
can be compromised.

The other major reason why we can't proceed this way, is that many
aspects of the architecture, and the extensions that we define, will
depend upon the architectural style in use.  For example, see HTTPR as
a proposed solution for reliability.  It completely disregards the
state transfer based architecture of the Web, and as a result, is a
really poor solution for it.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Monday, 1 July 2002 12:18:15 UTC