The SOA design patterns catalog establishes a set of
foundational service patterns responsible for identifying and defining
the scope of functional service contexts and boundaries, as well as
service capabilities. As shown in Figure 1,
the majority of these patterns pertain and lead to the definition of
agnostic logic suitable for reuse and therefore subject to the Service
Reusability principle.
As explained in the
upcoming sections, the combined application of these patterns
essentially carries out the separation of concerns in support of the
service-orientation paradigm.
Functional Decomposition
The
separation of concerns theory is based on an established software
engineering principle that promotes the decomposition of a larger
problem into smaller problems (called concerns) for which corresponding
units of solution logic can be built.
The rationale is that a larger
problem (the execution of a business process, for example) can be more
easily and effectively solved when separated into smaller parts. Each
unit of solution logic that is built exists as a separate body of logic
responsible for solving one or more of the identified, smaller concerns (Figure 2). This design approach forms the basis for distributed computing and is essentially embodied by the Functional Decomposition pattern.
Service Encapsulation
When
assessing the individual units of solution logic that are required to
solve a larger problem (carry out a business process), we may realize
that only a subset of the logic is suitable for encapsulation within
services. This identification of service logic is accomplished via the
application of the Service Encapsulation pattern (Figure 3).
Agnostic Context
After the initial
decomposition of solution logic we will typically end up with a series
of solution logic units that correspond to specific concerns. Some of
this logic may be capable of solving other concerns, but by grouping
single-purpose and multi-purpose logic together, we are unable to
realize any potential reuse.
By identifying what parts of
this logic are not specific to known concerns, we are able to separate
and reorganize the appropriate logic into a set of agnostic contexts (Figure 4).
Agnostic Capability
Within
each agnostic service context, the logic is further organized into a
set of agnostic service capabilities. It is, in fact, the service
capabilities that address individual concerns. Because they are
agnostic, the capabilities shaped by this pattern are multi-purpose and
can be reused to solve multiple concerns (Figure 5).
Utility Abstraction
The application of the Utility Abstraction
pattern results in the separation of common cross-cutting functionality
that is neither specific to a business process nor a business entity.
This establishes a specialized agnostic functional context limited to
utility logic. The resulting type of service is referred to as a utility
service and the repeated application of this pattern within a service
inventory results in the creation of a logical utility layer (Figure 6).
Entity Abstraction
Every
organization has business entities that represent key artifacts
relevant to how operational activities are carried out. The application
of Entity Abstraction shapes the functional context of a service so that it is limited to
logic that pertains to one or more related business entities. As with
Utility Abstraction , the repeated application of this pattern establishes its own logical service layer (Figure 7).
The Inventory Analysis Cycle
When
viewing the preceding set of patterns, one can see there are steps
within a service-oriented analysis process. It is important to realize
that this process (and its steps) is preferably carried out iteratively,
as part of a cycle that identifies, defines, and also refines agnostic service contexts and agnostic capabilities.
This is commonly accomplished by
decomposing a set of business processes that belong to a given domain
within the IT enterprise. This domain represents the boundary of a
planned service inventory. By iterating through a separate analysis and
functional decomposition of each business process, agnostic service
candidates and their capabilities can be continually refined until they
reach a state where their reuse potential has been fully determined
before they are physically designed and developed. This takes the
guesswork out of applying the Service Reusability
principle in that the reuse of each service is pre-determined based on
the current state of the business. Future business change is naturally
accommodated by leveraging the inherent characteristics and flexibility
established by this and other principles.
Each of these service
candidates is added to a collection that eventually results in a
blueprint of the service inventory, as illustrated in Figure 8.
The depicted analysis cycle is one of several ways to incorporate
service-oriented analysis within an SOA methodology. A key consideration
here is that the extent to which the cycle needs to be iterated is
directly related to the scope of the planned service inventory. When
applying Domain Inventory within an IT enterprise, multiple service inventories can co-exist and
can be independently planned and defined with different approaches, each
iterating through their own cycles within manageable boundaries.
Additional Design Considerations
While
we’ve been primarily focused on the identification, definition, and
classification of reusable service logic, it’s important to acknowledge
that the Service Reusability principle encompasses several more considerations that shape the service logic and its support architecture, including:
robustness of reusable service logic
sufficiently generic and flexible service contracts and functionality
testing and quality assurance to ensure sufficient “real world” reusability
These types of
characteristics, many of which are shaped by design techniques borrowed
from the commercial software product development industry, help prepare
service logic for a broad range of reuse scenarios.
