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

Sorry for rejoining this discussion late; I have been away the last 
couple of days.

I generally agree with Umit's previous messages.

Down to your point below. I agree with you, at a certain level in the 
design stage, one should not worry about the headers vs. body 
distinction. At some later stage in the design process, one will have to 
decide whether the entire application data should be serialized as a 
(for example, SOAP) body, or whether some of it should be serialized 
instead as (one or more SOAP) header blocks.

It may be a matter of taste if the corresponding WSDL should mirror that 
  separation of concerns, i.e. headers only in the binding, not in the 
interface.

To make things more concrete, let's suppose my application deals with 
two complex types, one of which I want to serialize as a SOAP body, the 
other as a SOAP header block.

With your proposal, how would I do this?

Thanks,

Jean-Jacques.

Sanjiva Weerawarana wrote:

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

Received on Wednesday, 29 October 2003 06:26:21 UTC