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] comments and ideas

Delayed reply...

On 06-04-2003 15:24, Paolo Romano wrote:

>>acknowledgment is received is an expensive mechanism, whose advantage is
>>simplicity, but which may lead to severe overheads in case of loss of
>>acknoledgments for large messages.
>> One solution may be defining an apposite "inquiry" message, which could
>>be sent in case of failure suspect by any indoubt part. Note that such a
>>message could also be useful in order to ensure end-hosts state
>>synchronization: e.g. it could be used in a request-response mep to let
>>the requester acknowledge the responder upon the receiption of the
>>response message (see pag.10 Nokia_WebServicesReliability "Because
>>Responder depends on Step 6, MEP must be extended for delivering
>>information to Responder after step 4.") What do you think about it?
>>ebMS' StatusRequest service does this, more or less.
>><snip />
> <paoloReply>
> If I remember well, ebMS' StatusRequest should not be employed for
> reliable messaging, but only to discover availabilty of service. Please
> correct me if i am wrong. I suggest to use this inquiry mechanism to avoid
> retransmission of unacknowledged requests.
> </paoloReply>

The ebMS intent was to avoid intermediate checks using the StatusRequest 
because (IIRC) the most common case was perceived to be that a failure 
had occurred in request transmission (containing more data, et cetera). 
  The StatusRequest was added to improve final agreement on status 
synchronisation.  It's effectively one last chance for the sender to 
hear a "yes, I got it" or confirm "no, don't know about that message" 
after it has effectively given up on changing the receiver's idea of 
that status.

We can certainly discuss this use case and the various cost / benefit 
decisions made in previous specifications as we move forward in this TC.


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