One of the neat things about SOA (services-oriented architectures) is that they're supposed to promote reuse. It's long been one of the holy grails of software engineering; if you're going to have reuse, you need a place where you can store the assets that you'd like to repurpose.
BEA's announcement that it's buying repository provider Flashline as part of its SOA governance strategy reminded us that there's still confusion over what registries and repositories do.
Dating back to the days of CASE, repositories were supposed to be the place where all the goodies about software development were to be stored. The problem was, no consensus ever emerged as to what actually went into repositories. Do you deposit code itself, or metadata about attributes like platforms, dependencies, other artifacts like test cases, or do you simply keep a card catalog of pointers?
With all the fuzziness about what repositories were supposed to do, no wonder that the market stalled on takeoff. Even Microsoft got scared off after investing millions in a joint effort with the old TI (Texas Instruments) Software. Today they've resurrected the repository idea -- somewhat -- in Visual Studio Team System. But Microsoft labels it a "data warehouse."
So, when UDDI registry standards emerged as one of the first building blocks of web services, you'd be excused for thinking of it as a new form of repository. As first conceived, UDDI was supposed to be the catalog or yellow pages that service requests would search at run time to discover the right service.
With UDDI version 3, most players in the SOA space began offering their own registries, or partnered with companies providing them. At that point Flashline's CEO Charles Stack grew quite vocal in claim that UDDI registries were overblown (since the BEA acquisition, he's ratcheted down the tone). For a brief time, Flashline offered $50,000 to any customer upgrading from UDDI registry to its repository.
Some players like Infravio are trying to bridge both functions with a modular single product approach. They claim that the back and forth communication between registries and repositories exacts a hit on performance at run time.
Others like Flashline, of course, say both are and should remain separate: repositories are where you put service artifacts and metadata at design time, while registries are where you list service descriptions and policies that are accessed at run time.
-1-