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?
>
> -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: ;
>>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: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
