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


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.


----- Original Message ----- 
From: <>
To: <>
Cc: <>
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 Wednesday, 29 October 2003 23:39:57 UTC