- Client-Server
- Client
- Server
- Connection Types
- Synchronization
- Interesting Architectural Patterns
- Good Architectural Design Tenets
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.6 Interesting Architectural Patterns
In the following sections, we describe some of the patterns of small-, medium-, and large-scale mobile application architectures.
3.6.1 Pattern Matrix
If we assume there are four possible client layers, three possible server tiers, and three connectivity types, there are 36 possible combinations in total. This can be represented in tabular form (see Table 3-1).
Table 3-1. Pattern Matrix
|
Client |
Server |
Connectivity |
Comments |
|---|---|---|---|
|
0 |
1 |
Always |
|
|
0 |
1 |
Partial |
|
|
0 |
1 |
Never |
Not Viable |
|
0 |
2 |
Always |
|
|
0 |
2 |
Partial |
|
|
0 |
2 |
Never |
Not Viable |
|
0 |
3 |
Always |
|
|
0 |
3 |
Partial |
|
|
0 |
3 |
Never |
Not Viable |
|
1 |
1 |
Always |
|
|
1 |
1 |
Partial |
|
|
1 |
1 |
Never |
Not Viable |
|
1 |
2 |
Always |
|
|
1 |
2 |
Partial |
|
|
1 |
2 |
Never |
Not Viable |
|
1 |
3 |
Always |
|
|
1 |
3 |
Partial |
|
|
1 |
3 |
Never |
Not Viable |
|
2 |
1 |
Always |
|
|
2 |
1 |
Partial |
|
|
2 |
1 |
Never |
Not Viable |
|
2 |
2 |
Always |
|
|
2 |
2 |
Partial |
|
|
2 |
2 |
Never |
Not Viable |
|
2 |
3 |
Always |
|
|
2 |
3 |
Partial |
|
|
2 |
3 |
Never |
Not Viable |
|
3 |
1 |
Always |
|
|
3 |
1 |
Partial |
|
|
3 |
1 |
Never |
Not Viable |
|
3 |
2 |
Always |
|
|
3 |
2 |
Partial |
|
|
3 |
2 |
Never |
Not Viable |
|
3 |
3 |
Always |
|
|
3 |
3 |
Partial |
|
|
3 |
3 |
Never |
Not Viable |
However, not all of these combinations are particularly useful or viable. For example, if a mobile client device is never connected to a back-end server, this is not a useful architecture in our case. Thus, 12 of the 36 combinations are not viable, leaving just 24 patterns.
Currently, the "partially connected" patterns are probably the most prevalent since connectivity cannot always be guaranteed. In the future, the "always connected" patterns can be expected to be much more prevalent.
3.6.2 Zero-Layer, Three-Tier, Always Connected Architecture
In Figure 3-19, we present a simple mobile architecture. The mobile client has zero application code layers on it, which means it is a thin client. The server holds all the application code and it is organized in a three-tier architecture.
)
Figure 3-19 Zero-layer, three-tier, always connected architecture
The Presentation Tier has application code that is able to render pages to a mobile device such as a Pocket PC. The pages are ordinary web pages (e.g., ASP.NET, JSP, HTML) and are viewable through the use of a web browser such as Microsoft Pocket Internet Explorer.
The Presentation Tier also communicates with business and data access objects on the Application and Database Tiers. Typically, data may be read from the database and written back to it during an update.
This architecture is very simple because the mobile client is assumed to always be connected to the server. Thus, there is no provision for storing application data on the mobile device. If the mobile device becomes disconnected, it will not be able to obtain up-to-date information until the connection is re-established.
3.6.3 Three-Layer, Three-Tier, Partially Connected Architecture
In Figure 3-20, we present a more complex mobile architecture. The mobile client has three application code layers, which means it is a fat client. The server also holds application code and is organized in a three-tier architecture.
)
Figure 3-20 Three layer, three-tier, partially connected architecture
The mobile client has a complete standalone application that is able to read and write user-entered data to a local database during periods when it is not connected to the server. When connectivity has been re-established, the data can be retrieved from the local database and uploaded to the server using a store-and-forward mechanism.