How can multi-purpose service logic be positioned as
an effective enterprise resource?
|
Problem
Multi-purpose logic grouped
together with single purpose logic results in programs with little or no
reuse potential that introduce waste and redundancy into an enterprise.
|
|
Solution
Isolate logic that is not
specific to one purpose into separate services with distinct agnostic
contexts.
|
|
Application
Agnostic service contexts
are defined by carrying out service-oriented analysis and service modeling
processes.
|
Impacts
This pattern positions
reusable solution logic at an enterprise level, bringing with it increased
design complexity and enterprise governance issues.
|
|
Principles
Service Reusability
|
Architecture
Service
|
Table 7.3 – Profile summary for the Agnostic Context
pattern.
Problem
The solution logic required to solve a single concern will
frequently include logic that is also suitable for solving other concerns.
Grouping single and multi-purpose functionality together into one unit of logic
will limit or even eliminate the potential for reuse.
Figure 7.12 – Decomposed units of solution
logic will naturally be designed to solve concerns specific to a single, larger
problem. Units A, C, and F represent logic that contains multi-purpose functionality
trapped within a single-purpose (single concern) context. Single-purpose logic
(also called non-agnostic logic) is represented by the striped pattern.
Solution
Solution logic that is agnostic to the larger problem is
separated from logic that is specific to the larger problem. One or more
services with distinct agnostic functional contexts are then identified within
which the agnostic logic is located.
Figure 7.13 – The application of this pattern results
in a subset of the solution logic being further decomposed and then distributed
into services with specific agnostic contexts.
Application
Solution logic is further decomposed and reorganized as a
result of carrying out formal analysis and modeling processes. Agnostic logic
is defined and continually refined into a set of candidate service contexts.
These contexts can be based on pre-defined agnostic service model
classifications, such as those that establish the entity and utility service
layers (explained in the Inventory Structure Patterns section of
Chapter 5).
Impacts
The application of this design pattern essentially results
in the creation of highly reusable services, which ties directly into several
strategic SOA benefits, including an increased and repeatable return on
investment.
Achieving these benefits tends to increase the overall
quantity of services required to solve a given problem, which leads to
additional design considerations and performance overhead associated with
service compositions.
The governance effort of agnostic services is significantly
more than if the corresponding solution logic were dedicated to a single
application. Additionally, the governance of the overall architecture is also
impacted as the quantity of agnostic services within an inventory grows.
Relationships
From a service design perspective, the Agnostic Context
pattern is one of the most distinctive patterns associated with
service-orientation. It therefore has several relationships with other patterns
that apply specialized variations of Agnostic Context, such as Entity Abstraction and Utility
Abstraction. The closest relationship is between the Agnostic Context and
Agnostic Capability patterns, as the latter is applied to services that have
already been deemed agnostic.
The reference to inventory-related patterns at the bottom of
Figure 7.x simply reminds us that within any given boundary, this pattern (as
with all basic service design patterns) is applied repeatedly through iterative
processes.
Figure 7.14 – The Agnostic Context pattern is core to
service design and is responsible for forming the basis of several fundamental
architectural design patterns.
Case Study Example
Case study content is not available on this Web site.
