RE: mustUnderstand on client side

>My experience comes mainly from the EDI world so I'll use and 
>example from the EDI culture to explain why I believe 
>mustUnderstand semantics and behavior must be clearly defined 
>in XMLP and these rules must apply to
>*all* SOAP message exchanges, regardless of the direction 
>(request or response).

I strongly agree with this - but would at the same time hope it already
to be the case for SOAP simply because the processing model expressed in
SOAP/1.1, section 2 doesn't address the role of the SOAP processor. In
other words, it doesn't matter whether a SOAP processor is a client, a
server, a peer, an intermediary etc. etc.

There are many situations where in a client/server scenario, the server
may send something to the client that the client doesn't understand.
HTTP clients deal with unknown content types by saving them to disk or
similar.

A few scenarios illustrating mandatory parts of responses include: The
response is encrypted and the key has to be obtained from a third party
for a fee or there is a copyright statement that must be obeyed.

As Noah points out, however, there are many ways that this can be
negotiated including additional round trips etc. and I would add that it
depends on the scenario and therefore also on the message exchange
pattern. There clearly are cases, where it may not make sense to use the
mustUnderstand construct in so-called responses.

I think this is ok - after all we are in the business of defining a
consistent set of semantics for a protocol and the constructs that it
defines. We are not in the business of guaranteeing that whatever people
might do on top makes sense.

>It's my understanding that SOAP has no such versioning 
>mechanism to "sync" communicating parties, but instead relies 
>on a freely extensible, mustUnderstand attribute to ensure 
>that two parties "understand the protocol". As SOAP 
>implementers evolve their implementations over time it's very 
>likely there will be different levels of support for the same 
>"service" (e.g. process purchase order) (as in the EDI case 
>described above) across a trading community. It appears to me 
>that mustUnderstand is the only way, given the current design, 
>to "ensure" that two parties are in "sync". If XMLP allows the 
>receiver of a response message to ignore mustUnderstand then 
>there is no way for the responder to know for sure that the 
>response message was actually understood.

I absolutely agree and would add that this goes for all of the SOAP
processing rules (mustUnderstand, actor, etc.)

Henrik

[1] http://www.w3.org/TR/SOAP/#_Toc478383491

Received on Wednesday, 2 May 2001 11:14:17 UTC