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


Sunil,

My comments are inline:

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

<Iwasa>
I'm not sure what you mean by "Poll was sent asynchronously".
Do you mean requesting acknowledgment message in the
HTTP request message from receiver to sender, after receiver
received PollRequest message?
If this is the case, the current spec doesn't assume it can be done.
See the following text in section1.7 and 2.1.

Section1.7
-------------
Polling RM-Reply Pattern:
We say that the Polling RM-Reply pattern is used if a second underlying
protocol request is issued to the receiver of a previous message, in order
to obtain an RM-Reply. The RM-Reply is contained in the underlying protocol
response to this request. This polling pattern is expected to be used in
situations where it is inappropriate for the sender of reliable messages to
receive underlying protocol requests.


Section2.1
------------
(3) Poll Messaging Model
With this messaging model, a second underlying protocol request is issued in
the same direction as the one containing the outbound Reliable Message to
act as a request for acknowledgment. The Acknowledgment Message is contained
in the underlying protocol response to this request. This messaging model
may be used in situations where it is inappropriate for the sender of
reliable messages to receive underlying protocol requests. The figure 3
shows this model.

We can change the spec to allow that if we want, but I don't
think it is nessesary and make the spec complicated, since
we may need to add new attribute to specify that - syn Ack
or async Ack for PollRequest.

Thanks,

Iwasa
</Iwasa>



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



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