In the area of distributed programming there are several established approaches for solving the problem of communication between separate programs.
Within the wide range of solutions, from low-level socket operations to high-level and domain-specific information exchange systems, two "middle-level" approaches are particularly interesting as they hide implementation details at the same time offering a generic interface that can be deployed in a variety of application domains. These two solutions are RPC-oriented communication and messaging.
This article tries to highlight the essential difference between these two communication approaches.
RPC, which stands for Remote Procedure Calls, is a concept that tries to generalize a regular procedure invocation to a case where caller and receiver do not reside in the same process - and are potentially distributed across separate machines.
The essential goal of this approach is to make remote invocation as similar as possible to regular procedure calls and to hide the details of the physical connection.
This goal is very compelling in that it potentially allows to turn the distribution of the final system into a deployment-time decision - in other words, that from the programmer's perspective it does not matter whether the call is local or remote as long as it syntactically looks the same, and the final decision about the distribution of individual system components can be made later. Removing the distribution aspect from the code can be very beneficial for the project if at its early stages the final details of its deployment are not fully known.
The potential benefits of RPC have their costs, however, and they mainly come from the fact that the syntax of regular calls leaves no place for the information that might be usefully used if the system is actually distributed. Regular procedure calls, as known from mainstream programming languages, provide only a simplified notion of the call that assumes several "facts":
The problem with RPC is that by hiding the fact of distribution at the syntax level, it makes it more difficult for the programmer to properly address the inherent challenges that come with the physical aspects of distribution.
Messaging as a communication concept is very much different from RPC in that it does not attempt to hide the physical aspects of communication. It is still trying to hide the implementation details, but not to the point of dismissing the notions related to run-time costs of exchanging data.
Messaging as a communication concept can be easily explained due to its similarities to the e-mail system. The most important of these similarities is the fact that messages are recognized as first-class entities, and that users think of each message as something tangible that is acted upon. The focus here is not on hiding, where the communication and its challenges are not visible at all - but rather on encapsulation, where the fact of communication is exposed in a form that the user can interact with. In the e-mail analogy, a message is something that is not only transmitted, but something that can be also backed-up or printed.
Following is a non-exhaustive list of opportunities that can be, depending on implementation, exposed as regular functional features of a messaging system:
The above list of possible features shows that what is considered to be a deployment detail in the RPC approach, is turned into a wide range of functional opportunities in the messaging approach.
It is still possible to use messaging as a distributed implementation of the "call" and in fact object-oriented methodology uses the term "message" to refer to requests that can be sent between objects. The advantage of messaging, however, is that by exposing the fact of communication in a tangible form of the message as a first-class entity, the programmer gains the opportunities for expansion into the functional areas that are either uncomfortable within the constraints of a "procedure call mindset" or just not possible at all.
Did you find this article interesting? Share it!