[rm-wg] Failure of Lifecycle State change operations

[David Snelling]

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)