SOA Legacy Service Integration via IDL and Server-Side Mapping
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In service-oriented architectures (SOA), integrating legacy services implemented in older programming languages like COBOL into modern systems is challenging due to difficulties in mapping data types and the presence of pseudo-parameters, leading to unnecessary parameters in IDL files and complexities in language bindings.
Innovation Solution
The method involves creating two files: an Interface Definition Language (IDL) file for client-side interface information and a Server-Side Mapping (SVM) file for language-specific mappings, allowing for flexible and simplified language bindings by separating language-specific aspects and avoiding irrelevant parameters, with the SVM file used by a remote procedure call server for runtime mapping.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If a single IDL file is used to define the interface between client and legacy service, then the interface definition can be generated automatically, but the IDL file contains unnecessary parameters and language-specific extensions that complicate client-side language bindings
Solution Approach 1:
The interface definition is segmented into two separate files: an IDL file containing only client-relevant interface information, and a server-side mapping file containing language-specific mappings and legacy service parameters. This segmentation allows the IDL file to remain clean and simple while the mapping file handles the complexity of legacy service integration.
Solution Approach 2:
Language-specific parameters and legacy service extensions are extracted from the IDL file and placed into a separate server-side mapping file. This extraction removes unnecessary complexity from the IDL file, making it easier to generate client-side language bindings without carrying over irrelevant parameters.
2Adaptability or versatility
If language-specific parameters are included in the IDL file to support legacy services, then the legacy service can be accessed, but client-side language bindings become more complex and harder to maintain
Solution Approach 1:
A server-side mapping file acts as an intermediary between the clean IDL file and the legacy service implementation. This mapping file contains all language-specific parameters and transformations needed to access legacy services, while keeping these details hidden from the IDL file and client-side language bindings.
3Measurement precision
If the IDL file exactly matches the legacy service parameter definitions, then the service interface can be accurately described, but parameters irrelevant to the client are included
Solution Approach 1:
The IDL file is designed with local quality appropriate for client-side consumption, containing only interface information relevant to the client. The server-side mapping file handles the translation to the legacy service's specific parameter requirements, allowing each file to have the quality and detail level appropriate to its purpose.
Data Source
AI summary
Making a service implementation accessible for a client application in a service oriented architecture. The method may include extracting an interface definition language file from the service implementation, which defines the interface information to be provided by the client application to access the service implementation during runtime. The method may further include extracting a server-side mapping file from the service implementation, which defines how the interface information provided by the client application is mapped when accessing the service implementation during runtime.