Re: [wsrm] New Issue

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

iwasa wrote:

> Sunil,
>
> I am neutral whether we allow to send back Poll
> reply in a different HTTP connection or not.
>
> However I don't think the proposed changes are appropriate,
> because it creates inconsistency. (E.g. Figure 3)
> The essential concern I have with your proposal is
> inconsistency of the relationship among Response, Callback
> and Poll reply pattern.

 I'm confused. How is this change can create inconsistencies
 with Response or Callback when the this figure (and the proposal)
 is very specific to the 'response for Poll'?

 They change should not interfere with Callback or Response pattern
 as the replyTo attribute is on the PollRequest element. Note that
 as part of this discussion (in the con. call), we have decided that
 replyTo attribute for ReplyPattern should not be used if the pattern
 is either 'Response' or 'Poll'.

>
> Because an appearance of replyTo attribute is used to
> differentiate bindings of sync Poll Reply(which reply is
> on the same HTTP connection with PollRequest) and
> async Poll Reply(which reply is on the different HTTP
> connection with PollRequest).

 Correct.. Essentially giving async capabilities to the Poll
 request.

>
> In that case, why don't we do the same thing
> for Response reply pattern and Callback reply
> pattern?
>

Because that's how the patterns are defined. You may be
 confusing with the WSDL operations. Note that one can
 use (though not recommended) the Callback pattern for
 a WSDL 1.1 operation, in which case the RM-Reply
 it sent to the listener identified by the reply-to attribute

>
> In other words, we could have two messaging models(or
> reply pattern or whatever) but not three reply pattern
> as follows:
>     Model1:
>         1. Sender sends Reliable Message to receiver.
>         2. Receiver sends Ack or Fault to the sender.
>     Model2:
>         1. Sender sends Reliable Message to receiver.
>         2. Sender sends Poll message to receiver.
>         3. Receiver sends Ack or Fault to the sender.
>
> And model1 will be either:
>     - The current Response reply pattern
>       (Ack or Fault is in the HTTP Response) or
>     - The current Callback reply pattern
>       (Ack or Fault is in the HTTP Request)
> And model2 will be either:
>     - The current Poll reply pattern
>       (Ack or Fault is in the HTTP Response) or
>     - New poll reply pattern
>       (Ack or Fault is in the HTTP Request)
> And the appearance of replyTo differentiate
> those two binding patterns for each of above models.
>

Isn't that what we are doing right now with my new proposal?

>
> Actually this is what I have insisted in the F2F meeting
> last year. Despite of that, we decided on the current three
> reply pattern with your request (which is mixing HTTP binding
> with messaging models, IMHO). I would say it was not
> good decision and it made the spec depend on the HTTP like
> (Req/Res type) underlying protocol. But anyway we chose it and
> the many of the spec depend on the three reply pattern now.
> So if we want to change that, it might require to update many more
> portion of the spec.
>
> In conclusion, what I would propose are:
>     1. We keep it as is.  (It means that we do not allow
>         Poll reply in the HTTP request.), or

We already accepted this. So I'm not sure what the issue
 here.




>
>     2. Allow to send Poll reply in HTTP request. And
>         update other portion of the spec consistent as
>         described above.
>         (Replacing three reply pattern with the above
>           two messaging models.)
>

But that's what the new proposal allows? What you are
 suggesting is strictly editorial.

>
> Since we have time limited, 1. above might be
> better for now unless TC member agrees with
> this change immediately, and accept only three days review
> period (from Monday to Wednesday next week)
> for this change. In that case, I will do this change by
> the end of this week.
>

 we already voted on this and accepted.

>
> Anyway I don't think this is a critical issue
> we have to resolve immediately.

 To me this is critical. Because without this I can't do
 poll with JMS transport.

>
> We can discuss this for the next version if TC exists,
> and if we want. Timing to finalize the current spec
> is more critical, I believe.
>
> Thanks,
>
> Iwasa
>
> ----- Original Message -----
> From: "Sunil Kunisetty" <Sunil.Kunisetty@oracle.com>
> To: <wsrm@lists.oasis-open.org>
> Sent: Wednesday, March 03, 2004 6:47 AM
> Subject: Re: [wsrm] New Issue
>
> >
> >  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.
> >
>
> 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.