Lifecycles in WSO2 Governance Registry 4.1.1

Today I thought of taking you all through the lifecycle improvements that we did for WSO2 Governance Registry 4.1.1. We introduced a new lifecycle model with the WSO2 Governance Registry 4.0.0 release. This  model had many improvements when compared with the older versions(like G-Reg 3.6.0 and earlier versions) and had lot of flexibility. A detailed description about this model can be found here. This post focuses more towards the improvements that we did from G-Reg 4.0.0 to G-Reg 4.1.1.

The main improvement we did was to add couple of extension points to the lifecycle model in G-Reg 4.0.0. The lifecycle model in G-Reg 4.0.0 had extension points like "validations" and "permissions" which could be used to customize the behavior of the lifecycle runtime execution. Extension points like "validations" are a good method to run some custom code at a check item click or prior to a transition but our lifecycle model lacked the ability to attach an extension after a transition. So, for that we have introduced the following extension points in G-Reg 4.1.1 release.

1. Executors
2. Transition UI

With these new extension points, our lifecycle model has the ability to handle various kinds of validations and executions. In brief, our new lifecycle model allows users to plugin their custom code before and after a state transition. A detailed post about "Executors" can be found in here. I'll be covering the about the  "transition UI" improvements in another post. 

For more details about WSO2 Governance Registry 4.1.1, please go through our documentation which can be found here. Also you can find more details about the lifecycle model in WSO2 Governance Registry using this link.

Default Executors in G-Reg

This post applies to G-Reg 4.1.1 and upwards.

As you all know, WSO2 Governance Registry supports adding extensions to the execution logic of a lifecycle.This blog post covers about one particular extension point which is called an executor. This post discuss about the default executors that we have included in the Governance Registry distribution. To get more information about executors, please refer this.

We have 3 default executors in G-Reg. From this post, I'm planning to give an overview about these executors.

1. Service version executor
2. Demote action executor
3. Copy executor

Service Version Executor

The main functionality of this executor is to version services and dependent resources of services(wsdl,schema and policy) when a lifecycle promote action happens. This executor was introduced  to G-Reg with the service version functionality implementation. To get an idea about this executor, we need to have some idea about the service version functionality of G-Reg.

Service Versioning

In G-Reg, we have introduced the ability version services and its dependent resources as an part of lifecycle management of the service. With this improvement, a service in G-Reg are kept in 3 environments when it is governed using the default service lifecycle.

1. Trunk
2. Branches/testing
3. Branches/production

Each of these environments are correspond to a lifecycle state in the default service lifecycle. The default service lifecycle in G-Reg has 3 states.

1. Development
2. Testing
3. Production

The service version functionality happens in the following way.

1. At creation, the service resource(and its dependent resources) will be placed in "trunk" environment. The path structure of the service resource is like - "trunk/services/{namespace}/{name}". We limit the creation of 2 services with the same name and namespace in this environment. 
2. All the services in "trunk" environment are on "development" state of the lifecycle.
3. When a "promote" action happens, a UI is displayed to the user to enter the new versions of the service and its dependent resources(This is done using the "transition UI" functionality of G-Reg which I will be covering in another blog post).
4. After completing the above action, the service and its dependent resources are moved to "branches/testing"environment. The path structure of a service resource in this environment is like - "branches/testing/{namespace}/{version}/{name}". In this environment, we create a collection with the version that the user has given and because of that, we allow users to keep multiple versions of the same service in this environment.
5. With the above step, we do some additional processing and update the dependencies with the new paths and also update the version filed in the service to reflect the new version. 
6. Promotion from "Testing" state to "Production" state is similar to step 3,4 and 5. All the services and the its dependencies are moved from "branches/testing" to "branches/production" environment. 

The service version executor is the one who does steps 4,5 and 6 when a promote transition happens. It is written in a way such that a user can change the environments from the lifecycle configuration. To get some idea about this, we need to look at the configuration of the service version executor.

Here you will notice several "parameter" elements. We focus our attention on 2 of these which are,

1.  currentEnvironment
2.  targetEnvironment 

The target environment parameter is the one who decides what is the next environment that the service is placed on. In other words, these 2 parameters say that, take the resource out from "/_system/governance/trunk/{@resourcePath}/{@resourceName}" and place it in "/_system/governance/branches/testing/{@resourcePath}/{@version}/{@resourceName}" path. By changing this configuration, an user has the ability to change the environments based on their requirement.

Also one important fact to note about this executor is that it is media type aware and it works only for services. 

Demote Action Executor

The demote action executor in G-Reg 4.1.1 does not do any copying of the resources to the previous environments. We have identified that the demote action requirement varies from one user to another. The ideal demote action would be to redirect the user to the resource in the previous environment but that is again challenging because there can be multiple versions of the same service in the previous environment. 

Therefore, we have introduced a demote action executor to avoid changing the lifecycle state when the demote action is performed for service in a particular state. In other words, this executor does not do anything apart from keeping the same lifecycle state when the demote action is preformed. 

Copy Executor

The idea behind the copy executor is to do a basic copy of resource from the given location to another. This executor has the ability to work with any media type and it is not media type aware. This executor does a basic copy operation(registry API copy operation) of that resource and it does modify the content or make associations like the service version executor. 

The configuration element of the copy executor is somewhat similar to the service version executor. 

Here you will find 2 parameters called the "currentEnvironment" and "targetEnvironment". These parameters work in the following way. The copy executor will copy any resource that is inside "currentEnvironment"  to the corresponding path in the "targetEnvironment". 

Eg: - Say that you have a resource in the following path.

    "/_system/governance/e1/foo/bar/xyz".

When the user applies a lifecycle (that is configured with the copy executor with the above configuration parameters) to resource "xyz" and do a promote operation, the copy executor will copy that resource to the following path.
"/_system/governance/e2/foo/bar/xyz"

Lifecycle extentions in WSO2 G-Reg - Part 1

This post applies to WSO2 Governance Registry 4.1.1 and upwards.

As you all know, WSO2 Governance Registry supports adding extensions to the execution logic of a lifecycle.This blog post covers about one particular extension point which is called an executor.

From this post, I'm planning to cover the following topics.

1. What is an Executor
2. How to write a Executor
3. Add a custom Executor to a lifecycle

What is an Executor

In WSO2 Governance Registry lifecycle model, there are several extension points that one can use to plug there own execution logic. There are several types of pluggable extension points. One of them is called the "executor". An executor is an execution logic that is executed once a state transition happens in a lifecycle.

How to write an Executor

Writing an Executor in G-Reg is very easy. We have an interface called "Execution" in G-Reg which can be found in "org.wso2.carbon.governance.registry.extensions" bundle. This interface has 2 methods.

• void init(Map parameterMap)

This method is called when the execution class is initialized. All the execution classes are initialized only once.
@param parameterMap Static parameter map given by the user. These are the parameters that have been given in the lifecycle configuration as the parameters of the executor.
Eg:- 
   

The parameters defined here are passed to the executor using this method.

• boolean execute(RequestContext context,String currentState,String targetState)

This method will be called when the invoke() method of the default lifecycle implementation is called. Execution logic should reside in this method since the default lifecycle implementation will determine

the execution output by looking at the output of this method.


@param context The request context that was generated from the registry core for the invoke() call. The request context contains the resource, resource path and other variables generated during the initial call.

@param currentState The current lifecycle state.

@param targetState The target lifecycle state.

@return Returns whether the execution was successful or not.

To write a custom executor, an user has to implement this interface and add the custom logic inside the execute method. The runtime will execute all the executors that is registered against a particular event an a particular state.

Add a custom Executor to a lifecycle

Adding an Executor to a lifecycle has several steps to follow. 

1. Compile the class and create a jar file out of it
2. If the jar file is an OSGI bundle add it to "GREG_HOME/repository/components/dropins" folder and if the jar file is not an OSGI bundle then add it to "GREG_HOME/repository/components/lib" folder. Here what we did is that we added the executor implementation to the classpath of the G-Reg server. 
3. Add the executor to the lifecycle configuration. Following is a segment of a lifecycle configuration that has an executor. 

There are 3 things that we need to focus our attention on. 

1. The event that we register the executor - defined by the "forEvent" attribute of the execution element.
2. The class of the executor - defined by the "class" attribute of the execution element.
3. Static parameters that is passed to it(optional) - defined by the "parameter" elements of the execution element. 

Using these configurations, an user has the ability to attach their own execution logic to a lifecycle in G-Reg.

Lifecycle Management of SOA Artifacts for WSO2 Products

This is about another webinar we(Sadeep and My Self) did recently. Here we demonstrated how WSO2 products interact with each other and how to use WOS2 Governance Registry's lifecycle management feature to manage SOA artifacts in different environments. We addressed the following use case (problem) in this webinar.

To give you a more detailed description about the exact problem we addressed in this webinar: Say that we have 3 ESB environments, namely "Dev","QA" and "Prod". In these environments, development work is done on the "Dev" and for testing purposes the artifacts under "Dev" environment should be moved(copied) to the "QA" environment. Once the QA work has been done, the artifacts in the "QA"environment should be moved(copied) to the "Prod" environment. We need a way to automate this to some extent so that we have minimum user interactions in this process. 

The solution we proposed was to introduce the WSO2 Governance Registry as a control mechanism to this process. In that solution all the 3 ESB environments are taking to a WSO2 Governance Registry and each of these ESB environments will look there SOA artifacts from the registry. We used the concept call "registry mounting" in such a scenario and each of the 3 ESB instances are mounted to 3 different collections in the registry.

Then the Governance Registry uses its lifecycle management feature to move the SOA artifacts from one environment to another. We use a simple lifecycle with 3 states (Development, QA and Production) and in each state transition, we copy the contents to the next environment.

For demonstration purposes we use an environment where we have 3 ESB instances and each of these instances were mounted to a Governance Registry. We created a proxy service in the "Dev" environment and used the deployment synchronizer feature of WSO2 products to persist it to the Governance Registry. During the demo session we demonstrated how to apply the lifecycle to the collection where the resources are stored in and when we do a "Promote" action how the resources are moved to the next environment. Using the deployment synchronizer, the ESB instance in the QA environment was able to find the new proxy service(that was copied to the "QA" location in Governance Registry) and deploy it in that instance. 

Here I have given an overview of the webinar and you can find more details about this including the webinar slides and the complete recording using [1]. I would also like to thanks Chanaka and Sadeep for their efforts on making the slides. 

[1] http://wso2.org/library/webinars/2011/11/lifecycle-management-soa-artifacts-wso2-products

My First Webinar

Few weeks back I got the opportunity to conduct a Webinar for the first time in my life. It was an wonderful experience for me and I thought of sharing some of it with you.

Day : Thursday, August 11, 2011 

Topic : Service Governance with the WSO2 Governance Registry

Presenters : Janaka Ranabahu and Isuru Wimalasundera

In here, I'm not going to discuss in detail about what we did on the webinar and what are the capabilities of the latest WSO2 Governance Registry. Instead, I'm trying to give an abstract of the webinar that we did. 

The webinar was conducted by myself and one of my colleagues "Isuru Wimalasundera".  We had to cover the topic of service governance using WSO2 Governance Registry. The idea behind this webinar was to give an introduction to the new lifecycle configuration model of WSO2 Governance Registry 4.0.0 and to give an introduction to WSO2 Governance Registry 4.0.0 UDDI v3 capabilities. During the webinar we covered about the new SCXML based lifecycle configuration model and some of its capabilities such as defining custom validations and defining permissions for lifecycle actions. Also during the webinar, we gave a brief description about the elements in the new lifecycle model and about the service version feature that we have introduced in WSO2 Governance Registry 4.0.0. 

Those who are interested more about this, visit here for the presentation slides and video cast. Also if you have any questions about what we discuss on this webinar, post them here or post them in our forum.

Stay tuned for more webinars about WSO2 Governance Registry by following our webinar page. There you can find about our past, present and upcoming webinars. 

Configure LifeCycles in WSO2 Governance Registry

Finally I thought of writing some technical stuff about WOS2 and its products. Currently I'm working in the WSO2 Governance Registry and this blog explains about the new lifeCycle configuration of WSO2 Governance Registry 4.0.0.

LifeCycles are a powerful concept when it comes to in the context of governance of different artifacts. The WOS2 Governance Registry (we'll call it G-Reg from this point onward) have the capability of associating lifeCycles for artifacts that are stored in the repository. The power of G-Reg's lifeCycles model is that the user has the ability to define his/her own lifeCycle. Users can do this using the configuration model we provide with G-Reg. The idea of this post is to describe about the new lifeCycle configuration model of G-Reg and what are the improvements that we have done to the configuration model itself.

Little detail about the configuration

First of all let me explain a bit about the current lifeCycle configuration. The new G-Reg lifeCycle configuration model is developed around the W3C specification of state chart XML or in other words SCXML[1]. The SCXML specification is a very powerful specification and we have used this mainly because of two reasons.

1. SCXML is a stranded state machine language that has been adopted by the W3C
2. The SCXML model is very extensible and therefore we can use our custom definitions without violating the specification

We have used this extensibility to our advantage and came up with a configuration model that has many capabilities. In the previous version of G-Reg(prior to G-Reg 4.0.0) we have used a simple lifeCycle configuration model. Even though the users had the ability to extend that lifeCycle configuration, it was somewhat a difficult talk. So what we did in this latest release was that, we took all of that hard work away from the user and made it part of the default implementation. First we'll look at the new configuration model and then let us see what a user can actually do with it.

Configuration Model

The new lifeCycle configuration model of G-Reg is given bellow. First let me explain a bit about the configuration model and later(most probably it will be another post) I will explain how a user can write their own configuration using this.

If you look at the new model carefully, you can see that it has some similarities to the previous configuration model as well. One such similarity is that we still use the same three elements to define this configuration as a lifeCycle. The elements "aspect","configuration" and "lifecycle" behave the same way as in previous lifeCycles configurations. The part that we need to concentrate is the element that has the name "scxml". This is the element that is defined according to to SCXML specification.

Let me explain the configuration element by element in detail.

<aspect name="" class="org.wso2.carbon.governance.registry.extensions.aspects.DefaultLifeCycle">

This element defines the aspect and note that G-Reg have defined lifeCycles as aspects too. There are two attributes in this, "name" and "class". "name" attribute contains the name of the lifeCycle and the name has to be a unique one. Note that G-Reg does not allow creating two lifeCycles with the same name. The "class" attribute defines the class that is associated with the lifeCycle. 

The "org.wso2.carbon.governance.registry.extensions.aspects.DefaultLifeCycle" is the default class that handles the new lifeCycle configuration and its specified operations. A user has the ability to define his/her own class(more information about this can be found using [2]) but the default class provided with the G-Reg distribution have the capability to handle any configuration that follows the above given template. 

<configuration type="">

This element defines whether the type of this configuration is "literal" or "resource". This is same as in previous G-Reg versions where, if you give the configuration through the registry.xml, then the value should be "resource" and if it is given through the management console, the value should be "literal".

<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0"

initialstate="">

This is the element that contains the SCXML based new configuration. The important fact about this element is that it defines the initial state of the lifeCycle. With SCXML the users have the ability to define an initial state and the initial state does not have to be the first state of the configuration. Also by changing the value of this attribute, a user can quickly modify the initial state and the flow of the lifeCycle. This is a huge leap forward from the previous configuration models. 

Up to this point of the configuration, there can be only one element of each of the above described elements. The above mentioned elements are used to provide meta data about the lifeCycle(such as its name,class and other things) and the elements that are described below contains the actual configuration.

<state id="">

"State" elements defines the states of the lifeCycle. A lifeCycle can have multiple states and in the configuration, more than one state element can be given. The "id" attribute of the "state" element defines the name of that state. Note that G-Reg does not support multiple states with the same name and therefore all the state names of a lifeCycle should be unique.

<datamodel>

This element contains all the custom elements that we have defined in G-Reg's new lifeCycles model. The SCXML specification allows users to define a data model to a state and we have used that extension to define our custom elements. We have defined few custom "data" elements(according to the SCXML specification) to define check items, transition permission, transition validations and transition scripts. 

<data name="checkItems/transitionValidations/transitoinPermission/transitionScripts">

This element defines about the data of its child elements. Note that a user can only define one such element of each kind since the underline implementation will ignore multiple elements and take only one into consideration. The attribute "name" defines about the data that this element contains. The "name" attribute should be set to "checkItems" if the user is defining check items as its child elements. Likewise the name should be set to "transitionValidations" if the data element defines transition validations and "transitionPermission" if the data element defines transition permissions and "transitionScripts" if the data element defines about the transition scripts. So I recommend not to modify this element.

<item name="" forEvent="">

These elements contains the check items for each state. There can be more than one such element and the attribute "name" defines the name of the check item. G-Reg 4.0.0 allows you to define check items that are required for each transition. The "forEvent" attribute defines whether this check item is required for an specific transition. A check item can be required for more than one event and in such a scenario a user can give a comma(",") separated list for the "forEvent"attribute. Keeping the "forEvent" attribute empty means, that specific check item is not required for any transition event.

<permissions>

The "permissions" element defines permissions for that specified action. A permission element can hold more than one child element which defines permissions. Under check items, the "permissions" element defines the users that have the capability of checking(check/uncheck) that check item. If a user does not have permissions to check an check item, then the management console will display that specific item in disabled mode. The idea behind that was to let the user know that there are some more check items in that state but he does not have permission to check them and to avoid user confusion.

<permission roles=""/>

This element comes as a child element of the "permissions" element and will define the roles that have permission to do the specified action. Here the attribute "roles" accepts a comma(",") separated list and these roles should be present in G-Reg.

<validations>

The "validations" element defines the validations that needs to be done for each action. This element can contain one or more "validation" elements(which is described next).

<validation forEvent="" class="">

Validations are an important part of lifeCycles. The "validation" element defines the event and the validation class that has to be invoked at runtime. The attribute "forEvent" defines the event that this validation should be performed. This gives user the flexibility to define validations for each event. The user has the ability to define validations for check items, which makes it easy to validate different things at different levels.

The attribute "class" defines the class that needs to be executed at runtime to perform the validation. A user must give the full qualified name of a class that implements the "customValidations" interface, as the value of the attribute "class".

<parameter name="" value=""/>

The parameter elements are used to give parameters to the validations classes. It is up to the user to define the name value pairs and the parameter element has attributes to define these values. A validations element can have more than one parameter element and it is up to the user code to handle them. The underline implementation of the "DefaultLifeCycle" class will pass all the parameters in a map object. 

<js forEvent="">

G-Reg lifeCycle configuration has the ability to give JavaScript functions to execute at both the server side and the client side. The "js" element defines the scripts that needs to be executed to different events. The "forEvent" attribute defines the transition action where this JavaScript function needs to be executed. 

<console function="">

The "console" element is there to define the JavaScript function that needs to be executed at the client side. The "function" attribute defines the name of the function and this function will be executed at a transition of one state to another. 

<script type="text/javascript">

This element contains the actual JavaScript code segment. A user has the ability to define any code segment here. The "type" attribute is set to "text/javascript" because at this moment G-Reg only support JavaScript as a scripting language.

<server function="">

This is as same as the "console" function and the only difference is that this element defines the scripts that needs to be executed at the server side. This element also has a "function" attribute that defines the function name. 

Now I have explained all of the custom elements that we have defined in the new lifeCycle configuration of G-Reg. There is one element that I need to focus your attention on. 

<transition event="" target=""/>

This element defines the transitions of a state. One improvement that we have done with this new lifeCycle configuration model is of allowing the user to define the transitions(the name and the target state) instead of using static transitions.

For all of you that have experience in lifeCycle configurations of previous G-Reg releases, you may recall that the configuration did not have a direct method of defining the transition event names and most importantly the target of the transition. Also you may recall that there were only two transitions that we supported by default. With the new SCXML based configuration model, we support any number of transitions from one state. Also this model has the capability of defining the target state of the transition and the name of the event as well. The attribute "event" is used to define the transition event name(eg: "Promote" or "Demote" or any name that the user specifies) and the attribute "target" is used to define the target state of the transition. 

That concludes the explanation of the new lifeCycle configuration model of G-Reg 4.0.0 and as you all can see, the new lifeCycle configuration model support many things by default. I hope that this guide was helpful to all of you to understand about the lifeCycle configuration and to write one of your own. If you have any inputs, questions, feel free to drop a comment because I will gladly accept them all.


Folks, Note that I'm planning to write another post explaining the default service lifeCycle of G-Reg 4.0.0 and how we are managing service resources using it. 


References

[1]  http://www.w3.org/TR/scxml/

[2]  http://wso2.org/project/registry/4.0.0/docs/user_guide/lcm.html#lcm

Blogger, I'M BACK

It has been some time since I last wrote a blog due to various reasons. Now I'm thinking of start testing my blogging abilities. There are lots of things that I have to share with my blog. I had a great time in the last 7 months and I intend to share most of my experience with you guys as well.

So stay tuned to my blog because you will see lots of posts coming out in the next few weeks. :)