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: resolution agreed for rel 33 and rel 50


The attached text was agreed at the 11/25 meeting to resolve rel 33 
(reopened) and Rel 50.


-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: *Message Delivery*:

The following text was voted resolve reopened issue Rel 33 at the Nov 25 WSRM meeting

 

*Message Delivery*:

 

Message delivery is the action of transferring the responsibility of processing further a message, from the RMP and onto the next processor entity. This action marks the end of the RMP processing for this message. The time at which this action occurs must be clearly identifiable so that the next message processor can always establish in which order two deliveries are made.

 

Examples of message delivery are:

·        pushing the message in a queue accessible by an application,

·        calling back an application component,

·        storing the message in a database where it is accessible by the next processor.

 

 

*Acknowledgement*:

 

An acknowledgement is a message containing an RM:Response element referring to at least one previous message (and containing no RM:Fault element).

 

An acknowledgement means that the acknowledged message has been successfully delivered,  meaning that it has satisfied all the reliability requirements placed on it for delivery, and that the RMP, having made the message available to its next processor, is no longer responsible for processing it further.

 

 

The following agreed text resolved Rel 50: (motion from 11/25 meeting closed the issue with this text.)

*Expiry Time*

ExpiryTime indicates the ultimate date after which the receiver RMP MUST NOT deliver a received message to the application.

After a message has been sent for the first time, ExpiryTime in a message MUST NOT be modified in any case by the Sender, when resending the message: two messages with same ID (duplicates) MUST have same ExpiryTime.

When a message expires on the Sender side before being sucessfully sent, a Sender RMP MUST NOT send it or resend it, and must communicate a delivery failure to the Sender application.

NOTES:  Given the above definition of ExpiryTime, in case duplicate elimination is required, when a received message is processed, it is sufficient to only check for its duplicates among IDs of past messages that have not expired yet at the time of the duplicate check.

 

 



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