The following is the official release note sent by WSO2 G-Reg team. You can download the new version using this link.

WSO2 Governance Registry 4.5.0 Released

07 September 2012

The WSO2 Governance Registry team is pleased to announce the 4.5.0 release of the WSO2 Governance Registry. WSO2 Governance Registry is a user-friendly, but comprehensive enterprise governance, registry and repository solution available under the Apache Software License v2.0. WSO2 Governance Registry is pre-loaded with best practices to help users with governance adoption. WSO2 Governance Registry is fully integrated to the WSO2 Carbon platform with the 4.5.0 release. This allows WSO2 Governance Registry users to benefit from the flexibility and extensibility provided by the Carbon platform. WSO2 Governance Registry can be either used as a complete product or used in combination with components of other WSO2 products. User specific components, extensions or UIs to the WSO2 Governance Registry can be easily added as Carbon components.
We are striving for a simple and happy first time user experience as well as a satisfying experienced user experience with this release.

New Features in This Release

• Adding Operators to Advanced Search API (Negation and Range Queries for Property Values)
• UUID Support at Resource Level
• Hierarchical Subscriptions for Collections
• Onetime Email Verification for Subscriptions
• URL Referenced Assets
• API Assets
• Worklist Notification Bar
• Task Scheduling for Registry
• Additional Reporting Improvements
• Improving Support for Configurable Governance Artifacts
• Support for Source Configuration Management(SCM)
• Support for Java Management Extensions(JMX)
• XPath Query Support for Search
• Lifecycle Audit
• Dynamically Clensing Version History
• Invocation Statistics API
• Inversions and Range Queries for Search
• WS API for Governance Artifacts(CRUD Operation Support)
• Adding Executor for Services to Publish as APIs
• Display Life Cycle Status in the List View of Services, WSDLs, Schemas and Policies
• Search by Name for the List View of WSDLs, Schemas, Policies and Configurable Governanace Artifacts
• Display Notification Type Information on Notifications UI

Issues Fixed in This Release

WSO2 Governance Registry Issue Tracker

Features of WSO2 Governance Registry

• Storing and managing arbitrary resources and collections
• Tagging, commenting and rating
• Managing users and roles
• Authentication and authorization on all resources and actions
• Resource / collection versioning and rollback
• Advanced search capabilities - tags, users, etc.
• Built in media type support for common types (WSDL, XSD)
• Built in support for known repository types
• Dependency management - maintain relationships between dependent resources for impact analysis
• Pluggable media type handlers for handling custom media types
• Pluggable custom UIs for resource types
• Activity log and monitoring with filtering support for the activity logs
• Atom Publishing Protocol (APP) support for reading/writing the data store remotely
• Subscribe to resources, collections, comments, tags, etc. with any standard feed reader (Bloglines, Google Reader, etc)
• Intuitive User Interface with an Ajax-based Web 2.0 interface
• Internationalization
• Support for deploying back end and front end (UI) in separate servers
• WSDL Tool to import service information from a given WSDL, and WSDL custom-view
• WSO2 Governance Registry federation - mounting a remote WSO2 Governance Registry to a specified location
• Based on the OSGi based WSO2 Carbon architecture: this is a unification of all Java based products from WSO2
• Advanced service governance through, discovery, impact analysis, versioning and automatically extraction of service meta data
• Dashboard support with gadgets with design-time and run-time governance information
• Advanced Life cycle management with checklists, and scripting support
• Validation policies. e.g. WSDL Validation, WS-I Validation and Schema Validation
• Eventing and notifications
• Supports remote links, symbolic links for resources
• Attach remote WSO2 Governance Registry instances, providing one interface for many WSO2 Governance Registry instances
• Support for processing custom URL patterns via pluggable URL handlers
• Support for custom query languages via pluggable query processors
• Import/export resources and collections
• Improved transaction support
• Support for WebSphere, WebLogic, and JBoss
• Provisioning and feature management support for WSO2 Carbon family of products
• Support for clustering
• Check-in/Checkout tool
• Gadgets for impact analysis on services and registry resources
• Dynamic Handler configuration, and simulation
• Tree-based Resource view
• API to govern SOA artifacts
• Complete Web Services API for Registry
• WS-Discovery support
• Platform, and Group/Cluster based deployment model, with support for adding remote mounts
• Support for multiple server instances
• E-mail verification for subscriptions
• Hierarchical permission model with granular and extensible permissions
• Governance Archive for uploading WSDLs and Schemas with imports
• Ability to update resource content by uploading
• Rich text editor for editing text resources
• XML editor for editing handler, lifecycle and service UI configurations
• Support for deploying Carbon Applications (C-App)
• Content Search
• WebDAV support
• Open-Social API
• JCR API
• UDDIv3 support
• Cache-backed Registry
• Resource Locking/Retention
• Configurable Governance Artifacts
• Improvements to the Lifecycle Model (Executors, Validators, Permissions, and Transition UI)
• Improvements to Metadata Search
• Improvements to Impact Analysis
• Conflict Resolution for Concurrent Updates
• Human-Readable Names for media-types

Project Resources

• Home page : http://wso2.com/products/governance-registry
• Library : http://wso2.org/taxonomy/term/350/all
• JIRA-Issue Tracker : https://wso2.org/jira/browse/REGISTRY
• QA Artifacts : 
  SVN : http://wso2.org/repos/wso2/trunk/commons/qa/registry

Installation and Running

1. Extract the downloaded zip file
2. Run the wso2server.sh or wso2server.bat file in the /bin directory
3. Once the server starts, point your Web browser to https://localhost:9443/carbon/
4. For more information, see the Installation Guide:
   Locally : INSTALL.txt
   On the web : http://docs.wso2.org/wiki/display/Governance450/Installation

Known Issues

WSO2 Governance Registry Issue Tracker

Reporting Problems

Issues can be reported using the public JIRA available at https://wso2.org/jira/browse/REGISTRY

Contact us

WSO2 Governance Registry developers can be contacted via the mailing lists:
For Users: user@wso2.org
For Developers: dev@wso2.org

Alternatively, questions can also be raised in the WSO2 Governance Registry forum:
Forum http://wso2.org/forum/351 

Support

We are committed to ensuring that your enterprise middleware deployment is completely supported from evaluation to production. Our unique approach ensures that all support leverages our open development methodology and is provided by the very same engineers who build the technology.
For more details and to take advantage of this unique opportunity please visit http://wso2.com/support/
For more information about WSO2 Governance Registry please see http://wso2.com/products/governance-registry visit the WSO2 Oxygen Tank developer portal for additional resources.
Thank you for your interest in WSO2 Governance Registry
-The WSO2 Governance Registry Development Team

CopyExecutor explained

In my previous posts, I have explained about the lifecycle management functionality in WSO2 Governance Registry. These posts covered a variety of topics ranging from the configuration model to its extension points. Executors are one such extension point and I have given an introduction to executors and about the default executors in couple of my previous posts.

This post explains about the default copyExecutor that is shipped with WSO2 Governance Registry 4.5.0. First, lets look at the code of the copyExecutor. You can find the original code segment using this link (which in located in WSO2 code base).

Before explaining the copyExecutor code, we need to get an understanding about how to configure the copyExecutor. The copyExecutor is designed to do one specific registry operation. That is to do an copy operation of a resource from one location to another. With the lifecycle configuration model of WSO2 Governance Registry, we are able to pass parameters to an executor class and because of that, we have made those resource paths (the source path and the target path) configurable from the lifecycle configuration. So altogether the copyExcutor has the following configurations.

• Source path
• Target path
• Copy comments
• Copy tags
• Copy ratings
• Copy associations

The configuration of the copyExecutor is as follows.

Let us go through the copyExecutor code and see how we have implemented these.

In one of my earlier posts, I explained that each executor must implement the Execution interface. This interface has 2 methods.

• void init(Map parameterMap)
• boolean execute(RequestContext context,String currentState,String targetState)

Out of these 2, the init method is called when we parse the lifecycle configuration and initialize the aspect. Also this method gets the static parameters we defined in the lifecycle configuration. Hence in the copy executor, we pass these parameters and we keep track of them using several variables. 

The execute method is called when we invoke a lifecycle operation. Inside this method, we do all the operations. The copyExecutor has the ability to append a version to a given path and these versions can be sent from the Management Console. Hence inside this execute method, we read the parameters that were sent from the UI and create a path according to them. The underlying code segment is as follows.

After that we are checking whether the resource path is in the given current environment. If not, we can not proceed further in the code but the executor should not fail. Hence we return "true" to inform the lifecycle implementation that the executor executed successfully.

Finally, we do all the other operations such as doing the copy operation and copying tags,ratings,comments and associations.

As you all can see, the copyExecutor has a simple code but has a great set of use cases. During this webinar we used the same copyExecutor to copy artifacts from one environment to another. Likewise it has many use-cases when it comes to governance scenarios. 

Application Governance with the WSO2 Governance Registry

We are doing a webinar on "Application Governance with the WSO2 Governance Registry" on Thursday, August 23. Here is the abstract that is published on the WSO2 site. Refer [1] for more information.

At any given time enterprises have several development teams working on a range of applications, all at various stages - from development, to quality assurance, to production. Finding a single product, with the capabilities for storing these applications and managing the lifecycle of each artifact across different environments, is a challenge.

The WSO2 Governance Registry is the central repository management product of the WSO2 SOA platform. It is a single product that utilizes its lifecycle management functionality to move configuration artifacts and descriptions (such as Services, WSDLs and WADLs) between development, test, and production environments.

Join Janaka Ranabahu for this webinar as he examines two features in the WSO2 Governance Registry: the powerful asset definition language (RXT) and lifecycle configuration model. Based on standard XML configurations, these features enable users to define any kind of asset or lifecycle model with ease. Additionally, Janaka will demonstrate how to combine these features along with the other functionality in the WSO2 Governance Registry to govern an application across several environments.

During the demonstration, he will

• Introduce an application asset using the RXT configuration.
• Define a new lifecycle to manage these artifacts.
• Show how you can use the lifecycle management functionality in the WSO2 Governance Registry to move artifacts across multiple environments.

[1] http://wso2.org/library/webinars/2012/08/enterprise-use-case-webinar-application-governance-wso2-governance-registry

Performance improvements in WSO2 Governance Registry 4.5.0

WSO2 Governance Registry 4.5.0 is scheduled to be released this summer. This version of Governance Registry has many new features(some are carbon core features) and lots of improvements as well. In this release we have concentrated more in improving the overall performance of the product. There are few areas that we have focused our attention on and this post focuses more in one of those areas which is performance related to governance artifacts.

Governance Metadata and RXT

"Governance Metadata" and "RXT", these keywords can be considered as the base of governance in WSO2 G-Reg. Lets look at what these keywords describe. 

• Governance Metadata - We have used the term "Governance Metadata" to describe basic governance artifacts like "Services","WSDL","Schema" and "Policy". We have used this term because we store metadata related to web services. Metadata of a web service is what a client needs to know to interact with it. 
• RXT - We use the term RXT or Registry Extension Type to describe configurable governance artifacts. A configurable governance artifact is a new feature that we introduced in WSO2 G-Reg 4.1.1 and with that, users have the capability of defining their own asset model in G-Reg. Configurable governance artifacts are defined using a XML configuration language and those can be added from the management console.

All of these artifact types are called governance artifacts. WSO2 G-Reg exposes an API called the Governance API which can be used to handle these governance artifacts using external code. We have done a significant improvement in performance when handling these governance artifacts using the Governance API.

Artifact ID

The people who have worked with the WSO2 G-Reg's Governance API will know that, each governance artifact has a unique ID called the Artifact ID. The artifact ID is there to identify a governance artifact even after its unique properties get changed. 

Before G-Reg 4.5.0, we used a resource to keep track of all these artifact IDs. We had a resource called the artifact index where we stored all the artifact IDs and the corresponding paths as properties of that resource. This was a bottleneck when it came to highly concurrent scenarios.

In G-Reg 4.5.0, we have identified that the artifact ID should be something unique to all the resources. Therefore we have introduced a new column in the registry database (REG_RESOURCE.REG_UUID) to track these IDs. Now each resource in G-Reg 4.5.0 has a UUID and this gave us the ability to remove the usage of artifact index resource. We have noticed a significant improvement of performance when handling governance artifacts in G-Reg 4.5.0. 

So my final conclusion is that G-Reg 4.5.0 has far better performance than its predecessors when it comes to handling governance artifacts. 

Default transition UI - Part 02

WSO2 Governance Registry lifecycle model has many extension points. One of them is called the transition UI. In one of my previous posts, I have given an insight to what transition UIs are. This post is an continuation of my previous post.

WSO2 G-Reg distribution includes a single transition UI. This transition UI is used by the default service lifecycle for its service version functionality(more information can be found here). This transition UI does the following.

The name of the default transition UI is "pre_invoke_ajaxprocessor.jsp".

The main functionality of this UI is to take user input for the versions of services and their dependent resources, so that they can be passed to the service version executor.

It is displayed only for services. It will ignore all other media types.

It will list down all the dependencies of a service resource. These dependencies are gathered recursively. Hence all the dependencies of that service and its dependent resources, will be displayed in the UI.

Parameters can be passed to these UIs. The lifecycle configuration model supports adding parameters to a transition UI element and these parameters are added as URL parameters. Please note the section after the "?" in the following example.

The "pre_invoke_ajaxprocessor.jsp" accepts 5 different parameters and all of these are optional.

1. preserveOriginal - Setting this parameter will allow users to instruct the server to keep the old resource or whether to delete it. If this parameter is set to "false", then the underlying implementation will delete the resource after a state transition. This parameter is set to "true" by default.
2. viewVersion - This parameter is there to instruct the jsp page to avoid displaying the content of the page. If the viewVersions is set to "false", the underlying implementation of the jsp page will do an invokeAspct() call including parameters like "preserveOriginal". We use this parameter to pass the value of the "preserveOriginal" parameter to the server without displaying any additional UI to the user.
3. displayMediaType - This parameter is used to override the default media type which is checked by the jsp page. By default, this UI checks whether the resource has a media type equal to "application/vnd.wso2-service+xml"(which is the default service media type of WSO2 G-Reg). By setting this parameter, users can override the above mentioned value. 
4. showDependencies - Instructs the jsp page to not to show the dependent resources of the service. If this parameter is set to "false", the jsp file will only show an input field for the service resource in the custom UI(it will not give input fields for any dependent resources).
5. currentEnvironment - Defines what is the current environment of the service(or its dependencies). The value of this parameter should be a path in the registry. If this parameter is set, the jsp page will not show input fields for resources that are not in the given registry path. 

Default transition UI - Part 01

In one of my previous posts, I discussed about few improvements that we did in the lifecycle configuration of WSO2 Governance Registry 4.1.1. In that post I explained about one of those points, which is the executor interface. Today lets have some insight into the other improvement we did, which is the transition UI.

What is a transition UI?

We use the term "transition UI" to describe a portlet that is displayed as an result of an lifecycle action. In other words, transition UIs are used to get user input at runtime, as a part of a lifecycle transition. To get some clear idea about it, lets look at the following use case. 

Eg:-

Say that I'm a user who is going to govern all my services in WSO2 G-Reg using its lifecycle management capabilities. As a part of the governance process, I need to keep my services in different locations of G-Reg based on the lifecycle state of a service. As a part of this operation I also need to add a version to my services.

Adding a version to a service that is been moved to different environment is somewhat a tricky operation. The version that needs to be added, should be given by a user at runtime. For this, we need some kind of a mechanism to give user inputs for a lifecycle state transition.

We introduced the transition UI feature to achieve the above, which is to give user input for a lifecycle state transition. There are few key things that a user should know about transition UIs.

Transition UIs are registered for an action/event in a particular state. The registration happens through the lifecycle configuration.

If the lifecycle configuration demands the same transition UI for multiple actions/events, then it has to be re-registered.

Only one transition UI can be given for a action/event in a particular state.

Parameters can be passed to transition UI. These parameters are defined in the lifecycle configuration and they are considered as static parameters. Hence they can not be changed at runtime.

The input values that are given through the transition UI are passed to back-end and they can be read using an executor.

Transition UI appears below the lifecycle portlet and there are no popup windows.

There are few transition UIs that we ship by default. I'll be covering about them in another post.

WSO2 Governance Registry 4.5.0 - Lifecycles

At the time of this post, we are preparing for the release of WSO2 Governance Registry 4.5.0. This new version has lots of new features and performance improvements. From this post, I would like to mention one such improvement that we did for G-Reg Lifecycle management feature.

Lifecycles in a nutshell

WSO2 G-Reg has a powerful lifecycle model with lots of flexibility. In WSO2 G-Reg, users have the ability to define their own lifecycle model using a simple XML configuration. The default lifecycle configuration of G-Reg has the ability to define states,check items,permissions,transition UIs, pre and post transition actions. A detailed description about the lifecycle model of WSO2 G-Reg can be found in this post.


In G-Reg 4.5.0 we have introduced the ability to audit lifecycle operations. This means we capture all the lifecycle operations of a particular resource. Following are some key points when it comes to lifecycle auditing.

Lifecycle auditing is turned on by default.

Auditing can be turned off from the lifecycle configuration. This can be done by setting audit=false in the lifecycle element in the lifecycle configuration.

Lifecycle auditing happens per lifecycle. Based on the configuration, all the resources associated with that lifecycle are audited.

Audit logs are kept as a resource in G-Reg. These resources are stored under, "/_system/governance/repository/components/org.wso2.carbon.governance/lifecycles/history" collection. A resource is created for every resource/collection that is associated with a lifecycle. The name of this resource is calculated by replacing all the "/" with "_" of its full path.

Audit logs are kept as a XML file. A sample audit log is as follows.