One of the neat things about SOAs (services-oriented architectures) is that they're supposed to promote reuse. 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.

At the risk of splitting hairs, we'll side with Flashline on this one. At run time, you're more interested in checking whether a service is the right one or whether policies will allow it to be exposed, and under what conditions. You don't need information about all the back-end dependencies that are of more concern to developers. Anyway, while your system is parsing XML, the last thing you need is searching through a complex database.

But as to what role repositories play in governance remains a gray area. Maybe it makes sense to use them for pushing approved services out to the registry. Then again, that overlaps what source code and version control tools from IBM/Rational, Borland, Microsoft, Serena, and others already do. Should we treat services any different?

What about when improper service requests are made at run time? Should the registry check back with a repository or with run time management engine from providers like AmberPoint or SOA Software? Our sense is that repositories are overkill for run time, and that you may as well utilize tools that are designed for fast response. We believe that repositories are where you store and version policy, rather than enforce it.

Significantly, BEA is positioning the Flashline acquisition as part of an SOA governance strategy. We agree that the important word is "part," because BEA still relies on third partiers for registry and run time services management. And in the future, we expect that IBM will ramp up its alliance (and probably acquire) WebLayers as its SOA governance response.

Services have finally given repositories a purpose for being, but we're still a ways from figuring out where they actually fit in.

Tony Baer, principal of onStrategies, is a well-published IT analyst with over 15 years background studying implementation issues in enterprise systems, application development, data management, and business intelligence. This piece first appeared in the onStrategies Perspectives newsletter and on Tony's new blog, onStrategies Perspectives.