W3C home > Mailing lists > Public > www-ws@w3.org > May 2003

Re: Proposed issue; Visibility of Web services

From: Mark Baker <distobj@acm.org>
Date: Wed, 28 May 2003 16:34:54 -0400
To: www-ws@w3.org
Message-ID: <20030528163454.A16633@www.markbaker.ca>

I'll try and keep this as brief as possible, and present things
slightly differently than I have been.

On Tue, May 27, 2003 at 08:08:13PM -0400, Christopher B Ferris wrote:
> There's an abundance of "visibility" of 
> the RFC2616
> defined HTTP header fields,

Agreed.

> but the extension headers? No "visibility" 
> there I'm afraid:

Agreed.

> I would actually go as far as to suggest that SOAP is MORE visible than 
> HTTP

But above you just said there's an abundance of visibility into RFC 2616
headers, which I agree with.  As an apples-to-apples comparison then,
SOAP has no standardized headers, and therefore a generic SOAP
intermediary has less visibility with respect to headers; sure, there's
the wonderful role/mU stuff that's added, and while that does most
definitely help SOAP visibility, I suggest that it is rather a minor
contribution.  In addition, since you agree that HTTP's standardized
methods improve visibility, I'd also expect that you'd agree that it's
standardized application methods improve visibility too, no?  SOAP has
no methods either.

SOAP is more a framework (or at least it's used that way).  HTTP is
something that one builds on top of a framework, filling in application
headers and methods, etc..

> because a) there is a well defined process model

Yes, but HTTP has a well defined processing model too.  SOAP's is
richer in an important way though, and that does help with visibility
as I said above, regarding role/mU.

> and b) you don't have to 
> concern
> yourself of having name collision because SOAP headers are namespace 
> qualified.

True, but for the generic case, this isn't an issue since there are no
extensions.

Do you realize that what I mean by a "generic intermediary" is one
that we could code today, deploy, and then never change again?  As
Walden described, how well would a generic SOAP intermediary do in
understanding the interaction between some SOAP application produced in
the future?  How well would a generic HTTP intermediary do?

I'll cut it off there, if that's ok.

Thanks.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
  Actively seeking contract work or employment
Received on Wednesday, 28 May 2003 16:45:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:42 GMT