1. An example design for an Amadeus APIv2 Web Server Application

2. An example design for an Amadeus APIv2 Server Application
Use Case View
The Context.
The Travel Booking Engine, the End User, the Application Provider, the Apiv2 Proxy and the Amadeus Central System.
The main use case – Book Travel Solution
Design View
Starting up the Travel Booking Engine.
An End User’s first request
An example of session establishment.
An End User in-series request.
An End User closes the session.
An example of session termination and clean-up.
An End User does not close the session.
An example of Inactivity time out
Conversation States

3. The Context Travel Booking Engine End User Network
Application Provider’s site
Network
Amadeus site
Introduction
This presentation describes an example UML design for a multi-user, multi-threaded Travel Booking Engine using the Amadeus APIv2. The design purposely concentrates on the interaction between the Application Provider’s software and the conversation management aspect of APIv2 Proxy library.
The Use Case
The Travel Booking Engine represents the Application Provider’s system. This system allows End Users to search for flight schedules and availability, and then book and ticket their selected itineraries. The Travel Booking Engine is multithreaded and capable of handling multiple End User requests in parallel. It is stateless with the context (AAA) being held on the Amadeus Central System. It is a scalable engine, and can be distributed across many servers.
The Actors
The Application Provider represents the owner and developer of the Travel Booking Engine.
The End User represents customers wishing to book a travel solution. They are most probably using a Web Browser and connecting to the Travel Booking Engine via the internet.
The Amadeus APIv2 Proxy is a software library installed on the Application Provider’s site. It includes a full set of functions to gather information and make travel reservations easily. It is not however, a ‘ready to use’ product in that it requires software development on behalf of the Application Provider to create the customized finished product.
The Amadeus Central System represents the site of the Amadeus Global Distribution System.
Travel Booking Engine

4. Book Travel Solution End User Network Application provider’s site
Amadeus
The main Book Travel Solution use case consists of features which allow the end user to search for availability (e.g. flight), book the chosen solution, and finally ticket the booking.

5. Starting up the Travel Booking Engine
End User
Network
Application provider’s site
Network
Amadeus
Starting up the Travel Booking Engine
The Travel Booking Engine is started up and its main entry point is called. Its first task is to prepare the server for accepting requests from End Users.
The Main thread instanciates an APIv2 Conversation Factory (1) to be used later for creating APIv2 conversations. Only one factory is required per Corporate/user. A Corporate/user basically represents a Travel Agency office on the Amadeus Central System.
The Conversation Factory is authenticated by the APIv2 Gateway (2).
Next the Main thread enters its main event loop, and listens for requests (3) from End Users.

6. An End User’s first request
Network
An End User’s first request
Application provider’s site
Network
Amadeus
Query
Here we show the sequence of messages triggered by an End User’s first query (first-in-series message).
i. The query is received by the Main listening thread (not shown for simplicity) which forwards it to a Worker Thread and then continues listening for further queries from other End Users.
ii. The Worker thread realizes that this is a first-in-series query and that there is no context yet. It requests a new Conversation from the Conversation Factory (1 & 2), and forwards the query to the Amadeus Central system (3 & 4). It waits and receives a successful reply.
iii. The next step is to serialize the conversation into a serialized string (5 & 6). This character string represents the link with the context record (the AAA) located on the Amadeus Central System. This serialized string will be eventually handed back to the End User’s browser. The End User’s browser will mirror it to the Travel Booking Engine in the case of any follow-up queries (either middle-in-series, or terminate messages).
The purpose of passing the context serialized string information back to the End User here is to:
a. simplify the Travel Booking Engine architecture and free it from maintaining any state information (it is stateless).
b. allow the Travel Booking Engine software to be distributed across many servers (it is scalable).
c. allow End User queries to be load balanced across servers for greater performance.
iv. Finally, both the reply and context serialization string are returned to the End User’s browser.
Reply + Serialized String

7. An End User in-series request.
Network
An End User in-series request.
Application provider’s site
Network
Amadeus
Query + serializedString A
Reply + SerializedString B
Here we show the sequence of messages triggered by an End User’s follow-up query (middle-in-series message).
The query is received by the Main listening thread (not shown for simplicity) which forwards it to a Worker Thread and then continues listening for further queries from other End Users.
The Worker thread realizes that this is a middle-in-series query and that there is an existing context represented by the serialized string A. It unserializes the serialized string A using the Conversation Factory to recreate the Conversation object (1 & 2).
The Worker Thread forwards the query to the Amadeus Central system (3 & 4). It waits and receives a successful reply.
The next step is to serialize the conversation again into a serialized string B (5 & 6). This character string is an updated link to the context record (the AAA) located on the Amadeus Central System. Important: serialized string B is not the same as serialized string A.
Finally, both the reply and context serialization B string are returned to the End User’s browser.

8. An End User closes the session.
Network
Application provider’s site
Network
Amadeus
An End User closes the session.
Serialized string
Here we show the sequence of messages triggered by an End User closing a session (terminate).
The serialization string is received by the Main listening thread (not shown for simplicity) which forwards it to a Worker Thread and then continues listening for further queries from other End Users.
The Worker thread realizes that this is a terminate request (there is no query) and that there is an existing context represented by the serialized string A. It unserializes the serialized string A using the Conversation Factory to recreate the Conversation object (1 & 2).
The Worker Thread closes the conversation (3 & 4) and the close request is forwarded to the Amadeus Central System. Control returns immediately to the Worker Thread (no need to wait for the reply).

9. An End User does not close the session
Network
Application provider’s site
Network
Amadeus
An End User does not close the session
If no activity is registered by the End User, the AAA context record held on the Amadeus Central System will automatically be released after a given ITO has elapsed (typically 30 mins).

10. Conversation States Application provider’s site
The Conversation object has two main states, Active or Passive.
In the Active state, it represents both a TCP/IP connection to the API Gateway, as well as a link to the AAA context record on the Amadeus Central System.
In the Passive state, the Conversation object represents simply a TCP/IP connection to the (API Gateway). This object can be reused by any context serialized string to render it Active again.