[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] New Issue
Sunil Kunisetty wrote:
The current definition of the Poll RM-Reply pattern says that the Poll response
should be the same underlying transport connection as that of the Poll request.This is good and useful for Senders behind the firewall case and if this is the
only usecase we were supporting. This was indeed the case onetime.However, since then, we have relaxed the usage of Poll and made it a general
purpose status query kind of thingy which is usable even with Request and
Callback.However, we cannot use it with Callback if the underlying transport is truly one-way
such as JMS transport.Take the following example:
Sender sends a one-way message with RM-GD feature. However, it hasn't received
the Ack or Fault for a long time. Assume he is using a pure one-way transport.Instead of retrying. He wants to poll it again. Since his transport is one-way, he
can't get the response on the same connection as that of the request. Instead,
he wants the Receiver to send him the Poll Ack/fault to its listener just as the
callback.Note that this use case assumes the Sender can listen to acks and faults.
However, the current specification doesn't have this provision. And hence
I propose that we remove the restriction on the response.I propose that PollRequest takes an optional ReplyTo element and if
present, the Receiver sends the Poll response to this endpoint.If this element doesn't exist, then the Receiver sends (or rather attempts)
the response in the same connection.Comments???
-Sunil
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]