RE: Intermediaries

 

> -----Original Message-----
> From: Cutler, Roger (RogerCutler) 
> [mailto:RogerCutler@chevrontexaco.com] 
> Sent: Friday, December 05, 2003 3:37 PM
> To: Ugo Corda; Francis McCabe
> Cc: www-ws-arch@w3.org
> Subject: RE: Intermediaries
> 
> 
> Yes -- is it possible that the issues that you are trying to 
> raise with respect to intermediaries are beyond a reasonable 
> scope for the present effort, given the practical limitations 
> of time and personnel?

I for one am becoming less and less convinced that the idea of "application
defined equivalence" to distinguish intermediaries from "regular" web
services is productive.  

I think it would be desireable to identify the various senses in which
"intermediaries" is used in the web services context. As far as I can tell,
the only thing that distinguishes any kind of intermediary is that it is
both a message receiver and a message sender.  We have at least the
following:

"Underlying protocol" [I fear to say "transport"] intermediaries that help
move bits around efficiently, e.g. TCP/IP routers, HTTP proxies and caches.

"message intermediaries" that perform some MOM-level service such as
gateways between HTTP and MQ, routers that send a message to the
geographically appropriate destination,  or perhaps those that handle a
protocol such as WS-ReliableMessaging.  These make sure that SOAP messages
(as opposed to bits) are delivered to the correct ultimate receiver node.

"service intermediaries" provide higher-level services such as policy
enforcement.  WS-Security aware Firewalls are an obvious example, as would
be the SOAP Primer example of an intermediary that quietly changes business
class reservation requests to coach class if an application-level policy
requires it.

Received on Friday, 5 December 2003 16:17:23 UTC