Re: Proposed issue; Visibility of Web services

Mark Baker <distobj@acm.org> wrote on 05/29/2003 01:36:28 PM:

> On Thu, May 29, 2003 at 12:28:46PM -0400, Christopher B Ferris wrote:
> > I guess I just don't know what you think a "generic" intermediary is 
then. 
> > Give me an example
> > of a generic HTTP intermediary that does not have a specific role(s) 
like 
> > caching.  If my cache example
> > is not generic, I don't know what is. You seemed to have simply 
ignored 
> > that aspect of
> > my previous message. Was my example not "generic" by your standards?
> 
> No, at least not for the purposes of doing the apples-to-apples
> visibility comparison.  I was trying to emphasize that HTTP defines
> many application layer features, while SOAP does not.  That may seem
> obvious and non-important, because SOAP may have lots in the future, but
> that's really the point; it doesn't have them now, so a SOAP
> intermediary developed with no knowledge of them has no visibility into
> a transaction that uses them (outside of knowing that it doesn't know
> what they mean, ala mustUnderstand).
> 
> Mike has said that SOAP firewalls will be going to market soon.  What
> SOAP applications will they understand?  Will those firewalls be

Need they necessarily understand the application? Might they not be 
leveraging things such as WS-Security to determine if the original
sender can be authenticated and given authorization using the endpoint
address? Firewalls that look only at the method (GET) to determine
if the request should be allowed through are fairly limited in their 
utility. If it is important that the request also be authenticated
with something slightly more robust that a user/password, does an
HTTP firewall satisfy that requirement? (NOT!) Might it be more robust
(and flexible) to allow the container of the service provide the 
granulariry of 
authorization at the method level?

> upgraded for every new extension that comes along?  Because that's the
> only way will they have similar visibility into SOAP transactions that
> HTTP intermediaries developed today will have into HTTP transactions
> executed 10 years from now.

Quite possibly, but SOAP provides a framework and process model that
enables this... HTTP does not.

> 
> BTW, I would *really* appreciate a response to this;
> 
<snip/>
Cheers,

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

Received on Thursday, 29 May 2003 14:03:19 UTC