By the end of the lesson, you can explain why a remote call differs from a local one, name the four possible outcomes of a call, and interpret partial failure.
Why is it needed?
In the syntax of the code a remote call can look like a function call, yet it is fundamentally different. The fallacies of distributed computing summarise well what tends to be forgotten: according to the "eight fallacies" (Peter Deutsch and James Gosling, Sun), it is wrongly assumed that the network is reliable, latency is zero, bandwidth is infinite, the network is secure, the topology does not change, there is one administrator, transport cost is zero, and the network is homogeneous.
What changes?
In a local call the caller and the callee work in the memory of the same process. In a remote call the request and the response travel as messages, so:
the data must be serialised (turned into a message) and converted back on the other side;
a local object reference cannot be sent; only the agreed representation;
the call takes time, and the time varies;
the callee may be unreachable, slow or faulty while the caller keeps running.
sequenceDiagram
participant A as Caller
participant N as Network
participant B as Callee
A->>A: Serialisation
A->>N: Request
N->>B: Request
B->>B: Processing
B-->>N: Response
N-->>A: Response
A->>A: Handling the result
The four outcomes of a call
For the caller four outcomes are possible: success, business rejection (for example "not enough stock"), technical failure, and unknown outcome. The first three can be handled; the fourth is the most dangerous. A technical failure and a business rejection call for different actions: a rejection is not fixed by automatically repeating the request.
An unknown outcome arises when the server executed a modification but the response was lost. A timeout only shows that the caller's time limit expired; it does not prove that the operation was not carried out. That is why repeating a modifying operation is safe only if the operation can be identified or queried (6.5).
Partial failure
In a distributed system one part may work while another is unreachable. The fault can be the network, an intermediate component, or just one service instance. A slow response and an outage can look the same to the caller for a long time. Handling failure of remote calls is therefore part of the design, not a later addition. The Fowler–Lewis article also puts it this way: applications must be designed to tolerate the failure of services, and the client must react to it as smoothly as possible.
Identifiers for diagnostics
Three different identifiers are useful: an operation identifier for the safety of repetition, a trace identifier for observing the call chain, and a request/message identifier for pairing the response. The three are not the same; a retry can create several network attempts for the same business operation.
Common misconceptions
Statement
Clarification
"A remote call is just a slower local call."
New classes of failure (partial failure, unknown outcome) also appear.
"A timeout means the operation did not happen."
Only that the response did not arrive within the time limit.
"The network is reliable."
The first of the eight fallacies.
"A business rejection and a technical failure can be handled the same way."
Repeating the one is pointless, the other may be worthwhile.
In short
A remote call is a message: it must be serialised, and its time and outcome are not under the caller's control.
Four outcomes: success, business rejection, technical failure, unknown outcome.
A timeout does not prove that the operation was not carried out.
Partial failure is natural; failure handling is part of the design.
Review questions
Why can a remote modification succeed despite a timeout?
What is the difference between a business rejection and a technical failure?
What are the operation identifier, the trace identifier and the message identifier for?
A Remote Call Is Not a Local Function Call
Objectives
By the end of the lesson, you can explain why a remote call differs from a local one, name the four possible outcomes of a call, and interpret partial failure.
Why is it needed?
In the syntax of the code a remote call can look like a function call, yet it is fundamentally different. The fallacies of distributed computing summarise well what tends to be forgotten: according to the "eight fallacies" (Peter Deutsch and James Gosling, Sun), it is wrongly assumed that the network is reliable, latency is zero, bandwidth is infinite, the network is secure, the topology does not change, there is one administrator, transport cost is zero, and the network is homogeneous.
What changes?
In a local call the caller and the callee work in the memory of the same process. In a remote call the request and the response travel as messages, so:
The four outcomes of a call
For the caller four outcomes are possible: success, business rejection (for example "not enough stock"), technical failure, and unknown outcome. The first three can be handled; the fourth is the most dangerous. A technical failure and a business rejection call for different actions: a rejection is not fixed by automatically repeating the request.
An unknown outcome arises when the server executed a modification but the response was lost. A timeout only shows that the caller's time limit expired; it does not prove that the operation was not carried out. That is why repeating a modifying operation is safe only if the operation can be identified or queried (6.5).
Partial failure
In a distributed system one part may work while another is unreachable. The fault can be the network, an intermediate component, or just one service instance. A slow response and an outage can look the same to the caller for a long time. Handling failure of remote calls is therefore part of the design, not a later addition. The Fowler–Lewis article also puts it this way: applications must be designed to tolerate the failure of services, and the client must react to it as smoothly as possible.
Identifiers for diagnostics
Three different identifiers are useful: an operation identifier for the safety of repetition, a trace identifier for observing the call chain, and a request/message identifier for pairing the response. The three are not the same; a retry can create several network attempts for the same business operation.
Common misconceptions
In short
Review questions
Learning resources