Re: Intermediaries - various cases

No, a SOAP intermediary is a SOAP node that (may process but 
certainly) relays SOAP messages. A "SOAP processor" (obsolete 
term as far as SOAP 1.2 is concerned) is an implementation 
artefact that does some processing for/on behalf of a "SOAP 
application" (undefined term); collectively, they may be seen as 
an implementation of a SOAP node (or a SOAP intermediary, if they 
support forwarding).

It may also be worth pointing out that being a SOAP intermediary 
is not necessarily a full-time job. The decision to act as a SOAP 
intermediary is (SOAP) message specific. A given SOAP node may 
play the role of the ultimate SOAP receiver for some messages and 
that of a SOAP intermediary for others.

Jean-Jacques.

Katia Sycara wrote:
> 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 Monday, 30 September 2002 08:05:03 UTC