On Fri, Dec 12, 2014 at 8:39 PM, Eranda Sooriyabandara <era...@wso2.com> wrote:
> 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? > Sorry no. It would be a single lifecycle for the development of the service and a single lifecycle for being published on a Store or not. What you describe is a situation where these two lifecycles are "linked" for certain kinds of transitions. Lets assume one store for Dev/Test and another Store for Prod. When you move from Dev to Test, you just change the State of the Development lifecycle, but the issue is when you move from Test to Prod. Now the relationship between the two lifecycles can be one of the three models below or even something completely different: - When you move from Test to Prod the Store lifecycle simply resets itself (i.e. you start from scratch). - Your Store lifecycle includes additional states to capture being published on the Dev/Test store as well as the Prod Store. - If your Dev/Test and Prod versions of the service do run in parallel and you also want to manage the Published state of the service is these two stores separately from each other, then obviously you will be needing two Store lifecycles. This is exactly why you need the independence between these lifecycles. Thanks, Senaka. > > 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/ > > > > > -- *[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
