Modernize Baggage Acceptance Messaging with Enhanced Efficiency and Security

The baggage acceptance process plays a critical role in air travel, ensuring the safe and efficient handling of passenger luggage before a flight. In the following use case, we will delve into a framework created by IBM for the modernization of a traditional mainframe-based baggage messaging system using AWS managed services to align with the evolving requirements of the airline industry.

Traditional Baggage Acceptance Messaging Architecture

Airlines traditionally rely on mainframes for their essential systems and employ messaging architecture for baggage management. At the heart of the airline’s baggage acceptance process is an on-premises messaging queue (MQ) system, responsible for receiving and processing baggage source messages (BSMs). These messages contain vital information about accepted bags, facilitating seamless coordination among various baggage handling, tracking, and real-time staffing stakeholders.

The increasing data volumes and real-time demands of baggage acceptance pose reliability and operational challenges. With the surge in passenger traffic, existing on-premises MQ systems may encounter significant hurdles, even when they have separate queues for processing messages from the hub and non-hub stations. Hub stations serve as critical transfer points for connecting flights within an airline’s network.

The sequential nature of BSMs within a flight context also introduces complexities in maintaining precise order during processing. This can lead to baggage mishandling, revenue loss, and an unsatisfactory passenger experience.

Figure 1: Baggage Acceptance Messaging Architecture – Current State

Figure 1 explains the high-level process for the current state baggage acceptance system. Bags are accepted at Self Service Baggage Drops or Kiosks/Check-ins [area 1]. Once bags are accepted the baggage check-in system invokes legacy services to generate bag tags among other processes that generate baggage source messages [area 2]. The mainframe systems also receive BSMs from partner airlines [area 3]. The mainframe systems publish BSMs using an IBM MQ architecture for downstream systems [area 4]. A legacy BSM processor will listen to BSMs and extract the structured bag information by parsing BSMs before writing to the “Baggage Acceptance” database [area 5]. Downstream processes read the data from the “Accepted Bags” database [area 6].

In the following sections, we will delve deeper into the use case’s intricacies, innovative solutions, and successful outcomes. We will demonstrate how these efforts may lead to a more agile and future-ready baggage messaging system to support bags acceptance for an airline.

Need for Modernization

Airlines must acknowledge the significance of modernizing their baggage acceptance messaging architecture to make it more agile, scalable, and robust. The primary objectives include:

Enhancing security
Enhancing Reliability
Improving operational efficiency
Ensuring compliance with aviation regulations
Providing high availability
Enhancing the overall passenger experience for mission-critical operations

Modernization Challenges

The following key challenges require meticulous planning and strategic implementation:

1. Latency and Connectivity: Overcoming latency issues caused by the distance between on-premises data centers and cloud servers across different regions.

2. Coexistence with Legacy Systems: In most cases, the existing MQ cannot be moved to the cloud due to enterprise constraints. This creates a key challenge for ensuring seamless integration and data synchronization between the cloud-based solution and the existing on-premises MQ system.

3. Handling Sequential Nature of BSMs: Implementing mechanisms to preserve the sequential order of BSMs within a flight context during cloud deployment.

4. Data Security and Encryption: Ensuring robust encryption protocols for data in transit and at rest to safeguard sensitive passenger information.

Solution

Figure 2: Baggage Acceptance Message Architecture – Proposed Approach

As depicted in Figure 2, in this use case, we propose the division of messages into hub and non-hub queues. This recommendation aims to enhance reliability, streamline processing, and reduce delays and latency resulting from the substantial data volume generated by hub stations. To facilitate flexible integrations with downstream systems, the solution transforms BSMs into a JSON file format.

Moreover, the solution incorporates two supplementary queues for hub and non-hub messages, facilitating seamless integration with the existing mainframe systems. The solution leverages a new BSM processor on the cloud to process messages from these queues [area 1]. The BSM processor will extract the structured bag information by parsing BSMs before saving them in the cloud under the “Accepted Bags” database. Downstream processes can then read the information from this database [area 2].

Modernizing Baggage Acceptance Messaging Architecture in Amazon Web Services (AWS)

The solution leverages Amazon Managed Streaming for Apache Kafka (Amazon MSK) as the key architectural component for the messaging architecture for downstream systems. Amazon MSK comes in two varieties: provisioned or serverless. Choosing the best cluster type for each workload depends on the type of workload and organization’s preferences.

Amazon MSK provisioned clusters: offers more flexibility in how you scale, configure, and optimize your cluster.
Amazon MSK Serverless: makes scaling, load management, and operation of the cluster easier for you. With Amazon MSK Serverless, you can run your applications without having to configure, manage the infrastructure, or optimize clusters, and you pay for the data volume you stream and retain. Amazon MSK Serverless fully manages partitions, including monitoring as well as ensuring an even balance of partition distribution across brokers in the cluster.

Figure 3: High-Level Solution Architecture

Key Architectural Components:

1. Connectivity using AWS Direct Connect and AWS Transit Gateway: To ensure secure private network communication between the on-premises data center and AWS Cloud, AWS Direct Connect architecture using AWS Transit Gateway could be implemented. This dedicated network connection service establishes a private link between the two environments, reducing latency and ensuring reliable data transfer. Additionally, AWS Transit Gateway simplifies network connectivity and routing, enabling seamless communication between Amazon Virtual Private Clouds (AWS VPCs) and the on-premises data center.

2. Kafka Producer using AWS Lambda: To process the incoming BSMs, a listener architecture utilizing AWS Lambda functions was employed.

Scalability: AWS Lambda automatically scales based on demand, optimizing resource utilization during peak times and reducing operational costs during low-demand periods.
Security: AWS Lambda may be deployed within the AWS VPC and configured to use a unique security group. During runtime, AWS Lambda leveraged elastic network interfaces, transit gateway and direct connect architecture to privately communicate with the MQ on-premises. The solution may leverage a client-side certificate to establish encryption during transit from on-premises MQ.
Continuous Polling: Since Lambda cannot subscribe to the on-premises MQ, and can only poll the messages at a certain frequency, the solution could use an Amazon EventBridge to implement a watchdog implementation. EventBridge will keep the Lambda “warm” by invoking at a regular interval of one minute, during which the Lambda will use a timer to continuously poll the message from the on-premises MQ with a near-zero frequency.
Ensuring Sequential Processing of BSMs: To ensure the sequential nature of the messages the MQ solution could be configured to have a shareable connection set to false. Hence only one AWS Lambda consumer instance is allowed to read messages from each hub and non-hub MQ respectively. In a multi-region active-active architecture, AWS Lambda in a second region may attempt to read the messages from the MQ but will fail to obtain the MQ connection since the MQ is configured to accept only one connection at a time. This is to ensure that the second region is on active/standby for an automatic failover.
High Availability Using Automatic Failover and Recovery: The solution will leverage two regions’ active/active disaster recovery strategy with each region supporting three subnets. In the event of a regional failure, the second region AWS Lambda will obtain the connection and start processing.

3. Amazon Managed Streaming for Apache Kafka (Amazon MSK):

Partitioning Strategy for Parallel Processing: To optimize baggage messaging processing, the solution can address the challenge of handling varying message volumes by implementing a partition key based on departing station, flight number, and departure date. This partitioning supports the parallel processing of messages while maintaining their sequential order within each flight.
Data Security and Privacy: During implementation, stringent encryption measures must be put in place to address data privacy concerns both in transit and at rest. To ensure data security, the solution must utilize AWS Customer Managed Keys to protect sensitive passenger information within the cloud infrastructure. Additionally, transport layer security encryption must be leveraged to secure messages in transit when Lambda publishes messages on a Kafka topic.
- Encryption in Transit: To achieve encryption in transit, the following steps need to be taken:
  - Enable secure socket layer/transport layer security (SSL/TLS) encryption on the Kafka broker. This involves setting up SSL certificates on the Kafka broker instances to establish a secure connection.
  - Used SSL/TLS Endpoints: During the setup of the Amazon MSK cluster, SSL/TLS endpoints were created to enable secure connections between Lambda and the Kafka brokers. These endpoints played a vital role in encrypting the data communication.
  - Configured Lambda Client: The AWS Lambda function needs to be configured to use SSL/TLS endpoints when publishing messages to the Kafka topic. This ensures that all data sent from Lambda to Kafka is encrypted during transit.
  - Encryption at Rest: Amazon MSK seamlessly integrated with AWS Key Management Service (Amazon KMS) to offer transparent server-side encryption, ensuring that all data is encrypted at rest. When creating the Amazon MSK cluster, the solution specified the Amazon KMS key for encrypting data at rest. Amazon MSK employs TLS 1.2 and encrypts data in transit between the brokers of the Amazon MSK cluster by default. For communication between clients and brokers, the solution may be configured to allow only TLS-encrypted data.
Failover Strategy:
- Multi-Region Failover Strategy – The proposed solution is to deploy separate Amazon MSK clusters in different regions with the same message available on all clusters to achieve regional failover. Mirror Maker (MM2) is another approach that can be considered for a failover strategy but additional factors need to be considered like network latency and partition distribution which may impact the order of messages on the destination cluster.

4. Kafka Consumer using AWS Lambda: To process the incoming BSMs, a listener architecture utilizing AWS Lambda functions can be employed, and can subscribe to topics from one or all the clusters depending on the use case.

Conclusion

In this article, we discussed how to modernize the legacy baggage acceptance messaging architecture for airlines. We explained the cloud-based modernization approach of a legacy system to build a robust and performance-efficient co-existence layer by improving the availability, security, and integrity of data while ensuring sequential processes in the cloud.

Check out more AWS Partners or contact an AWS Representative to know how we can help accelerate your business.

Special thanks to our contributors and collaborators: William A. Brown – IBM Consulting, Ryan Keough – AWS, Vijay Gokarn – IBM Consulting, Bikram Mondal – IBM Consulting, and Angela Barros – IBM Consulting