Multi-tier (8-Layer) Architecture for Enterprise Solutions

Today, I’d like to write about multi-tier architecture as the best option for enterprise software products. Before delving into detail, I’ll look at software architectures with different numbers of tiers. I will then describe the best technologies for each layer.

N-Tier Architectures

Depending on a software product’s goals and complexity, it may have from one to any number of layers. In addition to being divided into layers (logically), the product may also be divided into tiers (physically).

One-tier architecture, where all software components are kept in one place.

Such software can be run on a single computer, and is the simplest and most direct option. All components are included in one application. If data needs to be changed, this can only be done using the computer on which the software is installed. One-tier architecture is not sufficient for web applications or cloud solutions.

Two-tier architecture includes two layers: a presentation layer and a data layer. The former runs on the client side, while the latter stores data on a server.

This approach improves scalability and divides the user interface from the data layer. Most of the processing occurs either on the client side or on a server. In the context of an increasing number of users, the performance of this software architecture may be poor.

Three-tier architecture is the most popular option. It provides the following independent layers:

• A presentation layer, which displays information and communicates with other layers.
• An application layer, which contains business logic and controls application functionality performing processing.
• A data layer, which stores and retrieves information. Data in this tier is kept independent of application servers or business logic.

This division allows each layer to be developed, tested, executed and reused individually. The application layer can also be multi-tiered itself. In this case, the general architecture is called N-tier architecture.

Multi-tier architecture has many advantages, such as:

• Scalability — any layer can be scaled separately from others.
• Flexibility — any layer can be changed according to new requirements without affecting other layers.
• Security — each layer can be secured independently and in an individual way.
• Management — each layer can be managed individually and maintained in isolation.

Example of an 8-Layer Application

The following image shows an example of an application with 8 layers. Those layers can be distributed across servers (tiers) based on specific needs:

The Client Application Layer is a front-end layer that enables interaction with customers using Web, Mobile, and Desktop applications.

The Client API Layer includes specific APIs (Application Program Interface) that are used for interacting with client applications.

The Third-Party Systems API Layer includes public APIs for integration with third-party systems.

The Service/Business Logic Layer is responsible for processing business data (such as algorithms).

The Data Distribution Layer ensures that data is distributed to cluster and is available for all nodes so that each node can work effectively. Distributed data grid is an example of this.

The Data Transformation Layer abstracts API entities from database entities. This layer makes it possible to keep the database model stable when the API requires changes.

The Persistence Logic Layer uses persistence ORM (Object-Relational Mapping) and saves data, retrieves data, etc. This layer contains database interaction logic.

The Database Storage Layer plays a data-storage role.

Each of these layers may be executed in a distributed environment, and this can be a one- to N-tier application.

When developing an enterprise software product using the Smart Engine approach, we prefer to use three- or four-tier architectures. Typical four-tier solutions are described below.

Typical Solutions for Multi-Tier Architecture

Here, I will describe some technological solutions we often use. As you know, each tier can be developed using particular technologies. This is why I want to show the best solutions for each tier separately.

Presentation tier

The presentation tier can be presented using desktop, web or mobile applications. With respect to web applications, we prefer the following technologies: JavaScript with Jquery, and AngularJS.

Mobile applications can be created using Cordova, ReactJS, or Native App. Choosing the best technology depends on specific project needs. Cordova allows for quick development of a simple application with few pages. However, if a full-featured mobile application is required, Native App with direct access to Native SDK can be the best choice.

Integration/API tier

You may need APIs to interact with a business layer or third-party objects. In this case, you can use SOAP or REST techniques. Which one you use depends on the third-party object’s specification and on the particular project requirements.

SOAP is language, platform, and transport independent. It works well in distributed enterprise environments. On the other hand, REST is more efficient, faster, and closer to other web technologies in design philosophy.

Application tier

The application tier contains business logic, which can consist of one or more modules. Technologies we recommend for use in this tier are as follows: Java EE 7 and Java SE 8, Spring Framework, and JPA/Hibernate ORM.

Depending on project requirements, the application tier can be separated into several tiers. This step may increase the application scalability and maintainability. Clustering is also possible.

Data tier

The data tier can consist of additional sub-tiers. For example, a typical ETL (Extract, Transform and Load) process includes extraction, transformation, and storage layers; each of the layers may be executed in a separate tier.

Depending on project requirements, SQL or NoSQL databases can be used. A hybrid SQL+NoSQL approach is also possible. Our recommendations are as follows:

• SQL databases: PostgreSQL, MySQL, Oracle. Each of these has its own pros and cons.
• NoSQL databases: Choosing a NoSQL database depends on the data model that is most relevant for a particular project. We prefer working with MongoDB, Couchbase (document-oriented), and Neo4j (graph-oriented) databases.

Depending on the project specifics, you may consider using Amazon Web Services. This enables you to save money on infrastructure and maintaining the hardware. In addition, the autoscaling feature increases and decreases capacity according to demands, and in this way reduces costs.

Business Logic Tier

Now I would like to focus on the application layer, which is also called the business logic tier. The best approach with respect to this layer is to use service-oriented architecture (SOA). In this case, the business logic is implemented as a set of services; each service is a separate application.

Since each service is independent, they may each be used for individual goals. The services may be divided into the following groups:

• Algorithms for calculations and predictions;
• Preparing and processing data for the algorithms;
• Processing output and reporting.

The SOA approach enables every specific component in the business logic architecture to be clustered. Clustering provides fault tolerance. Each service can be a cluster of servers, and enabling the autoscaling feature in Amazon Cloud allows the software product to withstand load spikes.

Conclusion

We  believe that building the architectures and using the technologies described above equate to the best way to develop an Enterprise Software Product. When working on a project, our Smart Team always suggests the most relevant technologies for the suitable architecture.