Distributed Object Models Distributed Systems Middleware – ICS243F

Distributed Object Models Distributed Systems Middleware - ICS243F Nalini Venkatasubramanian

Distributed Objects Combine techniques Object Oriented Programming Encapsulation, modularity Separation of concerns Concurrency/Parallelism Increased efficiency of algorithms Use objects as the basis Distribution Build network-enabled applications Objects on different machines/platforms communicate

Objects and Threads C Model Objects and threads are tangentially related Non-threaded program has one main thread of control Pthreads (POSIX threads) Invoke by giving a function pointer to any function in the system Threads mostly lack awareness of OOP ideas and environment Partially due to the hybrid nature of C ?

Objects and Threads Java Model Objects and threads are separate entities Threads are objects in themselves Can be joined together (complex object implements java.lang.Runnable) BUT: Properties of connection between object and thread are not well-defined or understood

Java and Concurrency Java has a passive object model Objects, threads separate entities Primitive control over interactions Synchronization capabilities also primitive “Synchronized keyword” guarantees safety but not liveness Deadlock is easy to create Fair scheduling is not an option

COOP Applications Three kinds of concurrent problem solving Pipeline Concurrency Start, split up problem, compute solutions, check solutions Divide & Conquer Start, split up problem, compute solutions, combine solutions (Product of a large vector of numbers) Cooperative problem solving Start, split up problem, problem solvers communicate during problem-solving to exchange state, partial results (complex simulations)

Fundamentals of Distributed Objects Concurrent object oriented languages Goal: Merge parallelism and OOP Parallelism gives "naturalness" in algorithm design efficiency OOP gives modularity safety Provide modeling, simulation capabilities

The Actor Model A Model of Distributed Objects Interface Thread Interface Thread State Procedure State Messages Procedure Interface Thread State Procedure

The Actor Model Actor system - collection of independent agents interacting via message passing Features Acquaintances - initial, created, acquired History Sensitive Asynchronous communication An actor can do one of three things: Create a new actor and initialize its behavior Send a message to an existing actor Change its local state or behavior

Actor Primitives Three actor primitives Create(behavior) Send to(message, actor) Become(behavior) State change specified by replacement behaviors

Complexities of active objects Reachability Reachability Operator - for binary relations, A, on base actors and subsets B, R of base actors ReachO(A,B,R) is the least set of base actors such that: (r) R ReachO(A,B,R) (f) If a ReachO(A,B,R) and aAa’, then a’ ReachO(A,B,R) (i) If a ReachO(A,B,R), a’Aa and ( a0 B) (a0 A* a’), then a’ ReachO(A,B,R) where A Ab Ab and B, R Ab.

Reachability A D B E C I Reachability from Roots in configuration k is given by G K H I J Rch(k) ReachO(Acq(k), Busy(k), Roots)

Specifying Reachability Snapshots Records and maintains safe approximation to reachability using acquaintance and busy status annotations. If snapshot requested, eventually Termination: recording will complete Progress: Actors unreachable at start will be so recorded Noninterference: under any conditions reachability is preserved Transparency: under any conditions application observational behavior is preserved.

Using Snapshots: Distributed Garbage Collection Annotations and communications with the basic runtime system can be used to compute snapshot properties. Unique GC Root accepts requests for GC and synchronizes GC phases. Three phases - non-overlapping Pre-GC - recording GC snapshot Distributed Scavenge - actors reachable according to the GC snapshot are marked Local Clearance - each node clears local memory of actors not marked in the scavenge phase.

ABCM: Applications Symbolic and numerical distributed algorithms Symbolic algorithms include: Theorem proving Truth maintenance Production systems Language parsing -Found to be useful for distributed artificial intelligence Implemented in CommonLisp Provides most of the same features of Lisp

ABCM: Object Model Objects are Data members Methods to operate on those members Methods for message exchange/passing No shared memory All communication through message passing Each object has a thread of control like Actors

ABCM: Object Model Object Model Upon receiving a message, the object will do one of four things: More message passing Creation of new objects Reference and update member variables Various operations (arithmetic, list processing) on values stored in local memory and passed in messages

ABCM: Object Model Each object has an incoming buffer Buffers assumed infinite No blocking send Can send any time Messages are put in buffer in the order they arrive No global clock (more later) “Channels” determine ordering of messages (more later)

ABCM: Object Model Object is always in one of three modes Dormant (initial state) Waiting to get hit by a message that matches one of its activation patterns Active Got a message with the appropriate pattern Cannot accept new messages in this state Returns to dormant when done processing Waiting Waiting for a specific type/pattern of message to arrive In waiting mode, an acceptable message can "cut to the front of the line" ahead of other messages that don't match the pattern

ABCM: Message Passing Model No Broadcasting You must know the name of the recipients of a message Objects always "know about" themselves They may acquire and forget knowledge about other objects as time goes on Asynchrony Any object can send a message to any other object at any time Guaranteed Arrival, Buffered Communication Guaranteed delivery in finite time, buffers are infinite, no blocking write. Incoming buffers are in order of arrival Channel-like behavior along connections. No global clock. Unrelated events take place "concurrently."

ABCM: Message Passing Model Three types of message passing: “Past” Objects send message and don't wait for reply “Now” Synchronous RPC Object sends a message and waits for the response before continuing. “Future” Asynchronous RPC Object sends a message, gets back a token, checks result later.

ABCM: Message Passing Model Two modes: Ordinary mode Object cannot be interrrupted while in active mode. "Nonpreemptive multitasking" Express Mode Messages sent in express mode can interrupt active mode Can break some of the math behind the model Only one level of interrupts Can mark a set of statements "atomic" so they aren't interrupted. Can do a breaking interrupt (break the operation going on when express message got received) DB query that gets cancelled

ABCM: Conclusion Lays foundation for many other distributed object systems Some aspects CORBA-like (synchronous RPC) Some aspects not (asynchronous RPC, interrupts) Active objects will become important later

Modular Heterogeneous System Development Two general solutions to heterogeneity Provide a homogeneous environment Java – the JVM Provide homogeneous connectors among heterogeneous components CORBA, other ORBs Characteristics of Java Lowest-Common-Denominator environment for applications Simplifies life, but at what cost? Characteristics of ORBs Limits mobility Take advantage of platform specific resources

Java and ORBs Key Insight Make Java more like an ORB Linking Java and CORBA one way to do this Add more distributed synchronization, coordination services to Java Better control over OS-type stuff, especially thread schedulers

Java and Concurrency Now Java has a passive object model Objects, threads separate entities Primitive control over interactions Synchronization capabilities also primitive “Synchronized keyword” guarantees safety but not liveness Deadlock is easy to create Fair scheduling is not an option

Increase abstraction for D.S. “Synchronizers” Specify high level synchronization policies that range over active objects “Communicators” Specify high level communication policies that dictate how active objects communicate “Liaisons” A way to specify how/which active objects/actors interact

Liaisons A component is a group of actors A liaison is the subset of actors in a component that can interact with other components Actual subset is dynamic Interaction between liaisons define connection properties

Infospheres (Mani Chandy, Caltech) Compose active objects for small distributed applications Calendars, design activities Not concerned with 24x7 highly critical systems Uses the Web, Java Many of same paradigms as ABCM

Infospheres Objects are composed into active groups of objects, called “dapplets” Sessions are groups of dapplets that come together for a temporary period to accomplish a goal Duration may be short (calendar coordination) or long (design) State of dapplets persists across sessions Each session only has access to relevant session data

Infospheres Object Model Dapplets are processes, composed of one or more objects Each process has a set of inboxes and outboxes (message queues) Many to many correspondence between inboxes, outboxes Process can add a message to an outbox Process can read first message from an inbox Channels are used (like ABCM) Delays are arbitrary, guaranteed delivery, no interrupts Clock is a Lamport-like distributed clock scheme

Infospheres Distributed System Issues Synchronization and Concurrency Provide a library of services that can be used by dapplet developers for reliable synchronous, concurrent distributed applications Deadlock detection, transactions are services in this library

Infospheres Deadlock detection Each resource treated as a token Resource types correspond to token “colors” Token manager dapplets keep track of which dapplets have which tokens Can request, release a group of tokens to token managers atomically

Infospheres Conclusion Uses active object paradigm Does not get ORB-like services A general framework for building distributed applications Reliability of various DS services, fault tolerance yet to be seen