During the last few years, UDDI has been at the center of Service Oriented Architecture (SOA) Governance platforms. Specifically, UDDI has been the main mechanism used to implement service registry and repositories which we all know are the fundamental component of SOA governance frameworks such as HP-Systinet, SOASoftware or SoftwareAG-Infravio. At this point, I believe the majority of the SOA community has already added UDDI to the list of "irrelevant" Web Services specifications. Although we can attribute different causes to the failure of UDDI, all of them have their roots on the limitations of the UDDI data model. Attempting to model the highly diverse characteristics of SOA environments with standards like UDDI is proven to be a great recipe for failure.
At a high level, SOA governance scenarios can be divided on two main groups: design time and runtime. Design time governance scenarios fundamentally evolve around service lifecycle aspects such as policy configuration, documentation, service publishing, versioning, virtualization among many others. Effectively addressing those scenarios requires fairly sophisticated toolsets like the included in some of the SOA governance frameworks. The role of UDDI on SOA governance scenarios is irrelevant in most of the cases and should be constrained to an interoperability artifact at best.
Runtime SOA governance scenarios intend to manage the runtime behavior of services by enabling capabilities such as endpoint discovery or monitoring. Although UDDI includes some of the mechanisms to address those scenarios, they tend to introduce a lot of interoperability challenges in heterogeneous environments.
If UDDI is not the right answer, what other alternatives do we have?
Around a year ago, vendors like MuleSource and WSO2 proposed an innovative type of service registry based on the concept of the Representation State Transfer (REST) and standards such as the Atom and the Atom Publishing Protocols (APP).
Among many other benefits, this approach removes the complexities introduced by UDDI by adopting RESTful interfaces as the fundamental communication mechanism for interacting with the resources stored in the services registry. While this model still relies on an efficient toolset to address SOA design time governance scenarios, it does not impose any constraints on how elements are represented on the registry. From a pure standards standpoint, Atom and APP represent a more versatile and interoperable alternative to the equivalent UDDI artifacts.
Runtime governance scenarios can be also greatly benefited from the adoption of a RESTful SOA governance model. For instance, monitoring the runtime behavior of a service could be as simple as subscribing to an Atom feed that details some of the metrics associated with the service. Additionally, scenarios like runtime endpoint discovery can be enabled by just using a simple HTTP GET request that queries the service registry. Additionally, the use of RESTful interfaces overcomes the majority of UDDI's interoperability limitations and provides a naturally scalable model for addressing complex SOA governance scenarios.
As we have seen so many times throughout the history of software, simple and open technologies tend to be more widely adopted by the developer community and they are more likely to survive the technology hypes. If we want governance to stop being a fancy requirement of SOA solutions, we need to adopt more open architecture styles. Until now, RESTful services registries appear to be a very attractive alternative that I hope it continues gaining supporters in the SOA community.
Kudos to my friends at MuleSource and WSO2 for pioneering this idea.