wsrm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrm] Rel 33 and Rel 50, follow-up
- From: Jacques Durand <JDurand@fsw.fujitsu.com>
- To: "'wsrm@lists.oasis-open.org'" <wsrm@lists.oasis-open.org>
- Date: Wed, 26 Nov 2003 17:09:17 -0800
Title: Rel 33
Following-up to last call, for our spec editor:
1. I
propose that we format the resolution of Rel 33 as a set of two definitions in
the Terminology section
(which
I suggest should be renamed Definitions section, as it is not just about setting
the vocabulary,
but
also introducing precise and new semantics):
Message Delivery:
Action of transfering 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 indentifiable so that the next message
processor
can always establish in which
order two deliveries are made.
Examples of 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 completely and
successfully delivered (see Message
Delivery).
2. Here is the
rewording of Rel 50 that was requested before it was approved, again formatted
as a Definition item.
ExpiryTime:
As a mandatory element for each message,
ExpiryTime indicates the ultimate time
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 (i.e. duplicates) MUST have same
ExpiryTime.
When a message expires on the Sender
side before being either successfully sent or acknowledged,
a Sender RMP MUST NOT send it or resend it,
and must communicate a delivery failure
to the Sender application.
NOTE:
- 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.
Jacques
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]