This subchapter introduces two implemented e-shop applications, developed by the author of this thesis for the purpose of deeper technical comparison in the chapter 5. The first application is developed as a monolith and the second one using microservices.
4.1.1 Monolithic application example
The first application aims to showcase how an e-shop can be implemented easily and cheaply, while following good standards for extensibility and scalability.
For the implementation of the monolith, defined in chapter 2.3.2, the well-established three-tier architecture was selected for its composition (IBM Cloud Education, 2020). It is composed of 3 tiers:
• Presentation layer – This layer consists on the server side of controllers that map requests into respective methods. Then they either return a name of the page template to use with attached data or in cases of REST requests, they return object payloads.
• Business logic layer – Business layer is represented by a set of façade interfaces that receive calls from controllers of the Presentation layer. It is here where the main processing of the business requirements is done. When an access to the Data layer is needed, the façades call the respective interfaces of the Data layer.
• Data layer – In order to better encapsulate the data access logic, a set of service interfaces manages their respective data domains. Since the data are in this application
retrieved from a database, connections are handled by JPA Repositories (more about database connections and related issues also in the chapter 5).
For a better understanding of the overall processing logic of requests, the following diagram serves for illustration.
Figure 4.1.1 General Request Processing in a monolith, source: author
Description:
1. Request is intercepted by a controller based on the request URL
2. When validation is required for incoming data (depending on the URL and related called method), specific validation tools are then used for data validation.
3. Façade interfaces are then call to proceed with logic using received payloads.
4. Used objects are in this case Data Access Objects.
5. Specific serviced are then called when data manipulation logic is required.
6. Used objects are now Hibernate Entities.
7. Service interfaces then call their persistence services, based on their implementation 8. In our case, JPA Repository interfaces are used.
9. Connection to database is then performed, based on a data source specified.
4.1.2 Microservice application example
The second implemented example demonstrates, how the functions of an e-shop could be handled by separate collaborating services using the MSA approach described in chapter 2.3.2. The requests attempting to access the server pages, are mapped in controller classes of the WebService application. It serves as the main webpage request hub, as it then delegates the processing of request to other responsible services. The splitting of functionalities into services is then further described in chapter 4.2.
Each service has similar composition as the monolithic version of e-shop, as described in the previous chapter 4.1.1. That means it consists of presentation layer, business layer, and data layer. With the difference that the controllers mostly receive only REST requests (except for WebService) and that not all of them have a direct database connection in the Data layer; they rather call other services responsible for the specific data domain. More thorough description of the database implementation can be found in the chapter 4.4. And finally, there is one special component RegisterService whose only purpose is to register all the other services, allowing them to communicate between each other.
For a better illustration, the following diagram showcases how requests are processed in the implemented microservice version of e-shop.
Figure 4.1.2.1 General Request Processing via Microservices, source: authors
Description:
1. Request is intercepted by a controller of a web service. For cases of web page requests, it is always the WebService component.
2. In order to be able to complete their functionality, services need to make calls to other service to delegate their respective part of work.
3. Not all services have direct access to data, they then have to make calls to the services that do.
The following diagram then illustrates how the request processing within a single microservice looks like.
Figure 4.1.2.2 General Request Processing via Microservices, source: author
4.1.3 Two new business cases
For the purpose of illustration how adding new features to existing systems works, here are two new business cases.:
1) New payment method
The first business requirement will simply add a new payment method to be offered to the customer during the payment checkout step. For a real-life illustration, let us say that we will implement the Amazon Pay option.
2) Suggestions of additional products for the customer
In order to further increase the e-shop revenue, the marketing department has decided to create a new feature that will offer additional products to the customer, based on what other customers bought while also buying the same product that customer just put to the basket.
The marketing department also stated that they want this suggestion logic implemented internally, without the use of any third-party service as some other shops do it. The
algorithm might change regularly and there would be a need for runtime change between algorithms during runtime. Another requirement by the marketing department would be API used only by the department itself for feedback purposes.