W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2002

RE: Intermediaries - various cases

From: Katia Sycara <katia@cs.cmu.edu>
Date: Fri, 27 Sep 2002 20:08:51 -0400
To: Ugo Corda <UCorda@SeeBeyond.com>, "'Anne Thomas Manes'" <anne@manes.net>, Ricky Ho <riho@cisco.com>
Cc: www-ws-arch@w3.org
Message-ID: <NFBBLCDGGLCHCHFEJFIGIEEMCIAA.katia@cs.cmu.edu>

I am not sure why we care whether the SOAP processor is an intermediary or
the receiver of the message.
 At the logical level, the application is the receiver of the message (since
it is the receiver application that must do something that the requestor is
asking it to do, e.g. make a travel reservation). In that view the SOAP
processor is an intermediary.
 An additional point is that it is just a matter of current implementation
that the SOAP processor is the end point of processing SOAP messages and it
has a different mechanism (other than SOAP) to communicate with the
application. In the future this could change.
  --Katia
-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Ugo Corda
Sent: Friday, September 27, 2002 3:31 PM
To: 'Anne Thomas Manes'; Ricky Ho
Cc: www-ws-arch@w3.org
Subject: RE: Intermediaries - various cases



If we are talking about a SOAP message processor that translates the SOAP
request into a call to an application method, I think the message processor
is the ultimate receiver node. The communication between that message
processor and the application is not done using a SOAP message, so we cannot
see the SOAP message processor as an intermediary and the application as the
ultimate receiver SOAP node (even though that application represents the
application layer - as defined in the XML Protocol Abstract Model - for that
SOAP message processor node).

Ugo

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Friday, September 27, 2002 11:59 AM
To: Ricky Ho; Cutler, Roger (RogerCutler); 'Mark Baker'; Heather Kreger
Cc: www-ws-arch@w3.org
Subject: RE: Intermediaries - various cases



True -- but don't we also want to articulate this form of intermediary?

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Ricky Ho
> Sent: Friday, September 27, 2002 1:38 PM
> To: Anne Thomas Manes; Cutler, Roger (RogerCutler); 'Mark Baker';
> Heather Kreger
> Cc: www-ws-arch@w3.org
> Subject: RE: Intermediaries - various cases
>
>
>
> Whether the message is physically sending over the network to
> another node
> which you have no control is a significantly different model.  A "network
> intermediary" has a different security, trust, fault handling
> scenario than
> an "interceptor" which runs in the same VM of the SOAP endpoint.
>
> Rgds, Ricky
>
> At 01:07 PM 9/27/2002 -0400, Anne Thomas Manes wrote:
>
> >So here's a question: is a SOAP node the application that makes
> the initial
> >request or is it the SOAP message processing runtime runtime engine that
> >actually sends the request over the network or is it the
> combination of the
> >two? Likewise on the server side, is the SOAP node the application that
> >receives the final request or is it the SOAP message processor that
> >translates the request into a method call or is it the combination of the
> >two?
> >
> >The way many SOAP message processors work, you can add all kinds of extra
> >middleware functionality (implemented as interceptors or header
> processors)
> >in the SOAP message processor. For example, you can perform logging or
> >encryption or message reconciliation or message persistence,
> etc. A lot of
> >these functions can happen without the application's awareness.
> I view these
> >interceptors and header processors as intermediaries (although
> Mark tells me
> >that they are nodes). Physically, I'm not sending the message over the
> >network between each interceptor, but conceptually I am.
> >
> >Anne
> >
Received on Friday, 27 September 2002 20:09:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:06 GMT