SOA - A Shot in the Arm for Registry Fans?
It seems so. Registry fans are just beginning to get the attention they have been hoping for the last few years. As I was catching up with my email, I just came this article titled “Registry + Repository = SOA Platform“. Very interesting! A registry and repository to build and deploy SOA!
Let me try to make sense of the contribution of registries to SOA first. The author of this article quotes that “registries hold references to things”. That is right. Registries hold metadata of services and other interesting things. But this article fails to say why and how it helps SOA. As I discussed here, in most applications, registry is a development-time component, but not a runtime component. Developers intending to make use of web services can search repositories to find services that match certain classification criteria. Once a service is found, the next step is to build a client application, which usually starts with some codegen tool to generate interfaces/classes that proxy the service, and then programming to those interfaces/classes. This is the old-fashioned way of wiring up distributed applications. The only exception is when the client already knows how to use the service, and is consulting the registry only to know the where-abouts of the service.
So registries can be useful when the client wants to be directed to an instance of a service based on some runtime criteria such as QoS, fail over etc. Some web services management (WSM) tools advertise such “dynamic routing” as one of the main features of their products. Such tools can indeed take the help of registries for looking up for services (including their WSDL). The difference between the old-fashioned style of fail-over and load-balancing and the new age dynamic routing is the ownership of routing. For instance, in the HTTP world, proxy servers do the routing. In most RPC style applications, client consults some look-up service (such as a JNDI or a naming service) to do the routing. In this context, I don’t see much difference between these styles. The role of registries in this context is not as phenomenal as the author of this article is hoping for. Moreover, WSM-controlled routing has its disadvantages. I will post more about these limitations in a future post.
The second part of the equation is repositories. The author quotes that “repositories hold things”. But what things? I have read this article a few times to understand what he meant by a repository. Is he talking about an XML repository used as a general purpose database? Or is he is referring to a repository for service metadata? Although the article is not very clear, my hunch is that it is the latter. But how does it contribute to SOA? Hmmm.
Looks like my fad-analyzer is not working very well. Time to upgrade?
Hi Subbu,
your points are good, the content of this particular piece was focused on helping people understand the distinctions between and the relationship between registry and repository. So the piece really operates at the reference architecture level, and should help people at least understand how to think and talk about these components and how they relate to one another.
The piece doesnt really go into detail on implementation strategies and standards. I’ve no shortage of opinions on this type of thing, but I’ve reserved those for a future write up… What are the “things” stored in repositories and how does that help SOA? That’s a finer-grained (i.e. Blueprint level) issue. Happy to talk with folks on these topics in more detail, just send me an email…
Miko
Hi Subbu,
I discovered your blog today and I like it, we might get into discussions over versioning soon.
The registry case is incredible, I remember the original goal of UDDI being “dynamic discovery” and I have been thinking it was only valuable in powerpoint presentations!
I think the registry should be used to provide application level routing, the registry should not just return a URL for a service name, the registry should return a URL for a service name, taking into consideration other variables, like who is asking for the service. The URL returned might be different for a client A and a client B. They just might ask for the same service name but have a different URL returned because for example, those service consumers are not using the same version of the service.
Application level routing might also be used in multi-protocol SOAs, the registry deciding what protocol must be used to access a certain service in certain circumstances taking into consideration technical service level requirements like support for transactions, security context propagation or guaranteed delivery.
Load-balancing, fail-over is more about infrastructure routing, this can be indeed managed by appliances or using software-managed clusters.
In this context, the real alternative for a registry is a message or service broker (Hub and Spoke concept). If the routing is complex (ex:data-dependant), the only solution might be to use a broker but a broker could be a bottleneck and is definitely increased the latency of the communication because it is an additional intermediate in the communication between the service consumer and the service provider while the registry is not.
Robin