The various groups defined in governance activities need access to different sets of information on deployed and available services at different points of time. Service specification documents explain the externally visible features of the service to a service consumer and are mostly limited to the interface details (WSDL documents in case of Web services). Better and more comprehensive service specification documents may additionally define service level characteristics like reliability, policies, and state. Service specifications focus on describing the service in its static form but fall short in providing a real-time view of the deployed service being used as a reusable asset in the enterprise. The service registry addresses this shortcoming.
The service registry – The service registry has at least two antecedents: first is the document repository and the second a UDDI registry. The term service registry may be a misnomer since the registry is also a repository of service meta-data. A service registry is quite useful in the following stages of the service lifecycle as an information store of service meta-data:
A case for standards
Work is underway by consortia like OASIS, IEEE, W3C, IETF and WS-I , to define standards and specifications around SOA. While some may view it as standards overload, there undoubtedly is a case for defining guidelines on service specification and service life-cycle processes. Best practices for using service registries in SOA governance and feature-set specification of a service registry are useful too. Standards, specifications and guidelines when defined, provide a good framework for using the service registry in SOA governance and consequently realizing the benefits of SOA adoption.
Regunath Balasubramanian leads the Technical Achiever Program at MindTree and is a practicing architect. He is an advocate of open source both in using and contributing. He blogs frequently on technology athttp://regumindtrail.wordpress.com.