Search Wiki Pages Project: rm-wg     Wiki > 22ndJune2007 > View Wiki Page

wiki1823: 22ndJune2007

Agenda Items Paul has been pondering the top level class hierarchy and relationships for the Ref Model. See https://forge.gridforum.org/sf/docman/do/listDocuments/projects.rm-wg/docman.root.discussion_documents?_message=1182384417965 for the latest two diagrams. Whilst he can easily imagine that the patterns are managed things and have a life cycle, he finds it harder to visualize the Policy component as a descendent of GridComponent, especially in terms of the life cycle. We discussed the first draft of Lifecycle on the last call and it became apparent that there were a number of use cases where a call to a lifecycle change request (e.g. Commission) could not return synchronously in a sensible time. Therefore it seems likely that Lifecycle operations should be asynchronous. We should agree this on the call Friday. Once that is agreed, we need to discuss the management of errors in this setting. If all goes well, the GC sends the client a notification of state change, failure to deliver etc can be managed by time outs at the client's end, (i.e. wait a sensible time and pole the GC to see if it's state changed) or policy on the GC, i.e. send periodic status notifications independent of state changes on the GC. But what is the best way to handle errors in this setting? Is a simple error substate adequate. For example, if a Commission operation fails, the GC state changes to Extant_substate_Error. Or do we provide a separate state property for this. We need to be careful to distinguish this notion of failure (i.e. on the latest operation) from the state of the GC, i.e. Extant_substate_Failed.

	Versions		Associations		Attachments		Back Links

Version	Version Comment	Created By
Version 1		Paul Strong - 06/21/2007