TRAVEL TECHNOLOGY SOLUTIONS

Orion is a software platform that allows normalization of multiple disperse travel systems and provides advanced automation capabilities.

Archetectural Solution

Our architecture should start from understanding that platform must work with two diverse types of sources:

Basically, Classic GDS will cover all communication between platform and any given GDS. Therefore, NDC will support any other type of sources that has to be integrated each source individually.

Integration

Web Services

Each source type will cover five (5) main zones:

Air
An airline can be defined as a company that offers regular services for transporting passengers or goods via the air
Hotel
The hotel industry is one of the most important components of the wider service industry.
Cruise
The cruise industry is a highly profitable international activity, and the fastest growing sector of the travel, tourism and leisure industry.
Car
End-to-end online car rental to travel agents by integrating with popular GDS providers
Rails
Integration with rail services providers for bookings and ticket modifications. Rail service providers varies from independent to GDS hosted.
Cruise
Potentially we should also have a zone like Other that will hold information on any other service that available in the future for example transportation to Airport (Uber, Shuttle).

For whom this product?

Our client base are:

as you can see all participants of this industry. Vast majority of our clients are Travel Agencies (TA).

15 years experience with TA's

After a long time working with TA's we have noticeably clear understanding what they want. They are interested in two main capabilities: Booking Process and Post-Booking Process. That will be our initial main concerns

Regardless of the process strategical capabilities of a platform have to have ability seamlessly integrates with heterogenous travel systems, providing a critical element for any end-to-end travel system development strategy.

Technical Overview

New platform will be divided into 5 main sets of micro-services:

1. Security

Set of micro-services that will be control via Identity Server 4.0 with OAS3 security. Basically, we will move to this portion of our eco-system everything that has to do with platform user identification. End-point of security layer is done via Authentik that is hosted in our environment.

Nginx Proxy Manager

Nginx Proxy Manager to control routing, reverse proxy and SSL handler. Hosted in our environment.

More
CloudFlare

CloudFlare to extend infrastructural control.

More
Portainer

Portainer to control containers, images and internal networking. Hosted in our environment.

More
Azure or DigitalOcean

Azure or DigitalOcean hosting of Container Registry.

More
2. Administrative

This is one of the main and most important entities within whole architecture. We have implemented a several layers of administration starting from system administration to client-side administration. Under system administration we implemented following stack:

  • Nginx Proxy Manager
  • CloudFlare
  • Portainer
  • Azure or DigitalOcean

Client-Side administration get managed via administrative sites. Such site gets generated automatically for each client. Through this site client will register and control it own servers, GDS's, users etc.

3. Data Access Layer

This layer gives a client additional ability to gain access to their data via Hasura. Client can develop and implement additional API's in order to better administer everything that has to do with platform. There is a whole document for platform admin site.

4. Statistics, Logs and Tracers

Separate set of services that will be completely redesigned to unify and streamline process of collecting logs for any future analysis as well as types of entries (Log vs. Trace).

5. GDS/Source

We have developed a list of GDS related services needed for each capabilities. Each GDS integrated directly through set of micro-services. During new client integration a process of certification has to be performed on client basis. One noted challenge is that every webservice in given GDS must be reviewed from versioning stand point and lifespan for this service. We came across the fact that GDS will deprecate a service or replace it with different one. Such information is open to a public and has to be properly managed on our side. Also, we know that major GDS's like Amadeus and Sabre are using SOAP services for their current main capabilities. However, they are slowly moving towards REST architecture. Platform also capable to support native or cryptic commands for each individual GDS systems. These capabilities allow us to solve and overcome any “gap” situations when GDS don't have API solution for given task, but such task can be done through native commands.

PARTNERS AND CLIENTS
amadeus sabre travelport stripe authorize square connexpay

Our contacts

Feel free to write and call us. Let's keep in touch!
+1-305-502-8599
1920 E. Hallandale Blvd. Suite 907 Hallandale, FL 33 009