Thus, message passing may subsume both local and remote invocation (whether sender and receiver are on the same or distinct processors is transparent to the programmer) as well as possible inaccessibility of an object/service.
In the Electra [Maffeis 1995] distributed system, the concept of remote invocation has been extended in the following fashion.
A type of proxy, called an interface object, is used to trap the normal-function invocation and replace it by a remote invocation which marshals the parameters, issues a remote procedure call, and unmarshals the results (Figure 3).
The code for an interface object is generated automatically by the preprocessor and includes codes to carry out remote invocation, or to map objects locally.
Although there is no semantic difference between invoking an operation on a remote object and invoking it locally, there is a huge difference in performance: the overhead for a local invocation is a few microseconds, but remote invocation takes several milliseconds (ms).
To ensure that invocation takes place on a particular node, both callee and caller must reside on that node: invoking the operation on a nonresident object will result in a remote invocation, and operations on replicated objects are always invoked at the caller's location, since a replicated object is guaranteed to be always resident.
In-process invocations have little ORB involvement and execute rapidly, while remote invocations typically execute with performance comparable to RPC mechanisms that provide a similar level of service.