Title: RE: [wsrm] message headers for Ack and Fault ??
inline <JD>
-----Original Message-----
From: Sunil Kunisetty [mailto:]
Sent: Wednesday, February 11, 2004 11:13 PM
To:
Cc: Jacques Durand; WSRM (E-mail)
Subject: Re: [wsrm] message headers for Ack and Fault ??
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.)
> >
> > 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.
> >
> 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?
-Sunil
<JD> I understand that this messageHeader serves a purpose in Responses,
but still that seems quite contrived: we apparently use it only for matching
the ReplyPattern elements between req and resp.
I believe our design would be tighter if we added the returned ReplyPattern
to the RM:Response element, as Sunil hints at as a possible alternative.
Further, I believe the ReplyPattern element in a request, would be more at its
place in the RM:Request element, as it should be associated with the element
that has "request semantics".
Doing so, the MessageHeader element would only contain ID and general message info,
and would only need be included in "reliable messages", as
the second sentence in 3.1. clearly suggests already (at odds with current usage).
Later on when we have RM:Response piggybacking on business messages, the info in
messageHeader would be totally orthogonal to the info in RM:Response.
jacques
