- 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>
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 UTC