WSO2 Registry custom UIs - an example

I though it would be useful to give a quick sample of custom UIs, since this is a new concept for SOA registries. So our sample here is an Axis2 module configuration file. Usually, if a custom UI is not provided, WSO2 Registry will give a download link to download the resource content. But we would like to view the module configuration, without downloading it. And also, we prefer to edit some parameters on the fly, from the UI. So, here are the results of using WSO2 Registry custom UI functionality to achieve above requirements.

Custom UI to view Axis2 module configuration:

Custom UI for editing Axis2 module configurations:

(sorry that images are not very clear after uploading them to blogger. I have to find a better way to add images)

Thus, you can generate UIs to match exact requirements of your SOA artifacts. You may highlight certain values, make some values immutable, add descriptions, etc. Magic behind this is the handler mechanism of WSO2 Registry (in fact, generating custom UIs is just a one application of handlers). And WSO2 Registry makes it more convenient to write custom UIs for XML content. You can just write XSLTs to generate view and edit UIs for XML content. That's exactly what we have done in this sample. You can browse the view and edit XSLTs for this sample from WSO2 Registry svn. All the resources for this sample can be browsed here.

Custom UIs for SOA artifacts

Major step towards SOA governance is the visibility you get about the SOA deployment. Visibility has to cover many sections such as resource structure, users, privileges, dependencies between resources, etc. And we should not forget about the visualization of contents of SOA resources. But the resources in SOA deployments have different contents including WSDL, XSD and other application specific XML formats as well as other text and binary formats. So there is a challenge to provide the best view for all resource types.

WSO2 Registry addresses this problem by introducing custom UIs for SOA resources. That means the UIs for resources can be written by users and plugged in to the registry. Thus, each resource type gets the best possible UI. This is done by the handler mechanism implemented in the registry. Handler authors get the flexibility to provide UIs for both viewing and editing their resource types. Of course, WSO2 Registry will eventually provide built in UIs for many common resource types. So the end result is that the users of the WSO2 Registry gets a detailed and nicely tailored view of their SOA resources.

This feature is currently in the development stage. You can take an early look from the svn. Just build the registry and try out the custom-ui-sample1. This is still taking shape. More stuff will come in to this soon. So, stay tuned to WSO2 Registry to find out how make SOA governance easier.

More uses WSO2 Registry

I discussed about main methods of using the WSO2 Registry here. We can combine those methods of individual usages to achieve more interesting deployments of the Registry.

Let's consider the combination of Registry server deployment and the remote Registry deployments. In this scenario, you can start with deploying the Registry war file in an application server. To start with, create the initial users and roles to whom you are expecting to give some level of administrative privileges. Then you can define the initial categorizations of the Registry by creating the top level collection structure. These collections may include sub-collections for each of your departments, partners, suppliers, clients, etc. Then you can give the desired permission levels for the users who are supposed to manage each of those sub-collections. Once this is done, managers/heads of each sub-collection can use the Registry to store all the resources needed for their sections. These include the employee records (word documents), accounts (excel sheets), business plans (presentations), product details (pdf files), etc.

But that's not all. All the SOA related resources for each department can also be stored in the sub-collection tree of corresponding department. IT managers can store WSDLs for their services, jars/aars for pluggable components or services, configuration files used by department's servers, etc in the sub-collection tree of their department. Once you setup the resources for your SOA deployments in the Registry, you can point your web services servers, ESBs, application servers, etc to the Registry. Any server, that is completely unaware about the Registry or its APP based protocol can use it to fetch resource. Because simple HTTP GET requests are all you need to fetch resources from the WSO2 Registry. But if you want to access all the features provided by the Registry, you can embed the Registry APP client to your Java servers and call the Registry API though it. In this way, you can manage your organization's general resources as well as resources for driving the SOA deployments of your organization around the WSO2 Registry.

Three ways of using WSO2 Registry

In my previous post, I blogged about the 0.1 release of WSO2 Registry. Below are three simple ways of putting it in use.

Registry server with the cool web UI

This mode of usage is targeted at end users who want to organize and manage their enterprise/organization around the Registry. You can start this with virtually zero steps. Just drop the wso2registry.war file in to an application server and you are done! Now point your web browser to the URL http://localhost:8080/wso2registry (you have to use the port of your application server). You will get the web UI of the Registry, from which you can perform all the operations supported by the Registry.

Now you can keep on adding resources, categorizing them using collection, creating users/roles, granting permissions for users to access only the required operations on required resources, etc. So that is the initial administration step. Once you create necessary administrative users and roles, you can open up the Registry to your organization (and probably to your partners as well). Then sit back and watch how your enterprise's registry grows as users fill in content, tag them, comment on them, rate resources.... Basically Registry provides the infrastructure for building a community from your organization's members (and partners) who collaboratively builds and manages the resources of your enterprise.

Registry as a Java library for building content oriented applications

Core of the Registry can be embedded in Java application as a jar file. It provides an API through which all the features provided by the Registry can be accessed. So what is the use case of this... It serves as the back end to build applications that need to store and manage any content. In addition, your application automatically gets all the tagging, commenting, rating, versioning,... features. Plus, the comprehensive permission scheme on all the resources stored in the Registry. We, at WSO2 has used this Registry core to build the community site for WSO2 Mashup server. You can find a perfect example of building a Web 2.0 style community site using the WSO2 Registry library in the Mashup community site.

Registry to host remote content for applications

WSO2 Registry provides a remote API using APP. Currently it provides a Java APP client for the Registry API. You can embed this client in your Java applications and use WSO2 Registry as a remote content repository for your applications. This can serve as a great method for clustered deployment of content oriented applications, where all applications can be pointed to the same Registry for synchronizing the content among all nodes. Then all your applications get the community features mentioned above as well. As the Registry is running in the server mode in this case, you can simply use the web UI to administer the content of distributed applications.

As it uses the APP as the wire protocol, it is not restricted to Java. Programs written in any language can process the APP based protocol mentioned here and access the Registry remotely.

This is very high level overview of the uses of WSO2 Registry. Each of the scenarios mentioned above has more application specific usages. Start playing around and discover how it suits your organization or the application.

WSO2 Registry 0.1 Released

WSO2 Registry enables you to store, catalog, index and manage
your enterprise meta data in a simple, scalable and easy-to-use
model. It is designed around community concepts such as
tags, comments, ratings, users and roles. Think of the registry
as a structured wiki designed to help you manage your
meta-data in a simple business-friendly system.

In addition, the registry allows you to store more unstructured
data such as Word documents, Excel spreadsheets and text
formats. Using these approaches, you can build a catalog of
enterprise information ranging from services, service descriptions
to employee data and on going projects.

WSO2 Registry can be deployed in Application Servers and
access using the Web UI or the APP interface. It can also be
used as a Java library inside other Java programs as
a resource store with all community features and versioning.

WSO2 Registry is released under the Apache License v2.0

Check out the project home page at
http://www.wso2.org/projects/registry
for additional information.

Enjoy the new way of managing resources over the web!!!


Features List

* Storing and managing resources and collections
Add, edit, delete and retrieve resources
Categorize resources using collections

* Tagging, commenting and rating resources
Tag resources and browse other's tags
Identify validity/weight of tags using tag clouds
Comment on resources and see what others have to say about your resources
Rate resources and see how the community has rated resources

* Managing users and roles
Create, edit and delete users
Add roles and assign users to roles

* Authentication and authorization
Protect resources/collections by controlling the authorization based on
users and roles

* Resource / collection versioning
Browse previous versions of resources/collections
Restore any resource/collection to previous versions

* Tag based search
Search resources by tags applied by you and others

* Advanced search
Search resources based on advanced criteria

* Activity log and filtering support for the activity logs
Browse all activities performed on the Registry with date, time and the
user who performed the activity.

* APP based Remote Registry
Embed remote Registry inside Java programs and make Java programs
interact with hosted Registry servers.

* Media type handling support (experimental)

* Web based user interface with Web 2.0 look and feel