Hi Senaka, Well if we "always" have a separate store-model, your model of having a > strong tie up between the lifecycles would have made sense. But that is not > necessarily the case. There can be a single store, a couple or even 3 > separate. >
Here I am trying to get the overall picture. When there are 2+ stores are we attaching 2+ lifecycles to a single service, one per each store? If this is the case these stores should be independent of the Service lifecycle isn't it? thanks Eranda > If you want that kind of flexibility or even beyond that, the lifecycles > themselves have to be independent of each other. > > So, in summary, the answer to your question is that it will not always be > separate stores and therefore a rigid lifecycle model which you are > proposing here won't be ideally fitting. > > Thanks, > Senaka. > > On Fri, Dec 12, 2014 at 8:04 PM, Eranda Sooriyabandara <era...@wso2.com> > wrote: > >> Hi Senaka, >> >> >>> There is a use-case. For example, even in the case of a service, you can >>> push it to the ES at anytime after it has been created. There is no concept >>> of a service needs to be in Production or Testing for it to be available on >>> the Store. But, for a service to be published on the store, you need it to >>> be reviewed and also it needs to have an endpoint. So, the service has a >>> Store-lifecycle. But, it has a separate development lifecycle. Similarly it >>> can have other lifecycles for other concepts. >>> >> >> I got it. I had a confusion where I thought there will be separate stores >> for dev, testing and production and there will be separate services in dev, >> testing and prod which done by the current service lifecycle. Are we going >> to change them? If the plan is for no separate stores for dev, qa and >> production and one service maintain for across all lifecycle, it does make >> sense to have a separate lifecycle. Please correct me if I am wrong. >> >> thanks >> Eranda >> >> >>> >>> Thanks, >>> Senaka >>> >>> >>> On Friday, December 12, 2014, Eranda Sooriyabandara <era...@wso2.com> >>> wrote: >>> >>>> Hi Senaka, >>>> >>>> >>>>> Lets take your example. Say we have both ES-LC and Dev-LC. Ideally, >>>>> there will be two independent lifecycles. There needs to be some >>>>> implementation or configuration that will tie these two lifecycles >>>>> together. For example, like there are some checklist rules that need to be >>>>> statisfied for being able to Promote from X to Y, you might also need to >>>>> satisfy some other conditions in different lifecycles in order retain your >>>>> existing state or promote from current to next and vice versa. >>>>> >>>> >>>>> So, the user can define/extend how the lifecycles depends on each >>>>> other, but from the framework level you can have two or more completely >>>>> independent lifecycles. >>>>> >>>> >>>> Is there any usecase where there can be two independent lifecycles per >>>> resource? AFAIU, can't be. My logic is in our environment if we have two >>>> lifecycle bind together then the scope of combining lifecycle is bound to a >>>> state. >>>> >>>> For example >>>> When when we promote Dev to Test will the state of ES lifecycle should >>>> remain the same? (may be it's in Published state) >>>> >>>> If it bound to a state why can't we specify one lifecycle as a part of >>>> other lifecycle. We can define it as below >>>> >>>> <stateLC name="ESLifecycle"> >>>> <stateLC name="RainLifecycle"> >>>> >>>> Please correct me if I am on wrong way. >>>> >>>> thanks >>>> Eranda >>>> >>>> >>>>> >>>>> Thanks, >>>>> Senaka. >>>>> >>>>> On Fri, Dec 12, 2014 at 1:21 AM, Eranda Sooriyabandara < >>>>> era...@wso2.com> wrote: >>>>> >>>>>> @Sagara, Senaka, Shazni, >>>>>> >>>>>> Here I am bit worried about the lifecycle state combinations we are >>>>>> getting. >>>>>> Let's take the example of Service. In service lifecycle we have >>>>>> Development, Test, Production and then we have a ES lifecycle which >>>>>> contains Created, Published, Retired. Think we associate both lifecycle >>>>>> to >>>>>> a service where we need to promote the service to the service store while >>>>>> keep it in the development. We can do it by changing the ES lifecycle to >>>>>> published. Then we promoting the service lifecycle to QA and still we see >>>>>> ES lifecycle is in published state which is bit confusing. Please correct >>>>>> me if I am wrong. >>>>>> >>>>>> If you look closely to the use case provided by Sagara, Service >>>>>> lifecycle is the main lifecycle and the ES lifecycle is a state specific >>>>>> lifecycle where when we promoting Dev to Test we should not transfer the >>>>>> state of ES lifecycle. So I hope we should have a main lifecycle and we >>>>>> should be able to define state specific lifecycles where we can select >>>>>> existing lifecycles. >>>>>> WDYT? >>>>>> >>>>>> thanks >>>>>> Eranda >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> *[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 >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Eranda Sooriyabandara*Senior Software Engineer; >>>> Integration Technologies Team; >>>> WSO2 Inc.; http://wso2.com >>>> Lean . Enterprise . Middleware >>>> >>>> E-mail: eranda AT wso2.com >>>> Mobile: (812) 964-9032 >>>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>>> Blog: http://emsooriyabandara.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 >>> >>> >> >> -- >> >> *Eranda Sooriyabandara*Senior Software Engineer; >> Integration Technologies Team; >> WSO2 Inc.; http://wso2.com >> Lean . Enterprise . Middleware >> >> E-mail: eranda AT wso2.com >> Mobile: (812) 964-9032 >> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >> Blog: http://emsooriyabandara.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 > -- *Eranda Sooriyabandara*Senior Software Engineer; Integration Technologies Team; WSO2 Inc.; http://wso2.com Lean . Enterprise . Middleware E-mail: eranda AT wso2.com Mobile: (812) 964-9032 Linked-In: http://www.linkedin.com/in/erandasooriyabandara Blog: http://emsooriyabandara.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
