1.1 Client–server architecture
A client–server architecture (Figure 1) divides an application into two parts, ‘client’ and ‘server’. Such an application is implemented on a computer network, which connects the client to the server. The server part of that architecture provides the central functionality: i.e., any number of clients can connect to the server and request that it performs a task. The server accepts these requests, performs the required task and returns any results to the client, as appropriate.
Consider an online bookstore as an example. The application allows a user to search and look at the details of a large range of books, and then to order a book. The application software provides an interface and a means of selecting or finding a book’s details, as well as displaying book information and allowing a book order to be generated.
The application could take the form of a single ‘chunk’ of software downloaded from the web. However, if the software is one monolithic item, then every time anything is changed or updated, the entire application has to be redistributed again. Obviously this would not work well in this example because the catalogue of books will change regularly. An improvement might be to split the application into two parts. One part, the client, can provide the interface for users and be distributed to them. The other part can be kept and run on the company’s own server machine (Figure 1). The client application can display information and be used to pass information to the server for searching, such as the title of a book. This client application, or software, is quite commonly called the ‘presentation’ layer or tier.
In this client–server model, many clients can connect to the server application and request information about books. The server has to process these requests and send the response to the client that originated the request and not to any other client. As long as the network is working well and the server can keep up with responding to all the requests it receives, such a ‘split’ application will provide much the same level of service as the monolithic version. This simple client–server architecture is also commonly called ‘two-tier architecture’.
The catalogue of book information can be held centrally on the server and then be easily updated. This allows other ‘centralised’ information to be maintained and sent to clients, such as the stock level of each book. Users of the client will find it much simpler and smaller to work with than the complete application. At the same time the company will have better control and be able to, for example, monitor usage of the server application itself. A common client used to access applications is a web browser that accesses server applications (such as applications on websites) using HTTP. The use of a web browser as the client end of an application is interesting because, for most applications, the browser is provided by a third party. This means that application builders must rely on agreed standards for the behaviour of the client component.
There are also different distributions of functionality across a two-tier architecture. For instance, suppose you have a client that accesses your bank account online. If that client is a web browser, for example, it can be used to request and display your accounts’ statements from the bank’s server. The information you may obtain is restricted to the pre-defined views of the information provided by the server. So, while the server’s information might include your account balance, if you want to find out the total payments in and out over the last week or year, then you will still have to calculate it yourself, based on the figures the server provides. Alternatively, you might access your bank server over the internet using another, ‘more intelligent’ client, such as a mobile app. This client might include a facility to extract figures from your bank statements and to perform whatever calculations you require. Such a client might also create bar or pie charts that display your income and expenditure across different categories that you define.
The web browser client in the example of the online bank simply displays the information that the server provides. The ‘more intelligent’ mobile app client allows you to take the information the server provides and to manipulate and display it in various ways according to your own personal needs. The web browser with little functionality of its own is often termed a thin client while the more intelligent client is usually termed a thick (or ‘thicker’) client.
We have seen that a two-tier approach seems to have some advantages, at least for applications that operate over networks. The client that is distributed to users may change, while the server part can be a centralised component that maintains dynamic, global data in a consistent and secure way for the organisation and for users to access and use. If a third party component, such as a web browser, provides the functionality required to support the application, then it can be adopted as part of the solution, with a significant saving of development effort. There is a potential disadvantage from splitting the application across a network in that data has to be transmitted over what may be a slow or unreliable connection.
There are other, slightly less obvious advantages in breaking the application into components in this way. We shall look at some of these in more detail shortly, but let’s look at one advantage now. This is an advantage from which you will have benefited if you have ever decided to change your web browser. You might have changed from Internet Explorer to Mozilla Firefox, for example, just as a personal preference. When you did this you changed the client component of all the online applications you use. This is only possible because web browsers are based largely on common standards and because they are not realised as an intrinsic or built-in part of any of the applications you use; in other words, the client is loosely coupled to the server application.