Introduction to Mobile Application Architectures
This chapter is from the book
This chapter is from the book
This chapter is from the book
Where there is no vision, the people perish.
—Proverbs 29:18
In this chapter, we discuss mobile application architectures. We start by describing some of the general concepts and terms behind client-server architectures and follow this by describing clients and servers and the connectivity between them. We then present several interesting architectural patterns and describe why they are useful as general mobile application architecture solutions. Finally, we discuss some of the tenets behind good architectural design and the considerations you need to be aware of when designing mobile applications.
3.1 Client-Server
Application architectures are often modeled to highlight or illustrate the overall layout of the software (e.g., application code and platform) and hardware (e.g., client, server, and network devices). While there are many possible combinations of software and hardware, application architectures often fall into a series of recognizable patterns.
Application architectures are commonly modeled in terms of a client-server architecture wherein one or more client devices requests information from a server device. The server typically responds with the requested information (see Figure 3-1).
)
Figure 3-1 Client-server architecture
We can further consider client-server architectures using layers and tiers and the communication between the layers and tiers. Each of these is described in greater detail in the following sections.
3.1.1 Layers
Application code functionality is not necessarily uniform throughout an application. Certain sections of application code are better suited for handling the user interface, while other sections are developed to manage the business logic or communicate with the database or back-end systems.
Layering describes the division of labor within the application code on a single machine. Layers are often no more than code modules placed in different folders or directories on the client or server.
With client-side code, there are generally zero to three layers of application code. With server-side code, there are generally one to three layers of application code. This is partly a matter of good software design that helps code re-usability, partly a matter of security, and partly a matter of convenience.
A client with zero code layers essentially has no custom application code. This type of client is commonly referred to as a thin client and is possible in client-server architecture if the server holds all the custom application code. A client with one to three layers of application code is commonly referred to as a fat client.
A server can also have one to three layers of custom application code. However, you cannot have zero code layers on a server by definition.
The code layer that interacts most closely with the user is often referred to as the Presentation Layer. The second layer is often referred to as the Business Layer, as it typically handles the business logic of the code. The third layer is often referred to as the Data Access Layer. It typically handles communication with the database or data source (see Figure 3-2).
)
Figure 3-2 Layers
It is possible to have more than three layers on either the client or server but too many layers can become unwieldy and difficult to manage. As a result, this is not frequently encountered.
3.1.2 Tiers
While breaking up application code functionality into layers helps code re-usability, it does not automatically make the architecture scalable. In order to do so, it is important to distribute the code over multiple machines.
Tiers describes the division of labor of application code on multiple machines. Tiering generally involves placing code modules on different machines in a distributed server environment. If the application code is already in layers, this makes tiering a much simpler process.
The code that interacts most closely with the user is often placed in the Presentation Tier. A second tier, which holds the application business logic and data access logic, is often referred to as the Application Tier. The third tier often houses the database or data source itself and is often referred to as the Database Tier (see Figure 3-3). This is an example of a three-tiered architecture.
)
Figure 3-3 Tiers
The servers that make up each tier may differ both in capability and number. For example, in a large-scale distributed web application environment, there may be a large number of inexpensive web servers in the Presentation Tier, a smaller number of application servers in the Application Tier, and two expensive clustered database servers in the Database Tier. The ability to add more servers is often referred to as horizontal scaling or scaling out. The ability to add more powerful servers is often referred to as vertical scaling or scaling up. Tiering the application code in such a fashion greatly facilitates the ability to scale applications.
In large-scale distributed web applications, tiers are often bounded by firewalls. For example, a firewall may be placed in front of the Presentation Tier while a second firewall may be placed in front of the Application Tier. The Presentation Tier is thus sandwiched between firewalls in what is termed the Demilitarized Zone (DMZ), while the Application and Database Tier servers are shielded behind the second firewall in what is termed the Intranet Zone. Tiering therefore also facilitates security and allows large enterprises to shield precious internal systems from traffic originating from untrusted zones such as the Internet and DMZ. Without tiering, it becomes very difficult to secure internal systems.
Tiers generally describe server architectures, and we do not typically count client devices as a tier. While it is possible to do so, this is not a usual convention.