[Registry-dev] Resource lifecycle handling

[Glen Daniels]

Hi Deepal, all:

Before we do anything this concrete, I'd really like to understand all 
the requirements for the various kinds of things people want to do with 
lifecycle handling, and then build something that accommodates the 
general requirements while still supporting particular lifecycles as you 
describe.  So bear with me as I hit the drawing board here. :)

Lifecycle management, as far as I can see, involves a few pieces:

* A property (or multiple properties) indicating which state(s) a 
resource is in with respect to a lifecycle.

* A set of values for each such property, and valid transitions between 
them.

* A set of behaviors (for instance "move resource from /dev/ to /qa/", 
"send email to Fred") associated with particular transitions.

* Some UI associated with each state

So in *some* cases, we'll want to have particular directories in the 
Registry for particular states - for instance it definitely seems 
appropriate for some users to have "/qa/"  and "/production/" or 
"/tested/" and "/deployed/".  When something has been approved after 
testing, actually copying to somewhere like "/deployed/" seems good, 
since the production system is probably running pointing it's 
configuration at the "http://registry/deployed/" URL.  But there are 
other transitions (for example "ready for review -> reviewed" which 
might not warrant a copy, just a state change.

This is why I'm reluctant to tie every state to a top level directory. 
Also, I'd like us not to enforce states as top level directories anyway, 
since it's very possible that some people would rather have 
"http://registry/myDepartment/services/deployed" than 
"http://registry/deployed/myDepartment/services".

So I'm envisioning something like this:

Each resource can be on potentially multiple lifecycles.  On the Java 
side, we have something like:

Resource {
   Iterator<Lifeycle> getLifecycles() {...};
   Lifecycle getLifecycle(String name);
   void addLifecycle(Lifecycle lc);
}

Each Lifecycle is a plugin that looks something like this:

interface Lifecycle {
   String getName();

   // Associate a new Resource with this lifecycle.  This could
   // set custom properties, create sub-directories, etc...  If
   // this throws an Exception, the association has FAILED.
   void associate(Resource newResource) throws Exception;

   // Do something (change state) - action names are lifecycle-
   // specific, and it's up to the implementation to decide
   // if a given transition is allowed, and what to do if so.
   void transition(RequestContext context, String action)
            throws Exception;
}

So a simple example:

SimpleLifecycle implements Lifecycle {
   static final String STATEPROP = "simple.state";
   static final String INIT_STATE = "init";
   static final String FINISHED_STATE = "done";

   void associate(Resource resource) {
     // might check to see if it's already there 1st...

     // Set custom state property for this LC
     resource.setProperty(STATEPROP, INIT_STATE);
   }

   void transition(RequestContext context, String action)
     throws Exception {
     Resource res = context.getResource();
     String curState = resource.getProperty(STATEPROP);
     if (curState == null)
       throw new Exception("Not in this lifecycle");

     // We only know how to "finish"
     if (curState.equals(INIT_STATE) &&
          action.equals("finish")) {
       res.setProperty(STATEPROP, FINISHED_STATE);
       // send an email, etc.
       return;
     }

     throw new Exception("Invalid transition or action");
   }
}

So by judicious use of Handlers and Lifecycles, you can easily do stuff 
like - 1) every resource that gets dropped into "/myarea" in the 
registry URL space is automatically started on the "doc_approval" 
lifecycle, or 2) every WSDL in the system goes through the "ws-i 
conformance" lifecycle.

The last important piece of this is some way to tie into the UI - each 
lifecycle essentially gives us new "actions" that can be performed on 
each participating Resource.  So if we had a method (I think on 
Registry) like:

   Iterator<Action> getValidActions(Resource r);

and one on Lifecycle like:

   Iterator<Action> getValidActions(RequestContext r);

(the RequestContext offers access to the Resource, the Registry, etc)

then that could use the current state of the Resource and even the 
current user to determine what each Lifecycle contributes.  At first the 
valid actions could simply map to URIs (maybe like 
"r1;lifecycle[simple]:finish" for the above example), and we could 
display a simple little list of valid actions in a "lifecycle" pane. 
Clicking on them would POST to the URL (technically shouldn't use GET 
due to side effects).  The "state change" URLs would also appear in the 
Atom feed for the Resource as links.

Eventually we could also support forms that would allow custom data to 
affect the action as parameters - so if a given lifecycle accepted an 
email address as an parameter to the "approve" action, that could be put 
in via the UI and submitted as the POST data.

Sorry for the length of this but I hope I got the idea across.  With 
this kind of a generic, not too complicated system, we can still build 
exactly the kind of "default" lifecycle you were thinking about, Deepal, 
but we wouldn't burn it in - it would be a plugin that users would be 
able to use or add to / replace with their own custom lifecycles.

Thoughts?

--Glen

Deepal Jayasinghe wrote:
> Hi all,
> 
> Following are the what I am planing to do for lifecycle handling.
> 
> - Lifecycle consists of five pre-difined phases ( Created ,Developed 
> ,Tested ,Deployed and Retired)
> - Phases can move only forward not backward , eg we can move from 
> Created  to Developed.
> - There will be four directory in the root level to represent all those 
> phases except Created   (something similar to SVN trunk , branch and tags)
> - When moving from one phase to another resource will be copied into the 
> correct location
> 
> For example say we create a resource like
> /products/webservices/Axis2/1.4
> then that will be in the Created  state. When we move it will go into 
> the Developed  state and all the resources under the above path will be 
> copied into
> /Developed/webservices/Axis2/1.4 .
> 
> To have the state of the resource we need to add a new flag to the 
> databases , so need to change the database as well.
> 
> Thoughts  .....
> 
> Thank you,
> Deepal
>> One more thing ,
>>
>> I think we can have a set of pre-defined phases and provide ability to 
>> chose set of them for a given resource. Then in registry.xml we define 
>> all the available lifecycle phases and add an ability to define them 
>> from the UI.
>>
>> Thanks
>> Deepal
>>> Hi all,
>>>
>>> Now we have full support resource copy and rename we can implement 
>>> resource lifecycle management. But we need to think how we are going 
>>> to do that , and we need to find out what are the phases we are going 
>>> to have in our lifecycle management.
>>>
>>> So I am thinking to implement something similar to SVN branching as a 
>>> way of lifecycle handling , for example when going from QA to 
>>> production there will be new branch created for the production phase 
>>> , and it will get a new URL so that we can set the permission as well.
>>>
>>> When it come to implementation are we going to add a new method into 
>>> Registry interface or are we going to introduce new class to handle 
>>> the lifecycle. I would rather like to come up with a new class for 
>>> lifecycle (LifeCycleManger) and separate tab in the GUI as well.
>>>
>>> One other thing we need to have is custom code running support when a 
>>> resource state changes. Say someone tries to move a Resource from QA 
>>> phase to production phase then  there should be some set of 
>>> pre-conditions and post conditions so we need to have the support for 
>>> them as well. This is somewhat  similar to media type handling we 
>>> have in the current implementation.
>>>
>>> I think we have to have a section in registry.xml for lifecycle 
>>> handling , and which may contains configurations such as ;
>>>  - What are the phases in the lifecycle (Development , QA ,Production 
>>> and etc...) , and which should be configurable as well
>>> - A way to register handlers for state changes
>>> - Associate URL name (suffix) for the phase
>>> - Permission based on the lifecycle, (who can change the resource 
>>> lifecycle states. )
>>>
>>> Thoughts ... ?
>>>
>>> Thanks
>>> Deepal
>>>
>>>
>>>
> 
> 
> 
> _______________________________________________
> Registry-dev mailing list
> Registry-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>