OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]