Alain, Karl:
Thank you for the excerpts!
So Karl, let me confirm your opinion:
Are you thinking of using the method which is implemented in WS-GRAM?
If so, I agree with that it increases the reliability of the system,
but it doesn't seem to be able to replace asynchronous operations completely.
What it does is:
* Give a unique message ID to a (synchronous) message
* In case of trouble, the client can re-send the same message using the same message ID
It surely increases the reliability of the system, but it is for synchronous operations;
it wouldn't be suitable for operations which take a long time.
In such a case, a client can't tell if there are some network/server problems, or it is normal and just taking a long time;
they should be treated differently. For example, if there might be some network/server problems, it might be desirable to
inform that to the user; on the other hand, if it is normal and just taking a long time, it shouldn't be informed to the user.
In addition, it only supports "polling", which causes more overhead than "callback" method.
(By the way, it seems that GRAM has "batch mode" as an application level asynchronous operation.
That's why the current method is enough for GRAM, I think.)
Comments?
--
Takuya Araki
Grid System Technology Group
Internet Systems Research Laboratories
NEC Corporation
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