Re: Proposed issue; Visibility of Web services

Mark Baker wrote on 05/28/2003 04:34:54 PM:

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

Oh? While I will grant you that the work is not yet complete, certainly
the OASIS Web Services Security TC work would qualify as a standard
SOAP header. Similar work is being done to standardize SOAP headers for
reliable messaging, addressing, policy, ...

> 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

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.

I never claimed that standardized application methods were not "a good 
thing".

I sincerely hope that there will be LOTS of standardization around 
domain-specific
business interfaces. There is already LOTS of activity in this space.

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

Agreed, so now you are agreeing that SOAP's processing model adds to 
visibility in an important way. I'm glad we seem to be making progress.

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

Oh? I guess you consider the generic case something that lacks all manner
of security. Certainly, you don't consider HTTP's security to be adequate 
for
business quality application use over the internet, do you?

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

Yes. Are you suggesting that one cannot code a generic SOAP intermediary
today, that had a specific role(s) assigned to it, that processed specific
set of SOAP headers? If so, you are sadly mistaken in your assumptions.
The SOAP processing model allows this. It also allows the intermediary to 
know
when it does need to be changed. You cannot say the same for an HTTP
intermediary.

> Walden described, how well would a generic SOAP intermediary do in
> understanding the interaction between some SOAP application produced in

Quite well, IMO. It certainly would know when it could not and I don't
think you can say the same for HTTP if you had to add a new header that
the intermediary had to care about.

I certainly believe that I could design a generic SOAP caching 
intermediary
that had an assigned role URI (e.g. 
http://www.w3.org/200@/@@/soap/roles/cache)
and a SOAP feature 
(http://www.w3.org/200@/@@/soap/features/cached-response)
that had a specific SOAP module:
        <soap-cache:Cache-Control mustUnderstand='true' 
                role='http://www.w3.org/200@/@@/soap/roles/cache'
                max-age='somevalue' no-cache='true|false'
 
xmlns:soap-cache='http://www.w3.org/200@/@@/soap/features/cached-response'/>

and deploy that generic SOAP intermediary (it may be generic but
it would always have a specific function(s)).

I could send SOAP messages that contained this header block,
regardless of what the contents of the SOAP:Body were (or whether
there was a method name secreted in the SOAP:Body) and that intermediary
would always know whether it was safe to cache the response message.

At some point in the future, I could also add a new header or extend the
feature, and target that at the same intermediary with mustUnderstand
true or false, depending upon whether the new aspect of the feature
were something that the caching intermediary, in its role as
a cache were something that it must or need not understand. 

        <ns:SomethingNewThatsCool mustUnderstand='true'
                role='http://www.w3.org/200@/@@/soap/roles/cache'
                xmlns:ns='http://something.else/' .../>

Adding this to the message, with or without a Cache-Control
header and the intermediary immediately knows that it can't
fulfil its role and should be upgraded.

You cannot say the same for an HTTP intermediary.

A SOAP intermediary therefore has MORE visibility into the semantics
that IT cares about. It can have confidence that it can ignore that
which it can safely ignore and that some new thing in the future
will signal when it needs to care and cannot safely ignore.

I think that is a much improved model, and I think
that many would agree including a number of TAG members.

> the future?  How well would a generic HTTP intermediary do?
> 
> I'll cut it off there, if that's ok.
> 
<snip/>

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Received on Thursday, 29 May 2003 08:50:38 UTC