Solution Perspective

Who is this guidance for?

This guideline is for any party responsible for the deployment of a baggage information exchange solution. Specifically, these may be:

• IT Architects Developers. Individuals who need to design build and test a solution.

• IT Service Providers. Individuals who need to service manage a solution.

• IT Service Owners. Individuals who need to manage an IT service provider.

What does this guideline provide guidance on?

This guidance provides conventions for the configuration of protocols so on a worldwide basis airlines and partners in exchange of baggage information understand how to setup communication for the services defined by the BIX Working Group.

When should this guideline by applied?

This guidance should be reviewed at the design, implementation and service provision stages of an airline broker node.

Concepts for solution

In Baggage Logistics we recognize exchange of messages between Airline and its Handlers, between peering Airlines, and from Airline to Authorities.

Conceptually Baggage aligns with Modern Airline Retailing:

“The main principle is to split the source of content and the consumption of this content. The source sits in the airline eco-system, and the consumption is done by interfaces and/ or devices accessing these different airline systems, then triggering any update back to the airline systems”².

The source, the single source of truth for a bag (or baggage containing cart or ULD) is with the custodian Airline.

Message exchange is always from or towards the custodian Airline.

From the source there is an outbound connection (typically for instructions and notifications), and there is an inbound connection (typically for reports).

It is up to the custodian Airline to decide how reports reflect in updates to the source of truth.

Connections are established on request of the party that consumes baggage information and may post its findings.

The communication paradigm could be described as “connect directly to the source of the information”.

Solution Architecture

The architecture describes logical components, interfaces and communication concepts for the RP1755 standard. Regarding the already existing baggage system architecture and implementation rules at an airline or airport, the following mentioned terms or components will not be implemented in a specific environment, but functional implemented in other components.

The solution contains two parts, an information provider (single source of truth) and an information consumer (client to consume information and post findings).

The information provider -custodian Airline- exposes end points (a broker or an API gateway) where the information consumer can subscribe or publish (get or post) information on relevant baggage items

The protocol between end points and client acknowledges delivery of content, either through acknowledgement at level of protocol, or through a synchronous mechanism.

In case of asynchronous protocol, the protocol shall enforce delivery of content in correct sequence. In case of a synchronous protocol, a solution shall be available to prevent excessive polling.

Messages in transport shall be encrypted.

As an option, messages in transport may be signed to be tamper-proof.

For asynchronous messaging the broker and client shall exchange through a channel as per AsyncAPI terminology.

At time of writing the community lacks experience to express guidance on channel naming conventions other then

• Keep inbound and outbound channel between custodian and client distinct

• Keep channels distinct between two clients to respect confidentiality

• Consider to partition message exchange in distinct channels per airport

Architecture Components for asynchronous exchange scenario

The logical components are identified with help of AsyncAPI terminology

Baggage Producer and Consumer

The producer and the consumer interface to baggage systems of Airline and Handlers and provide capability to connect to the server.

Baggage Broker

The server exposes the end points where the conversation is channeled. This is where the “single source of truth” manifests itself. The server is controlled by the custodian Airline. In asynchronous communication the server is typically referred to as the broker.

Baggage System

The baggage system means the already existing baggage system at airlines or handlers where the baggage logic (including the RP1745 baggage communication) is implemented and baggage information is persisted.

These baggage systems must be extended to be able to deal with the RP1755 messages and mechanisms. As the airlines and handlers has different systems running, details on how to implement RP1755 are not covered by this document.

The solution perspective only shows how to communicate from an existing baggage system with the partners for RP1755 messages.

Note that a Baggage System can be either producer or consumer depending on the Role and Gesture in conversation

The airline baggage messaging node shall contain both a broker, a publishing message client and a consuming message client, all three front-ending the baggage system of the airline.

The handler baggage messaging node contains only a consuming and a publishing message client.

Via the baggage messaging nodes, the airline/airline and airline/handler communication for RP1755 messages is established.

Logical components of the baggage broker node are the Broker, the Baggage Message Consumer and the Baggage Message Producer.

Open

Figure 18 – Logical Components of Baggage Broker Node

Architecture

Open

Architecture Components for synchronous exchange scenario

Placeholder for future work

Implementation practices

End point discovery