Opening the book…
In distributed computing, a distributed object system allows programs on different machines (or in different processes) to interact as if they were invoking methods on local objects. This model encapsulates service implementation behind well-defined interfaces, isolating clients from how and where the service is actually executed. In other words, a client invokes methods on a remote object, and the underlying infrastructure handles network communication, data marshaling, and result delivery. This approach differs from the basic client-server model by making remote interactions appear object-oriented and transparent to the programmer. Distributed object middleware essentially acts as a “software bus” – a communication framework enabling objects in different environments (different languages, operating systems, or hardware) to find each other and exchange data.
Early distributed object systems emerged to simplify building distributed applications. Instead of manually handling sockets and custom protocols, developers could use an object proxy or stub to call remote methods. Pioneering examples of this paradigm include Remote Procedure Call (RPC) mechanisms, Java’s Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), and Microsoft’s Distributed Component Object Model (DCOM). Each system has unique features and limitations, but all share the goal of abstracting away networking details behind object-like method calls. Below, we define and distinguish some of these key distributed object technologies [1].
This page titled 7.1: Distributed Objects in Distributed Computing was last modified on Sat, 12 Sep 2026 08:40:23 GMT and is shared under a CC BY 4.0 license and was authored, remixed, and/or curated by Felix Amoruwa.
The book could not be loaded just now.