The value of a service registry in a SOA

Introduction

Organisations typically have a significant number of services, created by many different workgroups and departments. In order to avoid tight-coupling, centralise integration logic and promote re-use, these services are typically exposed and consumed over an Enterprise Service Bus (ESB). Applications no longer have to store and maintain the endpoint addresses of all the services they call. These are all centralised in the ESB. When a service changes its endpoint, the endpoint is changed in the ESB, and all applications that consume it remain unchanged. This is one of the great benefits of an ESB.

The problem

At one of our customers, we are doing just that: no point-to-point connections, all service calls go over the ESB. Applications are unaware of the exact location of the services they call and are not impacted when that location changes. So far so good, but in a certain way we’re just moving the problem elsewhere. When an endpoint changes, we need to change and redeploy at the integration layer. More in specific, as we’re using IBM Integration Bus (IIB) as ESB product at this customer, we need to rebuild and redeploy the complete IIB integration application when one or more endpoints change. As the ESB is the backbone of the integration layer, this is a high-risk procedure we want to avoid unless absolutely needed.

The solution

Fortunately, our client had a license for WebSphere Service Registry & Repository (WSRR), IBM’s service registry product. Service registries hold information about services residing in your systems or other organizations' systems that you already use, plan to use, or want to be aware of. This information is basically service metadata that is used for selection, invocation, management, governance and reuse of services in a SOA. Next to this feature, WSRR also offers a complete governance process for all services entered in the registry. Now, how does WSRR solve our problem described in the previous section?

One of the metadata WSRR stores for each service is its endpoint. WSRR integrates quite nicely with IIB. In an IIB flow, we can use an endpoint lookup node to dynamically retrieve the endpoint of a service we want to invoke. We no longer have to hard code the endpoint in our IIB flow, it is retrieved dynamically at run time! When a service endpoint changes, we simply update it in WSRR, and the new endpoint is automatically retrieved by the IIB flow. No need to rebuild and redeploy the entire IIB project!

More advantages

Next to the feature described above, WSRR also allows us to manage multiple versions of the same service. A certain version can be deployed in the acceptance environment, while the test environment may already be using a newer version. WSRR allows us to effectively manage this, we always have a good overview of which versions of which services are deployed in which environments. This is part of the greater governance model that WSRR offers us. Each service version has its own life cycle, from when it’s first proposed to when it’s deployed in the production environment. With WSRR we can manage all service versions throughout their life cycles.

Conclusion

We’re already starting to reap the benefits of WSRR at our customer by storing all endpoints in WSRR instead of having them scattered in the various IIB flows. Our next step will be to use the governance model offered by WSRR to effectively manage all service versions throughout their life cycles. We’re sure that this will help us manage the ever increasing number of services at our customer!

Niek Jacobsen