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; 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
