| |
Problem
Service may not always have a one to one mapping with a legacy system for the required functionality and data. If multiple legacy systems provide functionality and data, the service will need to determine which legacy system to communicate with.
Figure 1: The consumer requests information from the service ignorant of the fact there are multiple legacy systems. The service receives the message but has no way of knowing which legacy system to route the message to.
|
This scenario may occur within an SOA when:
|
|
•
|
Different business products and services are provisioned using different systems. For example, one provisioning system may be required for the Mobile network as apposed to another one for the Fixed Line network when fulfilling a Service Order within a Telco environment.
|
|
•
|
Business acquisition occurs and a strategy is applied in which legacy systems are integrated into the existing SOA.
|
|
•
|
Large scale enterprises have different legacy systems for different product lines, divisions, business units etc.
|
Solution
Services extract predefined data attributes from the message they receive and use this to lookup and determine which legacy system to interact with at runtime effectively establishing a router table. Services also use externalized legacy adapters to facilitate the interaction with the legacy systems.
Application
As an example, a consumer may wish to return details about a particular product. The consumer has no comprehension that the product details may come from a number of legacy systems and the service does not know the required legacy system at design time. The process to overcome this is as follows:
|
1.
|
A consumer sends a message to the product service. The service contains the request for product details and contains the product code.
|
|
2.
|
service receives the message and extracts the product code out of it.
|
|
3.
|
The service sends a message to the reference data service. This request for reference data lookup message contains product code and ‘product service legacy router’ as the keys for the lookup.
|
|
4.
|
The reference data service performs the lookup and returns the name of the legacy system to use.
|
|
5.
|
The service determines the correct legacy adapter to use and invokes the legacy adapter passing it the product code.
|
|
6.
|
The legacy system is invoked and information is returned to the legacy adapter in the legacy systems data format and data model.
|
|
7.
|
The services legacy adapter uses Data Format Translation and Data Model Transaction to format the information retrieved into the Canonical Schema ready for return to the service. Often legacy systems will not be Canonical Schema compliant.
|
|
8.
|
The legacy adapter passes the data in Canonical Schema back to the Service.
|
|
9.
|
The service processes the data.
|
|
10.
|
The service returns the data to the consumer.
|
Figure 2: The consumer requests information from the service not knowing that there are multiple legacy systems. The service uses the reference data service to lookup the legacy system to use. Once the legacy system is determined, the service passes a request to the appropriate legacy adapter and it in turn sends a message to the correct legacy system. On return, the legacy adapter uses Data Format Translation and Data Model Translation to format the legacy system data into the Canonical Schema. The data is then returned to the consumer.
Impacts
Performance requirements and latency can become a factor when having to call the reference data service. However, this is balanced by the alternatives of hard-coding lookup within the service at design time. Large amounts of metadata can also be required to provide correct routing rules for functionality and these need to be managed effectively.
|
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP) 
Arcitura YouTube Channel
