distributed object models n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Distributed Object Models PowerPoint Presentation
Download Presentation
Distributed Object Models

Loading in 2 Seconds...

play fullscreen
1 / 34

Distributed Object Models - PowerPoint PPT Presentation


  • 127 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Distributed Object Models' - ranger


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
distributed object models

Distributed Object Models

Distributed Systems Middleware - ICS243F

Nalini Venkatasubramanian

distributed objects
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
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 threads1
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 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
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
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
The Actor Model

A Model of Distributed Objects

State

Interface

Thread

Interface

Procedure

State

Thread

Messages

Procedure

Interface

State

Thread

Procedure

the actor model1
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
Actor Primitives
  • Three actor primitives
    • Create(behavior)
    • Send_to(message, actor)
    • Become(behavior)
  • State change specified by replacement behaviors
complexities of active objects
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
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

specifying reachability snapshots
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
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
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
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 model1
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 model2
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 model3
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
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 model1
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 model2
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
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
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
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 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
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
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
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
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
infospheres1
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
infospheres2
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
infospheres3
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
infospheres4
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