Distributed Systems Middleware Prof Nalini Venkatasubramanian Dept of

Distributed Systems Middleware Prof. Nalini Venkatasubramanian Dept. of Information & Computer Science University of California, Irvine 1

CS 237 - Distributed Systems Middleware – Spring 2011 Lecture 1 - Introduction to Distributed Systems Middleware Tuesdays, Thursdays 12: 30 -1: 50 p. m. Prof. Nalini Venkatasubramanian nalini@ics. uci. edu Intro to Distributed Systems Middleware 2

Course logistics and details z Course Web page yhttp: //www. ics. uci. edu/~cs 237 z Lectures – Tu. Th 12: 30 – 1: 50 p. m z Reading List x. Technical papers and reports x. Reference Books Intro to Distributed Systems Middleware 3

Course logistics and details z Homeworks y. Paper summaries y. Survey paper z Course Presentation z Course Project y. Maybe done individually or in groups y. Potential projects will be available on webpage Intro to Distributed Systems Middleware 4

Comp. Sci 237 Grading Policy z Homeworks - 30% • 1 paper summary due every week • (3 randomly selected each worth 10% of the final grade). z Survey Paper - 10% z Class Presentation - 10% z Class Project - 50% of the final grade z Final assignment of grades will be based on a curve. Intro to Distributed Systems Middleware 5

Lecture Schedule y. Weeks 1, 2: Fundamentals • • • General Purpose Middleware , Adaptive Middleware Distributed Operating Systems Messaging, Communication in Distributed Systems Naming and Directory Services Distributed I/O and Storage Subsystems y. Weeks 3, 4, 5, 6, 7: Middleware Frameworks x. Distributed Computing Frameworks – DCE, Hadoop x. Object-based Middleware –CORBA, COM x. Java Based Technologies – Java RMI, JINI, J 2 EE, EJB x. Database access and integration middleware (ODBC, JDBC, mediators) x. Messaging Technologies • XML Based Middleware, Publish/Subscribe Technologies x. Service Oriented Architectures • . NET, Web Services, SOAP, REST, Service Gateways x. Cloud Computing Platforms and Technologies • Amazon EC 2, Amazon S 3, Microsoft Azure, Google App Engine Intro to Distributed Systems Middleware 6

Course Schedule y. Weeks 8, 9 and 10: Middleware for Distributed Application Environments x. Real-time and Qo. S-enabled middleware x. Middleware for Fault tolerant applications x. Middleware for Mobile and Pervasive Environments x. Middleware for P 2 P architectures x. Middleware for Grid/Cloud Computing x. Middleware for Secure applications Intro to Distributed Systems Middleware 7

What is Middleware? z Middleware is the software between the application programs and the operating System and base networking z Integration Fabric that knits together applications, devices, systems software, data z Middleware provides a comprehensive set of higher-level distributed computing capabilities and a set of interfaces to access the capabilities of the system. Intro to Distributed Systems Middleware 8

The Evergrowing Alphabet Soup Distributed Computing Environment (DCE) Orbix IOP IIOP GIOP WSDL WS-BPEL WSIL Java Transaction API (JTA) JNDI LDAP JMS BPEL BEA Tuxedo® Object Request Broker (ORB) EAI RTCORBA SOAP Message Queuing (MSMQ) Distributed Component XQuery Object Model (DCOM) opal. ORB XPath Remote Method Invocation TM INI ORBlite Encina/9000 (RMI) Rendezvous Enterprise BEA Web. Logic® Java. Beans Remote Procedure Call Technology (RPC) (EJB) Extensible Markup Language (XML) ZEN IDL J Borland® Visi. Broker®

More Views of Middleware z software technologies to help manage complexity and heterogeneity inherent to the development of distributed systems, distributed applications, and information systems z Higher-level programming abstraction for developing the distributed application z higher than “lower” level abstractions, such as sockets provided by the operating system y a socket is a communication end-point from which data can be read or onto which data can be written From Arno Jacobsen lectures, Univ. of Toronto

Middleware Systems – more views z aims at reducing the burden of developing distributed application for developer z informally called “plumbing”, i. e. , like pipes that connect entities for communication z often called “glue code”, i. e. , it glues independent systems together and makes them work together z it masks the heterogeneity programmers of distributed applications have to deal with y network & hardware y operating system & programming language y different middleware platforms y location, access, failure, concurrency, mobility, . . . z often also referred to as transparencies, i. e. , network transparency, location transparency From Arno Jacobsen lectures, Univ. of Toronto

Middleware Systems Views z an operating system is “the software that makes the hardware usable” z similarly, a middleware system makes the distributed system programmable and manageable z bare computer without OS could be programmed, so could the distributed application be developed without middleware z programs could be written in assembly, but higher-level languages are far more productive for this purpose From Arno Jacobsen lectures, Univ. of Toronto

Distributed Systems Multiple independent computers that appear as one y. Lamport’s Definition x“ You know you have one when the crash of a computer you have never heard of stops you from getting any work done. ” y“A number of interconnected autonomous computers that provide services to meet the information processing needs of modern enterprises. ” Intro to Distributed Systems Middleware 14

Examples of Distributed Systems z Banking systems z Communication - email z Distributed information systems y. WWW y. Federated Databases z Manufacturing and process control z Inventory systems z General purpose (university, office automation) Intro to Distributed Systems Middleware 15

Characterizing Distributed Systems z Multiple Computers yeach consisting of CPU’s, local memory, stable storage, I/O paths connecting to the environment z Interconnections ysome I/O paths interconnect computers that talk to each other z Shared State ysystems cooperate to maintain shared state ymaintaining global invariants requires correct and coordinated operation of multiple computers. Intro to Distributed Systems Middleware 16

Why Distributed Computing? z Inherent distribution y. Bridge customers, suppliers, and companies at different sites. z Speedup - improved performance z Fault tolerance z Resource Sharing y. Exploitation of special hardware z Scalability z Flexibility Intro to Distributed Systems Middleware 17

Why are Distributed Systems Hard? z Scale ynumeric, geographic, administrative z Loss of control over parts of the system z Unreliability of message passing yunreliable communication, insecure communication, costly communication z Failure y. Parts of the system are down or inaccessible y. Independent failure is desirable Intro to Distributed Systems Middleware 18

Design goals of a distributed system z Sharing y. HW, SW, services, applications z Openness(extensibility) yuse of standard interfaces, advertise services, microkernels z Concurrency ycompete vs. cooperate z Scalability yavoids centralization z Fault tolerance/availability z Transparency ylocation, migration, replication, failure, concurrency Intro to Distributed Systems Middleware 19

• Personalized Environment • Predictable Response • Location Independence • Platform Independence • Flexibility • Code Reusability • Real-Time Access • Increased • Interoperability to information Complexity • Portability • Lack of Mgmt. • Scalability • Reduced Tools • Faster Developmt. Complexity And deployment of • Changing Business Solutions Technology ORGANIZATION Intro to Distributed Systems Middleware System Administrator Application Developer END-USER [Khanna 94] 20

Application Systems: support enterprise systems Distributed Computing Platform • Application Support Services (OS, DB support, Directories, RPC) • Communication Network Services (Network protocols, Physical devices) • Hardware Intro to Distributed Systems Middleware Interoperability Portability Integration Management and Support Network Management Enterprise Systems: Perform enterprise activities 21

Application Systems: User Processing Data files & Interfaces programs Databases Distributed Computing Platform • Application Support Services Dist. Data Distributed C/S Support Trans. Mgmt. OS Interoperability Portability Integration Management and Support Network Management Enterprise Systems: • Engineering systems • Manufacturing • Office systems • Business systems Common Network Services • Network protocols & interconnectivity OSI TCP/IP SNA protocols Intro to Distributed Systems Middleware 22

An Event-driven Architecture for a Real-time Enterprise The Enterprise Services Bus

Distributed Systems & Middleware Research at UC Irvine z Safe and Adaptive Middleware y Comp. OSE|Q - Safe composability of m/w services and protocols x Security, fault tolerance, reliability, QOS, mobility y Contessa – Context Sensitive System Adaptation (formal methods based) x Adaptive Data Collection – wireless and instrumented sensor networks x Adaptive Communication -- groupware on MANETS, mesh networks, x Adaptive Middleware for Mobile Applications z Mobile Multimedia Systems and Applications y FORGE – Cross-Layer Adaptation (OS, Device, Network, Application) Techniques y x. Tune: On-the-fly formal methods for cross-layer adaptation y MAPGRID – Grid/Cloud Computing for Mobile Applications z Pervasive Computing Systems and Applications y Responsphere – A Next Generation Pervasive Computing Testbed y SATWARE – Stream Acquisition and Transformation Middleware z Application Focused Distributed Systems Research y RESCUE: Improving Information Flow in Crises y SAFIRE: Situational Awareness for Firefighters y Multimedia Applications 24

Research Approach Design and develop adaptive middleware for distributed applications When, where, how to adapt Formal Methods Foundation Algorithms Machine Learning Systems Genetic Algorithms Statistical Modeling Design, implementation, evaluation Graph Algorithms 25 Arsenal Game Theory

Mobile Middleware 26

Dynamo: Power Aware Mobile Middleware To build a power-cognizant distributed middleware framework that can o exploit global changes (network congestion, system loads, mobility patterns) o co-ordinate power management strategies at different levels (application, middleware, OS, architecture) o maximize the utility (application Qo. S, power savings) of a low-power device. o study and evaluate cross layer adaptation techniques for performance vs. quality vs. power tradeoffs for mobile handheld devices. Network Infrastructure Caching Compress Encryption Decryption Compositing Transcode Execute Remote Tasks Low-power mobile device Wide Area Network Wireless Network proxy Use a Proxy-Based Architecture 27

Middleware for Pervasive Systems UCI RESPONSPHERE Infrastructure Campus-wide infrastructure to instrument, experiments, monitor, disaster drills & to validate technologies sensing, communicating, storage & computing infrastructure Software for real-time collection, analysis, and processing of sensor information used to create real time information awareness & post-drill analysis 28 28

SAFIRENET – Next Generation Multi. Networks Information need z Multitude of technologies y Wi. Fi (infrastructure, ad-hoc), WSN, UWB, mesh networks, DTN, zigbee z SAFIRE Data needs y Timeliness Multiple networks y Reliability NEEDS DATA x immediate medical triage to a FF with significant CO exposure x accuracy levels needed for CO monitoring z Limitations y Resource Constraints x Video, imagery x Transmission Power, Coverage, y Failures and Unpredictability z Goal Sensors y Reliable delivery of data over unpredictable infrastructure Dead Reckoning (don’t send Irrelevant data) 29

Mote Sensor Deployment Heart Rate Proprietary EMF transmission Polar T 31 Heart rate strap transmitter Inertial positioning IMU (5 degrees of freedom) Polar Heart Rate Module Crossbow MIB 510 Serial Gateway Crossbow MDA 300 CA Data Acquisition board on MICAz 2. 4 Ghz Mote IEEE 802. 15. 4 (zigbee) To SAFIRE Server Carbon monoxide Temperature, humidity Carboxyhaemoglobin, light 30

SATware: A semantic middleware for multisensor applications Abstraction - makes programming easy - hides heterogeneity, failures, concurrency Provides core services across sensors - alerts, triggers, storage, queries Mediates app needs and resource constraints - networking, computation, device 31

Next Generation Alerting and Warning Project Dissemination in the Large Delivery Layer Research Wired Networks Wireless Networks Content Layer Research Efficient Publish Subscribe Content Customization 32 Systems and Deployments Crisis. Alert Disaster. Portal

Classifying Distributed Systems z Based on degree of synchrony y. Synchronous y. Asynchronous z Based on communication medium y. Message Passing y. Shared Memory z Fault model y. Crash failures y. Byzantine failures Intro to Distributed Systems Middleware 33

Computation in distributed systems z Asynchronous system y no assumptions about process execution speeds and message delivery delays z Synchronous system y make assumptions about relative speeds of processes and delays associated with communication channels y constrains implementation of processes and communication z Models of concurrency y Communicating processes y Functions, Logical clauses y Passive Objects y Active objects, Agents Intro to Distributed Systems Middleware 34

Concurrency issues z Consider the requirements of transaction based systems y. Atomicity - either all effects take place or none y. Consistency - correctness of data y. Isolated - as if there were one serial database y. Durable - effects are not lost z General correctness of distributed computation y. Safety y. Liveness Intro to Distributed Systems Middleware 35

Flynn’s Taxonomy for Parallel Computing Single (SD) Multiple (MD) Data Instructions Single (SI) Multiple (MI) SISD MISD Single-threaded process Pipeline architecture SIMD MIMD Vector Processing Multi-threaded Programming

SISD (Single Instruction Single Data Stream) Processor D D D D Instructions A sequential computer which exploits no parallelism in either the instruction or data streams. Examples of SISD architecture are the traditional uniprocessor machines (currently manufactured PCs have multiple processors) or old mainframes.

SIMD Processor D 0 D 0 D 1 D 1 D 2 D 2 D 3 D 3 D 4 D 4 … … … … Dn Dn Instructions A computer which exploits multiple data streams against a single instruction stream to perform operations which may be naturally parallelized. For example, an array processor or GPU.

MISD (Multiple Instruction Single Data) D Instructions Multiple instructions operate on a single data stream. Uncommon architecture which is generally used for fault tolerance. Heterogeneous systems operate on the same data stream and aim to agree on the result. Examples include the Space Shuttle flight control computer. Intro to Distributed Systems Middleware 39

MIMD Processor D D D D D Instructions Processor D D Instructions Multiple autonomous processors simultaneously executing different instructions on different data. Distributed systems are generally recognized to be MIMD architectures; either exploiting a single shared memory space or a distributed memory space.

Communication in Distributed Systems z Provide support for entities to communicate among themselves y. Centralized (traditional) OS’s - local communication support y. Distributed systems - communication across machine boundaries (WAN, LAN). z 2 paradigms y. Message Passing x. Processes communicate by sharing messages y. Distributed Shared Memory (DSM) x. Communication through a virtual shared memory. Intro to Distributed Systems Middleware 41

Message Passing z Basic communication primitives y Send message y Receive message z Modes of communication y Synchronous xatomic action requiring the participation of the sender and receiver. x. Blocking send: blocks until message is transmitted out of the system send queue x. Blocking receive: blocks until message arrives in receive queue y Asynchronous x. Non-blocking send: sending process continues after message is sent x. Blocking or non-blocking receive: Blocking receive implemented by timeout or threads. Non-blocking receive proceeds while waiting for message. Message is queued(BUFFERED) upon arrival. Intro to Distributed Systems Middleware 42

Reliability issues z Unreliable communication y. Best effort, No ACK’s or retransmissions y. Application programmer designs own reliability mechanism z Reliable communication y. Different degrees of reliability y. Processes have some guarantee that messages will be delivered. y. Reliability mechanisms - ACKs, NACKs. Intro to Distributed Systems Middleware 43

Reliability issues z Unreliable communication y. Best effort, No ACK’s or retransmissions y. Application programmer designs own reliability mechanism z Reliable communication y. Different degrees of reliability y. Processes have some guarantee that messages will be delivered. y. Reliability mechanisms - ACKs, NACKs. Intro to Distributed Systems Middleware 44

Distributed Shared Memory z Abstraction used for processes on machines that do not share memory y. Motivated by shared memory multiprocessors that do share memory z Processes read and write from virtual shared memory. y. Primitives - read and write y. OS ensures that all processes see all updates z Caching on local node for efficiency y. Issue - cache consistency Intro to Distributed Systems Middleware 45

Remote Procedure Call z Builds on message passing y extend traditional procedure call to perform transfer of control and data across network y Easy to use - fits well with the client/server model. y Helps programmer focus on the application instead of the communication protocol. y Server is a collection of exported procedures on some shared resource y Variety of RPC semantics x“maybe call” x“at least once call” x“at most once call” Intro to Distributed Systems Middleware 46

Fault Models in Distributed Systems z Crash failures y. A processor experiences a crash failure when it ceases to operate at some point without any warning. Failure may not be detectable by other processors. x. Failstop - processor fails by halting; detectable by other processors. z Byzantine failures ycompletely unconstrained failures yconservative, worst-case assumption for behavior of hardware and software ycovers the possibility of intelligent (human) intrusion. Intro to Distributed Systems Middleware 47

Other Fault Models in Distributed Systems z Dealing with message loss y. Crash + Link x. Processor fails by halting. Link fails by losing messages but does not delay, duplicate or corrupt messages. y. Receive Omission xprocessor receives only a subset of messages sent to it. y. Send Omission xprocessor fails by transmitting only a subset of the messages it actually attempts to send. y. General Omission x. Receive and/or send omission Intro to Distributed Systems Middleware 48

Other distributed system issues z Concurrency and Synchronization z Distributed Deadlocks z Time in distributed systems z Naming z Replication yimprove availability and performance z Migration yof processes and data z Security yeavesdropping, masquerading, message tampering, replaying Intro to Distributed Systems Middleware 49

Traditional Systems Client/Server Computing z Client/server computing allocates application processing between the client and server processes. z A typical application has three basic components: y. Presentation logic y. Application logic y. Data management logic Intro to Distributed Systems Middleware 50

Client/Server Models z There at least three different models for distributing these functions: y. Presentation logic module running on the client system and the other two modules running on one or more servers. y. Presentation logic and application logic modules running on the client system and the data management logic module running on one or more servers. y. Presentation logic and a part of application logic module running on the client system and the other part(s) of the application logic module and data management module running on one or more servers Intro to Distributed Systems Middleware 51

Distributed Systems Middleware y. Enables the modular interconnection of distributed software (typically via services) xabstract over low level mechanisms used to implement resource management services. y. Computational Model x. Support separation of concerns and reuse of services y. Customizable, Composable Middleware Frameworks x. Provide for dynamic network and system customizations, dynamic invocation/revocation/installation of services. x. Concurrent execution of multiple distributed systems policies. Intro to Distributed Systems Middleware 52

Modularity via Middleware Services Application Program API Middleware Service 1 API Middleware Service 2 Intro to Distributed Systems Middleware API Middleware Service 3 53

Useful Middleware Services y. Naming and Directory Service y. State Capture Service y. Event Service y. Transaction Service y. Fault Detection Service y. Trading Service y. Replication Service y. Migration Service Intro to Distributed Systems Middleware 54

Types of Middleware Services z Integrated Sets of Services -- DCE z Domain Specific Integration frameworks z Distributed Object Frameworks z Component services and frameworks y. Provide a specific function to the requestor y. Generally independent of other services y. Presentation, Communication, Control, Information Services, computation services etc. z Web-Service Based Frameworks Intro to Distributed Systems Middleware 55

Integrated Sets Middleware z An Integrated set of services consist of a set of services that take significant advantage of each other. z Example: DCE Intro to Distributed Systems Middleware 56

Distributed Computing Environment (DCE) z DCE is from the Open Software Foundation (OSF), and now X/Open, offers an environment that spans multiple architectures, protocols, and operating systems. y. DCE supported by major software vendors. z It provides key distributed technologies, including RPC, a distributed naming service, time synchronization service, a distributed file system, a network security service, and a threads package. Intro to Distributed Systems Middleware 57

DCE Distributed File Service DCE Security DCE Other Basic Service Distributed Directory Services Time Service Management Applications DCE Remote Procedure Calls DCE Threads Services Operating System Transport Services Intro to Distributed Systems Middleware 58

Integration Frameworks Middleware z Integration frameworks are integration environments that are tailored to the needs of a specific application domain. z Examples y. Workgroup framework - for workgroup computing. y. Transaction Processing monitor frameworks y. Network management frameworks Intro to Distributed Systems Middleware 59

Distributed Object Computing z Combining distributed computing with an object model. y. Allows software reusability y. More abstract level of programming y. The use of a broker like entity or bus that keeps track of processes, provides messaging between processes and other higher level services y. Examples x. CORBA, COM, DCOM x. JINI, EJB, J 2 EE x. NET, E-SPEAK Intro to Distributed Systems x. Note: DCE uses a procedure-oriented distributed Middleware systems model, not an object model. 60

Issues with Distributed Objects y. Abstraction y. Performance y. Latency y. Partial failure y. Synchronization y. Complexity Intro to Distributed Systems Middleware 61

Techniques for object distribution y. Message Passing x. Object knows about network; Network data is minimum y. Argument/Return Passing x. Like RPC. Network data = args + return result + names y. Serializing and Sending Object x. Actual object code is sent. Might require synchronization. Network data = object code + object state + sync info y. Shared Memory xbased on DSM implementation to Distributed Systems x. Network Data Intro = Data touched + synchronization info Middleware 62

CORBA z CORBA is a standard specification for developing object-oriented applications. z CORBA was defined by OMG in 1990. z OMG is dedicated to popularizing Object. Oriented standards for integrating applications based on existing standards. Intro to Distributed Systems Middleware 63

The Object Management Architecture (OMA) Common facilities Application Objects Object Request Broker Object Services Intro to Distributed Systems Middleware 64

OMA z ORB: the communication hub for all objects in the system z Object Services: object events, persistent objects, etc. z Common facilities: accessing databases, printing files, etc. z Application objects: document handling objects. Intro to Distributed Systems Middleware 65

Distributed Object Models 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 Threa d Interfac e Threa d State Procedure State Messages Procedure Interface Threa d 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

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