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

Hi Tom,

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

Fair enough.

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

I don't think so, obviously ..

> 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 think this comes to a design philosophy question. When people design
services, should they be thinking about headers vs. body things or
should they be designing in terms of the data they need and produce?
In BPEL for example, do you want the process author to have to decide
what's the "body" vs. what's the "headers"? That's not the way biz
people think - they think of the data they need for the service to
work and what business data the service will produce.

I contend that's how Web services should be implemented too - by
thinking of the data the services need & produce. In order to get
the data to/from the service, certain QoS may be needed - e.g.,
security and reliability. Those things are what create headers and
require headers. However, the description of the service should
describe first the kind of application data they need and then layer
on the QoS info they need, at the binding level. Features and properties
(or WS-Policy) are ways of doing that obviously.

Note that I'm not proposing to drop the soap:header binding element-
I think its fine if someone wants to define specific SOAP headers
to be sent (or received). I'm arguing to remove the header concept
from the abstract description of the service.

If you still disagree, can you help me understand? Can you give
me an example scenario where I'm modeling the service and still
absolutely have to think in terms of headers vs. body instead
of just in terms of the data the service consumes and produces?
Maybe one of us can convince the other if the example is good.

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

;-)

Sanjiva.

Received on Monday, 27 October 2003 10:45:45 UTC