RE: Explaining visibility, take 54

Mark,

Although it's conceivable that people might want to build an intermediary
dedicated to processing a specific type of SOAP message, it's not the normal
practice. There are a host of Web services management products now on the
market that are generic SOAP/XML intermediaries. These systems intercept
messages en route and perform actions based on a set of business rules. They
can do things such as routing, caching, auditing, logging, message
transformation, security checking, metering, monitoring, and business
analysis.

It is a tremendously visible environment.

Your visibility argument simply doesn't hold water. If anything, XML
provides more visibility than HTTP headers.

Anne

> -----Original Message-----
> From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
> Mark Baker
> Sent: Friday, May 09, 2003 11:23 AM
> To: Mike Champion
> Cc: www-ws@w3.org
> Subject: Re: Explaining visibility, take 54
>
>
>
> On Fri, May 09, 2003 at 10:42:15AM -0400, Mike Champion wrote:
> > > A.  A generic SOAP/XML intermediary
> > > B.  An intermediary hardcoded to the WSDL document above
> > > C.  An intermediary hardcoded to some other WSDL document
> > >
> > > I suggest that B has vastly superior visibility to A or C.
> >
> > Uhh, OK, but what's the point?  An intermediary by definition is a "3rd
> > party" component that doesn't understand the application-specific data
> > format (such as that WSDL describes), so "B" and "C" are oxymorons.
>
> Aha!!  No, that's not the case.
>
> "Third party" just means a party distinct from the other two (e.g.
> a cache between a client and server).  It doesn't suggest anything
> about restricting what that intermediary can do.
>
> It is possible for an intermediary to be written that has knowledge of
> some application interface.  Those intermediaries have much higher
> visibility into the interactions between components that are using the
> same application interface, than they would if it were between
> components using a different application interface.
>
> MB
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
>

Received on Friday, 9 May 2003 12:11:28 UTC