Re: [wsrm] message headers for Ack and Fault ??

[Tom Rutt <tom@coastin.com>]

Jacques Durand wrote:

> inline <JD>
>
> How do you correspond a response to a request if the Poll request
>  is also sent asynchronously? Note that a callback is also asynchronous.
>
>  In the above example, if the Poll was also sent asynchronously, how do
>  you know (unless there is an attribute or this element) that ack was 
> for the
>  poll or the callback?
>
>  -Sunil
>
> <JD> I understand that this messageHeader serves a purpose in Responses,
> but still that seems quite contrived: we apparently use it only for 
> matching
> the ReplyPattern elements between req and resp.
> I believe our design would be tighter if we added the returned 
> ReplyPattern
> to the RM:Response element, as Sunil hints at as a possible alternative.
> Further, I believe the ReplyPattern element in a request, would be 
> more at its
> place in the RM:Request element, as it should be associated with the 
> element
> that has "request semantics".
> Doing so, the MessageHeader element would only contain ID and general 
> message info,
> and would only need be included in "reliable messages", as
> the second sentence in 3.1. clearly suggests already (at odds with 
> current usage).
> Later on when we have RM:Response piggybacking on business messages, 
> the info in
> messageHeader would be totally orthogonal to the info in RM:Response.
>
> jacques
>
I just had a though I would like to share.

The current behaviour seems to be:

For Response reply pattern, the response has a single ack or a single 
fault.  ( The syntax allows multiple acks, but the use is questionable)

For a callback, the response could have multiple acks , but may only 
include a single fault.  (The text is not clear about multiple acks in a 
callback)

We have two open issues Rel 108 and 115 regarding the semantics of 
faults with polling.

If the receiving RMP is willing to save state iformation about previous 
faults, then the poll response Schema could be modified
to include another element for returning multiple faults.

Eg:
      <faults>
          <fault>
            <faultCode>
                     ProcessingFailure
             </faultCode>
             <RefToMessageIDs> .... </RefToMessageIDs>
           </fault>
          <fault>
              <faultCode>
                     InvalidMessage
             </faultCode>
             <RefToMessageIDs> .... </RefToMessageIDs>
           </fault>
        </faults>

The idea is for each fault code that was returned in the past for a 
group, keep a separate ref to messageID list.

This would allow a poll response to include both ack info and fault info.

Tom Rutt



-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133