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. :)

University Life. Am I really missing it?

It has been more than 3 months since I graduated from the university. I thought of writing this blog to sum up some of the events that happened in the University from the day that I first went there and to the day I left. This is a blog that should have been written some time back ( not sure when exactly ) but I'm glad that I came up with the idea of writing this even now.

University of Colombo School of Computing ( most know it as UCSC ) is where I did my higher studies with the hopes of becoming a software engineer someday. After 4 (very short) years at the university, I thought of sharing my experiences with others.

I can still remember the day that we all came to the university for the first time. It was a rainy day and had lots of trouble because of that. That day all the newcomers were requested come with their parents because of the introduction that had been scheduled. Our academic year started after about a week from that day. In the first month we had an training about basics in computing. It was like the best days of university life. Every morning and evening our seniors grouped us together and gave us guidance and time to get to know each others. We were also engaged in fun activities and various kinds of sports as well. All of us were very sad when that period was over.

During the next 4 years at the university we engaged in various activities ranging from organizing preaches to organizing island wide competitions and also various trips. One of the most memorable thing about the university life was the organizing of the annual "pirith preach" which was organized by our batch. We all did a considerable amount of hard work to get it done. These pictures are some of the decorations we did for that ceromony.

The most memorable incident that affected all of us was the funeral of the founder of UCSC, professor V.K.Samaranayake. We were there at his funeral and it was the most memorable one.

I hope not to talk about all the 4 years in my university life. But when I come to think of those times, I still feel that was the best years of my life. We did many activities there, we had many challenges, how we faced those challenges and how we finished 4 years of university life is an experience that words can not explain.

Profile Generation using Linked Data

For all of you that read my previous blog, you know already that this not only a personal blog. So I thought of sharing about the research that I did in my final year at the University. This research is about using Linked Data (Data published as RDF Data) to generate a profile ( a collection of information ). The following is an abstract of the research paper that I have wrote.

  The Internet has become the world’s largest data source very rapidly due to the openness of its data publishing methods. The rapid growth of the Internet has yielded many benefits but caused some problems as well. The main problem faced by the Internet users is that of searching the large amount of data it has. Due to the openness of the data publishing methods of the Internet, data are scattered between different data sources and the amount of data repetition is also very high. Many new products such as search engines and Web crawlers have emerged because of this reason.

Even though there are search engines like “Google”, “Yahoo”, “Bing” and “Ask”, and Web crawlers like “Googlebot” and “Yahoo! Slurp”, it is still difficult to retrieve information from the Internet. The result of most of these search engines is a list of Web sites and pages that contains the keyword the user entered?. The problem here is that the user has to do further searching on these Web pages to find the information needed. This is mainly because the Internet doesn’t have any specific method of publishing data and information and also due to the fact that there are no relationships between similar data from different data sources. Various methods of publishing data such as text, graphics, tables, charts, audio and video do not help the cause of retrieving information and more importantly summarizing information. One reason for this is the fact that most of the data publishing methods are not machine readable and therefore very difficult to build a system that summarizes information.

On the other hand there are some attempts to address the issue of the information scattered over the Internet. The most significant methodology that has been used is the linked data principles. In simple words, Linked data is the term used to describe the data which are interlinked because of their similarity. The most significant thing about linked data is that data are interlinked without regarding the data sources. Since linked data is relatively a new technology, there are still ongoing researches about linked data browsing and searching.

Since the arrival of linked data, it has made a huge difference in the way of publishing data and information, mainly because linked data are both human and machine readable. This also opened up some more possibilities of summarizing information since it creates relationships between similar data. This research is about using those relationships to get a summary of information about an entity that the user gives; in other words, generating a profile using linked data.

There are several browsers like “Tabulator”, “Humboldt” and search engines like “Falcons”, “Semantic Web Client Library” that are developed to explore the Web of linked data. Most of these are still under research and some of these browsers are domain specific. The most significant thing about these browsers is that almost all of them use a similar algorithm to retrieve information from RDF (Resource Description Framework) data. These algorithms use SPARQL (SPARQL Protocol and RDF Query Language) queries to retrieve information from RDF files.

In this research, we have developed a methodology that uses the technology of linked data and generates a profile. This is a novel methodology and it uses a point awarding system that awards values for attributes or for the concepts in the RDF data file, based on the relevance of that concept to the profile we are generating.

The methodology we have developed and the considerations we took are as follows. To generate a profile, the first task would be to identify the attributes of the physical entity or to identify the concepts that should be included in the profile. Since this is one of the main difficulties faced when generating the profile, we have developed a methodology that uses linked data itself to identify the attributes of a physical entity. In this methodology, we use queries to gather the concepts. The query language we have used is SPARQL and we have created several types of queries. These queries are used for different purposes such as concept gathering and data gathering.

The process of concept gathering is done using a general query that returns all the concepts that are in relation with the entity we query. The types of queries we use cover a range of data sets where the keyword resides as the subject or the object of a RDF triple. If there are concepts that describe similar URIs or redirect URIs among the concepts gathered in the above manner, we use two special types of queries to gather the value those concepts hold. These values are used in creating more queries and this procedure is done until no new similar or redirect URIs are found.

The query execution happens in the following manner. The concept identification process has two query execution steps. For the first step, we use an initial endpoint and an initial query to retrieve a single concept list. For that, we have selected an initial endpoint prior to the execution of the system. The execution of the other endpoints halts until the first result set is returned and these results are used to create the queries that are needed to retrieve concepts from other endpoints.

The endpoints we have used range from generic endpoints to domain specific endpoints so that the profile we generate can include very common information as well as some domain specific information. Each of these endpoints are assigned with a value in such a way that the generic endpoints have a lower value and the domain specific ones have a higher value. The initial endpoint is assigned with the lowest value. Each of the concepts gathered from these endpoints are assigned with the corresponding value and at the end of the concept identification process, all the concepts are merged and the values are summed in similar concepts. Finally, a threshold value is chosen and the concepts that have a total value more than the threshold value are taken as the final list of concepts. These concepts are used to generate new queries and the corresponding data are gathered by querying all the endpoints.

The main benefit of this system will be for the day to day users of the Internet who are trying to get a summary of information about a particular real world entity. However this system has some limitations of generating the profile mainly because of the following reason. The amount of data which are published as linked data is limited. So sometimes there will be lesser information in the profile than in a common Web site. Since our methodology depends on the amount of data published as linked data, we can assure that the quality of the profiles generated by the system will increase with the growth of linked data.

Blogging......

It's been a long time since I had the idea of starting a blog. Everyday due to some reason I keep forgetting about the idea of starting a blog. The first thought that came to my mind about blogging is that "What am I going to blog about?" After a long battle in my mind about this, I came to realize that there are lots of things to blog about. I just didn't noticed them.

As a start I'm writing this blog to give some idea of whats coming in the future to the guys and gals who are interested in my blog. This is not a blog where I try to publish everything that goes through my mind. Instead I'm hoping of using this blog to share my experiences and knowledge as well.

This particular blog post of mine is a very short one. The thought that came across my mind is that "we have to start something small and then gradually build it." So I'm publishing this post to give life to my idea of blogging.