[graap-wg] asynchronous binding

[alain at ISI.EDU]

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/html/wsaddressdelta.asp)
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/wsgram/user/#submissionid)
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 at dc.jp.nec.com>