Separation of concerns in Distributed Computing (Multi-tier architectures)

In software engineering, a tier is a layer/subsystem in an application stack, isolated in functionality from other layers with a defined purpose. Tiers communicate with the surrounding tiers via a communication protocol.

The TCP/IP Stack

The TCP/IP stack (diagram below) is a good example of the concepts of tiers. The stack consists (from the bottom up) of the physical, data link, network, transport and application layer. The benefit of this is that layers do not have to worry about the tasks performed on the layers below them. The Application layer can safely assume that we have an error free connection from host to host without worrying one bit about sending frames across a 30-year-old copper line All layers below the application layer use error-correction protocols to ensure that all data received is error-free. Data-link handles flow control, while the Network layer handles routing, transport handles transport related flow control and connection establishment (for TCP connections…UDP is connectionless). The application layer concerns the applications running on different ports (e.g. HTTP web servers running on port 80, or FTP servers, database servers, mail servers, SSH servers, et cetera). TCP IP vs ODI

Discussion of Multi-tier Applications

A typical three-tier application consists of data, business logic, presentation and the display tier (shown in diagram below). The idea is similar to the MVC pattern in non-distributed applications where each component (model, view and controller) have very well-defined purposes and deal with different parts of the applications logic. It’s neat. There are a number of great advantages to splitting web applications into different tiers. The most obvious one is separation of concerns and that we achieve low coupling and high cohesion. Another benefit is that multi-tier architectures are easier to secure against malicious attacks because implementing security measures on a per-layer level is rather simple. The isolation from other layers makes multi-tier applications easier to test, maintain, secure and understand. They also benefit from higher efficiency and better data scalability. It is a good idea to run each tier of the application on a different physical machine to aid in load balancing. Other load balancing features include increasing the number of servers available to host each tier. For example, an application might have different database servers that certain users must be able to access. The data controller server acts as a router that directs requests to the correct database. (We will talk about another example later).

Advantages of Multi-tier Applications

  • Practises Separation of Concerns
  • Low coupling and high cohesion
  • easy to maintain, test and understand because of separation of concerns.
  • easy to secure against threats on different layers
  • higher efficiency
  • better data scalability

Multi-Tier architecture with multiple display client types and multiple databases The following sections refer to the diagram above.

Data Tier

The data tier is responsible for managing communications with the database such as recording transactions or modifying records. Having a separate tier for these operations means that all other tiers must go through the data tier to interact with the database via a given protocol. This ensures that people can not mess with the database or perform operations that corrupt data. One disadvantage of having a separate data tier is that attackers can scan data sent over the network. This is not possible if database and business tier run on the same physical server hardware.

Business Logic Tier

The business logic tier handles all business specific processing and validation. A company’s competitive offering is their customer data and manipulation of data. Good companies have business logic that is reliable, accurate, fast and flexible. The better a company’s implementation of business logic is, the more competitive they service is and the more successful they become. The business logic tier captures this business specific data processing. Advantages of this tier is that higher load can be distributed across multiple business logic servers. Each server could, for example, service different presentation front-end such as browsers, mobile apps, Windows and Mac GUI clients (if you chose to distribute the load based on client platform). Like with the Data tier, the disadvantages to a separate business tier are security issues if appropriate security measures have not been implemented. Data that is sent across a network (in most cases a local area network) can be intercepted. If the business logic layer is simple and requests are simply passed through to the data tier, then the additional overhead is not worth the effort of implementation as there is no business logic.

Presentation Tier

The presentation tier is concerned with user input and output. Unfortunately, the diagram does not illustrate the fact that there are hundreds (or millions) of clients connected to the Presentation tier. Millions of users may be accessing Google Earth via a Mac client, whilst another million users access it through their web browser. The presentation tier prepares data and converts it to a format readable by different types of clients. Browsers, for example, require HTML files with embedded JavaScript to enable users to use the application. Mobile apps require a JSON or XML API that can be queried in order to interact with the application. Windows and Mac GUI clients may interact directly with the business logic as the presentation tier is integrated into the GUI client (more on that on in the next section).

Display Tier

The display tier, in most cases, is a web browser running on the clients computer. It is not a “real” tier because there is no application-specific processing here. It is just the browser that allows users to view and interact with the application. Most distributed applications have hundreds, if not millions of display tiers. GUI applications like Google Earth have millions of clients running the application on their machine and accessing the data on Google’s servers. GUI clients designed to integrate with a particular multi-tier application often combine the presentation and display tier for performance benefits, such as client-side validations. Invalid input should not be sent to the business tier only to be rejected. To slow!!! Instead, validate in display tier using JavaScript

It is much faster to validate user input on the user’s machine (using a few lines of code) rather than sending non-validated input to the business logic tier only to receive a response one or thirteen seconds later that rejects the input with an error. This is why applications like Google Earth combine the display and presentation tier on the user’s local machine to remove the overhead of sending invalid input to the business tier for validation. The same thing happens on website with JavaScript client-side applications

Distributed Computing within Tiers

It is possible to split tiers into multiple sub-tiers. We can do this by separating sub-components of the tier and running them in parallel. Distributing the business tier allows for parallel computing - to split one job amongst many servers. Load balancing is therefore a very important benefit to separating concerns into tiers. Clients initially connect to one controller server which assigns clients to the least-utilised business tier server. (Imagine a request coming in from one of the client computers on the left and being directed to the least utilised business logic server.) Distributed Tier

Another advantage is fault tolerance. If there are five different business tier servers running at the same time then the effect of a hardware fault in one of the five servers is much smaller than if we relied on a single machine. We could also have a backup server that replaces a dying machine on the fly to help keep the load balanced as to not overwhelm the other four servers. This same principle applies to the data and presentation tiers. The overhead of this principle is its high complexity and configuration overheads. Another way to balance the load is to have clients send a request to the business controller asking which business server to connect to. Once the client receives a reply they connect directly to that business server. This reduces the bottleneck of having one controller server, which is a serious issue in some architectures, like Curtin’s OASIS set up.

In summary, multi-tier application use different layers that have well-defined purposes and which can only communicate with the layers above and below them. The main advantage of splitting up applications into tiers is to increase cohesion and reduce coupling. Multi-tier applications are easy to test, secure and understand because of their well designed structure. In addition, it is possible to user multiple physical servers per tier to balance the load and run computationally expensive tasks in parallel.