[rm-wg] Failure of Lifecycle State change operations
David Snelling
David.Snelling at UK.Fujitsu.com
Fri Jun 22 09:46:02 CDT 2007
Folks,
For Friday, if we have time.
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, I think 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.
I hope to talk to you Friday.
--
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
Fujitsu Laboratories of Europe Limited
Hayes Park Central
Hayes End Road
Hayes, Middlesex UB4 8FE
Reg. No. 4153469
+44-208-606-4649 (Office)
+44-7768-807526 (Mobile)
More information about the rm-wg
mailing list