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