Architectures for Distributed Systems

Hello guys, how are you? Today I will write about architectures for Distributed Systems.

An important distinction who we need to do about concepts is what are system architecture and software architecture.

A system architecture is about how the components of a distributed system are placed across multiple machines. It focuses on the entire system. An example would be a e-commerce system containing a web front-end, a service layer, and a database.

About the software architecture, it tells us about the logical organization of software components, that is, how they interact between them, your structures, how they can be independent of them, and so on. Focuses about components. It is at a lower level than the system architecture. Software architecture is a type of system architecture. Example: A component of a e-commerce system is the web front end.

System architectures

We have two main systems architectures that we use today: client-server and Peer-to-peer (P2P).

The client-server architecture has two main components: the client and the server. The server is where all the necessary processing takes place, while at the client it is where the user can access the services provided by the server. Usually, there is only one server that is on the remote side, but for security we use multiple servers, which will use load balancing techniques (I will write about it in another article). This architecture has advantages such as being easier to build and maintain, in addition to better security. On the other hand, it has disadvantages such as a single point of failure and less scalability. A client-server architecture reflects the traditional way of modularizing software, which is one module invoking functions in another module. Placing different software components on different machines leads to a natural physical distribution of functions over a collection of machines.

In the Peer to Peer (P2P) architecture, a node can request a service or provide it. The main idea of this architecture is that there is no central control in the distributed system. Each node can be a client or server at a certain time, depending on its action. Each node is generally known as a peer.

Architectural styles in Software Architecture

Now let’s talk about the logical organization of distributed systems in software components, that is, software architecture.

A common keyword in literature when we talk about distributed architectures is architectural style. An architectural style is formulated in terms of components, it is the way in which these components are connected together and how data is exchanged between the components. Components are modular units with well-defined interfaces. In addition, they have characteristics of being replaceable and reusable. Connectors are communication links between modules that coordinate between components. Therefore, the idea behind distributed architectures is to have components presented in different ways, where the components can communicate with each other over a network. The use of different configurations of components and connectors leads us to four main architectural styles for distributed systems:

• Layered architecture
• Objects-centered/SOA architecture
• Resource-based architecture
• Events-centered architecture

We can have a combination of these architectural styles. I will tell you a brief idea about each of the styles, since we will cover the main topics in more detail in the next posts.

Layered architectures: the idea in this architecture is simple: components are organized in a layered format where a component in a layer can to do a downcall a lower-layer component, and usually waits for an answer. Only in exceptional cases a component can to do a upcall to a higher level component.

Object-based architectures and service-oriented architectures (SOAs): This architectural style is based on an arrangement of loosely coupled objects, it is less structured. Each object corresponds to what we define as a component. The connector is an RPC (remote procedure call) or RMI (Remote method invocation). Some popular examples are Java RMI, Web Services and REST API Calls. In the case of distributed systems, the calling object does not need to be executed on the same machine as the called object. Object-based architectures are attractive because they provide a natural way to encapsulate data (called the “state” of the object) and the operations that can be performed on that data (which are called “methods” or behavior of the object) in a single entity. The interface provided by an object hides implementation details, meaning that at first we can consider an object completely independent of its environment.

Someone could say that object-based architectures form the foundation of encapsulating services in independent units. Encapsulation is the key word here: the service is seen as a separate entity, although it can make use of other services. Separating services so that they can operate independently leads to service-oriented architectures, often abbreviated as SOAs. In a service-oriented architecture, an application or distributed system is essentially built as a composition of different services.

Resource-based architectures: one of the problems with service composition is that connecting multiple components can easily lead to an integration nightmare. Alternatively, someone can view a distributed system as a large set of features that can be individually managed by components. Resources can be added or removed by applications, and can also be retrieved or modified. This approach has been widely adopted on the Web and is known as REST. RESTful architecture has become popular due to its simplicity.

Publish-subscribe architectures: It is an architecture in which there is a strong separation between processing and coordination. The idea is to view the system as a collection of processes operating autonomously. In this model, “coordination” deals with communication and cooperation between processes. The key feature is that the processes have no explicit reference to each other. Communication takes place describing the events that the subscriber is interested in.

Well, that’s it for today. Leave your comments, suggestions or comments below. I will be back in the next post writing about types of Communication between nodes.

See you there!