Client-server Distributed Computing: a summary of Architecture patterns

Distributed systems that are accessed over the Internet are normally organized as client-server systems. In a client-server system, the user interacts with a program running on their local computer (e.g. a web browser or mobile application). This interacts with another program running on a remote computer (e.g. a web server). The remote computer provides services, such as access to web pages, which are available to external clients.

Layers in a client/server system:

• Presentation is concerned with presenting information to the user and managing all user interaction.
• Data handling manages the data that is passed to and from the client. Implement checks on the data, generate web pages, etc.
• Application processing layer is concerned with implementing the logic of the application and so providing the required functionality to end users.
• Database stores data and provides transaction management services, etc.

Common architectural patterns for organizing the architecture of a distributed system:

1-Master-slave architecture

Master-slave architectures are commonly used in real-time systems in which guaranteed interaction response times are required. There may be separate processors associated with data acquisition from the system’s environment, data processing and computation and actuator management. The ‘master’ process is usually responsible for computation, coordination and communications and it controls the ‘slave’ processes. ‘Slave’ processes are dedicated to specific actions, such as the acquisition of data from an array of sensors.

 

2-Two-tier client-server architecture

In a two-tier client-server architecture, the system is implemented as a single logical server plus an indefinite number of clients that use that server.

Thin-client model, where the presentation layer is implemented on the client and all other layers (data management, application processing and database) are implemented on a server. There are very few thin-client applications with all processing carried out on remote server.

Fat-client model, where some or all of the application processing is carried out on the client. Data management and database functions are implemented on the server.

However, the distinction between thin and fat client architectures has become blurred. Javascript allows local processing in a browser so some parts of a ‘fat-client’ functionality can be made available without software installation. Mobile apps carry out some local processing to minimize demands on network. Auto-update of apps reduces management problems.

 

3-Multi-tier client-server architecture

In a multi-tier client-server architecture, the different layers of the system, namely presentation, data management, application processing, and database, are separate processes that may execute on different processors. This avoids problems with scalability and performance if a thin-client two-tier model is chosen, or problems of system management if a fat-client model is used.

Use case: when there is a high volume of transactions to be processed by the server.

 

4-Distributed component architecture

There is no distinction in a distributed component architecture between clients and servers. Each distributable entity is a component that provides services to other components and receives services from other components. Component communication is through a middleware system. Used when resources from different systems and databases need to be combined, or as an implementation model for multi-tier client-server systems. Benefits include:

• It allows the system designer to delay decisions on where and how services should be provided.
• It is a very open system architecture that allows new resources to be added as required.
• The system is flexible and scalable.
• It is possible to reconfigure the system dynamically with objects migrating across the network as required.

Distributed component architectures suffer from two major disadvantages:

• They are more complex to design than client-server systems. Distributed component architectures are difficult for people to visualize and understand.
• Standardized middleware for distributed component systems has never been accepted by the community. Different vendors, such as Microsoft and Sun, have developed different, incompatible middleware.

As a result of these problems, service-oriented architectures are replacing distributed component architectures in many situations.

 

5-Peer-to-peer architecture

Peer to peer (p2p) systems are decentralised systems where computations may be carried out by any node in the network. The overall system is designed to take advantage of the computational power and storage of a large number of networked computers.

Most p2p systems have been personal systems but there is increasing business use of this technology. Used when clients exchange locally stored information and the role of the server is to introduce clients to each other. Examples:

• File sharing systems based on the BitTorrent protocol
• Messaging systems such as Jabber
• Payments systems, e.g. Bitcoin
• Databases, e.g. Freenet is a decentralized database
• Phone systems, e.g. Viber
• Computation systems

P2P architectures are used when

• A system is computationally-intensive and it is possible to separate the processing required into a large number of independent computations.
• A system primarily involves the exchange of information between individual computers on a network and there is no need for this information to be centrally-stored or managed.

Security issues:

• Security concerns are the principal reason why p2p architectures are not widely used.
• The lack of central management means that malicious nodes can be set up to deliver spam and malware to other nodes in the network.
• P2P communications require careful setup to protect local information and if not done correctly, then this is exposed to other peers.