SOA governance basics - building the structure for SOA resources

What is the best way to use WSO2 Registry for SOA governance? How to structure your SOA resources? How should you model certain SOA resources? These might be some questions that comes to your mind when you first starts to use WSO2 Registry. Well... the simple answer for all above questions is that it is all up to you. And it depends on your requirements. In other words, WSO2 Registry gives you complete flexibility to build your SOA deployment in the most suitable way.

First, you can decide what are the top level categorizations of your deployment. This may be based on departments of your organization, different businesses you operate, your clients, suppliers, etc. Once you have a basic categorization, you can start mapping them to collections of WSO2 Registry. Note that you don't have to identify complete categorization at this point. If you have top level collections, to which you want complete control, that is what you need.

Next step is to identify the users of the SOA deployment. Possible candidates are developers, server administrators, managers of departments, representatives of clients, etc. Among these you should identify roles (e.g. HR department managers) and users (e.g. Chamith). And these can be mapped in to users and roles of WSO2 Registry.

Now you have identified possible users and top level collections. Then you should make sure that your users are not going to mess up with others' stuff. Authorizations are there to help you in this. Go to created collections and give and block required permissions.

Ok, next is modeling resources. Some of your resources can be a collection of resources. For example, a SOA service can be a collection of documents, WSDL files and binary files containing the actual service implementation. In that case, you can model a service using a collection. Some other resources can be just a single file. An example would be a configuration file of a server. Such resources can be modeled by a resource in WSO2 Registry. Now, these are the basics. There are more elegant ways to model resources in the way you want. You can define a media type for your SOA resources. These can be either a standard media type or a custom media type. Then you can write handlers in WSO2 Registry to apply custom processing to such resources. Below are few things you can do for modeling SOA resources.

* Restrict allowed child resource types for a particular collection type
* Extract some values from a text file content and set them as properties or tags
* Validate the resource content and block invalid resources
* Provide custom view (UI) for certain resource types

There is very little limitation on what you can do with this plug in mechanism. And more features are on the list, which will be available for plug in authors. I will cover more on handlers later. But for now, this gives you an idea of what options are available for modeling SOA resources in WSO2 Registry.

Making up the structure of SOA resources is just a basic step towards SOA governance. There is lot more to come for making it complete, which I will cover later.

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.