RE: WSO2 -> Axis issues (PLEASE READ, SPEC/TEST ISSUES)

Hi Mark!

> I agree that we need to test for this and I also think the 
> specification should be more explicit on how to deal with 
> errors during the processing of the WSA header information. 
> What I'm still unclear about is what algorithm to use in this 
> case. There appear to be only two:
> 
> (i)  it does make sense to say (as the last WG minutes 
> indicate) that if you encounter an error at any point in the 
> processing, then don't trust anything at all in the WSA 
> header and send a fault back to the sender (anonymous).

Where do you see that in the WG minutes?  We didn't say that at all -
what we agreed on was this text:

  "A recipient MUST generate a wsa:InvalidAddressingHeader (see 6.4.1
  Invalid Addressing Header) fault if such a message is received;
  headers with an incorrect cardinality MUST NOT be used to populate the
  corresponding abstract properties."

This simply means that if there are multiple FaultTos, then the [fault
endpoint] property won't be populated.  It does not say, for instance,
that the value will be assumed to be anonymous, or that we would in that
case ignore ReplyTo headers.

> (ii) if an error happens after processing part of WSA we 
> could try and 
> use that information to send back fault information (assuming we've 
> parsed wsa:ReplyTo or wsa:FaultTo).
> 
> The problem with (i) is that the receiver may not be expecting to get 
> error messages on that channel. The advantage is that it's simple to 
> reason about and can be tested by everyone.
> 
> The problem with (ii) is that we can't tell if the information we've 
> already parsed is valid and we also can't guarantee that WSA header 
> information is sent and parsed in the same way by all senders or 
> receivers. This makes a deterministic test impossible to achieve. The 
> advantage is that we MAY be able to send back errors to an 
> endpoint that 
> can actually deal with them.
> 
> I think we're all agreed that this is an edge case situation, so we 
> probably shouldn't optimise the specification (or our tests) 
> for it. As 
> such, I'm more in favour of (i) than (ii) because of its simplicity.

The problem with (i) is that that would require a change to the spec.
Right now the spec simply says "if there's a problem header, don't use
that one and you should generate a fault".  Therefore the currently
spec'ed behavior is that such faults should go to the fault endpoint -
i.e. the FaultTo if valid, and the ReplyTo otherwise, which is
essentially your (ii).

It's an edge case, but if I'm doing lots of async message flows through
intermediaries, I can see this being a problem for debugging.  If I've
got FaultTo set up to go back to my async management/logging endpoint,
and some intermediary on the chain adds a spurious MessageID header, I
might want the fault to go where I told it to go, not back up the pipe
to the intermediary.

--Glen

Received on Thursday, 16 March 2006 14:51:39 UTC