Distributed Object Models Distributed Systems Middleware ICS 243

Distributed Object Models Distributed Systems Middleware - ICS 243 F Nalini Venkatasubramanian

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

Objects and Threads z. C++ Model y. Objects and threads are tangentially related y. Non-threaded program has one main thread of control x. 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 z. Java Model y. Objects and threads are separate entities x. Threads are objects in themselves x. 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 z. Java has a passive object model y. Objects, threads separate entities x. Primitive control over interactions y. Synchronization capabilities also primitive x“Synchronized keyword” guarantees safety but not liveness x. Deadlock is easy to create x. Fair scheduling is not an option

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

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

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

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

Actor Primitives z Three actor primitives y. Create(behavior) y. Send_to(message, actor) y. Become(behavior) z State change specified by replacement behaviors

Complexities of active objects y. Reachability x. Reachability Operator - for binary relations, A, on base actors and subsets B, R of base actors Reach. O(A, B, R) is the least set of base actors such that: x(r) R Reach. O(A, B, R) x(f) If a Reach. O(A, B, R) and a. Aa’, then a’ Reach. O(A, B, R) x(i) If a Reach. O(A, B, R), a’Aa and ( a 0 B) (a 0 A* a’), then • a’ Reach. O(A, B, R) where A 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) = Reach. O(Acq(k), Busy(k), Roots)

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

Distributed Garbage Collection y. Annotations and communications with the basic runtime system can be used to compute snapshot properties. y. Unique GC Root xaccepts requests for GC and synchronizes GC phases. x. 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 z Symbolic and numerical distributed algorithms z Symbolic algorithms include: y. Theorem proving y. Truth maintenance y. Production systems y. Language parsing z -Found to be useful for distributed artificial intelligence y. Implemented in Common. Lisp y. Provides most of the same features of Lisp

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

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

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

ABCM: Object Model z Object is always in one of three modes y. Dormant (initial state) x. Waiting to get hit by a message that matches one of its activation patterns y. Active x. Got a message with the appropriate pattern x. Cannot accept new messages in this state x. Returns to dormant when done processing y. Waiting x. Waiting for a specific type/pattern of message to arrive x. 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 z No Broadcasting y You must know the name of the recipients of a message z Objects always "know about" themselves y They may acquire and forget knowledge about other objects as time goes on z Asynchrony y Any object can send a message to any other object at any time z Guaranteed Arrival, Buffered Communication y Guaranteed delivery in finite time, buffers are infinite, no blocking write. z Incoming buffers are in order of arrival z Channel-like behavior along connections. z No global clock. y Unrelated events take place "concurrently. "

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

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

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

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

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

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

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

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

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

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

Infospheres z Object Model y. Dapplets are processes, composed of one or more objects x. Each process has a set of inboxes and outboxes (message queues) x. 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 z. Distributed System Issues y. Synchronization and Concurrency x. Provide a library of services that can be used by dapplet developers for reliable synchronous, concurrent distributed applications x. Deadlock detection, transactions are services in this library

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

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