OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Sunil Kunisetty wrote:

>Tom Rutt wrote:
>
>  
>
>>Sunil Kunisetty wrote:
>>
>>    
>>
>>>>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.
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>I've few questions:
>>>1) How does a Poll response with no faults, i,e, a regular poll response look?
>>>
>>>      
>>>
>>I intended the above faults to be added to the exsiting response schema,
>>after the current ref to message IDS delivered.  If there are no faults,
>>the structure avove is empty.
>>    
>>
>
> I do not understand. If the RefToMessageIds are embedded inside the Faults,
> if the Faults are empty, where are RefToMessageIds specified. May be I'm
> missing something. If you can send me a COMPLETE proposal, that would be good.
>
Take the exisiting header schema for response, AS IS. and add a nnew 
element for faults after the existing RefToMessagIDs element,

The current refToMessageIDs is used now, and would continue to be used 
with this proposal, to list delivered messages. and would stay the same.

The new element at the end would be JUST to list the messages which had 
faults, an addtion to the first element which lists delivered messages.

So the new poll response would list both delivered messageIDs in the 
first list, and faulted messageIDs (if any) in the second list.

>
> The above problem can be solved by having the FaultCode as an attribute of
> SequenceNumberRange. Than again the problem is current SequenceNumberRange
> element is used for both Poll Request and Poll Response.
>
>  
>
>>    
>>
>>>2) If a Callback Response has to be batched (especially want to batch fault responses)
>>>  , how does it do it?
>>>
>>>      
>>>
>>Currently the text is unclear on callback response.  However, I assumed
>>the batching for callback can only be for acks.  Faults would
>>    
>>
>
> That wan't clear to me.
>

This needs to be cleared up.  If we had this new syntax to send both a 
delivered message id list along with the faulted messageID list
it might be useful for Callback as well.

Also, I thought we agreed that for response reply pattern only a single 
message can be acked in the response. 

>
>  
>
>>have to be sent each on their own callback request.
>>
>>    
>>
>>>3) If the Poll with fault is for one msg only, then what is the relationship between
>>>    this header and that Fault header in 1.1 case and 1.2 fault subcode?
>>>
>>>      
>>>
>
> Actually I meant to ask what about the Callback Response with just one Fault?
> Or are we saying that Fault is used for Callback and Response case and Faults
> is used for Poll case.
>
The current syntax does not let the sender know what fault occured for 
messages which were not delivered.  The fault
element in response to a poll request merely states that the poll 
request failed, not that any previous message failed.

The proposal above allows the poll response to indicate past messages 
(in the range of the poll) which faulted.

>
> Anyway, a complete proposal would be useful to understand.
>
>  
>
>>This is an interesting question, I assumed a fault for a poll would be a
>>fault in the data of a poll request.   The  current
>>syntax  (without my suggested  addition above) does not allow a poll
>>response to indicate that a message in the list
>>of the poll request was faulted.  It just does not appear in the list.
>>With my proposal above, a mesage which was faulted gets
>>indecated in the additional Faults element of the poll response.
>>
>>    
>>
>>> 4) What should be the response for Expired messages? In the current proposal,
>>>      they are ignored when responding.
>>>
>>>      
>>>
>>continue to ignore them, they did not fault.
>>
>>However you would not put them in the list of messages which were
>>delivered either.
>>
>>    
>>
>>>
>>>      
>>>
>>>>Its major problem is that it requires keepting fault information in the
>>>>persistence of the receiver.
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>>>Here it is again.
>>>>
>>>>
>>>>        
>>>>
>>>Was it sent before? I don't recollect seeing it before.
>>>
>>>
>>>
>>>      
>>>
>>>>        
>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>            
>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>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
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>--
>>----------------------------------------------------
>>Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
>>Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>    
>>
>
>  
>


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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]