Utility Abstraction

How can common utility logic be separated, reused, and independently governed?

Problem When the logic required to automate a business task is packaged together in one service, it results in the redundant implementation of common utility functions across different services.
Solution A service layer dedicated to utility processing can be established, providing reusable utility services for use by other services in the inventory.
Application The utility service model is incorporated into official analysis and design processes in support of utility logic abstraction.	Impacts To be effective, utility logic needs to be consistently abstracted, which imposes design considerations upon all service delivery projects. Furthermore, the absence of a predefined source for utility functions can make their definition challenging.
Principles Service Loose Coupling, Service Abstraction, Service Reusability, Service Composability	Architecture Inventory, Composition, Service

Table 5.7 – Profile summary for the Utility Abstraction pattern.

Problem

Among the logic required to automate just about any business task, there will be some that can be considered generic, Òcross-cuttingÓ processing functionality that has no relationship to formal business models. IT environments typically have a variety of technologies, products, databases, and other resources that offer features or functions useful for many purposes. This type of non-business centric logic can be considered utility logic.

Because there has historically been a tendency to group functionality associated with the automation of a business process, utility processing functions often find themselves bundled together with business process logic, business rules, and other forms of business logic (Figure 5.x).

Figure 5.30 – Utility logic is embedded within hybrid and business-centric services and therefore dispersed throughout a service inventory. In this state it is likely that much of the utility logic is redundantly implemented.

This packaging makes the individual strategic design and governance of this utility logic difficult. For example, if generic processing functionality capable of addressing multiple cross-cutting concerns is embedded together with business process-specific logic, it becomes challenging to make the generic processing logic separately available for reuse.

Solution

When looking for ways to organize functions into multi-purpose services, it is useful to group common utility features and functions into separate utility services. Because these utility services provide common functions that are not specific to any one task, they can be reused to automate multiple tasks. The result is a utility service layer (Figure 5.x) that is typically defined, owned, and governed by technology experts (and does not require the involvement of business experts).

Even though they are also classified as multi-purpose services, utility services are different from entity services because the manner in which they group functions is not related to business entities.

Figure 5.31 – Cross-cutting utility logic is identified with the help of enterprise architecture specifications, and then abstracted into a layer of dedicated services based on the utility service model.

Application

Utility processing is common to all enterprises and the process of abstracting cross-cutting functionality into reusable units of logic is a well-known pattern that has existed for many years. However, in order to establish a formal utility service layer that spans a service inventory requires constant attention to how logic is partitioned and grouped within functional service contexts.

During the service modeling process, the logical utility layer is already preconceived and conceptualized. Subsequently, when service contracts are ready to be defined, a special process geared toward utility service design needs to be applied so that the unique issues associated with this type of service can be addressed (see SOAMethodology.com).

Impacts

The definition of utility service layers can make some impositions on how traditional development projects may have been carried out. However, the fact that object-oriented analysis and design (as well as aspect-oriented programming) have raised an awareness of the benefits of abstracting cross-cutting utility logic, these requirements will not be foreign to many organizations.

One challenge constantly associated with utility service designs is the definition of appropriate service contexts. Unlike business service contexts that can be derived from existing business models, the functional context of utility services is often left to the judgment of architects and developers. It can therefore be difficult to set a service context that is suitable for long-term reuse and service contract longevity.

Relationships

Because its application also results in agnostic service layers (and therefore is fundamentally influenced by the Agnostic Context pattern), the Utility Abstraction pattern shares many of the same pattern relationships as the Entity Abstraction pattern. The primary difference is the absence of business-centric influences, such as Business-Driven Context.

Notable relationships specific to Utility Abstraction are the Service Agent pattern, which emulates the non business-centric functional context and the Cross-Domain Utility Layer which essentially results in a broad application of Utility Abstraction. Rules Centralization, Security Centralization, and Stateful Services patterns also can be considered specialized implementation of Utility Abstraction.

Figure 5.32 – The Utility Abstraction pattern tends to relate to design patterns that are not business-centric, but still concerned with the design of agnostic logic.

Case Study Example

Case study content is not available on this Web site.