RE: Open Content Model

Hi Chris!

> wsdl:required is instructing a *sending* SOAP node to include
> the required header block. I don't think that it is necessarily
> the case that the sending SOAP node understand (in the SOAPish
> sense) the header block it inserts in a message destined for
> another SOAP node.

Really?  Then what would be the point of bothering to have the header in there in the first place?  Why would I ever put in my description something that says "you need to send me a SOAP header that contains the integer '7', with such-and-such a QName"?  If everyone who uses this service is going to do that, why waste the bandwidth - I could just assume that that data was there at the receiving end on all calls, no?  The same would be true of any constant headers (which may be the only ones that could be sent without understanding the semantics, I think).

If the header values are NOT constants, then I would posit that the sender should in fact understand what they're doing - i.e. if you're supposed to send a header with a public-key certificate in it, you had better understand how to get one of those from an appropriate place if you hope the interaction to succeed.

> Where mU would come into play might be the case of a service
> endpoint that intends on including some SOAP header block
> in a response message (in the case of request-response)
> and it would be indicating in this case that the originator
> of the request message had better be capable of understanding
> (in the SOAPish sense) the response header block.

There is certainly a case to be made for "up-front" descriptions of headers which might be sent on a response message, but I still think this could be captured with a single attribute.

> Ergo, I think you may need both wsdl:required and wsdl:mustUnderstand,
> required for inbound messages and mustUnderstand for outbound
> response messages.

I'm still not yet convinced that they aren't the same thing.

--Glen

Received on Friday, 26 April 2002 11:48:02 UTC