WebLogic and 7911

It seems to me that there are two fundamentally different ways for a 
client to violate a MUST in a request and they are (sort of) like the 
difference between involuntary manslaughter and murder (bear with me here).

A "manslaughter-MUST violation" is something the client does without 
premeditation. That is to say, the client can't and doesn't know that 
they've violated the MUST condition. For example, the latest proposal 
for 7586/7588 has a clause that reads "Regardless of the value types, it 
MUST be true that wse:Expires/@min <= wse:Expires <= wse:Expires/@max as 
interpreted by the Event Source or Subscription manager at the time the 
wse:Subscribe request is processed." It is possible for a client to send 
a Subscribe request where @min <= wse:Expires <= @max at the moment the 
request is sent but, due to various circumstances (queuing delays, clock 
skew, etc.),  by the time the request is processed by the Event Source, 
wse:Expires > @max, and the request violates the MUST. Had things gone 
differently, the request might have satisfied the @min <= wse:Expires <= 
@max constraint when it was processed by the Event Source. We define the 
fault that is generated when this MUST condition is violated because 
there is no other way for the client (which, BTW, is conforming to the 
spec in this area) to determine what happened.

A "murder-MUST violation" is the result of premeditated action. That is 
to say, the client has a bug. If a client sends a WS-Transfer request 
with an [Action] of "http://www.w3.org/2009/09/ws-tra/Get" and a 
[Body]/[child] of "wst:Put", it is sending an illegal, non-conforming 
request. Unlike the above case, there are no circumstances under which 
this request could ever be valid. All you have to do is look at this 
request and you can tell that it is invalid. There may be some WS-T 
impls that will honor this request and perform either a Get or a Put 
and, while it seems weird that you can't tell what an implementation 
will do in this case, *non-conforming clients have no reasonable 
expectation of predictable behavior*.

It's difficult define and implement predictable behavior for conforming 
clients. It's *impossible* to define and implement predictable behavior 
for *all* the different ways you can violate a spec. Which isn't to say 
you should do nothing! To help developers and admins figure out what is 
going wrong, implementations can and do perform various checks on the 
well-formedness and validity of incoming requests, but the nature and 
extent of these checks are up to the implementation. For every check 
there is a performance penalty and you have to weigh this cost against 
the benefit of catching the problem, the ability to detect it via some 
other means, and the likelihood of its occurrence. This is why very few 
production SOAP services (or even test services for that matter) perform 
schema validation on their incoming requests; the performance costs of 
schema validation outweigh the benefit of catching the *rare* cases of 
non-schema-valid requests.

Which brings me to my final point: from a programmer's perspective, this 
is really a tempest in a teapot. Most WS-T client implementations will 
include request marshaling code that is auto-generated by some 
wsdl-to-code tool. Unless there is some major bug in your tooling that 
has gone undetected for a number of years, the [Action] and [Body]/child 
will agree with their definition in the WS-Transfer WSDL. If you are 
hand-coding WS-Transfer request marshaling, it is a simple matter to 
test the four (count them, 4!) WS-T operations to verify that [Action] 
and [Body]/child agree for all four operations. Once this code works, 
leave it alone and you will be fine.

- gp