InfoQ

InfoQ

InfoQ

En | 中文 | 日本語 | Br

592,113 Apr unique visitors

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Role of Service Registries in SOA Increasing in Importance

Posted by Jean-Jacques Dubray on Jun 29, 2007

Sections
Enterprise Architecture
Topics
SOA ,
Governance ,
Architecture ,
Enterprise Architecture ,
Registry
The concept of “service registry” has been a corner stone of Service Oriented Architecture since the year 2000, with the launch of the UDDI specification (an SPI that supports dynamic discovery of services). At first, it was thought that we needed global yellow pages from which services could be queried and discovered while supporting a “dynamic” consumer model. The “service registry” has evolved significantly since these early days. First, Global registries from Microsoft, IBM and SAP have all but shut down for the lack of published services while people have lost interest in the “discover & consume” pattern. Later, pioneers, such as Systinet, went on to built a healthy market by understanding that registries were a key ingredient of an enterprise SOA to enable consumers within an organization to be able to find the services that were already built by other parts of the organization. The truism to keep in mind is that you can’t reuse what you can’t find. Hence you can’t achieve the main benefits of an SOA without a local enterprise wide registry. Sure, most people start with a spreadsheet, but it quickly becomes unmanageable.

Registries did not stop there; they were complemented with a repository as it became clear that service metadata needed to be stored in a consistent way and version controlled (Schemas, WSDLs, …). ebXML had actually had the foresight to create a combined specification for a registry and repository way back in 2001.

With the growth of the ESB market, registries supported service end point look ups at run time. This capability became a widely used pattern, the mediation pattern, which can help isolate service consumers from the deployment of new versions of a service. It can also be used in combination with some business rules to decide the most appropriate end point to render the service for a particular request and consumer. The possibilities of this pattern are endless and coupled with a monitoring infrastructure it can also help you enforce service level agreements (SLA) either from a load balancing perspective or based on specific business requirements.

In parallel, the notion of “Governance” emerged. If we want to build services that can be reused, well, they have to be designed, funded and operated in such a way that other consumers would want to reuse them. Infravio and Systinet were amongst the first ones to offer this capability. At this point the market matured and innovators were acquired (Systinet is now part of HP, FlashLine is part of BEA and Infravio part of Software AG) while new products were developed (SOA Software) with an increased focus on SLAs. Registry became so strategic that some large infrastructure vendors such as IBM, and now SAP, chose to develop their own registry and integrate it tightly with their tools and infrastructure. We can expect that Microsoft and Oracle will follow.

Susanne Rothaug, product manager at SAP, details today in her blog the capabilities of this new registry.  SAP pushes one more time the boundaries of registries providing a single design environment that links business architecture with service designers and service consumers to better support the alignment between IT and the business.

With this new direction, we can expect the service registry to become the central information system where all the enterprise metadata is stored while supporting and federating business architecture, enterprise architecture and solution architecture. The action is just beginning! 

  • This article is part of a featured topic series on SOA

No comments

Watch Thread Reply