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

转载 2006年06月01日 15:15:00

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

The principles of service-orientation part 1 of 6: Introduction to service-orientation [by Thomas Erl]

 This is the first article in a six-part series dedicated to exploring the common principles of serv...
  • Xalloy
  • Xalloy
  • 2006年06月01日 15:10
  • 1094

The principles of service-orientation part 4 of 6: Service discoverability and composition [by Thomas Erl]

 Continuing our exploration of service-orientation, we now focus on two principles that tend to rece...
  • Xalloy
  • Xalloy
  • 2006年06月01日 15:17
  • 931

The principles of service-orientation part 2 of 6: Service contracts and loose coupling [by Thomas Erl]

 In the previous article we established the service-orientation design paradigm as currently providi...
  • Xalloy
  • Xalloy
  • 2006年06月01日 15:14
  • 1095

SPDA-CNN:Unifying Semantic Part Detectiojn and Abstraction for Fine-grained Recognition

这是2016年发表在CVPR中的一篇有关细粒度分类的文章 1. 引入: 1).细粒度分类的挑战性:微小的视觉差异可能会被其他的因素(如视角、角度等)遮掩。 2).最近有一些CNN-SVM框...
  • u010772289
  • u010772289
  • 2016年12月06日 18:33
  • 426

Business analysis and SOA part 2 of 6: Business service models and the entity-centric business service [by Thomas Erl]

 As part of the design of service-oriented solutions it is common to label individual services accor...
  • Xalloy
  • Xalloy
  • 2006年06月01日 15:23
  • 1262

Amazon Leadership Principles

Amazon Leadership Principles Whether you are an individual contributor or a manager...
  • besley
  • besley
  • 2012年11月22日 14:03
  • 1233

读书笔记:包设计的原则(Principles of Package Design)

包设计的原则(Principles of Package Design)1,发布/重用等价原则(The Release/Reuse Equivalency   Principle)(REP) 创建一个...
  • heroking2000
  • heroking2000
  • 2005年12月22日 13:26
  • 854

论文阅读(3)--SPDA-CNN: Unifying Semantic Part Detection and Abstraction for Fine-grained Recognition

这篇文章是来自罗格斯大学的Han Zhang等人的工作。由题目可知与上一篇文章一样,本文的作者也关注到了富有语义的局部(利用Part,Part,Part,重要事情强调三遍),作者不满足于CUB-201...
  • lc013
  • lc013
  • 2016年10月10日 21:37
  • 1153

Business analysis and SOA part 3 of 6: Process-centric business services [by Thomas Erl]

 In the previous article we described the role of service models and explored the design standards f...
  • Xalloy
  • Xalloy
  • 2006年06月01日 15:24
  • 1523

SPDA-CNN:Unifying Semantic Part Detection and Abstraction for Fine-grained Recognition

SPDA-CNN:联合语义检测和提取用以细粒度识别 最近在做细粒度分类和研读CVPR2016结果,看到这篇文章。做个笔记,方便自己回顾和与大家讨论。 1.摘要及引言多数的卷积神经网络缺少能够mode...
  • u011587569
  • u011587569
  • 2016年07月29日 22:13
  • 950
您举报文章:The principles of service-orientation part 3 of 6: Service abstraction and reuse [by Thomas Erl]