RPC, Messaging, REST: Terminology

The purpose of this article is to discuss terminology. The article is not about how and why, but only about the use of terminology. The article reflects the opinion of the author and does not claim to be scientific.





')

Introduction

If you work in the field of programming of distributed systems or in the integration of systems , then most of what is stated here is not new to you.



The problem arises when there are people using different technologies, and when these people begin technical conversations. At the same time, mutual misunderstanding often arises due to terminology. Here I will try to bring together the terminology used in different contexts.

Terminology

There is no clear terminology and classification in this area. The terminology used below is a reflection of the model established by the author, that is, it is strictly subjective. Any criticism and any discussions are welcome.



I divided the terminology into three areas: RPC (Remote Procedure Call), Messaging and REST. These areas have historical roots.

RPC

RPC technologies are the oldest technologies. The most prominent representatives of the RPC, it is - CORBA and DCOM .



At that time, it was generally necessary to connect systems in fast and relatively reliable local networks. The main idea of ​​RPC was to make the remote system call very similar to the function call inside the program. All the mechanics of remote calls was hidden from the programmer. At least they tried to hide her. Programmers in many cases were forced to work at a deeper level, where the terms marshalling and unmarshalling (as in Russian?) Appeared , which in fact meant serialization. Normal function calls within processes were handled by the caller in the proxy , and on the side of the system performing the function in the Dispatcher . Ideally, neither the calling system nor the processing system was concerned with the intricacies of data transfer between systems. All these subtleties were concentrated in the Proxy - Dispatcher bundle, the code of which was generated automatically.



Therefore, you will not notice, should not notice, no difference between calling a local function and calling a remote function.

Now there is a kind of renaissance RPC, the most prominent representatives of which are: Google ProtoBuf, Thrift, Avro.

Messaging

Over time, it turned out that an attempt to protect the programmer from the fact that the function being called was still different from the local one did not lead to the desired result. The implementation details and fundamental differences of distributed systems were too great to be solved with the help of automatically generated proxy code. Gradually, it was understood that the fact that the systems are connected by an unreliable, slow, low-speed environment should be clearly reflected in the program code.



Appeared technology web services . We started talking ABC: Address, Binding, Contract . It is not entirely clear why contracts appeared, which in essence are the Envelope (envelopes) for the input arguments. Contracts often complicate the entire model, rather than simplify it. But ... never mind.



Now the programmer explicitly created a service ( Service ) or a client ( Client ) calling the service. The service was a set of operations ( Operation ), each of which received a request at the entrance ( Request ) and issued a response ( Response ). The client explicitly sent ( Sent ) the request, the service explicitly received ( Receive ) it and answered (Sent), sending the response. The client received a (Receive) response and the call was completed.



Just like in RPC, Proxy and Dispatcher worked here somewhere. And as before, their code was automatically generated and the programmer did not need to understand it. Unless just that, the client explicitly used classes from Proxy.



Requests and responses are explicitly converted to a format intended for transmission over wires. Most often it is an array of bytes. The conversion is called Serialization and Deserialization, and is sometimes hidden in the proxy code.

The culmination of messaging manifested itself in the emergence of the paradigm of ESB (Enterprise Service Bus) . No one really can formulate what it is, but everyone agrees that the data on the ESB are moving in the form of messages.

REST

In a constant struggle with the complexity of the code, programmers took the next step and created REST .



The basic principle of REST is that operations-functions are sharply limited and left only a set of CRUD operations : Create - Read - Update - Delete . In this model, all operations are always applied to some data. CRUD operations are sufficient for most applications. Since REST technologies in most cases imply the use of the HTTP protocol, CRUD commands affected HTTP ( Post - Get - Put - Delete ) commands. It is constantly argued that REST is not necessarily HTTP bound. But in practice, reflection of operations signatures on HTTP command syntax is commonly used. For example, function call



EntityAddress ReadEntityAddress (string param1, string param2)



will be expressed in this form:



GET: entityAddress? Param1 = value1 & param2 = value2

Conclusion

Before starting a discussion on distributed systems or on integration, determine the terminology. If a proxy always means the same thing in different contexts, then, for example, request will mean little in RPC terms, and marshalling will cause confusion when discussing REST technologies.