[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] message headers for Ack and Fault ??
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. I do not understand how the sending rmp could be confused. > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]