This is actually a very messy question. :-) There are two related problems: the lack of transactional control to group the separate operations, and the lack of QoS guarantees for notification. For the transaction problem, you are worried about a race-condition between the creation and subscription where a state change would be missed. This can be addressed in a number of ways that are all unfortunately not standards: 1) require that a subscription always trigger a notification of the "current" state at the time of subscription in addition to future state changes, etc. 2) do one state query after subscription to get approximately the same value as in (1), with the added excitement of interpreting this result that is delivered outside the notification stream. 3) provide a merged createAgreement and subscribe operation; this is what we do in WS-GRAM in GT 4.0, both to avoid the race-condition and reduce the number of message exchanges. However, even with one of these solutions there is another set of risks: notification does not really guarantee reliability or ordered delivery of notifications that the provider "tried" to send. Of course, Web services in general do not provide message delivery guarantees, but the lack of a response to the deliverNotification operation means that the sender cannot even know if the message was received successfully. One solution for WS-Agreement would be use the peer-to-peer interface variant and use the proposed domain-specific accept() operation in favor of generic subscription/notification for this important state transition. In Globus, our long-term architectural solution to the generic notification QoS problem has been to assume a soft-state methodology w/ temporal metadata. We would advocate sending a stream of redundant messages within certain max/min frequencies and letting the consumer sort it duplication or loss. This leads to a system that will converge on steady state values and may diverge under loss/congestion. These concepts were built into OGSI from the start. However, the WSRF specifications do not provide such primitives and we have not introduced extensions for this yet. So, in GT 4.0 it is incumbent on the subscriber to actually poll values as a fall-back to avoid hanging forever in the presence of notification failures! Furthermore, the network could reverse the order of multiple notifications which might be confusing for an overly-trusting consumer, depending on the state model for the topic in question. With the right temporal metadata, a consumer of a notification stream can reorder or filter out-of-order messages to avoid violating state invariants. Even without such metadata, one can often filter out meaningless or "backwards" transitions, e.g. even our "DUROC" co-allocator that consumed GRAM state change messages would guard against non-sensical job state notifications by comparing them to the currently held view of the remote job's state before doing any further processing. karl On Mar 03, Toshiyuki Nakata loaded a tape reading:
If the initiator decided to subscribe, can you tell me the sequence of subscribe/notify?
1)my original assumption. 1.1) Initiator requests CreateAgreement 1.2)Provider creates an empty Agreement (With agreement state Not-Yet-Complete)and returns an EPR to the created Agreement. 1.3)Initiator subscribes for the notification using the returned EPR.
My worry is what if the provider had been very quick and had agreed to the agreement and had changed the agreement status to Agreed between timing 1.2 and 1.3?
Would the Initiator be notified of this at the timing of 1.3? or would the initiator have to do some kind of atomic chack and subscribe?
Best regards Toshi
-- We have moved to a new Office!! Toshiyuki Nakata ????? Internet System Laboratories NEC t-nakata@cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219)
-- Karl Czajkowski karlcz@univa.com