Theoretically, repositories capture the metadata about software code, and depending on your point of view, actual software artifacts themselves. By contrast, registries, which emerged to prominence courtesy of the UDDI specification, are intended as service catalogs to which service requests can bind at runtime.
Obviously, if you are operating an SOA environment, the last thing that a service request needs to leaf through is data on all the interdependencies to back end systems that may be associated with the service. UDDI registries are intended to be lighter weight contact points so as to add more overhead to SOA environments that already must deal with the compute-intensive burdens of parsing XML.
While it’s clear that repositories play a key role at design time, where you enter all the dependencies and policies associated with exposing a service, it’s not clear what the interactions would be at run time.
One scenario is that the registry plays the role of promoting it to run time with an event that triggers a human workflow for approving listing of a service in a UDDI registry. Of course, that’s also the same function that is performed by version and source code control offerings provided by application lifecycle management vendors like Rational and Borland.
Another scenario is what happens when a service is requested for a use that might be in a gray zone when it comes to complying with policy. Would that be the role of SOA run time governance tools from providers like SOA Software or AmberPoint, or would the registry then intervene?
Repositories of one sort or another have been kicking around since the days of CASE (Computer-Aided Software Engineering). They have never garnered much market because of several factors.
First of all, it is aimed at software development organizations with highly codified practices, which sharply limited their potential market. Second was the issue of just what exactly goes into the registry. Do you store all the software artifacts, policies, dependences, models, test cases, or just the metadata with pointers as to where the information resides? With such a fuzzy role, repositories traditionally proved a tough sell.
And the product category claimed some notable victims. Just over a decade ago, Microsoft ditched an effort with the former Texas Instruments Software unit to mass-produce a repository for the Visual Studio market. Microsoft realized it needed some form of tooling to help VS customers gain a better grip on all the code they were spewing out. But the effort foundered because of scope creep.
Just over a decade later it had the answer: Visual Studio Team System (VSTS). But significantly, at the heart of Team System sits what Microsoft calls a data warehouse. It doesn’t dare go near the term repository.
But the emergence of SOAs provided a new raison d’etre for repositories because of their emphasis on reuse. Yes, you had new standards for exposing functionality across your enterprise software portfolio, and therefore, a problem that was more containable and definable. And while reuse has always been a goal of modern software engineering, SOA standards provided a uniform system of headers that made it more attainable.
Flashline, which was founded in 1998, has been offerings its repository since 2001. Although initially aimed at more traditional software development cases, the emergence of services have kept the latest iteration relevant. Last fall, Charles Stack, the outgoing CEO of Flashline who plans to remain with BEA, told us that 90% of customers were using the repository to support SOA environments.
Nonetheless, when UDDI web services registry standards emerged, there was confusion in the market that registries were the same as repositories. Indeed, with its product Xregistry, Infravio provides a data store that serves both purposes.
Stack was quite vocal to us about the limitations of UDDI, saying it was useful simply for locating a service and providing policy info related to binding at run time. But to Stack, those issues were just the tip of the iceberg for SOA because of the issues associated with supporting software reuse. At one point, he told us that UDDI really missed the mainstream.
Last fall, the company unveiled a brief promotion where they would credit $50,000 towards any UDDI customer upgrading to the Flashline repository. Post acquisition, he could disclose if any customers took Flashline up on its offer.
Obviously, post acquisition, Stack is a bit milder in his comments. We’re still saying the same thing, we’re just being a bit friendlier about it, he said yesterday.
Businesses need more control on deciding when services can be put into production, said Paul Patrick, chief architect of the AquaLogic product family at BEA. Whether they call it a repository or not, organization need to store this data someplace. The problem won’t go away, whatever we name this thing.
