Master SOA Design
Pattern Catalog
|
|
"Introducing SOA Design Patterns", SOA World Magazine (PDF)
"The Case for Single-Purpose Services: Understanding the Non-Agnostic Context and a Strategy for Implementation", SOA Magazine (HTML)
"REST-Inspired SOA Design Patterns", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part I: A Comparison of Goals and Concepts", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part II: A Comparison of Design Principles", SOA Magazine (HTML)
"Service Facade", InformIT (HTML)
"Non-Agnostic Context", InformIT (HTML)
"Domain Inventory", InformIT (HTML)
"Service Normalization", InformIT (HTML)
"Service Decomposition", InformIT (HTML)
"Canonical Schema", InformIT (HTML)
"Policy Centralization", InformIT (HTML)
|
|
|
Reference Data Observer (candidate)
|
Home > Candidate Patterns List > Reference Data Observer
|
|
How can business reference data residing in many different systems be automatically distributed to consumers, without changing the distribution logic for every new system connected to the distribution mechanism.
|
|
|
|
Problem
Traditionally, the reference data in systems is updated procedurally in all surrounding consumers. When reference data is changed in back end systems, sometimes, for the middleware to work properly, this reference data must sometimes be manually copied into the service bus. This does not allow the services needing these reference values to work as expected until the change is performed in all relevant systems and the middleware, resulting in longer lead time to release a reference data change. Additionally, manual copying of data is error-prone and can result in exception handling, or inability to perform certain service logic.
|
|
|
Solution
Create an observing service in the service repository responsible for watching changes on the underlying reference data (either by subscribing on, or polling for changes). This service consequently publishes the updated data onto the service bus; this reduces lead times for reference data changes as well as removes any error-prone manual activities.
|
|
|
Application
|
|
|
|
Impacts
This service may increase the load on the middleware in case the service is scheduled to pull updates from underlying systems.
Finding changes in data of underlying systems may be difficult to achieve without changes to the underlying system which would allow for easier detection of changed data.
This service removes the need for manual reference data update and can on longer-term support reduction of work force.
|
|
|
|
|
|
|
|
Status
Under Review
|
|
|
|
Contributors
Roger Stoffers
|
|
Table: Profile summary for the Reference Data Observer pattern.
|
| |
Problem
For the service bus to work properly, often a copy of reference data pertaining to a back end system which is exposed on the service bus is required. This data does not appear automatically in the bus but has to be manually copied into the appropriate places.
|
Two issues arise with this approach:
|
|
•
|
Manual data entry is error-prone and can cause invalid operations on underlying systems, resulting in denied service calls, or worst case, data-inconsistency
|
|
•
|
It takes time before the middleware is aware that a change had happened and this results in longer lead times for changes
|
Figure - For many changes in reference data of underlying systems, manual duplication is required to update copies of the same data in the bus to allow the middleware to interface to the corresponding back end system. This is time-consuming and error-prone.
Solution
Create an observing entity in the service repository which looks for changes in underlying reference data. The service acts as an intermediary on the service bus to coordinate updates to the reference data copies in the service bus. This can only be applied if the reference data is either accessible by the service, or if changes are published to the service.
Reference data available in the service bus can be used ie. for request validation purposes as well as for mapping default values to specific service calls. This is not part of this pattern however.
Figure - The observing entity looks for changes in underlying data and publishes any changes detected on the bus. The trigger to look for changes could ie. be timer-based - the interval determines how often the service looks for changes.
Application
|
Create a service which is either triggered to execute
|
|
1.
|
by a timed event
|
|
2.
|
by an event cause by change in data pushed by the underlying back end.
|
Ad 1)
In case the timed event fires (ie. every 15 or 60 minutes, or once a day), the dedicated service retrieves back end data and looks for changes. Any relevant data is published in the service bus.
Ad 2)
Analyze the received data and publish in the service bus when necessary. Service agents can be used to filter irrelevant events.
Figure - Three examples of how middleware reference data copies can be updated. Service A is invoked by a timed event, queries a database to look for reference data changes and publishes the result on the bus. Service B behaves identical but uses a service to find changes in underlying reference data. Service C is published the reference data directly and does not need back end access to publish the event on the bus. Alternatively, a service of similar to service C can be used to publish events on the bus via a GUI intended to manage reference data centrally, directly on the bus.
Impacts
Not all reference data is suitable to apply this pattern on. This is ultimately a trade-off between cost and benefit, and the need of the business to have quick lead times for changes in the reference data, as well as a potential need for low administration systems.
This pattern on itself is to be supported with consumers of the data published on the bus to become more beneficial for the SOA infrastructure.
Benefit of the pattern is that all services on the bus can become aware of the exact same reference data changes published by the application of this pattern, which on its turn improves autonomy of the system, but this may come at significant implementation cost.
Relationships
This pattern can be extended with the Reference Data Distribution pattern which distributes any changes published on the service bus to applicable reference data consumers.
This pattern can use the Reference Data Centralization pattern to store an intermediate aggregated or accumulated copy of the reference data in the service bus, available for consumers in a centrally managed place.
Figure - Reference data observer provides updates to the data in the Reference Data Centralization and Reference Data Distribution pattern. By decoupling reference data change detection from reference data distribution the service autonomy increases and service normalization is supported.
|
|
|
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura YouTube Channel
