A new kind of (SOA) Registry

For a while I've been thinking that the SOA registry space has been a little overcomplicated. The first problem is the inheritance of the UDDI initiative. UDDI has a number of significant problems, but the biggest problem is that it has skewed the collective view of what a SOA registry and repository should look like.

The second problem is the lack of a really nice, simple, successful open source initiative in this space. When I talk to customers, even hardened Open Source supporters, they tell me they are looking at proprietary systems such as HP/Systinet and Software AGs Infravio.

So we thought, lets look at this again. Our view on OSS is to start with what is really needed and work from there, maybe adding some extras here and there. So what is essential in an SOA registry:

• You need to be able to store and retrieve stuff, both with a remote API and with a Web browser. Of course its also nice to have a local embeddable Java API.
• You need to be able to search, categorize and catalogue the stuff - and wouldn't it be nice if you could also tag and comment on that stuff.
• Its essential that there is security, access control and versioning on every bit of stuff you put in there, so you know that this is a robust and trusted source of information.
• The system should track dependencies between items, and should be able to manage those dependencies as items are versioned - this is really important for SOA governance.
• There needs to be ways of importing, exporting and copying stuff, as well as managing the lifecycle - from sandbox to test to staging to production to deprecation.

You notice I called the things you store and search and read from the registry/repository "stuff". In the SOA case they are mainly XML documents (WSDLs, WS-Policies, etc) but they might also be Word or Excel documents. And in fact, fundamentally they are just resources.

So now let's look at this problem from the Resource Oriented perspective instead. Let's think about UDDI and where it went wrong - why do I need a SOAP call to update a resource, when a POST or PUT can do? At least UDDIv3 allows me to read resources using HTTP, but is there any reason to have any SOAP call to read a resource? And why do I need unique identifiers to be TModels when the humble URI/URL makes a perfectly good unique identifier?

So fundamentally the approach we have taken is to build a registry/repository based on REST concepts. And as we looked at the REST space, we kept noticing how close the Atom Publishing Protocol (APP) is to our needs, so we've made that the public remote API to access the repository. Of course, if you are just browsing the registry, you only need a browser - APP is mainly there to support updating resources.

Of course, using Atom and APP gives some really nice benefits too - like being able to subscribe a feed of new resources that meet your search criteria.

If you want to join in, you can subscribe to registry-dev, or you can download the code, have a play around and submit some JIRAs. Join the fun!