Distributed Objects: A Lightning TourDistributed Objects: A Lightning TourWhat is an “object”?What is an “object”?Objects are units of data with the following properties:• typed and self-containedEach object is an instance of a type that defines a set of methods(signatures) that can be invoked to operate on the object.• encapsulatedThe only way to operate on an object is through its methods; the internal representation/implementation is hidden from view.• dynamically allocated/destroyedObjects are created as needed and destroyed when no longer needed, i.e., they exist outside of any program scope.• uniquely referencedEach object is uniquely identified during its existence by a name/OID/reference/pointer that can be held/passed/stored/shared.Why are objects useful for systems?Why are objects useful for systems?The properties of objects make them useful as a basis for defining persistence, protection, and distribution.• Objects are self-contained and independent.Objects are a useful granularity for persistence, caching, location, replication, and/or access control.• Objects are self-describing.Object methods are dynamically bound, so programs can import and operate on objects found in shared or persistent storage.• Objects are abstract and encapsulated.It is easy to control object access by verifying that all clients invoke the object’s methods through a legal reference.Invocation is syntactically and semantically independent of an object’s location or implementation.Tricks With Objects (I)Tricks With Objects (I)1. Extend the object name space outside of a process and across a distributed system.• Linked data structures can be partitioned across the nodes and traversed with location-independent invocation.Emerald, Guide2. Extend the object name space across secondary storage.• Objects (and their references) may live longer than processes; fault objects into memory as they are referenced.POMS and other persistent object stores and OODBs•Eliminate “impedance mismatch” between memory/disk.type-checked secondary storage with type evolutionTricks With Objects (II)Tricks With Objects (II)3. Define RPC services as objects.• Allows persistent, location-independent name space with dynamic binding and/or dynamic activation.Argus, Eden, Clouds, Arjuna• Encapsulate with a clean object wrapper for external access.4. Make object references unforgeable and reject invocation attempts with invalid references.• An unforgeable object reference is called a capability.Cambridge CAP, IBM System/38 and AS/400, Intel 432CMU Hydra and Mach, Stanford V, Amoeba, Eden• Use as a basis for protected sharing/interaction/extension.EmeraldEmeraldEmerald is a classic and influential distributed object system.• Distribution is fully integrated into the language, its implementation, and even its type model.This is a strength and a weakness: combines language issues and system issues that should be separated.• Objects can be freely moved around the networkProgrammers see a uniform view of local and remote objects.Moving objects “take their code and threads with them”.• Local invocation is fast; remote invocation is transparent.supports pass-by-reference for RPCUnderstanding EmeraldUnderstanding Emerald1. Emerald was marketed to OS researchers as a lightweight alternative to process migration (a hot topic at the time).Process migration was accepted as a means to balance load, handle failures, or initiate a remote activity.2. Emerald eliminated key problems with process migration.OS-dependent state associated with migrating processeshigh cost of interaction among colocated processes3. Emerald was seen as a sort of lightweight “operating system” as well as a language.The “kernel” is a runtime library in a Unix process (one per node) within which all Emerald programs run.The Emerald “kernel” had its own support for “processes”, which we would now call “threads”, and execution...protection...persistence.Issues for EmeraldIssues for Emerald1. How to implement object references so that they are location-independent?How to ensure uniqueness of object IDs?How to locate remote objects , e.g., if they have moved?2. What is the “hook” for transparent location-independent invocation?How to make it fast if the invoked object is local?3. How to migrate and dynamically import code and threads?4. What are the semantics of argument passing?5. Who’s going to implement distributed garbage collection?Uniform Mobility: an ExampleUniform Mobility: an Examplenode AStep 1: a thread invokes a purple object on node A, which recursively invokes a blue object on the same node.node AStep 2: the blue object moves to node Bconcurrently with the invocation.node BHow to preserve inter-object pointers across migration?How to keep threads “sticky” with migrating objects?How to maintain references in stack activation records?How to maintain linkages among activation records?What about virtual addresses in CPU registers?Object References in EmeraldObject References in Emeraldnode AEmerald represents inter-object references as pointers into an object descriptor in an object table hashed by a unique object identifier (OID).The object table has a descriptor for every resident object, and for every remote object referenced by a resident object, and then some.When an object moves, its containing references must be found (using its template) and updated to point to descriptors on the destination node.References to the moving object need not be updated because they indirect through the object table.node BUniform Mobility Example, ContinuedUniform Mobility Example, Continuednode AStep 3: the purple object moves to node Cbefore the invocation returns.node BWhat to do with the thread’s activation record for the purple object?- cost of context switchHow to find the purple object to return into its activation record?How to keep forwarding pointers up to date? (eager vs. lazy)- iterative lookup- piggyback on passed references and remote returnsnode CThe Relevance of EmeraldThe Relevance of EmeraldEmerald defines a conceptual basis for understanding today’s distributed object systems.CORBA, RMI, EJB, DCOMEmerald showed what is possible from a distributed object environment in its purest form.1. Uniform view of local/remote objects: orthogonality of location.referencing, invocation/returngarbage collection2. Uniform object model is compatible with (local) performance.extended