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

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

Tom Rutt wrote:

> Sunil Kunisetty wrote:
>
> >Tom Rutt wrote:
> >
> >
> >
> >>Tom Rutt wrote:
> >>
> >>
> >>
> >>>Tom Rutt wrote:
> >>>
> >>>
> >>>
> >>>>Jacques Durand wrote:
> >>>>
> >>>>
> >>>>
> >>>>>Could someone remind me why we need an RM:MessageHeader element for
> >>>>>Ack and Fault messages?
> >>>>>I could not justify this to our implementor Hamid.
> >>>>>Such headers could not possibly have a meaning for these signals, as
> >>>>>they would have to fully relate to a business response that we want
> >>>>>to be reliable, in case
> >>>>>of request-response pattern, or more generally in case these signals
> >>>>>piggy-back on business messages.
> >>>>>
> >>>>>Jacques
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>If we do not have a business reason to give the response its own
> >>>>identity for WS-relibability protocol, then
> >>>>we should do that.
> >>>>
> >>>>I do not see any requirement in our Requirements document which
> >>>>warrants the Message header for a reply which
> >>>>is not itself a reliable message.
> >>>>
> >>>>
> >>>I mistyped here.  What I meant to say is we have to justify the need
> >>>for a unique message ID for the reply, unless itself is piggybacking a
> >>>reliable message in the return direction.   I cannot come up with a
> >>>reason.  The messageID for the request serves for all logging purposes.
> >>>
> >>>
> >>The other two elements of the message header are expiry time and reply
> >>pattern.
> >>
> >>The expiry time is not necessary for a reply (it is a total waste of
> >>bandwidth for the reply to include this element), and the reply pattern
> >>must be the same on a reply as a request, so why bother sending either.
> >>
> >>
> >>
> >
> > There are some use cases that require to know the reply pattern used in
> > the response (Ack/Fault).
> >
> > For example, Sender sends a reliable message with callback pattern.
> > Assume he didn't receive the ack. or fault for a while. Sender 'polls'
> > the Receiver for that message. Finally he gets the ack. He may not
> > know whether he received the ack. because of Poll or Callback, as the
> > response will be the same. Ofcourse, one may say why does he need
> > to know that as long as he receives it. But it would be useful to know
> > so that he can do the cleanup (say to stop the callback listener etc.)
> >
> The callback response comes on an http request.
>
> The poll response comes on an http response.
>

 Not necessarily. What is important is that the poll request is sent from the
 original sender itself in a different transaction/connection. Ack may be sent
 as a (http) request if the Sender uses robust in-out pattern (robust in-out
 pattern is the same as the in-out except that out is sent to node/listener other
 than the sender node/listener).

 Again it may not be possible in all cases for the Sender to receive the
 request if it is inside the firewall, however, in the above use case I mentioned,
 the Sender is doing the poll as a follow-up for the Callback. So we have
 an implicit assumption that the Sender can receive a Http request.

>
> I do not understand how the sending rmp could be confused.
>

 I hope this clarifies.

>
> >
> > For the same reason [as part of REL 99], we decided that Ack. or Fault
> > should have this element with the same value.
> >
> > We can still get rid of the MessageHeader for responses and solve this
> > particular problem by having an additional optional attribute on the
> > Response element itself to indicate the reply pattern used.
> >
> > -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.
> >>
> >>
> >
> >
> >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