Re: [wsrm] message headers for Ack and Fault ??

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

Tom Rutt wrote:

> Sunil Kunisetty wrote:
>
> >>>>I ask a question:
> >>>>
> >>>>If the only allowed value for reply pattern in a reply is the one that
> >>>>is on the request, why bother returning it in the response at all?
> >>>>
> >>>>
> >>>>
> >>> How do you correspond a response to a request if the Poll request
> >>> is also sent asynchronously? Note that a callback is also asynchronous.
> >>>
> >>> In the above example, if the Poll was also sent asynchronously, how do
> >>> you know (unless there is an attribute or this element) that ack was for
> >>>
> >>>
> >>the
> >>
> >>
> >>> poll or the callback?
> >>>
> >>>
> >><Iwasa>
> >>I'm not sure what you mean by "Poll was sent asynchronously".
> >>Do you mean requesting acknowledgment message in the
> >>HTTP request message from receiver to sender, after receiver
> >>received PollRequest message?
> >>If this is the case, the current spec doesn't assume it can be done.
> >>See the following text in section1.7 and 2.1.
> >>
> >>
> >
> > 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.

> If the sender can accept an http request, they would use the callback
> reply pattern.
>

  In the use case I suggested, which I very clearly explained twice, the
  User indeed used the Callback reply  and he didn't get the Ack/Fault for
  a while. So instead of retrying with the Callback pattern, he did a Poll
  for the same message. So the question is how to distinguish the Ack
  if the Poll was used as a robust in-out pattern.

  I don't see anything wrong with this scenario and I don't believe that it is
  creating new requirements.

  Whether it is important enough to be addressed or not is a secondary issue.
  If the TC feels that this is not important enough, I'm fine. But I'd like to
  point out that this is a possible scenario.

>
> I do not see a requirment for what your are suggesting
>
> Independent of this discussion on the need for messageHeader on reply,
> we could resolve the new Rel115/108 issue by having the poll response
> having a different header
> than the normal response to also convey list the fault codes for faulted
> messages in the poll range.
>
> >
> >
> >
> >>Section1.7
> >>-------------
> >>Polling RM-Reply Pattern:
> >>We say that the Polling RM-Reply pattern is used if a second underlying
> >>protocol request is issued to the receiver of a previous message, in order
> >>to obtain an RM-Reply. The RM-Reply is contained in the underlying protocol
> >>response to this request. This polling pattern is expected to be used in
> >>situations where it is inappropriate for the sender of reliable messages to
> >>receive underlying protocol requests.
> >>
> >>Section2.1
> >>------------
> >>(3) Poll Messaging Model
> >>With this messaging model, a second underlying protocol request is issued in
> >>the same direction as the one containing the outbound Reliable Message to
> >>act as a request for acknowledgment. The Acknowledgment Message is contained
> >>in the underlying protocol response to this request. This messaging model
> >>may be used in situations where it is inappropriate for the sender of
> >>reliable messages to receive underlying protocol requests. The figure 3
> >>shows this model.
> >>
> >>We can change the spec to allow that if we want, but I don't
> >>think it is nessesary and make the spec complicated, since
> >>we may need to add new attribute to specify that - syn Ack
> >>or async Ack for PollRequest.
> >>
> >>Thanks,
> >>
> >>Iwasa
> >></Iwasa>
> >>
> >>
> >>
> >>> -Sunil
> >>>
> >>>
> >>>
> >>>>>-Sunil
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>In fact, this would clarify that a reliable message is one which has
> >>>>>>>>a rm:messageHeader.
> >>>>>>>>
> >>>>>>>>The response is not a reliable mesage, unless it is using
> >>>>>>>>
> >>>>>>>>
> >>piggybacking.
> >>
> >>
> >>>>>>>>Lets open a new issue on this one.
> >>>>>>>>
> >>>>>>>>Tom Rutt
> >>>>>>>>WSRM Chair
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>--
> >>>>>>----------------------------------------------------
> >>>>>>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.
> >>
> >>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>--
> >>>>----------------------------------------------------
> >>>>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.
> >>
> >>
> >
> >
> >
>
> --
> ----------------------------------------------------
> Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133