In a DISTRIBUTED OBJECT ARCHITECTURE, there is no distinction between clients and servers. Each distributable entity is an OBJECT that provides services to other objects and receives services from other objects. Object communication is through a MIDDLEWARE system called an OBJECT REQUEST BROKER (a SOFTWARE BUS). The broker provides a transparent set of services allowing objects to communicate, and to be added to and removed from the system. ┌────┐ ┌────┐ ┌────┐ ┌────┐ │ o1 │ │ o2 │ │ o3 │ │ o4 │ │ S1 │ │ S2 │ │ S3 │ │ S4 │ └─┬──┘ └─┬──┘ └─┬──┘ └─┬──┘ ────┴───────┴───────┴───────┴──── SOFTWARE BUS (object request broker) ────┬───────┬───────┬───────┬──── ┌─┴──┐ ┌─┴──┐ ┌─┴──┐ ┌─┴──┐ │ o5 │ │ o6 │ │ o7 │ │ o8 │ │ S5 │ │ S6 │ │ S7 │ │ S8 │ └────┘ └────┘ └────┘ └────┘ THE BROKER'S JOB: an object need not know the LOCATION of the objects it calls. It asks the broker, and the broker handles finding the target, marshalling the arguments, transmitting them, invoking the method, and returning the result. ADVANTAGES · it allows the SYSTEM DESIGNER TO DELAY DECISIONS on where and how services should be provided — a genuinely valuable property, because the deployment topology can change without redesign · it is a very OPEN SYSTEM ARCHITECTURE that allows new resources to be added as required · the system is FLEXIBLE AND SCALABLE — new objects can be added on new processors as demand grows · it is possible to RECONFIGURE THE SYSTEM DYNAMICALLY, with objects migrating across the network as required DISADVANTAGES · it is a more COMPLEX PARADIGM than the client–server model, and harder for designers to think about. Client–server systems have a natural "who serves whom" structure; a peer mesh of objects has none, and the resulting design can be difficult to visualise, test and debug. · the middleware itself becomes a critical dependency and a single point of failure · performance is unpredictable, because a method call that looks local may be a network round trip USES OF DISTRIBUTED OBJECT ARCHITECTURE: 1. As a LOGICAL MODEL allowing you to structure and organise the system. In this case, you think about how to provide application functionality solely in terms of services and combinations of services. 2. As a FLEXIBLE APPROACH TO IMPLEMENTING client–server systems. The logical model is client–server, but both clients and servers are realised as distributed objects communicating through the software bus.

MIDDLEWARE is the software sitting in the middle, between the objects, providing the services they need to interoperate. Sommerville lists what a broker must provide. CORBA — the Common Object Request Broker Architecture, from the Object Management Group (OMG). An international standard defining an architecture for an ORB. Four major elements: 1. AN OBJECT MODEL a CORBA object is an encapsulation of state with a well-defined, language-neutral interface defined in an IDL (Interface Definition Language) 2. AN OBJECT REQUEST BROKER handles requests for service delivery: locates the object, ensures it is ready, transmits the request, returns the result 3. OBJECT SERVICES common services many distributed systems need: directory/naming services, transaction services, persistence, security, event notification 4. COMMON COMPONENTS / FACILITIES higher-level, domain-specific standard components HOW A CALL WORKS — the mechanism worth understanding, because every RPC system since works this way: caller object │ calls a local STUB (a proxy with the same interface) ▼ STUB marshals the arguments into a byte stream │ ▼ ORB / network (the wire) │ ▼ SKELETON unmarshals, invokes the real method │ ▼ target object The stub and skeleton are GENERATED FROM THE IDL, which is why the call site looks like an ordinary method call. That resemblance is the design goal — and, as below, also the problem. OTHER TECHNOLOGIES in this family: Java RMI Java-only distributed objects DCOM Microsoft's equivalent .NET Remoting its successor SOAP / WSDL XML-based web services, an ORB by another name gRPC + Protobuf the modern, and much better-engineered, descendant: an IDL, generated stubs, binary encoding, HTTP/2 transport NOTE THE CONTINUITY: gRPC is the same idea as CORBA — define an interface, generate stubs, call remotely — with three decades of hard-won corrections. The idea was not wrong; the first implementations were.

THE CENTRAL DESIGN GOAL of distributed objects was LOCATION TRANSPARENCY: a remote call should look like a local one. This is the goal that fails, and the reasons are worth learning as a list. THE FALLACIES OF DISTRIBUTED COMPUTING — assumptions that a transparent remote call implicitly makes, all of them false: 1. THE NETWORK IS RELIABLE — it is not; calls are lost 2. LATENCY IS ZERO — a local call is ~1 ns; a same-datacentre call is ~500,000 ns; a cross-continent call is ~150,000,000 ns 3. BANDWIDTH IS INFINITE — passing a large object graph by value is catastrophic 4. THE NETWORK IS SECURE — it is not 5. TOPOLOGY DOESN'T CHANGE — it does 6. THERE IS ONE ADMINISTRATOR — there is not 7. TRANSPORT COST IS ZERO — marshalling and serialisation cost real CPU 8. THE NETWORK IS HOMOGENEOUS — it is not PUT NUMBERS ON FALLACY 2, because it is the decisive one: local method call ≈ 1 ns same-datacentre RPC ≈ 0.5 ms = 500,000 ns cross-continent RPC ≈ 150 ms = 150,000,000 ns A remote call is between 500 thousand and 150 million times more expensive than a local one. Any abstraction that makes those two look identical in source code is HIDING SOMETHING THAT MATTERS ENORMOUSLY. THE CONSEQUENCE IN PRACTICE — the "chatty interface" problem. Code written as if calls were free: for (Order o : customer.getOrders()) // 1 call for (Line l : o.getLines()) // N calls total += l.getPrice(); // N × M calls With 50 orders of 10 lines each, on a 0.5 ms link: calls = 1 + 50 + 500 = 551 time = 551 × 0.5 ms = 275 ms Rewritten as ONE coarse-grained call returning the total: time = 0.5 ms A 550× difference, from the same logic — and the local version of that loop runs in microseconds, so nothing in testing on one machine would reveal the problem. THE RULE THIS YIELDS: DISTRIBUTED INTERFACES MUST BE COARSE-GRAINED. Ask for everything you need in one call. This is the direct opposite of good local object design, where fine-grained accessors are a virtue — and that contradiction is exactly why "just distribute your objects" cannot work. WHAT REPLACED DISTRIBUTED OBJECTS: · SERVICE-ORIENTED ARCHITECTURE and REST — stop pretending remote is local. Make the network explicit, make calls coarse-grained, make services stateless, use a document (a representation) rather than an object reference. · MESSAGE-BASED / EVENT-DRIVEN INTEGRATION — accept that the call may not return, and design for asynchrony from the start. · gRPC — keep the IDL and generated stubs, but with explicit streaming, deadlines, and cancellation, so failure and latency are part of the programming model rather than hidden from it. THE LASTING LESSON, which is the real content of this topic: A GOOD ABSTRACTION HIDES DETAIL YOU DO NOT NEED. A LEAKY ABSTRACTION HIDES DETAIL YOU DO NEED. Location is the second kind.