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

> but I don't think that's a path the WG will like to
> go on because it'll dramatically complicate WSDL for everyone.
> [Tom, where are you? ;-)]

Here I am.  

I agree we do not want to dramatically extend the functionality of header.

BUT, I do not think I am currently in favor of removing WSDLs ability to specify headers as part of the contract for a web service.  In point of fact, I am very happy that the header syntax we have in the current draft is fairly simple and straightforward, way better than in 1.1.

Would it really fly to remove the ability to specify the contents of a <soap:header> element in SOAP requests via WSDL?  This seems like a major step backwards.  And one that we are sure to get violent objection to when we go to last call.

If my service needs headers, how to I tell consumers of my service what they look like (and which operations they go with) if not in WSDL?

I can think of a LOT more likely candidates for removal than this feature.  (Attributes come to mind.... :-( )

Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Sanjiva Weerawarana [] 
Sent: Friday, October 24, 2003 1:34 PM
To: Umit Yalcinalp
Subject: Re: PROPOSAL: Drop interface/operation/(input|output)/@headers

"Umit Yalcinalp" <> writes:
> I have one "naive" question about your proposal.
> I can envision two different use cases for headers, application specific 
> and middleware introduced. For the latter, one can envision using 
> properties and features (as has been discussed in this thread) and/or 
> specific specs that deal with a specific feature (which is the case 
> today with WS-* specs).
> However, I am not clear on what options we are leaving to applications 
> that would like to define headers. Can you clarify this if we were to 
> remove headers?

In our internal discussions, we've concluded that even when 
applications do introduce headers, that is done as a result of
some policy being applied. Thus, just having a mechanism to 
declare a header isn't enough - one has to say what the 
lifecycle of that header is, what scope it has (not share
across operations, shared across some ops, shared across all
ops etc.). 

In other words, the mechanism in the current draft is woefully
inadequate to describe headers. Extending the functionality is
an option, but I don't think that's a path the WG will like to
go on because it'll dramatically complicate WSDL for everyone.
[Tom, where are you? ;-)]

Hence our proposal that headers be dropped and left in the
domain of policies to introduce and describe the semantics / 
lifecycle of.

My apologies for the delay in replying.


Received on Friday, 24 October 2003 15:48:36 UTC