Session Manager

Best Practices & Recommendations

Version 1.2
Documentation Control
Department: Commercial Enterprise Architecture
Author: Leandro Tapia / Gonzalo Tapia
Revised For: Chris Parry Date: Apr - 17
Approved For: Gonzalo Tapia Date: Apr - 17

Version Date Observations From

1.0 Feb -17 Original version Leandro Tapia
1.1 Feb -17 Gonzalo Tapia
1.2 Apr – 17 Sabre updates Chris Parry
Summary
Documentation Control ................................................................................................................ 2
1. Introduction .......................................................................................................................... 4
1.1. Objectives ...................................................................................................................... 4
1.2. Definitions and Abbreviations ....................................................................................... 4
2. Session Manager Architecture .............................................................................................. 5
2.1. Business Context ........................................................................................................... 5
2.2. Session Manager Definition .......................................................................................... 5
2.3. Session Pool Definition .................................................................................................. 5
2.4. Architecture................................................................................................................... 6
2.5. Stateless Sessions .......................................................................................................... 7
2.6. Stateful Sessions............................................................................................................ 8
3. Session Manager Features .................................................................................................... 9
3.1. Main Features ............................................................................................................... 9
3.2. Administration Capabilities ......................................................................................... 10
 1. Introduction
1.1. Objectives
The following document describes the best practices and recommendations based on LATAM experience to
manage security sessions to access Sabre Web Services. The document aims to support our development
providers or agencies in a better understanding for the implementation of their own session manager.

To achieve this, the current implementation of LATAM session manager will be used as a case study,
identifying the main features and functionalities of the component. An architecture vision of the solution
and sequence diagrams will also be delivered for this purpose.

1.2. Definitions and Abbreviations

Terms Descriptions
SM Session Manager Software to handle life cycle of security session to access
to SABRE.
SP Session Pool
EPR Unique username to access to SABRE with specific permission level.
Robotic EPR Robotic EPR are unique user only for Systems integration.
Resource Pool Also known as Terminal Address Manager (TAM) Profile or TAM Pool, it is a
(RP) set of session resources allocated in SABRE host. The RP provides capacity
to process requests using a LNIATA identity per session, either via web
services or via the DCP GUI provided by Sabre

Página 4 de 10
 2. Session Manager Architecture
2.1. Business Context
Since applications all over the world require access to PSS to be able to offer Airline’s Products and Services,
a secure and efficient access mechanism is required, capable to operate over the network.

For this purpose SABRE handles security sessions and the apps are responsible to create and release of
sessions through Web Services to have access to SABRE Web Services. To obtain a session is a bottleneck
because of cost, latency and time.

 Cost: Sessions are limited resources and explicitly provisioned.

 Latency: There is a base latency time for every request.
 Time: Each call has a time overhead (get and release session).
 Concurrency: Difficult parallel processing.

Due previous business context, a few challenges need to be addressed:

 Share and maximize sessions between many users.

 Faster session creation (50ms).
 Make and efficient use of resources.
 Simplify parallel processing for orchestrations.
 Modular and Independent Services from SessionManager.
 Allow persistent scenarios (Stateful - AAA).

2.2. Session Manager Definition

Session Manager (SM) is software that can handle the entire life cycle of security sessions connected to
SABRE, decreasing creation times at runtime through an in memory sessions used by apps. In this context,
sessions are valid only for Robotic EPR used by apps that access to SABRE.

This approach is a SABRE recommendation and there's no out of the box solution available for customers.

See the link below for more details about SABRE session manager recommendations.

https://www.sabretravelnetwork.com/files/ttx/2013%20TTX%20Sabre%20Web%20Services%20Advanced%
20Practices.pdf Replace this with the Dev Studio link for consistent branding

2.3. Session Pool Definition

Session Pool (SP) is part of the SM and responsible for group sessions by app in order to have a granular
administration of sessions and reduce risk when a specific system runs out of normal behavior.

Every SP has resources allocated in SABRE to process transactions under a resource pool (RP) definition.

Based on LATAM experience and best practices over the years ideally there is a one to one relationship
between RP and Apps but also are possible grouping apps by criticality level or other concepts. The balance
allows us to have a fine grained administration, and quick diagnosis of issues. Keep in mind that more RP
requires more administrative tasks to handle.
 2.4. Architecture
Since 2010 LATAM has been working on a Service Oriented Architecture (SOA) to access to SABRE in order to
simplify PSS access reducing development time and cost through webservice reutilization.

The figure 1 represents a high level view of SM architecture – as implemented by LATAM.

Figure 1. SM High Level Architecture

Application: Business apps that requires access to SABRE. The apps only send a request to a specific
custom webservice.

LDAP: Provides first level of authentication for custom web services through HTTP basic
authentication.

Web Service Layer: Custom web services that orchestrate SABRE web services in order to accomplish
business needs.

Session Manager: Software that handle security sessions to access to SABRE. Apps provide a specific
app name that SM mapping to SP. SM has the capability to handle sessions in a stateless or stateful mode.

SABRE: SABRE web services layer. Web services could be out of the box or sabre commands.

Note that apps, webservice layer and SM are running on premise in the same network reducing latency
when an app sends a request to a specific webservice.

The figure 2 represents SM Logic Architecture. The core of the SM is running over a single server with fault
tolerance mechanism. SM implements a request to out of the box Sabre Web services to create
(SessionCreateRQ), close (SessionCloseRQ) and validate sessions (SessionValidateRQ) and store sessions for
every session pool on hashmaps.
The session pool configurations are fetching from database and an Administrator GUI is provided for data
maintenance.

SM Web services are exposed on an internal ESB for governance purposes and control access from Apps.
Figure 2. SM Logic Architecture

2.5. Stateless Sessions

Stateless sessions are provided for apps that do not require persistence sessions. Figure 3 represents a
sequence diagram for stateless session creation. (note: this depicts LATAM session manager deployment to
offer stateless sessions as noted below) (Note: Stateful represents a session with a work area and prior
context, and in Stateless, each request is unique without prior context)
 Figure 3. Stateless Sequence Diagram

2.6. Stateful Sessions

Stateful sessions are provided for apps that require persistence sessions. Figure 4 represents a sequence
diagram for stateful session creation.
Figure 4. Stateful Sequence Diagram
 Session creation and context change must follow the behaviors documented on Sabre Dev Studio:

 Each session create request must include the ‘returnContextID=”true” element. See Sabre Dev
Studio - Create Session for an example.
 Context Changes must be performed using ContextChangeLLSRQ (i.e., not via
SabreCommandLLSRQ).
 Following each successful ContextChangeLLSRQ: the application must stop all use of the security
token that was sent on the context change request, and send all subsequent web services
requests using the new security token that was returned in the context change response.

3. Session Manager Features

3.1. Main Features
Core App:

 The core of the system is a group of FIFO queues.

 Every session pool is an in memory queue.
 SM automatically maintains a minimum amount of sessions.
 SM interfaces are implemented as Web Services.
 Asynchronism mechanisms through WorkManagers.
 Concurrency Utils for Enterprise Edition (JSR-236)
 Java Management Extensions (JMX)
 Apache Commons Pools
 In-Memory Session Pool Management
 Managed Threads & Asynchronous processing
 java.util.concurrent (ConcurrentHashTable)
 Object Oriented Design
 Factory Pattern

Data Model:

 One instance per environment.

 Centralized data model to persist session pool configuration.
 Running on Oracle.

PSS Agnostic:

 Centralized session creation.

 SM can automatically increase sessions on-demand.
 Redundant sessions are automatically removed.
 Request from applications only need to know their app name.
 The “session” is a black box for apps.
 SM automatically maintains and validates sessions.
 Every session has a time to live set on 15 min.
 3.2. Administration Capabilities
House Keeping:

 Session timeout is set on 15 minutes.

 HK reset time to live in every session.
 Ping service is implemented to keep session alive.
 Sessions are updated with the last time access.
 Weekly Purge: close and reopen all session pools.

Security:

 Only SessionManager has the User ID and password to access to SABRE.

 Applications cannot open connections

Configuration Administrator:

 In house development that maintain (CRUD) session pool configurations in database.

 Administrator is a JEE application running on Weblogic with security through roles mapped to groups
in active directory.
 JMX operations are supported.

Min and Max sessions are configurable.