Herbjorn Wilhelmsen

Should a service only be considered a service if it's reusable? The answer to this question, as asserted by this pattern, is a firm "no." While agnostic services (services providing multi-purpose logic with reuse potential, as per the Agnostic Context pattern), receive the most attention during service modeling and design phases, it can often be short-sighted to focus only on agnostic service logic.

Non-agnostic logic represents any type of functionality that is unique to a given business process or task. In other words, non-agnostic logic is single-purpose in nature and therefore has no reuse expectations. One of the most common forms of non-agnostic logic relates to the composition of other services.

When combining various services into a larger service composition, a parent layer of business decision-driven functions often emerges to establish the overarching workflow of the business task. Because this type of functionality is often task-specific, it is classified as single-purpose (or non-agnostic) and further grouped into a separate task service (a service model established by a related pattern called Process Abstraction).

It's clear that in most service-oriented solutions the non-agnostic logic needs to be separated from the agnostic logic, but why does it need to be located in services? The short answer is: "it doesn't." You can position this parent logic in a rich client, a monolithic system, or some other software program that is evidently not service-oriented, and the service composition can still be carried out. The Non-Agnostic Context pattern does not require that you create task services, it simply points out that there are benefits to doing so.

These benefits have recently been documented in detail in the article "The Case for Single-Purpose Services: Understanding the Non-Agnostic Context and a Strategy for Implementation" by author Herbjorn Wilhelmsen. We won't be repeating them all here, but let's at least list them:

• Multiple Providers
• Isolation Against Change
• Centralizing Governance (Keeping it Together)
• Service Composition Optimization
• Offloading Work from Client Computers
• Business Alignment (Separation of Concerns)

As an example, let's pick the fourth item on this list so that we can take a brief look at how this pattern can help optimize service compositions.

Service-orientation takes the notion of a composition to a whole new level. It is not just focused on the successful aggregation of distributed software programs into a self-contained application, it has its sights set on flexible and adaptive composition. This means that services need to be designed not only to participate in a larger composition, but to facilitate the continuous need to augment, extend, or re-configure existing compositions and to take part in new compositions, to whatever extent business change demands it.

The inherent ability to effectively recompose services (as per the Capability Recomposition pattern) lies at the heart of service-orientation in its quest to enable maximum business agility at an organizational level. Service-orientation design principles address this goal by shaping services into highly effective composition participants.

Another way to think of this is to view it from the composition's perspective. A service composition is a mechanical entity, comprised of distributed moving parts that need to work in concert at runtime in order to carry out the overarching business task. Any part of this composition not subjected to the rigor of service-orientation can become a weak link that can inhibit or even compromise the quality and performance of the composition as a whole.

Isolating non-agnostic logic into a non-service-oriented program or platform can therefore reduce the effectiveness and potential of service compositions, sometimes dramatically so. This is especially the case with larger, more complex compositions, where inter-service reliance on mutually elevated runtime behavioral requirements and performance demands is further magnified.

It is these requirements and demands that the Non-Agnostic Context pattern can address, so that single-purpose logic is encapsulated into services tuned and optimized to take part in service compositions as they exist today, while further facilitating their on-going and anticipated evolutionary changes.

•   •   •

The SOA Pattern of the Week series is comprised of original content and insights provided to you courtesy of the authors and contributors of the SOAPatterns.org community site and the book "SOA Design Patterns" (Erl et al., ISBN: 0136135161, Prentice Hall, 2009), the latest title in the "Prentice Hall Service-Oriented Computing Series from Thomas Erl" (www.soabooks.com). Copyright 2009 SOA Systems Inc.

Related Stories

• SOA Pattern of the Week (#4): Service Normalization
• SOA Pattern of the Week (#3): Domain Inventory
• SOA Pattern of the Week (#3): Domain Inventory