[graap-wg] More async/asymmetry comments

[Karl Czajkowski]

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 at 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 at univa.com