2.14. Remote Procedure Call

Assume an architecture where a server performs functions as requested by a client, and where messages are used for communication. The communication will follow a simple pattern where the client constructs a message describing what function it wants performed and sends it to the server, who parses the message and performs the function as requested. If a result is to be returned, the server then constructs a message describing what result it returns and sends it to the client, who parses the message and uses the result.

If a messaging interface were used to implement this pattern, constructing and parsing the messages would be a responsibility of the application, with middleware only taking care of sending and receiving the messages. A middleware with a remote procedure call interface takes advantage of the fact that the format of the messages is entirely determined by the signatures of the functions to be performed. This makes it possible to delegate the responsibility of constructing and parsing the messages to the middleware, provided that the middleware knows the signatures.

For sake of simplicity and elegance, the interface between the application and the middleware is made to match the signature of the functions to be performed. The implementation of the interface inside the middleware, called stub, does the necessary constructing and parsing of the messages, termed marshaling and unmarshaling.

To be done.

The idea of masking remote communication behind an automatically generated facade of a procedure call has also been extended to support objects. Client proxies and server servants.