It occurs to me that a service registry can be used not only to keep track of service providers, but of service consumers as well.
I've talked about what a service registry is (and how it's different from a repository) and IBM's main service registry product, WSRR. One need in SOA is: When a service consumer needs to invoke a service, it needs some way to find the endpoints for the providers that implement the service. This is where a service registry comes in. In short, when you deploy a service provider as an endpoint in a production environment, you ought to add the endpoint to the service registry. This way, a service consumer can use the registry to find the endpoint and invoke it. I prefer a deployment model with a single function to add the endpoint into production and register it, and a retirement function that also removes the endpoint from the registry, so that all providers in production are automatically listed in the register.
Another quandary in SOA is: Who's using this service? You've deployed a service, and now you're tired of maintaining it and thinking about getting rid of it (that is, shut down all of the providers in production). If so, what applications will that affect? For all you know, no one's using the service, so shutting it down will be no problem. But you'd like to verify who's using it (if anyone) and consider the impact before shutting it down. Today, the main way to do this is to look at all of your apps in production and go through them to see if they're using the service; not very efficient. Perhaps you can use the ESB; assuming it can identify the consumers invoking a service, it can keep track of that. Still, that only tells you who's used the service lately; an app that hasn't used it in a while may (or may not) still be planning to use it again. Most projects fall back on using human-readable documentation to try to keep track of what apps are using what services, which obviously is rather incomplete and error-prone.
It occurs to me that the register can be used to solve this problem as well. Not only should service providers be registered, service consumers ought to be registered as well. This way, the registry not only contains a list of providers of the service, but also all apps that are consumers of the service. Then when you're considering making changes to the service (such as getting rid of it), you know what apps are using it and can take them into account. Registering and de-registering consumer apps ought to be an automatic part of deploying and removing the app; if the needed (Web) services are represented in the app as J2EE resources references, for example, those resource refs can be registered with the registry.
To paraphrase the saying about orange juice: Service registry: it's not just for providers anymore, it's for consumers too.