Enhancements to On-line Booking Systems

Candidate Architectural options

An analysis of a typical on-line booking system helps to understand the issues underlying the launch of new service offering. Following are some of the candidate options after getting an understanding of the provisional work flow:

Application of SOA (Service Oriented Architecture) model

Using a loosely coupled architecture in line with SOA model, is one of the most common approaches to allow deployment of new services. Some of the key attributes of this approach are listed below:

• This approach relies on creating each core functionality as an independent service offering with APIs to invoke the services (REST based)
• Different services will be talking to each other over REST interfaces depending on the service being catered, criticality of response time etc.
• Business Rule Engines can be used to allow flexibility in provisioning rules and required actions

While this is a tried and tested approach that helps in deployment, this method still does not allow a level of flexibility to extend the workflows without going through the conceptualize-implement-deploy cycle.

Using Micro Services Architecture:

This approach relies on having smaller (micro-)services which are logically pluggable to create a workflow. For communicating with other services, these micro-services use message queues. For instance, in the context of the booking system different micro-services that are involved are as follows:

• searching of item of interest
• selection of best option
• availability check
• booking with different payment options

All these micro-services can be configured to create the required workflow.

This approach allows better flexibility of defining new work flows using existing micro-services. However, this is a relatively complex and time consuming method and requires definition of the work flows (in the work flow engine) and implementation of supporting micro-services, if any.

Using Generic Service description templates

This approach is based on the premise that services (which are abstract in nature) can be treated as commodity products; which are stocked & sold as pre-packaged items with pre-defined tags (such as unique identifier, size attributes, validity period, price, etc.). The common work-flows related to inventory management, search/filtering, recommendation/ selection, purchase and fulfillment can be applied to any service (existing or new). The key step is to define a service(s) using extensible template(s) with a finite number of attributes (some of which could be optional and can be added on a need basis). Data model for any service would typically consist of a universal parameter set (which is common across different offerings) and specific parameter set (which is to be defined on per service basis). Once the life cycle management of these template based service(s) is in place, on-boarding of new services would be much simpler. This can help in launching new services in few weeks rather than few months. For on-boarding and launching a new service, the following steps are required:

• Identify the common parameters from the universal set that applies to the service.
• Identify parameters which are specific to the new service offering.
• Create a schema file (XSD) and model classes for the new offerings.
• Implement specific business processing layer, if specific business logic is needed. If not, the default Create, Read, Update, Delete, Buy, etc. processing for the generic data model will apply.
• Update the presentational Layer, if specific screens are needed, else the generic UI can be used to facilitate the work-flows.

If the workflow and service handling logic for services like inventory management, purchase, search etc. is in place, then the Generic Service Description template approach can help in getting new services and offerings launched in a matter of few weeks. This approach eases the data modelling and handling complexities using Generic schema templates which can be extended as per new offerings and services.