WSO2 Registry 1.0 ships

Today we shipped the first release of the WSO2 Registry. You can read the release note here on the registry-dev list where we openly develop it. Those of you who read my blog will have read about this already.

The WSO2 Registry is interesting for two simple reasons, which happen to be related.

1) Its a completely REST-based design, building on the Atom and AtomPub protocols. Everything you store in the Registry is a resource. You can link to these by their URLs - either generically or to a specific versions. There are three simple interfaces to the Registry:

• the Web UI - which is designed so that even my mother should be able to use it (no offense Momma);
  
• the Java API, which is dead simple and clean, and
  
• the AtomPub protocol API, which allows any client, including command line tools like wget and curl to access and update resources.

It's also fully versioned and secure.

2) The Registry has been designed around humans. This is what we call "The Social Enterprise", but has also been known as Enterprise 2.0. The idea is that an SOA registry is the bridge between all the different people (and systems) involved in Enterprise SOA. Some examples include:

• Business users adding hierarchy to the Registry to map out the business domains: e.g. /finance/operations/
• Developers, using the ability to add comments to any resource, describing what WSDL2Java binding options worked for them, or
  
• Explaining what they would like improved in the next version of this service, and
  
• Rating the service, and
• Tagging it with useful tags
  
• The service provider subscribing to the comments on this service using a simple Atom feed
• Service users subscribing to the service and being notified when new versions are published
• Allowing the ESB to use a specific version of the WSDL until the latest version has the right metadata to say its production ready.
  

All these simple things are made possible by thinking about the human aspects of SOA. SOA is as much about trust as about distributed computing - if I don't trust you to provide a good service, it doesn't matter whether its REST or SOAP - I'm not going near it.

I firmly believe that the REST design of this helped unify the goals of making this Registry work technically. The REST approach is proven to work technically - every SOA client can grab a schema or WSDL from an HTTP URL (which can't be said of UDDI - except that UDDI 3.0 also finally exposes resources as HTTP URLs). But even more importantly, the close integration between the Atom design and the Web UI meant that this is not only a simple product to use, but you can do useful things you just can't without the REST nature - such as subscribing using Atom, sending permanent URLs to other users, managing dependencies between resources as URL dependencies.

Take a look, join the discussion and comment, rate and tag us :)