Distributed Object Models

1. Distributed Object Models Distributed Systems Middleware - ICS243F Nalini Venkatasubramanian

2. 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

3. 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++?

4. 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

5. 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

6. 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)

7. 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

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

9. 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

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

11. 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.

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

13. 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.

14. 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.

15. 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

16. 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

17. 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

18. 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)

19. 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

20. 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."

21. 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.

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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