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

[Tom Rutt <tom@coastin.com>]

Sunil Kunisetty wrote:

>Tom Rutt wrote:
>
>  
>
>>Sunil Kunisetty wrote:
>>
>>    
>>
>>>Tom Rutt wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>Sunil Kunisetty wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>><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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>+1 ;-)
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>I take this to mean that you, Sunil, have no problems with the reply not
>>>>having its own message ID.
>>>>
>>>>
>>>>        
>>>>
>>>Yes, that's correct.
>>>
>>>
>>>
>>>      
>>>
>>>>If such is the case, an alternative to putting the reply pattern in the
>>>>respons is to have a separate header element
>>>>defined for a poll response.  This new heeader could have a schema to
>>>>convey fault info as well as a list of delivered messag ids.
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>I don't think we need a different Header element, a simple optional attribute
>>>would suffice.
>>>
>>>      
>>>
>>A different header syntax for poll would allow returning fault info as
>>well as the ack info.
>>    
>>
>
> But did we even decide on such header? I haven't see any proposal yet.
> I for one prefer the same header/element whether it is response, callback,
> or poll pattern.
>
> I can think of few problems interleaving faults with ack. I'll hold them until
> I see the actual proposal.
>
This is the essence of the resolution to REL 115 and Rel 108.

The concern is the lowered funtionality of polling response.

here is a pseudo exampl

<Faults>
    <Fault>
          <FaultType>  processingError </FaultType>
           <RefToMessageIDs> ... list of message ids which had that 
fault ... </RefToMessageIDs>
     </Fault>
    <Fault>
          <FaultType>  BadHeader </FaultType>
           <RefToMessageIDs> ... list of message ids which had that 
fault ... </RefToMessageIDs>
     </Fault>
 </Faults>

The above xml structure can cary a separate list of messageIDs which 
were not delivered for a specific set of fault codes.



Its major problem is that it requires keepting fault information in the 
persistence of the receiver.

Here it is again.


>
>  
>
>>    
>>
>>>
>>>      
>>>
>>>>>>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".
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>+1
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>--
>>>>----------------------------------------------------
>>>>Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
>>>>Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>>>
>>>>
>>>>        
>>>>
>>>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>>>
>>>
>>>
>>>      
>>>
>>--
>>----------------------------------------------------
>>Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
>>Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>    
>>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>
>  
>


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