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


 

Tom Rutt wrote:

Sunil Kunisetty wrote:

>Tom Rutt wrote:
>
>
>
>>Sunil Kunisetty wrote:
>>
>>
>>
>>>>
>>>>
>>>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.
>>
>>
>
> While that is the primary justification, that's not the only one. For your
> recollection, other use cases are avoid resends & for  thin clients.
>
> Also, that would have been the prominent one if Poll was only used for
> that scenario, and not with other patterns. However, now that we allow
> Poll to be used for Callbacks and Response patterns also, then the  use
> case I suggested is much more valid.
>
>
I agree that the poll request can be used to obtain status infomation
for reliable messages sent using any reply pattern.

The point I am making is that the poll request is always (by definition
and design) mapped to an underlying request/response protocol.

Thus there is no problem distinguishing a delayed callback response
(which is always on an underlying request) from a poll response
(which is always on a underlying response).

 As I mentioned earlier, poll response need to be  on the underlying response.
 The requirement we had was that poll request be sent on a separate
  transaction/connection than that of the original reliable message. Requiring
  it to be on the same response is an un-necessary implementation restriction.

 Also, when the ACK or Fault comes to the RMP/SOAP processing later,
 it  will be (most likely) agnostic to that fact that it was carried thru' a underlying
 request or underlying response.
 

 

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



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