Application Server Layer

The application server layer is the Node,js implementation of the gateway. This will require many node modules to bring the functionality required. At the time of writing version 0.6.9 is the most recent version.

There will be a separate URL/endpoint for each one provided:

The system will use a client key and user authentication which will be similar to OAuth 2.0. The client must register for a key, and then the user authenticates through the authorised client using their credentials. This will verify that the client is allowed to communicate with the application server. This access token will be established when the client (PHP, Android, iOS) is installed.

There will also be a user-based authentication which validates the user who is logging in via the client. This will be further discussed in the system design section.

There will be logging of every call to the end points. This will be logged to the file system, and will include time stamp, client IP address, user IP address, incoming and outgoing messages. This logging can be turned off, but should be enabled by default.

Every action in the database will have a hook which will allow override or other functionality to be implemented. This will mean that the core system will be the same for all clients, and the customisation will be Javascript which is stored as data.

There will be a second set of internal hooks which will be used for synchronising with other Butr instances.

The Gateway will have three sub-layers, but you can think of them as a single layer. This will all be coded in Javascript using Node.js.

The upper layer is the translation layer. This will take the message in whatever format and translate it ready for the middle layer to use. This will perform the mundane task of checking to see that the message is in the correct format. This will then convert the message into a Javascript object which will be passed to the middle layer. It will blindly just construct the Javascript object looking for the fields in the message.

The upper layer must be very strict on the messages and must absolutely be designed to not have any injection exploits. The error messages will be vague at best.

The middle layer is the router logic. It's first job is to ensure that the Javascript object has the correct format and all the required information has been provided. Once it's verified then the session authentication is checked to ensure that the message has the right credentials to call the given API message. If that checks out, then it's routed to the lower layer. It goes without saying that the middle layer must be bullet proof in terms of security as this is the gatekeeper to the system. Most of the emphasis for the security should be focussed at this level.

The lowest of the three is the business logic layer. This will be where the API call is translated into a transaction of one or more stored procedure calls. Each of these calls will have a unique transaction identifier. The database will then execute the stored procedure call(s) and then capture the responses.

The lowest layer will be the wrapper for the database communication and it will be aware of the existence of memcache and database shards if the database is indeed sharded.

It will then create a Javascript object which will be returned to the middle layer. The middle layer then will route the object the correct outbound upper layer and the result will be emitted in the correct format.

Once these three message formats are delivered, then further consideration for “industry standard” and other message protocols may be implemented. These include:

  • Open Travel Alliance (OTA)
  • Travel Technology Initiative (TTI)