Re: [Architecture] Associating multiple lifecycles to a registry resource
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.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org http://apache.orgE-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%201966Linked-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.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org http://apache.orgE-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%201966Linked-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:
Re: [Architecture] Associating multiple lifecycles to a registry resource
Hi Eranda, Alright I see where you are coming from now, :). 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. 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.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org http://apache.orgE-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%201966Linked-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:
Re: [Architecture] Associating multiple lifecycles to a registry resource
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.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org http://apache.orgE-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%201966Linked-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 .
Re: [Architecture] Associating multiple lifecycles to a registry resource
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
Re: [Architecture] Associating multiple lifecycles to a registry resource
Hi Shazni, On Thu, Dec 11, 2014 at 12:06 PM, Shazni Nazeer sha...@wso2.com wrote: Hi All, As a proof of concept I implemented multiple lifecycle support in the G-Reg. As Senaka pointed out, the lifecycle details are kept as resource properties. But from the beginning it self it has been designed assuming that resource would have only one lifecycle so that the resource property keys have no qualification to the lifecyle. Therefore, I introduced lifecycle name into the key so that at the implementation level we can differentiate which property belong to which lifecycle. In the registry core level there is no limitation of adding multiple aspects as such. Only in the lifecycle implementation it's restricted to adding multiple lifecycles, where in the DefaultLifecyle implementation, it just returns, if there's already a property with the key registry.LC.name, which can be solved using introducing lifecycle name in the property. Moreover, the method signature for certain methods like addCheckItems, addTransitionUI (which is in the org.wso2.carbon.governance.registry.extensions.aspects.utils.Utils) are changed to get a lifecycle name so that we can include the aspect name into the property key Further, the jsps related to lifecycle also have been tightly coupled with the assumption of having only one lifecycle per resource. It takes only the first in the list of actions to process and display the lifecycle. With the inclusion of the lifecycle name into the properties in the resource I modified the jsp (lifecycles_ajaxprocessor.jsp) to be able to add multiple lifecycle and view the attached lifecyles in the same view. The view of the lifecycle section is as shown below. I've few questions on the following. GovernanceArtifactImpl's API too has methods setLcName, getLcName which essentially assumes one artifact has one lifecycle. But I didn't change those methods as I thought that can be kept as it is for someone to define and get the default lifecycle. (i.e. the one like we show in the list view). But there are also other methods like getLifecycleName, detachLifecycle, getLifecycleState which I think need to be changed to get aspect name as a parameter. IMHO, the API methods need refactoring. I believe that it makes sense to have getLCNames (returns []) and setLCName (as-is), also there might need to be a concept of a default lifecycle and you may want to get/set the default. getLifecycleState (or anything that assumed the single lifecycle) should have a overloaded method that also accepts the lifecycle name. If you do not pass a lifecycle name (no arg), you should retrive the state from the default lifecycle. Does this make sense? Thanks, Senaka. WDYT?? thanks Shazni Nazeer Senior Software Engineer Mob : +94 37331 LinkedIn : http://lk.linkedin.com/in/shazninazeer Blog : http://shazninazeer.blogspot.com On Wed, Dec 3, 2014 at 5:24 PM, Senaka Fernando sen...@wso2.com wrote: 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
Re: [Architecture] Associating multiple lifecycles to a registry resource
@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 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Associating multiple lifecycles to a registry resource
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.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org http://apache.orgE-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%201966Linked-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
Re: [Architecture] Associating multiple lifecycles to a registry resource
Hi Eranda, 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. 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 javascript:_e(%7B%7D,'cvml','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.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org http://apache.orgE-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%201966Linked-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.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org http://apache.orgE-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
Re: [Architecture] Associating multiple lifecycles to a registry resource
Hi all, @Senaka - Thanks for your input. Yes, that makes sense to keep few methods for default lifecycle and change other methods like getLcNames to return an array [ ]. I'll do these modifications. +1 for having independent lifecycles. If there needs to be any connection between two lifecycles that has to be in implementation level of the lifecycles. The framework has to support independent multiple lifecycles. Agree with Senaka, that in case of services, it can be in store regardless of it development state. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Associating multiple lifecycles to a registry resource
Hi All, As a proof of concept I implemented multiple lifecycle support in the G-Reg. As Senaka pointed out, the lifecycle details are kept as resource properties. But from the beginning it self it has been designed assuming that resource would have only one lifecycle so that the resource property keys have no qualification to the lifecyle. Therefore, I introduced lifecycle name into the key so that at the implementation level we can differentiate which property belong to which lifecycle. In the registry core level there is no limitation of adding multiple aspects as such. Only in the lifecycle implementation it's restricted to adding multiple lifecycles, where in the DefaultLifecyle implementation, it just returns, if there's already a property with the key registry.LC.name, which can be solved using introducing lifecycle name in the property. Moreover, the method signature for certain methods like addCheckItems, addTransitionUI (which is in the org.wso2.carbon.governance.registry.extensions.aspects.utils.Utils) are changed to get a lifecycle name so that we can include the aspect name into the property key Further, the jsps related to lifecycle also have been tightly coupled with the assumption of having only one lifecycle per resource. It takes only the first in the list of actions to process and display the lifecycle. With the inclusion of the lifecycle name into the properties in the resource I modified the jsp (lifecycles_ajaxprocessor.jsp) to be able to add multiple lifecycle and view the attached lifecyles in the same view. The view of the lifecycle section is as shown below. I've few questions on the following. GovernanceArtifactImpl's API too has methods setLcName, getLcName which essentially assumes one artifact has one lifecycle. But I didn't change those methods as I thought that can be kept as it is for someone to define and get the default lifecycle. (i.e. the one like we show in the list view). But there are also other methods like getLifecycleName, detachLifecycle, getLifecycleState which I think need to be changed to get aspect name as a parameter. WDYT?? thanks Shazni Nazeer Senior Software Engineer Mob : +94 37331 LinkedIn : http://lk.linkedin.com/in/shazninazeer Blog : http://shazninazeer.blogspot.com On Wed, Dec 3, 2014 at 5:24 PM, Senaka Fernando sen...@wso2.com wrote: 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
Re: [Architecture] Associating multiple lifecycles to a registry resource
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.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software
Re: [Architecture] Associating multiple lifecycles to a registry resource
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.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org http://apache.orgE-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%201966Linked-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
Re: [Architecture] Associating multiple lifecycles to a registry resource
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.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org http://apache.orgE-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%201966Linked-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 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Associating multiple lifecycles to a registry resource
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.comSenaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org http://apache.orgE-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%201966Linked-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;
