Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

There is no question that the topic of SOA governance has become a hot topic in industry discussions. Increasingly the focus is centered on the issue of repositories and registries. What role should a repository and/or a registry play in an SOA initiative? There are those that say "a registry is all you need," while others, including Ron Schmelzer and Jason Bloomberg of ZapThink, argue that a repository with asset management and governance capabilities is just as important as the downstream registry. Before I explore this latter point of view, however, let's define those two terms within SOA.

A repository manages services and their artifacts (for instance, work products such as requirements documents, models, test plans, usage guides, and the like) through their full architectural, development, and deployment lifecycles. A registry, on the other hand, specifies the set of available deployed services (think Windows registry, which is used to manage the list of installed programs and some of their configuration settings). A repository may store artifacts directly, or more likely, it may simply reference where those artifacts reside (for example, version control repositories, requirements management tools, automated test tools). Repositories are also used to manage the supporting software assets that make up the service implementation--the myriad components, adapters, legacy application APIs, SQL queries, and other software elements that support the operations expressed by a Web service's WSDL document.

With these definitions, it becomes clear why a repository is just as important--if not more important--than a registry. A well-designed repository is where everything comes together on the architectural/development side of SOA; where new services can be proposed and managed through their development lifecycle, then exposed to downstream application developers directly within their IDEs. This production/distribution/consumption model is core to SOA, and applies not only to deployed services (the purview of a registry) but also to services under development or architectural review. Certainly, at some point those produced services will be deployed and exposed through some form of registry function (be it UDDI, an ESB's native registry/proxy service, a repository's search and notification APIs, or even LDAP), but thinking that you have solved your service management and governance problem by deploying a registry is like thinking that you've avoided an iceberg by avoiding the part you can see. The registry is 10 percent of the solution, and the bulk of our needs are "underwater" and invisible to the deployed service environment.

Much of the confusion may result from the industry's focus on SOA operational management and governance. Defining, tracking and managing factors like service-level agreements (average response time, peak response time, average throughput, peak throughput) and authorization policies (users from organization A are allowed to invoke this service while users from organization B aren't, for example) are clearly important once the pieces of an SOA get up and running within an organization's IT infrastructure. However, while operational governance and management is necessary for a successful SOA initiative, it is insufficient. In effect, focusing solely on operational management and governance is putting the cart before the horse (or perhaps more accurately putting lipstick on a pig). If an IT organization is simply concerned about how its services are deployed and managed without paying sufficient attention to the driving business architecture and the development processes and practices used to build services in support of that architecture, that organization is very likely to have a set of well-managed "service spaghetti," not a true SOA. For an organization to effectively define and implement an SOA it must extend SOA governance back to the development and architectural perspectives. Implementing a series of point-to-point services masquerading as an SOA will simply revive the integration nightmare of a few years ago with just another layer of technology.

To be successful with SOA, you must find a way to bind these perspectives together as seamlessly as possible to enable effective information flow in both directions: From architecture to development to operations, and vice versa. This is where a repository shines--in managing a broad range of software asset metadata and in expressing that metadata in different forms to the various constituents or stakeholders of an SOA.

Clearly, any SOA deployment needs some way to indicate which services are available and where they can be accessed. However, if you are not managing the process of defining, developing, and distributing those services, you are very likely to produce A Bunch Of Services (ABOS) instead of an SOA, and end up with a lot more point-to-point spaghetti code in the bargain. Don't fall into this operations-centric trap.

Brent Carlson is vice president of technology and co-founder of LogicLibrary a provider of software development asset (SDA) management tools. He is the co-author of San Francisco Design Patterns: Blueprints for Business Software (with James Carey and Tim Graser) and Framework Process Patterns: Lessons Learned Developing Application Frameworks (with James Carey). Brent can be contacted at http://www.logiclibrary.com/.

RELATED ARTICLES Logging In C++ : Part 2 OutSystems Updates Agile Platform SDK, .NET Controls Released for Communications Enabling Web Pages Welcome To the World of Cryptographic Voting recls 100% .NET		TOP 5 ARTICLES No Top Articles.