Govern your SOA deployment easily and it won’t cost you a thing…

SOA is the solution to all integration problems. Legacy apps, apps written in different eras, different platforms, languages all talk to each other through SOA. Now with SOA being the solution to everything, causes a new problem 🙂 Everyone is using SOA, means that everyone is exposing their functionality through a service, and a typical organization has a lot of functionality, resulting in a lot of, I mean “quite” a lot of services. Keeping track of all these services is a new nightmare! Is SOA actually giving more headaches than it solves? Well, not exactly. That is where governance comes in. You need to govern your SOA, and that needs to be a key factor when your planning your SOA deployment. So, when your planning you need what’s now popularly termed “Design-Time Governance”.

So, what do you need to look for in this space?
  1. Central location – To avoid the nightmare of everyone maintaining different documents, you need a central place where everyone 
  2. Separate locations – This might appear to contradict with the point above. But this refers the ability to drop documents into separate locations that are only visible to the relevant servers. For example: If you want only want one particular server to see/access the document, you drop it to one location, but if you want a set of servers in a cluster to see the document you drop it to a different location. Furthermore, if you want your whole SOA deployment to see the document you drop it to that location.
  3. Versioning – Your SOA setup is done and it is working like a charm. Your job is done. Or is it? 6 months down the line, you won’t be keeping the same functionality now, would you? No, you’ll be adding more functionality and exposing new versions of the service. So you need to support versioning of your services. It’s important to that you be able to easily create new versions, maintain old versions and restore old versions if something goes wrong.
  4. Permissions – That’s right, now you wouldn’t want everyone to see the company’s pay roll now would you? I thought so. So you need to restrict who sees which documents and control access to.
Have these essentials incorporated into your SOA deployment and I’m sure governing your SOA deployment would be a breeze. It is important remember that proper design-time governance often decided the success (or the failure) of your SOA initiative. To easily have the ability to use all these features take a look at this fully fledged commercial product available here and it’s available free of charge.

Tip on Check in client

The check in client is a neat tool to import and export data from the Registry to the File system. I ran into a small issue when working with it on a H2 database.

For some Databases (specially H2) the check-in client of the WSO2 Governance Registry reports a certain error:

“Error in initializing the Realm Service. Some databases like h2, derby in file mode, doesn’t allow to have multiple connections. In such case, Please make sure no other is connected to the database. If you running the script in separate place, please make sure you have given absolute paths to the file-based database urls.”

This problem by running the check-in client from the GREG_HOME folder. GREG_HOME is the location where the distribution was extracted to.

So now instead of,

GREG_HOME/bin > sh checkin-client.sh co / -u admin -p admin

run the command like this:

GREG_HOME> sh bin/checkin-client.sh co / -u admin -p admin

Hope this work around helps you folks out there who uses this neat tool.