[Registry-dev] Resource lifecycle handling

[Deepal Jayasinghe]

> 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
Yes for all the items in the above list.
>
> 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.
Well I can not completely agree with "ready for review" and "reviewed" 
transitions. Because once you review you might do some changes. So it 
will not just state changes , I do agree we can find many instance where 
when we do such transitions changes with no content changes.
>
>
> 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".
Actually I had a chat with Chathura before sending this mail , then we 
found out there can be instance where resource can have name like 
deployed. Let's take following as use case , say we have resource 
hierarchy like below

http://registry/myDepartment/services/foo
http://registry/myDepartment/services/deployed

Then when we do the transition changes into 
"http://registry/myDepartment/services" we have to copy the resource into

http://registry/myDepartment/services/deployed

Then you can find the problem we are going to encounter. Therefore to 
solve that problem I had to introduce top directory hierarchy similar to 
SVN model.
 
>
> So I'm envisioning something like this:
>
> Each resource can be on potentially multiple lifecycles.  On the Java 
> side, we have something like:
Its depend on the way you identifying the resource , if we going to 
identify the resource be its path then resource can have only one state 
at any given time.
>
> 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");
>   }
> }
Seems good to me , and very extensible.
>
> 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.
Yes , thats a great idea.
>
> 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.  
But it is very useful and very well said.

Thank you,
Deepal