One Registry to Bind Them All

I’ve been wrestling with what seems to be a common problem – finding the right language to describe, arrange and catalogue services/sub-services.

I need to describe everything my client organisation offers its customers in a common easy-to-consume ‘Service’ language, regardless of how the service is delivered – some services are technology-based (e.g.. SaaS or Data Centre related) and some are competency-based (e.g. software lifecycle expertise or SME advisory). I want to be able to describe all the services offered in a consistent, non-technical, language that is readily understood by both service consumers and service governors alike. And just to make life more interesting, services are described at varying levels of granularity which requires a degree of consolidation of some of the finer-grained services into ‘Service-Bundles’ – if only for ease-of-consumption. When I look at the prevailing services registry technology, it seems the current SOA-based registry offerings are too limited in their scope. Interestingly, although my client is building to an SOA, the usefulness WSDL/UDDI-focused registry is unclear today.

What is needed is a more expansive set of tools that deal with full service lifecycle management. This includes the classification, marketing and consumption of all the services involved in business transactions beyond the narrower world of SOA. So it seems there is a need to support a broader landscape of all the services both provisioned and consumed by a given business domain. Features might include:

• Service Taxonomy (relationships between services – across levels of granularity)
• Delivery Medium
• Lifecycle Management
• Proto-Services (candidate services not yet exposed)
• Version Management
• Service Withdrawal
• Event Definitions (real-world or technology-based triggers and exceptions)
• Content Definitions (any human-based or technology-based information exchanges)
• Policies and Policy Management (any rule, law or binding contract that constrains the service)
• Value and Trust calibration (inter-dependency and degree of desired or necessary binding).

I’m sure there are many other dimensions that might be included, but you get the general idea. It seems that even within the die-hard SOA camp, the once prevailing UDDI/Service-Broker-view of the world is giving way to a slightly more traditional perspective on how we provide and consume services (i.e. how business was transacted way before anyone uttered S-O-A). SOA thinking, however, is forcing a much needed degree of rigour on the definition, management and operation of services. Might a combination of these two perspectives (traditional services and SOA) drive out some interesting thoughts around what it really takes to operate in a marketplace of interacting services and therefore what a comprehensive Services Registry might look like?