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

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

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

 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.