How
can service autonomy be preserved when services require access to shared data
sources?
|
Problem
Service logic can be
deployed in isolation to increase service autonomy but services continue to
lose autonomy when requiring access to shared databases.
|
|
Solution
Services can have their own
dedicated databases with two-way replication to shared data sources.
|
|
Application
An additional database
needs to be provided for the service and two-way replication needs to be
enabled between it and other data sources.
|
Impacts
This pattern results in
additional infrastructure cost and demands, and an excess of replication
channels can be difficult to manage.
|
|
Principles
Service Autonomy
|
Architecture
Inventory,
Service
|
Table 6.24 – Profile summary for
the Service Data Replication pattern.
Problem
When applying the Service Autonomy design principle, various
steps can be taken to increase the overall independence and behavioral
predictability of services. The components that underlie custom-developed
services, for example, can be isolated from other programs into their own
process space or even onto dedicated servers. These are relatively
straight-forward measures because the components, the service contract, and
even the extra hardware that may be required are all new to the environment.
However, what usually stands in the way of achieving pure
service autonomy is the fact that even the most isolated service will likely
still need to interact with some central database in order to access or even
update business data. These repositories are usually shared not just with other
services, but with various parts of the enterprise, including the legacy
applications they may have been originally built for.
Although an organization could choose to rebuild their
existing data architecture in support of a new service inventory, the cost,
effort, and potential disruption of doing so may be prohibitive.
Figure 6.105 – Multiple services
accessing the same shared database will likely encounter locking and
performance constraints that will inhibit their individual autonomy.
Solution
Service implementations can be equipped with dedicated
databases, but instead of creating dedicated data stores, the databases provide
replicated data from a central data source. This way, services can access
current data with full autonomy while not requiring exclusive ownership over the
data.
Figure 6.106 – By providing each
service its own replicated database, autonomy is increased and the strain on
the shared central database is reduced.
Application
This design pattern is especially relevant to agnostic
services that are heavily reused and need to facilitate multiple compositions.
When this pattern is applied to a large amount of services within a given
inventory, it can dramatically reshape the underlying infrastructure of an
enterpriseÕs data environment.
Sophisticated data replication architectures may need to be
created and additional design techniques may need to be applied to the
databases themselves in order to avoid bottlenecks that may result from an
excess of concurrent access and locking. Some replication strategies can even
introduce the need for additional satellite databases that provide fully
replicated data sets on behalf of a central database, but become the contact
point for service databases requiring only a subset of the replicated
information.
Some services (especially those providing reporting-related
capabilities) may only require read access to data, which can be fulfilled by a
one-way data replication channel. Most services, though, will end up requiring
both read and update abilities, which leads to the need for two-way
replication.
Impacts
As stated earlier, repeated application of this design
pattern can result in costly extensions to the infrastructure in order to
support the required data replication in addition to costs associated with all
of the additional database licenses required for the dedicated service
databases. Furthermore, in order to support numerous two-way data replication
channels, an enterprise may need to implement a sophisticated and complex data
replication architecture which may require the need to introduce additional,
intermediate databases.
Relationships
Service Data Replication is a key pattern applied in support
of realizing the Service Autonomy design principle. It ties directly into the
application of Redundant Implementation and Composition Autonomy patterns,
because both aim to reduce service access to shared resources and increase
service isolation levels. To access or manage replicated data may further
involve some form of legacy interface, as per the Legacy Wrapper pattern.
Data replication can also play a role in service versioning
and decomposition. Specifically, a replication data source may be required to
support isolated capability logic as defined via the Distributed Capability
pattern, or it may be needed to support already decomposed capability logic
resulting from the Proxy Capability pattern.
Figure 6.107 – The Service Data
Replication pattern helps reduce the requirements for shared data access and therefore
supports a series of autonomy-related patterns.
Case Study Example
Case study content is not available on this Web site.
