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 according to the roles they fulfill. There are different types of roles, depending on the nature of the functionality being encapsulated and the context within which the service is being utilized.

For example, during runtime processing, services can assume different roles as they transition through processing stages within the execution of a larger activity. A service that receives a request message acts as the provider of the service and can therefore be labeled as the service provider in that instant. However, within a composition of services, the same service may turn around and forward the request message to another service. This effectively changes its role to that of the service requestor. These roles represent temporary states services transition through regardless of the nature of the functionality they provide.

When modeling business services, we are very much interested in the type of logic encapsulated within each service. As a result, a series of permanent classifications have emerged providing us with a set of high-level, predefined contexts that help us determine what should and should not be captured within a service boundary. These classifications are known as service models.

Service models

The use of service models establishes collections of services with common characteristics. When properly coordinated and further enforced through internal design standards, these characteristics can become the basis for a broad level of abstraction within an enterprise, establishing service layers that each abstract a particular logical domain. We'll talk more about service layers in this series after we describe some of the common service models.

It is important to note that there are business service models and service models dedicated to the encapsulation of non-business-related logic. The latter type refers to models commonly labeled as infrastructure or application services that group functionality according to a processing context (as opposed to a business context) usually to address low-level cross-cutting concerns.

Our focus in this series is on the following three primary business service models:

• Entity-centric business service
• Task-centric business service
• Process service

Other types of business service models also exist, several of which have been defined by vendors and consulting firms. In fact, you can create your own business service models to establish unique contexts that relate to business domains within your organization. Based on our cross-platform research, the three service models listed above represent the most common and primary means of encapsulating business logic through service-orientation.

Let's start with a look at the first item on our list: the entity-centric business service model.

The entity-centric business service model

This service model requires that we group functionality according to a context associated with a predefined business entity or information set. Common business entities include customer, timesheet, employee, order, invoice, claim and so on. An entity-centric business service essentially results in the creation of a service that usually has a name that represents the business entity, such as a Customer service or a Timesheet service.

With a functional context based on a pre-existing business entity, the service is limited to containing a range of functions associated with the processing of the logic and data tied to that entity. An Invoice service implemented as a Web service, for example, would only contain operations capable of processing invoice-related data.

The key design standard imposed by the use of entity-centric business services is not just the limitation of what they can contain, but the common requirement that any functions associated with the entity they represent must reside within their boundary. This positions this type of service as central architectural component within a service-oriented enterprise.

Other service models based on a context derived from a business process end up being bound to that process. When the process logic changes, the context under which the services are used and composed will likely change as well. This may invalidate the original grouping of service operations and could result in the requirement for a redesign and redevelopment effort.

Because the context of the entity-centric business service is agnostic to any one business process, they achieve "process logic independence" and therefore become highly reusable. And, because they represent a well-defined set of logic and data, they establish a level of abstraction and governance over a distinct business domain. This can significantly increase the agility with which business processes that rely on the composition of services can be altered in response to change.

Entity-centric business services form specific relationships with services based on other service models. As we will discover later in this series, building a business service layer consisting of a series of entity-centric services composed by a parent orchestration service layer establishes a desirable form of SOA that promotes a high degree of agility and accurate business model representation.

 

Building entity-centric business services

Entity-centric business services are generally produced as part of a long-term or ongoing top-down analysis effort during which a great deal of attention is given to the alignment of service logic encapsulation with corresponding corporate business models. As a result, they do require more up-front analysis and design effort than other types of service models, increasing both the cost and delivery time required to produce each service.

They also benefit from the existence of an enterprise service model which provides a broad perspective of all potential services (entity-centric or otherwise) and an understanding of how entity-centric business services can potentially interrelate and perhaps be further decomposed into sub-entities. We will discuss the enterprise service model toward the end of this series.

These prerequisites almost always make impositions on the traditional project delivery lifecycle, where tactical requirements need to be constantly balanced with the long-term strategic benefit associated with establishing a service as a reusable IT asset. Furthermore, investing in any type of reusable service model ultimately leads to significant governance issues that can further increase the costs and effort required to maintain and evolve these types of services over the long-term.

Despite these challenges, the emergence of this service model is one of the most important developments in the evolution of service-oriented computing so far. It introduces new design, deployment and maintenance considerations that increase the complexity of an enterprise service architecture, but also provides the potential of realizing some of the significant strategic benefits associated with SOA.

What's next

In part 3 of this series we will continue our discussion of business service models by turning our attention to those based on a business process-specific context. Though they provide less reuse potential that entity-centric business services, they establish important parent service composition layers that allow for a clean abstraction of business process logic.

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.