Re: [wsrm] New Issue

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

 If we do accept this, here are the  changes that we need
to do.

1. Add an optional replyTo attribute to PollRequest
2. pg 6/line 177: Remove the replyTo attribute for Poll pattern in Request  (this may contradict to what I said in the editorial comments...)
3. pg 7/line 212:Title of Example 3 would read "Acknowledgment Message embedded in HTTP Request"
4. pg 7/line 213:HTTP Headers will have to change (should use POST)
5. pg 8/line 239:Title of Example 4 would read "Fault  Message embedded in HTTP Request"
6. pg 8/line 240:HTTP Headers will have to change (should use POST)
7. pg 11/lines 334-339 should be reworded as follows:

          We say that Polling
RM-Reply pattern is used if a second underlying request is issued to the
          receiver of
a previous message, in order to obtain a RM-Reply. The RM-Reply can be
either
          contained in
the underlying response to this poll request or in a separate underlying
request
          from the receiver
to the sender. This poling pattern is generally expected to be used in
          situations where
it is inappropriate for the sender of reliable messages to receive underlying
          protocol requests
(behind the firewall cases) or to avoid resending bulk messages often.

1. pg 15/Figure 3. The 3rd line should be titled "Underlying protocol Response/Request".
2. pg 28/section 4.3
1. Table 9: Add an optional attribute call replyTo of type anyURI
2. We need to mention that RM-Reply MUST be contained in the underlying response of the Poll request if this attribute doesn't exist and should be sent  in an underlying request to the endpoint identified by this attribute if exists.
3. And finally the schema has to reflect this  by adding an optional attribute to the PollRequest element.

 -Sunil

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.