The principles of service-orientation part 3 of 6: Service abstraction and reuse [by Thomas Erl]

 

An aspect of service-orientation that ties directly into our previous discussion of service contracts and loose coupling is that of abstraction. It is through abstraction that we can control what parts of the underlying service logic are exposed to the outside world. By ensuring that these parts are designed in a generic manner so as to accommodate multiple potential service requestors, we can strive to position the service as a reusable IT asset. In this article we will explore different levels of abstraction and then move on to a discussion of how reuse supports the overall strategic goals associated with SOA.

Abstracting functionality and technology

Also referred to as service interface-level abstraction, it is this principle that encourages us to establish services as black boxes, intentionally hiding their underlying details from potential consumers. Abstraction is accomplished through the disciplined use of service contracts. By limiting what is made public about a service to what is documented in the service contract, a high degree of separation can be achieved between what becomes private (hidden) and public (consumable). This is desirable because it supports the loosely coupled relationship we described in part 2.

There is no limit to the amount of logic a service can represent. A service may be designed to perform a simple task or it may be positioned as a gateway to an entire automation solution. There is also no restriction as to the source of automation logic a service can draw upon.

For example, a single service can expose logic from multiple different underlying systems. In fact, as we move toward the standardization of service models that establish a functional context associated with a business entity or task, it is expected that in environments with numerous legacy solutions, one service will commonly expose functionality that relies on a variety of different systems.

Service interface-level abstraction is one of the inherent qualities provided by distributed platforms, such as component and Web services-based architectures. The use of Web services are especially synergetic because they elevate the level of attainable abstraction beyond just functionality. Web services abstract the proprietary implementation details of the underlying automation logic, which frees potential consumers of the service from having to interface with specific vendor technologies. Even though we refer to abstraction as a characteristic of the service, it is actually the individual operations that collectively abstract the underlying logic. Services simply act as containers for these operations. The level of abstraction of any given service is therefore determined to large extent by the collective levels of abstraction attained by each of its service operations.

This puts a great deal of emphasis on the design of the service contract. The more that is expressed in the service contract, the less details we end up abstracting. The more generic we make the service contract, the less process or consumer-specific the service becomes. This then determines the reuse potential of what we choose to expose (to not abstract) through the service contract.

Fostering agility through reuse

Service-orientation encourages reuse in all services, regardless of whether immediate requirements for reuse exist. This fundamental principle forces us to pay extra attention to each delivered unit of automation logic we want to call a "service."

The primary strategic goal associated with reuse is to position each service as an IT asset with "repeatable value." As the amount of reusable assets accumulate, the chances increase to fulfill new business automation requirements by building less and using more of what we already have.

This is expected to reduce the time it takes to build automation logic, thereby improving an organization's overall responsiveness to change. By decreasing the associated effort, the fulfillment of automation requirements is also anticipated to become more cost-effective, leading to the significant potential of streamlining IT development environments. This may sound like a tall order, but many organizations are investing heavily in the creation of a highly reusable service inventory to attain these very benefits.

This principle facilitates all forms of reuse, including inter-application interoperability, composition and the creation of cross-cutting or utility services. As we established earlier, a service is simply a collection of related operations. It is therefore the logic encapsulated by the individual operations that must be deemed reusable to warrant representation as a reusable service.

The emphasis on far reaching reuse also highlights the suitability of Web services as an implementation option for services. By making each service available via an industry standard communications framework, reuse potential can broaden dramatically because the logic encapsulated by a service now becomes accessible to service requestors built with different underlying technologies.

It all comes down to the service contract

Both of these principles bring us back to the required use of the service contract. It is the content of this contract that determines what is and is not abstracted. It is through the design of this content that we can determine how generic and reusable the non-abstraced parts actually are. This raises the need to truly view the design of a service as an investment. Building service-oriented solution logic is almost always more expensive and more time consuming because considerations need to be taken into account that go beyond immediate tactical requirements. An appreciation of what service-orientation is intended to accomplish is therefore useful in justifying this investment.

What's Next

We're half-way through the series and hopefully have shed some light on the unique characteristics, requirements and potential benefits of the service-orientation paradigm. Up next in part 4 we will discuss the need for services to be discoverable, regardless of whether a service registry actually exists within an environment. We will also take a closer look at the very important and often misunderstood characteristic of service composability.

This article contains excerpts from "Service-Oriented Architecture: Concepts, Technology, and Design" by Thomas Erl (792 pages, Hardcover, ISBN: 0131858580, Prentice Hall/Pearson PTR, Copyright 2006). For more information, visit www.soabooks.com.