Sunil Kunisetty wrote:
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.
Minor type. I meant "need not 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: ;
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.
