Intermediaries

Somf ot it depends on how transparent intermediaries are, and whether 
WSDL describes (in SOAP speak) the ultimate receiver, or the combined 
service provided by the ultimate receiver and one or more intermediaries.

Consider for example a service jointly provided by a (well-known, fixed) 
intermediary I1 and a server S.

A (SOAP) message travels through I1 and S. It contains blocks B1 and B2.

B1 is processed by I1. I1 appends B3 to the outbound message.

B2 and B3 are both processed by S.

What does the corresponding WSDL look like?

Option a)
---------
If we consider that I1 and S provide a combined service, the WSDL lists 
B1 and B2, i.e. what the initial sender is actually going to include in 
his message.

This view, however, does not fully indicate the processing performed by 
S (processing of B3) or I1 (processing of B1, creation of B3).

Option b)
---------
If we consider the ultimate receiver only, the WSDL lists instead B2 and 
B3, i.e. only the blocks processed by the ultimate receiver.

This view does not at all indicate the processing performed by I1 
(removal of B1, addition of B3), nor does it indicate what the initial 
sender must include in its message.


In neither a) or b) we have a view that fully indicates each node's 
processing (and that maybe ok in some cases where intermediaries should 
really be transparent).

So, +1 to David that we should at least consider the issue.

Glen, I'd be interested in details on your simple solution.

Jean-Jacques.

David Orchard wrote:

> Indeed.  But how does WSDL express the difference between the "application"
> components and the "infrastructure" components?  I haven't seen any syntax
> yet that shows this differentiation.  To a certain extent, the problem is
> that the "infrastructure" components are not targetted at the end
> application, rather something else like the security handler of the
> application.  As we (the industry and stds bodies) haven't really talked
> about intermediaries in this context, there is no guidance on how to
> structure wsdl nor whether to use soap:role to disambiguate.  Nor is there
> any guidance whatsoever on how to use WSDL in the face of intermediaries,
> either in the message path or even within the ultimate receiver.
> 
> It seems like wsdl 2.0 ought to do something about this.
> 
> Cheers,
> Dave
> 
> 
>>-----Original Message-----
>>From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
>>Behalf Of Glen Daniels
>>Sent: Wednesday, October 29, 2003 8:40 PM
>>To: paul.downey@bt.com; alewis@tibco.com
>>Cc: www-ws-desc@w3.org
>>Subject: Re: PROPOSAL: Drop
>>interface/operation/(input|output)/@headers
>>
>>
>>
>>Paul:
>>
>>I heartily agree with your estimation that in general, the
>>body is destined
>>for the actual application code, and the headers are either meant for
>>intermediaries or the infrastructure/middleware code on the
>>server or client
>>systems.  The features that are provided by those headers may
>>well expose
>>data or APIs to the application layer code, but the headers themselves
>>typically will be processed by the lower layers.
>>
>>Example - an application typically isn't going to get an
>>actual copy of the
>>security header for an ecryption/digsig extension.  Rather,
>>some lower layer
>>software will handle key management and decryption so that
>>the plaintext
>>body is delivered to the application code, along with a means
>>(sideband data
>>in some kind of context object, or an API) for getting the name of the
>>principal who sent the message, etc.
>>
>>--Glen
>>
>>----- Original Message -----
>>From: <paul.downey@bt.com>
>>To: <alewis@tibco.com>
>>Cc: <www-ws-desc@w3.org>
>>Sent: Wednesday, October 29, 2003 10:42 AM
>>Subject: RE: PROPOSAL: Drop
>>interface/operation/(input|output)/@headers
>>
>>
>>
>>Amy wrote:
>>
>>
>>>A number of specifications currently going forward use
>>
>>headers to supply
>>metainformation to the ultimate receiver.  See, for instance,
>>WS-Addressing, WS-Security (in some use cases; can also be
>>intermediary), WS-RM.
>>
>>In the case of these protocols i'd expect helpers from a toolkit
>>rather than having to understand the protocol in each application..
>>Given the application will probably have to plug-in the actual
>>values, intermediary was probably the wrong word to use - sorry!
>>
>>
>>>Actually, Glen and I were both at an interop dealie for
>>
>>WS-RM recently ..
>>
>>i did wonder - i read Glen's blog and spotted your name on
>>the WS-ReliableMessaging spec :-)
>>
>>--
>>Paul Sumner Downey
>>Web Services Integration
>>BT Exact
>>
>>
>>
>>
> 
>

Received on Friday, 31 October 2003 06:31:59 UTC