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:

>>>>I ask a question:
>>>>
>>>>If the only allowed value for reply pattern in a reply is the one that
>>>>is on the request, why bother returning it in the response at all?
>>>>
>>>>        
>>>>
>>> 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?
>>>      
>>>
>><Iwasa>
>>I'm not sure what you mean by "Poll was sent asynchronously".
>>Do you mean requesting acknowledgment message in the
>>HTTP request message from receiver to sender, after receiver
>>received PollRequest message?
>>If this is the case, the current spec doesn't assume it can be done.
>>See the following text in section1.7 and 2.1.
>>    
>>
>
> I don't think that restriction is warranted. What is important is the Poll
> request is initiated by the Sender in a different transaction/connection
> than the original message. How the response (Ack or Fault) is sent
> is an implementation issue and doesn't effect our protocol one way
> or other.
>
I do not understand.  The justification for poll is when the sender 
cannot accept http requests.

If the sender can accept an http request, they would use the callback 
reply pattern.

I do not see a requirment for what your are suggesting

Independent of this discussion on the need for messageHeader on reply,
we could resolve the new Rel115/108 issue by having the poll response 
having a different header
than the normal response to also convey list the fault codes for faulted 
messages in the poll range.

>
>  
>
>>Section1.7
>>-------------
>>Polling RM-Reply Pattern:
>>We say that the Polling RM-Reply pattern is used if a second underlying
>>protocol request is issued to the receiver of a previous message, in order
>>to obtain an RM-Reply. The RM-Reply is contained in the underlying protocol
>>response to this request. This polling pattern is expected to be used in
>>situations where it is inappropriate for the sender of reliable messages to
>>receive underlying protocol requests.
>>
>>Section2.1
>>------------
>>(3) Poll Messaging Model
>>With this messaging model, a second underlying protocol request is issued in
>>the same direction as the one containing the outbound Reliable Message to
>>act as a request for acknowledgment. The Acknowledgment Message is contained
>>in the underlying protocol response to this request. This messaging model
>>may be used in situations where it is inappropriate for the sender of
>>reliable messages to receive underlying protocol requests. The figure 3
>>shows this model.
>>
>>We can change the spec to allow that if we want, but I don't
>>think it is nessesary and make the spec complicated, since
>>we may need to add new attribute to specify that - syn Ack
>>or async Ack for PollRequest.
>>
>>Thanks,
>>
>>Iwasa
>></Iwasa>
>>
>>    
>>
>>> -Sunil
>>>
>>>      
>>>
>>>>>-Sunil
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>In fact, this would clarify that a reliable message is one which has
>>>>>>>>a rm:messageHeader.
>>>>>>>>
>>>>>>>>The response is not a reliable mesage, unless it is using
>>>>>>>>                
>>>>>>>>
>>piggybacking.
>>    
>>
>>>>>>>>Lets open a new issue on this one.
>>>>>>>>
>>>>>>>>Tom Rutt
>>>>>>>>WSRM Chair
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>--
>>>>>>----------------------------------------------------
>>>>>>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






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