The simplest (and earliest) distributed systems were composed of objects interacting with each other using Remote Procedure Calls (RPCs) or Remote Method Invocations (RMIs):

The architecture consisted of three layers on each machine:

• The stub/skeleton layer: These were stubs or proxies for clients and skeletons for servers. A stub is a client-held reference to a remote object and it implements the exact interface of the remote object. The stub forwards requests to the actual object on the server and the remote reference layer.
• The remote reference layer: Responsible for carrying out the semantics of the invocation. It delegates communication specifics to the transport layer.
• The transport layer: Responsible for connection management and remote object-tracking.

There were two main ecosystems for this type or architecture:

• Common Object Request Broker Architecture (CORBA): Defined by a group called Object Management Group (OMG), which was the RPC framework in the Java world
• Distributed Component Object Model (DCOM): Sponsored by Microsoft

In Go, stdlib has an rpc package that allows us to export any object method through remote procedure calls.

For example, imagine you have the following Multiply service:

type Args struct {
 A, B int
}

type MuliplyService struct{}

func (t *Arith) Do(args *Args, reply *int) error {
 *reply = args.A * args.B
 return nil
}

Then, you can enable it for remote invocation using the rpc package, like so:

func main() {
    service := new(MuliplyService)
    rpc.Register(MuliplyService)
    rpc.HandleHTTP()
    l, err := net.Listen("tcp", ":1234")
    if err != nil {
        log.Fatal("listen error:", err)
    }

    go http.Serve(l, nil)
}

The clients who want to make RPC calls can connect to this server and issue requests like so:

client, err := rpc.DialHTTP(
     "tcp", 
     serverAddress + ":1234")
if err != nil {
     log.Fatal("dialing:", err)
}

// synchronous rpc
args := &server.Args{3,4}
var reply int
client.Call("Multiply.Do", args, &reply)
fmt.Printf(" %d*%d=%d", args.A, args.B, reply)

This style of architecture has lost popularity in recent years due to the following reasons:

• It tries to add a wrapper for remote objects and fakes a local reference to a remote object. But as we saw from the eight fallacies, remote behavior is never the same as local, and the architecture does not leave much scope for easily solving this impedance mismatch.
• The caller and collie both need to be up and running at the time of communication. Often, this is not a requirement of the application build.
• Some of the frameworks, such as CORBA, started to become horrendously complicated since they were designed by committee.