W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2003

RE: PROPOSAL: Drop interface/operation/(input|output)/@headers

From: David Orchard <dorchard@bea.com>
Date: Wed, 29 Oct 2003 21:10:53 -0800
To: "'Glen Daniels'" <gdaniels@sonicsoftware.com>, <paul.downey@bt.com>, <alewis@tibco.com>
Cc: <www-ws-desc@w3.org>
Message-ID: <05f601c39ea4$31df0370$fe2b000a@beasys.com>

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 Thursday, 30 October 2003 00:12:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:27 GMT