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
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
