Inspirel banner

Defending Direct Messaging

There are two major messaging paradigms that are widely used in distributed infrastructures: direct, also known as "brokerless", and decoupled, which is based on some central service that is responsible for transmitting messages between involved components.

The direct paradigm is a natural distributed extension of local subprogram call or a method call in object-oriented programming. In this scheme there is a calling or requesting entity, some payload associated with call parameters and the call target, which is either a subprogram or a method. Often, there is also a payload coming back as a response - such a scheme is perfectly appropriate for command-response type of interactions and is presented on the following figure.

The direct interaction approach is very natural for object-oriented systems and can be easily understood without taking into account the distribution aspect - in fact, some of the distributed frameworks work very hard to support the notion of "location transparency" where the user code is not affected by whether the caller and target are two entities in the same process or maybe in distinct processes in the distributed system.

There are many protocols that are based on this interaction paradigm - and the fact that many of them were built to reflect some client-server relationship (or request-response processing) shows that there is a design continuity that leads from local calls to this form of messaging.

The following are examples of distributed frameworks that are based on the direct interaction paradigm:

In all these examples the most important common property is that both communicating entities need to be involved at the same time and for the time of the interaction they are coupled - usually this coupling is reflected in the session-based connection mechanism, but is also visible in the fact that the communicating entities need to know each other's locations.

Even though the direct approach is very natural for command-response (or client-server) interactions, it might not be the most effective or even appropriate for systems where the data flows in only one direction. Popular examples of such installations are broadcasting systems, like TV and radio stations. Thanks to the fact that data flows only from producers to consumers it is possible to decouple them in the sense that producers can be independent from who and when is listening, as shown on the following diagram:

The broadcast approach is technically possible only if there is a medium that allows this kind of communication. Electromagnetic waves are appropriate for TV and radio stations. Sound waves are appropriate for public announcements in shopping centers or trains stations. Wall-mounted boards are appropriate for local notifications in the office.

The problem is that there is no easily accessible analogy in the computer networking world, since multicasting is usually forbidden across network segments due to its destructive potential.

In order to overcome the lack of proper broadcasting medium a new entity can be introduced with the purpose of relaying messages between all participants and thus playing the role of the missing medium. Such an entity is called a broker, a message service or a message bus and its role is shown on the following diagram:

There are many existing solutions based on this idea, with CORBA Event Service, Java Message Service (JMS), some implementations of Data Distribution Service (DDS) and AMQP being among the most well known.

This approach has the following advantages:

These advantages were recently appreciated by the distributed systems community, which has led to the higher popularity of such solutions and the common perception that this is the step forward in the evolution of distributed systems with the promise to solve all the problems of direct communication.

Still, notwithstanding the advantages, the above diagram clearly shows that the broker-based communication raises some important questions:

In addition to these concerns, the indirect architecture cannot really solve all the problems of direct approach, simply because instead of offering a complete replacement strategy, the indirect interaction is built in terms of direct connections between the message service and the participating components. This means that the potential problems - like the coupling between components - are not really solved, they are barely moved to some other part of the system. In practical terms, the problems of service location, session retention and flow control between participants are replaced by exactly the same kind of problems, but between participants and the broker.

What does it all mean to the software engineer that plans the architecture for new distributed systems? Which of the two approaches is the right one?

The point is, neither one is the most appropriate as a general answer - but it can be argued that the direct approach is more fundamental, as it can be used either alone, or as a building block for the broker-based solution. In other words, it is always possible to build a broker-based system with a solution that handles direct interactions, but it might not be easy to recover the advantages of direct approach if the given middleware solution targets only broker-based architectures.

This is exactly the reason why it is worthwhile to invest in direct messaging solutions. Even though they might look like things of the past, they are still defending themselves as foundation building blocks for modern architectures and as such certainly have their place in the world of distributed systems.