Many organizations mark the beginning of their SOA initiative at the point when they deployed a registry as a mechanism for service discovery. At a minimum, a registry prevents duplicative effort, a place where developers can determine whether a service has already been created. As Timothy Vibbert of Lockheed notes, “It could just be a Web site that lists [services]. It may be manual discovery, but they’re discoverable.”
But as the number of services and the applications that use them grow, you’ll need a real registry. “We selected a UDDI registry in 2003 and put it in production in 2004,” says Ben Moreland of The Hartford. “We use it for the dynamic binding capabilities to give us the loose coupling between the client and the producer of the service.”
Most SOA deployments employ some sort of commercial registry or repository that offers deeper functionality than that defined by the UDDI spec, mainly to have a more structured way to store and manage service metadata. To complicate matters, the distinction between “registry” and “repository” is rather slippery. The common definition is that a registry contains data about services -- where they’re located, XML schemas, and so on -- whereas a repository contains the services themselves. In truth, services still run on their deployment platform, so repositories actually contain what amounts to a deeper level of metadata -- plus, registries generally offer repository capabilities. They just don’t call them that.
Choosing a registry may well be the first SOA-specific buying decision you’ll face. And it may also be the first time you encounter the fundamental choice between a single vendor’s offering and best-of-breed SOA solutions. All the big platform players, including BEA Systems, IBM, Microsoft, Oracle, and Sun have their own registries or repositories. But pure-play vendors abound -- including Above All Software, Flashline, Infravio, SOA Software, and Systinet -- all of which boast a unique mix of capabilities. Depending on the product, you may discover a wealth of stuff -- graphic representations of the relationships between WSDL and services, identity-based security that limits access to certain services, a rules engine to help manage service policies, and more.
When it comes to registries or repositories, David Aubrey takes the single-vendor view. “If you’re using any kind of framework, they’ll push a repository,” says Aubrey, senior architect at KomatiSoft, a New York-based financial application startup. “That’s one area, I wouldn’t try and force a third-party alternative unless I absolutely had to. At least not today. The key is interoperability with the framework and its rules engine, and that’s what they’re guaranteeing. Bring in a third-party solution, and you’re putting that whole synergy at risk.”
Not surprisingly, Flashline’s Stack takes the opposite viewpoint. “If you’re building your infrastructure for a service-oriented architecture on a proprietary vendor platform, I think you’re making an enormous mistake,” he says. “We caution all of our customers from the infrastructure standpoint to put a premium on openness, because otherwise you’ll have the worst case of vendor lock-in you’ll ever see.”