RE: Intermediaries

OK, I'll agree -- but what is the basis on which one makes the
distinction and draws the line?  Is it the "same message" criterion that
was discussed on the telcon, but which gets a bit fuzzy when you try to
look at it hard?  The kind of service that I'm talking about might
operate in such a way that the message passed through to the vendor is
identical to that submitted by the purchasing company -- or perhaps some
component of the message would be identical -- or maybe the message
would be reformatted to map the purchaser's format to the vendor's
format, but with the same purpose for the message.  It seems to me that
there is a spectrum of modifications that this thingie might do to the
message, and that the "same message" criterion is going to be difficult
to use to exclude this scenario from the class of intermediaries.

-----Original Message-----
From: Katia Sycara [mailto:katia@cs.cmu.edu] 
Sent: Saturday, December 06, 2003 11:45 AM
To: Cutler, Roger (RogerCutler); 'Champion, Mike'; www-ws-arch@w3.org
Subject: RE: Intermediaries


Roger, to my mind, this type of "gateway" you mention is a "full fledged
web service" that sort of performs message correlation rather than
receiving one message, somehow processing it and then sending it along
to another intermediary or " end user". 
 --Katia

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Cutler, Roger (RogerCutler)
Sent: Friday, December 05, 2003 4:52 PM
To: Champion, Mike; www-ws-arch@w3.org
Subject: RE: Intermediaries


Where do gateways fit into this?  Beyond the scope of intermediaries? If
so, what is the distinction that puts them outside the scope.

By "gateway" I have in mind, for example, a company that provides, as a
service, the collecting of purchase requests from client companies and
the sending of the required purchase request to vendors, handling  along
the way security, tracking, and so on.

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Champion, Mike
Sent: Friday, December 05, 2003 3:10 PM
To: www-ws-arch@w3.org
Subject: 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 Saturday, 6 December 2003 14:44:18 UTC