A few excerpts:
From WS-Addressing 08/2004
(http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/) Some processors may use message identifiers (<wsa:MessageID>) as part of a uniqueness metric in order to detect replays of messages. Care should be taken to ensure that a unique identifier is actually used. For example, it may be appropriate in some scenarios to combine the message identifier with a timestamp.
From WS-Addressing Additions and Updates 04/2004
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/ht...) 2.3 MessageID and Retransmission The purpose of the MessageID header is to assign each message a unique identity. This identity can be used for duplicate detection, message correlation, and many other purposes. The prior revision of WS-Addressing required that no message share the exact same MessageID content. This statement posed a problem for reliable messaging [WSRM], which retransmits the exact same application message to compensate for transient communication failures (dropped messages). This revision relaxes the requirement slightly so that messages that have the same application intent may use the same MessageID. This definition allows MessageID to be used for correlation in the presence of retransmissions. Allowing the retransmission caused a minor security issue since a retransmission might be interpreted as a replay attack. The security considerations section describes how a timestamp may be used to resolve this issue.
From WS-GRAM user guide:
(http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/execution/wsg...) A submission ID may be used in the GRAM protocol for robust reliability in the face of message faults or other transient errors in order to ensure that at most one instance of a job is executed, i.e. to prevent accidental duplication of jobs under rare circumstances with client retry on failure. The managed-job-globusrun tool always uses this feature, requiring either a submission ID to be passed in as input or a new unique ID to be created by the tool itself. If a new ID is created, it should be captured by the user who wishes to exploit this reliability interface. The ID in use, whether created or passed as input, will be written to the first line of standard output unless the quiet mode is in effect. If a user is unsure whether a job was submitted successfully, he should resubmit using the same ID as was used for the previous attempt. Quoting Takuya:
Karl:
Could you tell me the pointer to the standard spec. of the asynchronous operation binding you mentioned in the telecon?
I've found that WS-Addressing has "message information headers", which can carry the information that is necessary to implement asynchronous operations, but what you mentioned seems to be more than that... -- Takuya Araki Grid System Technology Group Internet Systems Research Laboratories NEC Corporation <t-araki@dc.jp.nec.com>