Orion is a software platform that allows normalization of multiple disperse travel systems and provides advanced automation capabilities.
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.
Each source type will cover five (5) main zones:
Our client base are:
as you can see all participants of this industry. Vast majority of our clients are Travel Agencies (TA).
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.
New platform will be divided into 5 main sets of micro-services:
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 to control routing, reverse proxy and SSL handler. Hosted in our environment.
More
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:
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.
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.
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).
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.
