A Microservice Based Collaboration Application For Airport Passengers and Transport Providers

The rise of technology has enabled the world to solve problems faced by people in their day to day activities irrelevant of the industry they belong to. Be it the education, healthcare, construction or retail industries, each and every sector has seen a rapid growth, improvement in services and a decrease in problems or issues faced earlier due to utilizing technology. The transportation industry is no stranger to others, the use of technology has helped to revolutionize and disrupt the industry by providing solutions and improvements for transportation related issues and situations. This article discusses one such problem/situation faced by people and a technological solution developed to resolve that.

Problem Statement

Travelling to another country can be enjoyable and exciting but getting ready for that can be tedious, especially in the last few days before departure, where a person has to find locations, make bookings and get all things ready to take with him. One of the most important things when travelling through air is that it is crucial to be in the airport on time or there is a risk of missing the booked flight. Therefore finding a reliable transportation source is a must, especially if you travel alone and don’t have anybody to drop-off you at the airport or if your local public transportation services are unreliable. The developed all-in-one solution comes into play to solve that troublesome problem, where people can book vehicles of choice beforehand easily and get that burden out of their heads.

Solution

The developed system provides a microservice architecture oriented web and mobile based collaboration platform for both travelers and transportation providers to collaborate with each other and make transfer appointments beforehand. The solution is implemented in a way that it provides the travelers not only to book vehicles for drop off to the airport but also to book vehicles to pick them up once returned back. Once a traveler creates an account in the system, he or she can create any number of appointments by selecting the required date/time, pick-up and drop off locations and the type of vehicle according to the number of travelers there are. Moreover, while creating the appointment the distance between the pick up and drop off locations and the travel fare will be calculated in real-time, therefore the travelers have the option to make the payment beforehand using the integrated payment portal. However, if for some reasons the travelers have concerns paying online, they are also given the option to make the payment through cash after the transfer. In addition to that, travelers might be in situations where they need to cancel their flights due to specific reasons, therefore in such scenarios the developed system also provides an option to cancel the appointments made. Once it has been cancelled, the assigned transportation provider will be notified of the same. On the other hand, transportation providers can also create accounts and add details of the vehicles they own to the system so that once a traveler has created an appointment, all transportation providers who have vehicles that match the vehicle selected in the appointment are notified. Transportation providers can then check their schedules and if there are no clashes with the appointment date and time aforementioned, one of them can accept the appointment. Once the appointment has been accepted, the traveler will be notified about the acceptance along with the details of the transport provider.

Key Features of The Developed Solution

• Can create any number of appointments based on date/time, pick up and drop off locations and the type of vehicle.
• Travel fare is calculated using the distance between the pick up and drop off locations while creating the appointment. It ensures that the travel fares are reasonably priced and does not vary from one transport provider to another.
• Travelers can pay the fare online using the payment portal using credit/debit cards or using cash upon drop-off.
• Ability to cancel appointments in case of unexpected situations.
• Notifications are sent for both travelers and transport providers when an appointment is made, accepted and cancelled.

Identified problems and their Mitigations

When a solution is developed to solve a certain problem, there might be some situations where the solution itself has some problems, such as the solution might work in an unexpected manner or will be used by end users in an unexpected way which was not initially identified and mitigated. Below mentions such identified problems in the developed solution and the mitigations that can be used to resolve each issue.

Problem: In this developed solution, when a traveler makes an appointment, a notification is sent to all transport providers having a vehicle matching the vehicle in the appointment. The system does not automatically match or assign a transport provider as he/she might not be willing to accept that appointment or will not be available at the appointment date/time, therefore the transport providers have to log into the system and accept any appointment if there are any. The problem with this scenario is that, if one or several transport providers will continuously be online, they might accept almost all open appointments leaving other transport providers with no appointments.

Mitigation: Can implement an algorithm to limit the number of appointments a single provider can accept daily or on a monthly basis. If the provider is willing to pay a monthly payment, then he or she will be given access to accept any number of appointments.

Problem: When an appointment has been made by a traveler, as mentioned above, all providers with the matching vehicle type receive a notification and one provider can accept the appointment. The problem with this implementation is that the system does not check the pickup and drop off locations when sending notifications to transport providers. Due to that, if for example a person from Colombo makes an appointment to Katunayake Airport with a car as the choice of vehicle, that notification is sent to all providers owning a car within the country which is unnecessary/in-practical as no transport provider for example from Kandy or Galle will be going to accept that appointment.

Mitigation: Can implement a mechanism to get the pickup location of the appointment when generating a notification for that. Based on the location, the notification can be tailored to be sent to providers within the city or the district the pick up location belongs to, so that other providers will not receive unwanted notifications.

Technical Design

System Architecture

The diagram below shows a high level architectural view of the implemented system. This system was developed in accordance with the microservice architectural style. There were many reasons as to why microservice architecture was chosen over monolithic architecture. The following paragraphs explain each of them and why microservice architectural style was chosen.

Monolithic architecture

Monolithic architecture is a traditional application development approach where an application is built as a single autonomous unit. The client side user interface (which contains HTML, CSS, JavaScript code that renders in browser), the service layer (which handles the business logic, retrieve and update the database using queries and contains code to handle HTTP requests from the presentation layer) and the database(which stores all data required by the application) resides in a single code base and is deployed as a jar/war file.

Advantages

• Developing an application following the monolithic architecture is relatively easier than developing it following the microservice approach since in microservice architecture, logic is broken down to separate services and developers need to spend extra time planning and developing mechanisms for inter-services communication, security mechanisms etc.
• Since monolithic applications are developed as a single unit, there is no need for communication between components like in microservice approach, therefore monolithic apps have less latency and give relatively higher performance.
• Debugging and testing is easier in monolithic applications as end-to-end testing can be run faster since there is only a single indivisible unit.

Disadvantages

• If the developed project has a higher number of functionalities and will continuously change or add new features, the application will become complex and too large, making it difficult to manage.
• Making changes is time-consuming, costly and needs to be carefully coordinated as all elements are tightly coupled with each other. Moreover in order to make the change take effect, the whole application should be redeployed.
• Scaling is in-efficient and and takes up resources unnecessarily. For example if even only a part of the application receives a higher traffic, instances of the whole application needs to be deployed in multiple servers.
• Unreliable compared to microservices approach as a single failure somewhere in the application may result in making the whole application to fail.

Microservice architecture

It is an application development approach in which applications are made up of smaller single purpose services that communicate and interact with each other through light weight protocols like HTTP. Each service in this architecture has a defined scope, its own business logic, a separate database and is responsible to carry out a specific business functionality or requirement. This approach to break the entire application into services makes it easier to change and update specific components as well as to scale the required components as per the need.

Advantages

• Unlike monolithic architecture, applications built following the microservice approach are easy to manage and change because each service has its own business logic and is independent from other services. Ability to change and update services individually also provides reduced downtime and allows better user experience.
• Using microservice approach allows to develop each service with different technologies giving developers the ability to use the best stack for each requirement. Due to this ability almost all client requirements could be fulfilled with ease.
• Since microservices are self contained they can be independently deployed and scaled up and down according to requirements allowing to utilize resources efficiently.
• If a particular service becomes unavailable due to a failure, it does not affect the rest of the services, they remain intact continuously providing other services to end users.

Disadvantages

• Complexity of applications built following microservice approach are higher when compared to monolithic applications. It will further increase its complexity with the addition of new services and with addition of instances of services that are already present.
• Debugging a microservice application is difficult as the control might flow through different services in order to cater a user requirement. In such scenarios, pointing out when, where and why a problem occurred is complex.
• Microservice applications can be less secure when compared with monolithic applications since there is communication between services through a network which could be vulnerable.

There are advantages and disadvantages in both monolithic and microservice architectural approaches but with the growing trend in the industry to focus more on user experience and provide the best possible experience for them, using microservice architecture was a good choice to develop this application. With its ability to continuously change or modify requirements/ functionalities without affecting the rest of the application, the ability to independently scale and deploy each service and the capability to not affect other services if one service becomes unavailable were the main factors contributed to this decision. Moreover disadvantages like high complexity with the increment of services and security concerns due to inter-service communications through a network could also be mitigated with proper planning and use of appropriate technologies, therefore there was no issue in going forward with the decision to build the application using a microservice architectural approach.

Components of the Project

This section describes the key components of the developed software solution and provides a detail as to what each component does and why each component has been used within the developed application.

End user applications(web and mobile apps)

There are three main identified end users using the developed application; travelers(who will be creating travel appointments), transportation providers(who will be accepting open appointments based on their availability) and administration(who will be monitoring all customer operations within the system and getting interacted if needed). Both travelers and transportation providers can register to the service by entering their personal details through the mobile or web applications. Once registered they will be redirected to their respective pages based on the role. After being redirected, travelers have the ability to create/cancel appointments, view all appointments made, view their payment history and payment status for each appointment and are able to update their personal information if required. Having said that, once being redirected, transportation providers can view all the appointments they have accepted so far. Apart from that they have the option to add and delete vehicles they own under their profile. They also have the ability to view all open appointments available that match their vehicle types and accept any if there are no clashes with their schedules. Moreover, similarly to travelers, they also have the option to update their personal information if required. On the other hand, administrators(staff working for the company providing this service) can access the system only through the web application. They have the ability to view the details of all the travelers and transportation providers registered to the system. They also can view all appointments, payments and vehicle details under each profile. If the administrators specifically know the name of a user, they can directly use that to get the required details.

API Gateway

The API(application programming interface) gateway is a server that acts as an entry point into a system. Rather than allowing users to directly access microservices which can be less secure, the API gateway acts as an intermediary between the end user applications and the microservices, where end user requests are sent to the gateway after which they are routed to the appropriate services. Apart from encapsulating the internal system architecture from the outside, API gateway can also be used for user authentication, load balancing requests, monitoring traffic, protocol translation etc.

The developed solution also includes an API gateway allowing to gain the benefits mentioned above, specially for the reasons of hiding the internal architecture and load balancing, enabling to spread user requests across multiple instances and provide faster responses. The API gateway used in this system was developed using Spring Cloud API Gateway from Spring cloud. Netflix’s Zuul 2 API gateway was also taken into consideration at the time of planning but was eliminated due to the reason that it does not have support from the Spring cloud team.

Eureka Service Discovery Server

Typically microservice architecture is made up of small services deployed separately and in order to provide functionality to users, these services often require communicating with each other. But the problem is how these microservices find each other. One potential solution is to hard code hostnames and ports but that might not be practical sometimes, because there could be any number of microservices and if it’s a large scale project there could be hundreds or thousands of them, therefore hard coding them is a cumbersome process.

To deal with that issue, a discovery server is used in this application. A discovery server is a lookup server that holds information about all the services and their instances in a microservice cluster. When a service is deployed and run, it registers with the discovery server using the name specified in the “spring.application.name” property of the service, after which the discovery server assigns a random port to it. Thereafter, when making a rest call to that service, the application name could be used instead of using the hostname and the port. This mechanism reduces the burden of adding fixed values for each service as well as makes scalability easier since once a new instance is created and deployed, it will be registered with the discovery server and will be automatically called upon based on the load to that service. The discovery server used in this application was developed using Netflix’s Eureka.

AUTH Server

Security is a major factor to be considered when developing applications especially in applications that collect user data as well as handle payments online. Several mechanisms can be used to apply security in applications such as, using API gateways, encrypting data etc. Identifying properly who the user using the application is, what he/she can carry out within the application and only allowing them to carry out activities/operations within their scope also allows to secure our applications from data theft and misuse.

The AUTH server used in the system handles the responsibility of authenticating and authorizing the end users of the application. The technologies used to implement them and how the logic/workflow gets executed is mentioned under the security section.

Services

Each microservice in this developed solution handles a specific business functionality/requirement. Each contains its own business logic and a separate database to store data related to that service. Below states the services available in the system and what each of them does/responsible for.

Customer Service: Responsible for storing data and carrying out data manipulation functions with regards to customers. Also works with other services like appointment service to provide aggregated information.

Driver Service: Responsible for storing data and carrying out data manipulation functions with regards to transport providers. Also works with other services like appointment and payment service to provide aggregated information.

Appointment Service: This service stores and manipulates all data regarding appointments and performs communications with other services to provide aggregated information to the end users.

Vehicle Service: Stores and manipulates data related to vehicles under every transportation provider.

Payment Service: This service stores and manipulates data related to payments. Every payment data entry is mapped to a traveler or a transportation provider. Moreover this service communicates with a third party payment provider to facilitate online payments within the developed solution.

Transportation Fee Calculator Service: Responsible for calculating the distance between pick up and drop off locations by passing the location details to a third party service provider and to calculate the travel fare from the data returned back by the external provider in real time.

Communication

Communication from the end user applications to the API gateway and from the gateway to the services and intercommunication within these services are done with REST API calls using HTTP as the underlying transfer protocol. All communications follow a request/response approach embracing HTTP keywords like GET, PUT, POST etc. The data within the requests and responses are transferred in JSON format.

Sample JSON payload received from customer microservice to the end user applications is shown below.

Fault Tolerant Mechanisms

As mentioned earlier, the current trend in the technology industry focuses more on the user experiences, therefore priorities are given to factors like reliability etc. Unlike monolithic applications where a single failure has the potential to bring down the entire system, microservice applications do not face that issue since all functionalities are broken down into smaller services. But, that does not mean that microservice applications are resilient to failure. Microservices by design communicate with other services to fulfill user requirements. During such times, a failure in one service might fail the entire chain of services causing a cascading failure issue resulting in wastage of resources, therefore such failures should be handled properly.

To mitigate such failures, a circuit breaker pattern using Netflix’s Hystrix library was implemented within the services of the developed application that communicated with other services, so that a fallback method gets executed if a service fails. The circuit breaker acts similarly as a circuit breaker that can be found in power supply units. If a failure is detected from a service when a request has been made, the circuit breaker automatically gets opened to ensure no additional requests are made to the particular service. During that time when the breaker is open, it continuously monitors the service to check whether it’s back to normal, and till that the fallback method gets executed for each incoming request. If the service has come back to its normal state, the circuit breaker will be closed and functionalities will take place as usual.

Code implementation of the Hystrix circuit breaker is available below in the code samples section.

Security

As mentioned above in the AUTH Server section, security is a major factor to be considered if that application is handling sensitive data. If an application does not have proper security mechanisms implemented, attackers can use that as an opportunity to hijack into the system and steal valuable data. This matter can lead to several problems like losing end users’ trust, fines and lawsuits from governments etc., therefore having proper security mechanisms should be a must.

This developed application also has some security implementations set in place, such as single access to the system using an API gateway, encryption of critical user data and most importantly end user authentication and authorization. It enables the system to identify who the user actually is, what he/she can do within the application and only allow access to carry out activities within their scopes/roles.

The application uses Spring Security module provided by Spring Cloud and OAuth 2.0 which is a token based authorization protocol used to provide access to protected resources over HTTP, to authenticate users and allow access to resources on microservices based on the user roles.

Security in Web Application

The web application uses Spring security module to authenticate and authorize end users. All web pages in the web application except for common pages like homepage, contact us page etc. have been configured to authenticate users and have been configured to allow access based on roles. So for example when a traveler needs to visit the traveler portal, he or she needs to get signed in first using the AUTH server. That allows the system to identify the person and what authorities and roles he/she has. Once authentication is successfully completed the web application checks whether the authenticated user has a role as a traveler. If yes then that user is granted access to that specified web page/portal and if not, that user is denied access. This allows to prevent misuse of data and privileges since even though the user can be an authenticated user, he/she cannot access all web pages but only pages with the roles matching the user’s role.

Security in Microservices

All microservices in the developed application uses Spring security module along with OAuth 2.0 protocol to only allow users to access microservice endpoints based on specific roles. OAuth 2.0 uses a token based approach to validate the identity and identify the role of a user. When a request is made from the client application along with the access token(received when signing in to the client application) to a rest endpoint in a microservice, the microservice verifies the token with the AUTH server and identifies the role of the user who made the request. If that role matches with the roles specified for the endpoint, the rest call is accepted and the requested resources will be sent. And if the roles does not match with the ones in the endpoint, access to that request will be denied. This mechanism ensures that operations like fetch, add, delete etc. cannot be done by every authenticated user but only by the users who has the authority to do that. The diagram below illustrates how the complete OAuth 2.0 work flow happens.

The developed solution has also enabled OAuth 2.0 Single Sign-On therefore once the user is authenticated in the web application and receives an access token, the user can use that token for every microservice request without having to request access tokens from AUTH server for each request.

Used Technology Stack

This section describes the technologies that have been used to develop the application, what are the advantages of using each and why it is the best fit for this solution.

Spring Boot

Spring boot is an open source project that is built on top of the Spring framework to provide the rapid application development feature to Spring. It is maintained by a company called Pivotal. Spring boot can be used to create production-grade standalone and web based applications that can be run easily simply by doing minimal configurations.

All microservices within the solution and the web application was developed using Spring boot. Usage of Java which is a popular object oriented language as the development language for Spring boot, ability to easily deploy to containerization platforms like Docker, having wide community support as well as having a reputed history as a good choice for developing REST API based applications were factors contributed into selecting Spring Boot.

Apart from that, using Spring boot also provides advantages mentioned below;

• Increases the productivity of the development team as it focuses on convention over configuration. There is no need to write xml configurations and many boilerplate code, rather developers can focus on the business logic.
• Can test web applications easily without the need to deploy WAR files as Spring boot comes with different embedded HTTP servers like Tomcat, Jetty etc.
• Comes with production ready features like health checks, auditing, metrics, externalized configurations etc. therefore could easily monitor and manage the applications in production environment.

MySQL

Each service in this microservice application except for transport fee calculator service has its own database to manipulate and store data related to that service. The developed solution uses MySQL to facilitate data storage and manipulation functionalities. MySQL is a popular open source relational database management system supported by a Swedish company called MySQL AB.

Features and qualities like ease of use, inclusion of a data security layer to protect sensitive data, support for multi-threading and compatibility to run in most of the operating systems in the market nowadays such as Windows, Linux and many varieties of UNIX are some advantages of using MySQL.

Thymeleaf

Thymeleaf is an open-source Java based server-side template engine for both standalone and web environments. It applies a set of transformations to template files using XML tags and attributes to display data received or produced by the backend of the application.

It was used within the developed Spring Boot based web application to display data received from the microservices in the solution as well as to retrieve user information entered to the web application through forms.

Bootstrap

Bootstrap is a powerful and popular open source front end framework used to make web development faster and easier. It gives the ability to create flexible and mobile friendly web layouts without much effort due to its unique column based grid system that automatically rearranges layout components based on the screen size. It also provides HTML and CSS based templates for common components in web sites like headers/footers, navigation bars, forms, buttons etc. which could be easily added to the layout.

Bootstrap was added to the front end of the developed web application to enhance the user experience by making it mobile friendly for end users accessing the web application through mobile devices.

Code Samples

This section shows several code snippets of how some key components/ functionalities of the developed microservice application were implemented.

API Gateway

This code includes the logic to route all incoming requests from end user applications to the appropriate microservices.

Circuit breaker

Below is the code used to implement Hystrix Circuit breaker within microservices in-order to protect from problems that arises due to service un-availabilities.

Discovery Server

Code and annotations used to implement Netflix’s Eureka discovery server.

Example code used to make microservices register as clients on the discovery server at service start-up.

Example REST call handling in a microservice

Sample code showing how a GET request API call is handled in controller and service layers of a microservice.

Conclusion

As mentioned in the introduction, the use of technology has enabled people to build solutions for almost all problems faced in their day to day lives. This article also discussed one such problem faced by travelers and a technological approach used to resolve that. As the next step, intend to enhance the developed system in the future by including new functionalities which will make the solution more productive and efficient, mitigating identified issues as well as by improving user experience.