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.