[Registry-dev] Resource lifecycle handling
Paul Fremantle
paul at wso2.com
Thu Mar 6 23:47:42 PST 2008
Glen
I really like this model. I guess I was a bit surprised that lifecycle was
being "baked" into the Java code - I expected it to be a usage of more
generic properties etc. However, that doesn't mean I'm against it - just
getting used to the idea.
I'm very much +1 on NOT hard-coding the actual lifecycle states but having
some pre-defined ones that can be improved later by the customer.
Paul
On Wed, Mar 5, 2008 at 6:29 PM, Glen Daniels <glen at wso2.com> wrote:
> 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
> >
>
> _______________________________________________
> Registry-dev mailing list
> Registry-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wso2.org/pipermail/registry-dev/attachments/20080307/cc04f155/attachment-0001.htm
More information about the Registry-dev
mailing list