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

Glen Daniels wrote:
> 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? 

I didn't say I saw it in the minutes: I was stating the two possible 
solutions that I could see. Nothing more.

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

Sure, but we're having a discussion here too ;-)

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

If that's what was agreed, then you're right and (ii) is the way to go. 
I don't necessarily agree with it, but then I couldn't stick with the 
meeting on Monday because I was on a plane. As long as we have something 
definitive in the text: it's ambiguity that worries me here more than 
the actual solution.

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

Agreed, but then again, you may not be meant to see those kinds of 
errors for very good reasons too. I think we could argue this ad 
infinitum, but as long as we've made a choice in the WG, let's just add 
a test.

Mark.


> --Glen
>

Received on Thursday, 16 March 2006 17:47:05 UTC