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

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

>
> > > >
> > > 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.

>
>
> 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.
> >