Hi Shazni, On Thu, Dec 11, 2014 at 12:06 PM, Shazni Nazeer <sha...@wso2.com> wrote:
> Hi All, > > As a proof of concept I implemented multiple lifecycle support in the > G-Reg. As Senaka pointed out, the lifecycle details are kept as resource > properties. But from the beginning it self it has been designed assuming > that resource would have only one lifecycle so that the resource property > keys have no qualification to the lifecyle. Therefore, I introduced > lifecycle name into the key so that at the implementation level we can > differentiate which property belong to which lifecycle. In the registry > core level there is no limitation of adding multiple aspects as such. Only > in the lifecycle implementation it's restricted to adding multiple > lifecycles, where in the DefaultLifecyle implementation, it just returns, > if there's already a property with the key "registry.LC.name", which can > be solved using introducing lifecycle name in the property. Moreover, the > method signature for certain methods like addCheckItems, addTransitionUI > (which is in the > org.wso2.carbon.governance.registry.extensions.aspects.utils.Utils) are > changed to get a lifecycle name so that we can include the aspect name into > the property key > > Further, the jsps related to lifecycle also have been tightly coupled with > the assumption of having only one lifecycle per resource. It takes only the > first in the list of actions to process and display the lifecycle. With the > inclusion of the lifecycle name into the properties in the resource I > modified the jsp (lifecycles_ajaxprocessor.jsp) to be able to add multiple > lifecycle and view the attached lifecyles in the same view. The view of the > lifecycle section is as shown below. > > > > > I've few questions on the following. > > GovernanceArtifactImpl's API too has methods setLcName, getLcName which > essentially assumes one artifact has one lifecycle. But I didn't change > those methods as I thought that can be kept as it is for someone to define > and get the default lifecycle. (i.e. the one like we show in the list > view). But there are also other methods like getLifecycleName, > detachLifecycle, getLifecycleState which I think need to be changed to get > aspect name as a parameter. > IMHO, the API methods need refactoring. I believe that it makes sense to have getLCNames (returns []) and setLCName (as-is), also there might need to be a concept of a default lifecycle and you may want to get/set the default. getLifecycleState (or anything that assumed the single lifecycle) should have a overloaded method that also accepts the lifecycle name. If you do not pass a lifecycle name (no arg), you should retrive the state from the default lifecycle. Does this make sense? Thanks, Senaka. > > WDYT?? > > thanks > > Shazni Nazeer > > Senior Software Engineer > > Mob : +94 777737331 > LinkedIn : http://lk.linkedin.com/in/shazninazeer > Blog : http://shazninazeer.blogspot.com > > On Wed, Dec 3, 2014 at 5:24 PM, Senaka Fernando <sen...@wso2.com> wrote: > >> Hi Isuruwan, >> >> I believe that might be a good approach to take. For example, the >> properties of lifecycles X, Y and Z would be orthogonal from each other and >> if there need to be some sort of relationship (i.e. when property A from >> lifecycle X changes so must property B from lifecycle Y), it can be handled >> at implementation level. I think that's a fair enough assumption to make. >> >> Thanks, >> Senaka. >> >> On Wed, Dec 3, 2014 at 7:21 AM, Isuruwan Herath <isuru...@wso2.com> >> wrote: >> >>> Hi Senaka/Sagara, >>> >>> IIUC in current registry API too there is no limitation to add more than >>> one aspect. >>> >>> A point to consider in this implementation IMO is: should we consider >>> allow any dependency between the life cycles attached in each "context"? As >>> Senaka mentioned if we allow to attach 1..n number of life cycles which >>> could possibly so different manipulations on the resource in state >>> transitions, this could be an issue. One option is we could let different >>> life cycles behave independently and handle the conflicts in implementation >>> level. >>> >>> Thanks! >>> Isuruwan >>> >>> On Tue, Dec 2, 2014 at 11:04 PM, Sagara Gunathunga <sag...@wso2.com> >>> wrote: >>> >>>> >>>> >>>> On Tue, Dec 2, 2014 at 10:34 PM, Senaka Fernando <sen...@wso2.com> >>>> wrote: >>>> >>>>> Hi Sagara, >>>>> >>>>> No there is no real-barrier. Even with SCXML this is possible. SCXML >>>>> is just a standard for states and transitions. We create an instance of a >>>>> state engine using a set of resource properties. If you want multiple >>>>> lifecycles, and want to retain the same model, it is a matter of using >>>>> multiple properties. If you group these together, these could end-up being >>>>> a Context that you define. But, when we say multiple we need to be careful >>>>> of whether it is 1 or 2 or 3 or X. That's what makes things complicated. >>>>> >>>>> Having said that, in the past, we had something called aspect, which >>>>> was later improved to lifecycle (i.e. lifecycle extends aspect), but then >>>>> lifecycle was not build as an extension point and the aspect interface >>>>> itself was useless. So, we ended with just one default lifecycle >>>>> implementation and few extensions based on that, and there was no real >>>>> need >>>>> and/or support for multiple lifecycles. This is why this was never >>>>> implemented in the past. But, with API-M and ES use-cases we had the need >>>>> but then it was hard to generalize since different products had their own >>>>> versions. It took a while for everybody to reach common ground and I >>>>> believe that we've got there now. >>>>> >>>> >>>> Thanks for sharing your insights and we are more or less in a common >>>> ground where everybody agree that inventing lifecycle implementation per >>>> product is not right way to solve problems. >>>> >>>> >>>>> Coincidentally I happened to write a blog post on the need of multiple >>>>> lifecycles, few days back, [1]. >>>>> >>>>> [1] >>>>> http://senakafdo.blogspot.co.uk/2014/11/state-of-development-vs-state-of.html >>>>> . >>>>> >>>> >>>> Great :) Will look into your post. >>>> >>>> Thanks ! >>>> >>>>> >>>>> Thanks, >>>>> Senaka. >>>>> >>>>> On Tue, Dec 2, 2014 at 4:35 PM, Sagara Gunathunga <sag...@wso2.com> >>>>> wrote: >>>>> >>>>>> >>>>>> Current G-Reg admin console is designed to associate only one >>>>>> Lifecycle with a registry resource at any given time but it seems we have >>>>>> valid use cases which require to associate more than one Lifecycle with a >>>>>> registry resource. >>>>>> >>>>>> E.g - ES + G-Reg integration >>>>>> >>>>>> - ES has an approval process which define and manage lifecycle of an >>>>>> assets within the 'context of store'. >>>>>> >>>>>> - Same asset/resource (e.g REST Service ) has governance lifecycle >>>>>> within the 'context of G-Reg' (e.g - dev, Q/A, product status). >>>>>> >>>>>> Right now both of above Lifecycles have been implemented using SCXML >>>>>> and the problem is it's not possible to associate more than one Lifecycle >>>>>> with a registry resource. During the last week we had a meeting and >>>>>> identified supporting to associate multiple Lifecycles is the best way go >>>>>> forward. >>>>>> >>>>>> Further in order to realize this multiple Lifecycles concept properly >>>>>> we should think associating more than one Lifecycle result into >>>>>> associating >>>>>> multiple 'contexts' to a resource and under each context the resource can >>>>>> have independent/dependent lifecycles. Further with this change >>>>>> 'state' >>>>>> of a resource should be qualified with a given context, in other words >>>>>> question "what is the state of resource A" should be raised as "what is >>>>>> the >>>>>> state of a resource A under 'context -X' ". >>>>>> >>>>>> As an example consider "Published a Q/A stage service into the store' >>>>>> >>>>>> - Under project or governance context - service state is 'Q/A' >>>>>> - Under Store context - service is >>>>>> 'Published' >>>>>> >>>>>> >>>>>> @Senka, I would like to know is there any specific reason that we >>>>>> haven't implement this support in past ? If there is no such barrier we >>>>>> can proceed further. >>>>>> >>>>>> Thanks ! >>>>>> -- >>>>>> Sagara Gunathunga >>>>>> >>>>>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>>>>> V.P Apache Web Services; http://ws.apache.org/ >>>>>> Linkedin; http://www.linkedin.com/in/ssagara >>>>>> Blog ; http://ssagara.blogspot.com >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* >>>>> Solutions Architect; WSO2 Inc.; http://wso2.com >>>>> >>>>> >>>>> >>>>> *Member; Apache Software Foundation; http://apache.org >>>>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: >>>>> +1 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>>> >>>>> >>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In: >>>>> http://linkedin.com/in/senakafernando >>>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >>>>> >>>> >>>> >>>> >>>> -- >>>> Sagara Gunathunga >>>> >>>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>>> V.P Apache Web Services; http://ws.apache.org/ >>>> Linkedin; http://www.linkedin.com/in/ssagara >>>> Blog ; http://ssagara.blogspot.com >>>> >>>> >>> >>> >>> -- >>> Isuruwan Herath >>> Technical Lead >>> >>> Contact: +94 776 273 296 >>> >> >> >> >> -- >> >> >> *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* >> Solutions Architect; WSO2 Inc.; http://wso2.com >> >> >> >> *Member; Apache Software Foundation; http://apache.org >> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >> >> >> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In: >> http://linkedin.com/in/senakafernando >> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >> > > -- *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 408 754 7388; ext: 51736*; *M: +44 782 741 1966Linked-In: http://linkedin.com/in/senakafernando <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
