[graap-wg] More async/asymmetry comments

[Toshiyuki Nakata]

Thank you very much for your clarification.


best regards
Toshi


Karl Czajkowski wrote:

>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)
>>
>>
>>    
>>
>
>  
>

-- 
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)