Agnostic Capability
How
can multi-purpose service logic be made available in a consumable format?
|
Problem
Grouping agnostic logic
into a service does not establish a formal service interface.
|
|
Solution
Agnostic service logic can
be partitioned into a set of complementary capabilities allowing the logic
represented by each capability to be individually invoked.
|
|
Application
Service capabilities are
defined, refined, and implemented through analysis, modeling, and design
processes.
|
Impacts
Poorly defined service capabilities
can inhibit the serviceÕs reuse potential and can lead to a variety
governance problems.
|
|
Principles
Standardized Service Contract,
Service Reusability,
Service Composability
|
Architecture
Service
|
Table 7.5 – Profile summary for the Agnostic Capability
pattern.
Problem
Moving related pieces of agnostic logic into an agnostic
service can still lead to functional overlap an does not establish the basis
for a technical interface that will be useful to a range of consumer programs.
Solution
A service encapsulates all logic associated with a
well-balanced functional context. This logic is decomposed into a set of
well-defined capabilities. The related collection of capabilities are part of
the same physical service implementation.
Figure 7.21 – Through the application of this pattern,
the service logic grouped within a specific service context is made available
as a set of well-defined and complementary capabilities.
Application
By carrying out the service-oriented analysis and service
modeling processes, candidate service capabilities are identified, defined, and
grouped into candidate service contexts. Through repeated iterations of these
processes, the definition and organization of the capabilities are further
refined.
This pattern essentially positions each capability as an
independent function able to solve a specific agnostic concern (a concern that
is common to multiple business processes or tasks). Agnostic capabilities
therefore lie at the heart of fundamental service-orientation principles, such
as Service Reusability and Service Composability.
Impacts
Capabilities grouped together into one physical service
implementation are usually expressed via the same service contract. If the
functionality of any one capability (or the grouping itself) changes over time,
the service contract may become invalid or may require further extension.
Additionally, more popular capabilities will tend to tax the overall service
implementation, which can compromise the performance and predictability of
other capabilities.
Note: All
of these impacts represent common SOA-related design issues addressed by other
patterns in this book.
Relationships
Agnostic Capability can be considered a continuation of
Agnostic Context, making these two patterns naturally related. But when
studying how services are assembled into compositions, the ultimate role of the
defined agnostic capabilities become evidently integral to the application of
both Capability Composition and Capability Recomposition patterns.
Figure 7.22 – The Agnostic Capability pattern provides
the externally facing functions that form the basis of service contracts.
Case Study Example
Cast study content is not available on this Web site.
