Centralized PNR Context Management via Interceptor Architecture
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In distributed travel reservation systems, ensuring consistency and performance of Passenger Name Record (PNR) data across multiple platforms and protocols is challenging, especially during migration from legacy mainframe systems to open systems, leading to complexity and double maintenance efforts.
Innovation Solution
A reservation service interceptor architecture is implemented, using a Generic Context Container (GCX) to centralize PNR context data, ensuring consistency and security by delegating functional queries with the current user PNR context, which is updated only at response time, and utilizing a Distributed Context Correlator (DCX) for synchronization across platforms.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If progressive migration from legacy mainframe system to open system is performed, then service interruption is avoided and double maintenance effort is reduced, but data synchronization and consistency across different platforms becomes complex
Solution Approach 1:
The patent introduces a Gateway as an intermediary component that mediates between the legacy TPF system and the new open system. The Gateway translates requests and responses between different protocols (TPF vs. HTTP/JSON), manages session state, and coordinates data synchronization. This intermediary approach allows progressive migration without requiring complete system replacement, maintaining service continuity while reducing the complexity of direct integration between heterogeneous systems.
Solution Approach 2:
The system is segmented into distinct modular components: the legacy TPF system, the Gateway, and the new open system applications. Each component can be independently developed, deployed, and maintained. The migration process itself is segmented into phases where specific functionalities are gradually moved from TPF to the open system, allowing incremental progress without requiring complete system replacement at once.
2Adaptability or versatility
If PNR data is shared across multiple servers and platforms, then system versatility and collaboration are improved, but data consistency and synchronization become challenging
Solution Approach 1:
The patent implements feedback mechanisms where the Gateway continuously monitors the state of PNR data across different systems. When changes occur in either the TPF system or the open system, the Gateway detects these changes and initiates synchronization actions. The system includes state tracking and validation feedback loops that ensure data consistency, with the Gateway adjusting data flow and synchronization timing based on detected changes and system state.
Solution Approach 2:
The Gateway performs preliminary actions by pre-loading and caching PNR data before it is needed by applications. It anticipates data access patterns and prepares synchronized copies in advance, reducing the risk of inconsistency during actual data access. The system also performs preliminary validation and transformation of data before it is exchanged between systems, ensuring consistency prerequisites are met before synchronization operations.
Data Source
AI summary
The method and system according to a preferred embodiment of the present invention allows ensuring consistency of the PNR record when it is handled within the subsystem controlled by the reservation interceptor module and including a plurality of OBEs. According to a preferred embodiment of the present invention the PNR context on open systems is centralized to avoid its fragmentation in the distributed environment, as gathering of all the context parts implies performance issues. In addition, instead of implementing a transaction session protocol to handle a start of transaction, intermediate updates and a final commit or rollback on the PNR context, the principle of the service interceptor architecture is to delegate the functional queries with the current user PNR context which will be modified in the central repository of PNR context only at response time when the whole functional use-case is finished.