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

2. Intro to Distributed Systems Middleware2 CS 237 - Distributed Systems Middleware – Spring 2015 Lecture 1 - Introduction to Distributed Systems Middleware Mondays,Wednesdays 1:00-2:20p.m., PCB 1200 Prof. Nalini Venkatasubramanian nalini@ics.uci.edu

3. Intro to Distributed Systems Middleware3 Course logistics and details zCourse Web page - yhttp://www.ics.uci.edu/~cs237 zLectures – MW 1:00 – 2:20 p.m zReading List xTechnical papers and reports xReference Books zReader for Course yKerim Oktay (koktay@uci.edu)

4. Intro to Distributed Systems Middleware4 Course logistics and details zHomeworks yPaper summaries (choose 2 papers in each summary from reading list) zMidterm Examination zCourse Project yPreferably in groups of 2 or 3 yPotential projects will be available on webpage

5. Intro to Distributed Systems Middleware5 CompSci 237 Grading Policy zHomeworks - 30% of final grade 1 summary set due every 2 weeks (2 papers in each summary) (3 randomly selected each worth 10% of the final grade). zMidterm Exam – 35% of final grade zClass Project - 35% of final grade zFinal assignment of grades will be based on a curve.

6. Intro to Distributed Systems Middleware6 Lecture Schedule yWeeks 1,2,3: Distributed Computing Fundamentals Middleware Concepts Distributed Operating Systems Messaging, Communication in Distributed Systems Naming, Directory Services, Distributed FileSystems yWeeks 4,5,6,7: Middleware Frameworks Distributed Computing Frameworks – DCE, Hadoop Object-based Middleware –CORBA, COM, DCOM Java Based Technologies – Java RMI, JINI, J2EE, EJB Messaging Technologies - XML Based Middleware, Publish/Subscribe Service Oriented Architectures -.NET, Web Services, SOAP, REST, Service Gateways Database access and integration middleware (ODBC, JDBC, mediators) Cloud Computing Platforms and Technologies - Amazon EC2, Amazon S3, Microsoft Azure, Google App Engine  Weeks 9, 10: Middleware for Target Application Environments Real-time and QoS-enabled middleware Middleware for Mobile/Wireless networks and applications Middleware for Sensor Networks, Pervasive, CyberPhysical Systems Middleware for Resilient/Fault tolerant applications

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

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

9. Intro to Distributed Systems Middleware9 Various Middlewares… zCORBA, OMG, CanCORBA, ORBIX, JavaORB, ORBLite, TAO, Zen, RTCORBA, FTCORBA,DCOM, POA,IDL,IOP,IIOP, zObjectBroker, Visibroker, Orbix, ObjectBus,ESBs zMOM – TIBCO TIB/Rendezvous, BEA MessageQ, Microsoft MSMQ, ActiveWorks zJVM, JINI, RMI, J2EE, EJB,J2ME, JDBC,JTA, JTS,JMS, JNDI, zEnterprise Middleware Technologies -- BEA WebLogic, IBM WebSphere, TivoliBeans zENCINA, Tuxedo, CICS zXML, XQuery, zSOAP, Web Services, WSDL, BPEL z…..

10. More Views of Middleware zSoftware technologies to help manage complexity and heterogeneity inherent to the development of distributed systems, distributed applications, and information systems zHigher-level programming abstraction for developing distributed applications zHigher than “lower” level abstractions, such as sockets, monitors provided by the operating system ya 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

11. Middleware Systems – more views zAims at reducing the burden of developing distributed applications for the developer yinformally called “plumbing”, i.e., like pipes that connect entities for communication yoften called “glue code”, i.e., it glues independent systems together and makes them work together zMasks the heterogeneity programmers of distributed applications have to deal with ynetwork & hardware yoperating system & programming language ydifferent middleware platforms ylocation, access, failure, concurrency, mobility,... zoften also referred to as transparency mechanisms ynetwork transparency, location transparency From Arno Jacobsen lectures, Univ. of Toronto

12. Middleware Systems Views zAn operating system is “the software that makes the hardware usable” zSimilarly, a middleware system makes the distributed system programmable and manageable zBare computer without OS could be programmed, yprograms could be written in assembly, but higher-level languages are far more productive for this purpose zDistributed application be developed without middleware y But far more cumbersome From Arno Jacobsen lectures, Univ. of Toronto

13. Key problem space challenges Highly dynamic behavior Transient overloads Time-critical tasks Context-specific requirements Resource conflicts Interdependence of (sub)systems Integration with legacy (sub)systems New application domains cf: Doug Schmidt

14. Key solution space challenges Enormous accidental & inherent complexities Continuous evolution & change Highly heterogeneous platform, language, & tool environments Key problem space challenges Highly dynamic behavior Transient overloads Time-critical tasks Context-specific requirements Resource conflicts Interdependence of (sub)systems Integration with legacy (sub)systems New application domains cf: Doug Schmidt

15. Key solution space challenges Enormous accidental & inherent complexities Continuous evolution & change Highly heterogeneous platform, language, & tool environments Key problem space challenges Highly dynamic behavior Transient overloads Time-critical tasks Context-specific requirements Resource conflicts Interdependence of (sub)systems Integration with legacy (sub)systems Mapping problem space requirements to solution space artifacts is very hard! New application domains

16. Intro to Distributed Systems Middleware16 Distributed Systems Multiple independent computers that appear as one yLamport’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.”

17. Intro to Distributed Systems Middleware17 Examples of Distributed Systems zBanking systems zCommunication - email zDistributed information systems yWWW yFederated Databases zManufacturing and process control zInventory systems zGeneral purpose (university, office automation)

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

19. Intro to Distributed Systems Middleware19 Why Distributed Computing? zInherent distribution yBridge customers, suppliers, and companies at different sites. zSpeedup - improved performance zFault tolerance zResource Sharing yExploitation of special hardware zScalability zFlexibility

20. Intro to Distributed Systems Middleware20 Why are Distributed Systems Hard? zScale ynumeric, geographic, administrative zLoss of control over parts of the system zUnreliability of message passing yunreliable communication, insecure communication, costly communication zFailure yParts of the system are down or inaccessible yIndependent failure is desirable

21. Intro to Distributed Systems Middleware21 Design goals of a distributed system zSharing yHW, SW, services, applications zOpenness(extensibility) yuse of standard interfaces, advertise services, microkernels zConcurrency ycompete vs. cooperate zScalability yavoids centralization zFault tolerance/availability zTransparency ylocation, migration, replication, failure, concurrency

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

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

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

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

26. Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware Operating Systems & Protocols Encapsulates & enhances native OS mechanisms to create reusable network programming components Extending the OSI Layering for the Software Infrastructure ISR ProcessingSCADA SystemsAir Traffic MgmtAerospace

27. 27 Distributed Systems & Middleware Research at UC Irvine zSafe and Adaptive Middleware yCompOSE|Q - Safe composability of m/w services and protocols xSecurity, fault tolerance, reliability, QOS, mobility yContessa – Context Sensitive System Adaptation (formal methods based) xAdaptive Data Collection – wireless and instrumented sensor networks xAdaptive Communication -- groupware on MANETS, mesh networks, xAdaptive Middleware for Mobile Applications zMobile Multimedia Systems and Applications yFORGE – Cross-Layer Adaptation (OS, Device, Network, Application) Techniques yxTune: On-the-fly formal methods for cross-layer adaptation yMAPGRID – Grid/Cloud Computing for Mobile Applications zPervasive Computing Systems and Applications yResponsphere – A Next Generation Pervasive Computing Testbed ySATWARE – Stream Acquisition and Transformation Middleware zApplication Focused Distributed Systems Research yRESCUE: Improving Information Flow in Crises ySAFIRE: Situational Awareness for Firefighters yMultimedia Applications

28. Distributed Systems & Middleware Research at UC Irvine Adaptive and Reflective Middleware: -- MetaSIM: Reflective Middleware Solutions for Integrated Simulation Environmetns -- Contessa: Adaptive System Interoperability -- CompOSE|Q: Composable Open Software Environment with QoS -- MIRO: Adaptive Middleware for a Mobile Internet Robot Laboratory -- SIGNAL: Societal Scale Geographical Notification and Alerting -- Contessa: -- CompOSE|Q: -- SIGNAL: Pervasive and Ubiquitous Computing: -- Pervasive Computing for Disaster Response: A Pervasive Computing and Communications Collaboration project between UC Irvine, California Institute of Technology, and IIT Gandhinagar -- I-sensorium: A shared experimental laboratory housing state-of-the-art sensing, actuation, networking and mobile computing devices -- SATWARE:A Middleware for Sentient Spaces -- Quasar:Quality Aware Sensing Architecture -- SUGA:Middleware Support for Cross-Disability Access -- Pervasive Computing for Disaster Response: -- I-sensorium: -- SATWARE: -- Quasar: -- SUGA: Cyber Physical Systems: -- Cypress: CYber Physical RESilliance and Sustainability -- Cypress: Middleware Support for Mobile Applications: -- FORGE: A Framework for Optimization of Distributed Embedded Systems Software -- Dynamo: Power Aware Middleware for Distributed Mobile Computing -- MAPGrid: Mobile Applications Powered by Grids -- Xtune: Cross Layer Tuning of Mobile Embedded Systems -- FORGE: -- Dynamo: -- MAPGrid: -- Xtune: Cross Layer Tuning of Mobile Embedded Systems Emergency Response: -- RESCUE: Responding to Crises and Unexpected Events -- Customized Dissemination in the Large -- SAFIRE: Situational Awareness for Firefighters -- Responsphere: An IT Infrastructure for Responding to the Unexpected -- RESCUE: -- Customized Dissemination in the Large -- SAFIRE: -- Responsphere: Intro to Distributed Systems Middleware28

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

30. 30 Mobile Middleware

31. 31 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 QoS, 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. Dynamo: Power Aware Mobile Middleware Wide Area Network Wireless Network Low-power mobile device proxy Use a Proxy-Based Architecture Network Infrastructure Execute Remote Tasks CachingCompress DecryptionEncryption Compositing Transcode

32. 32 Middleware for Pervasive Systems - UCI I-Sensorium Infrastructure 32 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

33. 33 Mote Sensor Deployment IEEE 802.15.4 (zigbee) Crossbow MIB510 Serial Gateway Polar Heart Rate Module Polar T31 Heart rate strap transmitter Proprietary EMF transmission To SAFIRE Server IMU (5 degrees of freedom) Crossbow MDA 300CA Data Acquisition board on MICAz 2.4Ghz Mote Heart Rate Inertial positioning Carbon monoxide Temperature, humidityCarboxyhaemoglobin, light

34. UC Irvine Sensorium Boxes (building on Caltech CSN project) ● SheevaPlug computer ● Accelerometer ● Ethernet ● Battery backup ● Additional Sensors ● Wi-Fi dongle, Smoke, Toxic gases (e.g. CO), Radiation, Humidity, Microphone, Camera ● Humidity ● control (de)humidifer, particularly for individuals with respiratory ailments ● Camera ● boiling pot, monitor pet's food and water, face recognition ● Microphone / accelerometer ● detect gunshot in an apartment building / complex ● Microphone / light sensor ● monitor thunderstorm activity

35. 35 SAFIRENET – Next Generation MultiNetworks zMultitude of technologies yWiFi (infrastructure, ad-hoc), WSN, UWB, mesh networks, DTN, zigbee zSAFIRE Data needs yTimeliness ximmediate medical triage to a FF with significant CO exposure yReliability xaccuracy levels needed for CO monitoring zLimitations yResource Constraints xVideo, imagery xTransmission Power, Coverage, yFailures and Unpredictability zGoal yReliable delivery of data over unpredictable infrastructure Sensors Dead Reckoning (don’t send Irrelevant data) Multiple networks Information need DATA NEEDS

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

37. MINA: A Multinetwork Information Architecture 1. Tier based overlay architecture (Using Network centrality, clustering ) 2. Heterogeneous Networks and devices 3. Diverse services and applications Observe-Analyze-Adapt

38. 38 Next Generation Alerting Systems Dissemination in the Large Delivery Layer Research Wired Networks Wireless Networks Content Layer Research Efficient Publish Subscribe Content Customization Systems and Deployments CrisisAlertDisasterPortal

39. Content Delivery with Hybrid Networks Infrastructure Networks Content Delivery Non- Cooperative Cooperative Reliable and Fast Content Delivery Massive Video Streaming Cost- Driven Content Delivery Delay- Guarantee d Content Delivery

40. Societal Scale Information Sharing Societal scale delay-tolerant information sharing Societal scale instant information sharing Information Layer Dissemination Layer 40 DYNATOPS: efficient Pub/Sub under societal scale dynamic information needs  DEBS’13 GSFord: Reliable information delivery under regional failures  SRDS’12 efficient mobile information crowdsoursing and querying  In progress OFacebook: efficient offline access to online social media on mobile devices  (MIDDLEWARE’13, INFOCOM’14)

41. Intro to Distributed Systems Middleware41 Classifying Distributed Systems zBased on degree of synchrony ySynchronous yAsynchronous zBased on communication medium yMessage Passing yShared Memory zFault model yCrash failures yByzantine failures

42. Intro to Distributed Systems Middleware42 Computation in distributed systems zAsynchronous system yno assumptions about process execution speeds and message delivery delays zSynchronous system ymake assumptions about relative speeds of processes and delays associated with communication channels yconstrains implementation of processes and communication zModels of concurrency yCommunicating processes yFunctions, Logical clauses yPassive Objects yActive objects, Agents

43. Intro to Distributed Systems Middleware43 Concurrency issues zConsider the requirements of transaction based systems yAtomicity - either all effects take place or none yConsistency - correctness of data yIsolated - as if there were one serial database yDurable - effects are not lost zGeneral correctness of distributed computation ySafety yLiveness

44. Flynn’s Taxonomy for Parallel Computing Instructions Single (SI)Multiple (MI) Data Multiple (MD) SISD Single-threaded process MISD Pipeline architecture SIMD Vector Processing MIMD Multi-threaded Programming Single (SD) Parallelism – A Practical Realization of Concurrency

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

46. SIMD D0D0 Processor Instructions D0D0 D0D0 D0D0 D0D0 D0D0 D1D1 D2D2 D3D3 D4D4 … DnDn D1D1 D2D2 D3D3 D4D4 … DnDn D1D1 D2D2 D3D3 D4D4 … DnDn D1D1 D2D2 D3D3 D4D4 … DnDn D1D1 D2D2 D3D3 D4D4 … DnDn D1D1 D2D2 D3D3 D4D4 … DnDn D1D1 D2D2 D3D3 D4D4 … DnDn D0D0 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.array processorGPU

47. MISD (Multiple Instruction Single Data) Intro to Distributed Systems Middleware47 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.Space Shuttle D Instructions D

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

49. Intro to Distributed Systems Middleware49 Communication in Distributed Systems zProvide support for entities to communicate among themselves yCentralized (traditional) OS’s - local communication support yDistributed systems - communication across machine boundaries (WAN, LAN). z2 paradigms yMessage Passing xProcesses communicate by sharing messages yDistributed Shared Memory (DSM) xCommunication through a virtual shared memory.

50. Intro to Distributed Systems Middleware50 Message Passing zBasic communication primitives ySend message yReceive message zModes of communication ySynchronous xatomic action requiring the participation of the sender and receiver. xBlocking send: blocks until message is transmitted out of the system send queue xBlocking receive: blocks until message arrives in receive queue yAsynchronous xNon-blocking send:sending process continues after message is sent xBlocking 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.

51. Intro to Distributed Systems Middleware51 Reliability issues zUnreliable communication yBest effort, No ACK’s or retransmissions yApplication programmer designs own reliability mechanism zReliable communication yDifferent degrees of reliability yProcesses have some guarantee that messages will be delivered. yReliability mechanisms - ACKs, NACKs.

52. Intro to Distributed Systems Middleware52 Reliability issues zUnreliable communication yBest effort, No ACK’s or retransmissions yApplication programmer designs own reliability mechanism zReliable communication yDifferent degrees of reliability yProcesses have some guarantee that messages will be delivered. yReliability mechanisms - ACKs, NACKs.

53. Intro to Distributed Systems Middleware53 Distributed Shared Memory zAbstraction used for processes on machines that do not share memory yMotivated by shared memory multiprocessors that do share memory zProcesses read and write from virtual shared memory. yPrimitives - read and write yOS ensures that all processes see all updates zCaching on local node for efficiency yIssue - cache consistency

54. Intro to Distributed Systems Middleware54 Remote Procedure Call zBuilds on message passing yextend traditional procedure call to perform transfer of control and data across network yEasy to use - fits well with the client/server model. yHelps programmer focus on the application instead of the communication protocol. yServer is a collection of exported procedures on some shared resource yVariety of RPC semantics x“maybe call” x“at least once call” x“at most once call”

55. Intro to Distributed Systems Middleware55 Fault Models in Distributed Systems zCrash failures yA processor experiences a crash failure when it ceases to operate at some point without any warning. Failure may not be detectable by other processors. xFailstop - processor fails by halting; detectable by other processors. zByzantine failures ycompletely unconstrained failures yconservative, worst-case assumption for behavior of hardware and software ycovers the possibility of intelligent (human) intrusion.

56. Intro to Distributed Systems Middleware56 Other Fault Models in Distributed Systems zDealing with message loss yCrash + Link xProcessor fails by halting. Link fails by losing messages but does not delay, duplicate or corrupt messages. yReceive Omission xprocessor receives only a subset of messages sent to it. ySend Omission xprocessor fails by transmitting only a subset of the messages it actually attempts to send. yGeneral Omission xReceive and/or send omission

57. Intro to Distributed Systems Middleware57 Other distributed system issues zConcurrency and Synchronization zDistributed Deadlocks zTime in distributed systems zNaming zReplication yimprove availability and performance zMigration yof processes and data zSecurity yeavesdropping, masquerading, message tampering, replaying

58. Intro to Distributed Systems Middleware58 Traditional Systems - Client/Server Computing zClient/server computing allocates application processing between the client and server processes. zA typical application has three basic components: yPresentation logic yApplication logic yData management logic

59. Intro to Distributed Systems Middleware59 Client/Server Models zThere are at least three different models for distributing these functions: yPresentation logic module running on the client system and the other two modules running on one or more servers. yPresentation logic and application logic modules running on the client system and the data management logic module running on one or more servers. yPresentation 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

60. Intro to Distributed Systems Middleware60 Application Program Middleware Service 1 API Middleware Service 3 API Middleware Service 2 API Modularity via Middleware Services

61. Intro to Distributed Systems Middleware61 Useful Middleware Services yNaming and Directory Service yState Capture Service yEvent Service yTransaction Service yFault Detection Service yTrading Service yReplication Service yMigration Service

62. Intro to Distributed Systems Middleware62 Distributed Systems Middleware yEnables the modular interconnection of distributed software (typically via services) xabstract over low level mechanisms used to implement management services. yComputational Model xSupport separation of concerns and reuse of services yCustomizable, Composable Middleware Frameworks xProvide for dynamic network and system customizations, dynamic invocation/revocation/installation of services. xConcurrent execution of multiple distributed systems policies.

63. Intro to Distributed Systems Middleware63 Types of Middleware zIntegrated Sets of Services -- DCE zDomain Specific Integration frameworks zDistributed Object Frameworks zComponent services and frameworks yProvide a specific function to the requestor yGenerally independent of other services yPresentation, Communication, Control, Information Services, computation services etc. zWeb-Service Based Frameworks zCloud Based Frameworks

64. Intro to Distributed Systems Middleware64 Integrated Sets Middleware zAn Integrated set of services consist of a set of services that take significant advantage of each other. zExample: DCE

65. Intro to Distributed Systems Middleware65 Distributed Computing Environment (DCE) zDCE - from the Open Software Foundation (OSF), offers an environment that spans multiple architectures, protocols, and operating systems ( supported by major software vendors) yIt 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. Operating System Transport Services DCE Threads Services DCE Remote Procedure Calls DCE Distributed Time Service DCE Directory Service Other Basic Services DCE Distributed File Service Applications DCE Security Service Management

66. Intro to Distributed Systems Middleware66 Integration Frameworks Middleware zIntegration frameworks are integration environments that are tailored to the needs of a specific application domain. zExamples yWorkgroup framework - for workgroup computing. yTransaction Processing monitor frameworks yNetwork management frameworks

67. A Sample Network Management Framework (WebNMS) Intro to Distributed Systems Middleware67 http://www.webnms.com/webnms/ems.html

68. Intro to Distributed Systems Middleware68 Distributed Object Computing zCombining distributed computing with an object model. yAllows software reusability yMore abstract level of programming yThe use of a broker like entity or bus that keeps track of processes, provides messaging between processes and other higher level services yExamples xCORBA, COM, DCOM xJINI, EJB, J2EE x.NET, E-SPEAK xNote: DCE uses a procedure-oriented distributed systems model, not an object model.

69. Distributed Objects zIssues with Distributed Objects yAbstraction yPerformance yLatency yPartial failure ySynchronization yComplexity y….. zTechniques yMessage Passing xObject knows about network; xNetwork data is minimum yArgument/Return Passing xLike RPC. xNetwork data = args + return result + names ySerializing and Sending Object xActual object code is sent. Might require synchronization. xNetwork data = object code + object state + sync info yShared Memory xbased on DSM implementation xNetwork Data = Data touched + synchronization info Intro to Distributed Systems Middleware69

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

71. Intro to Distributed Systems Middleware71 The Object Management Architecture (OMA) Application Objects Object Request Broker Common facilities Object Services Application objects: document handling objects. ORB: the communication hub for all objects in the system Object Services: object events, persistent objects, etc. Common facilities: accessing databases, printing files, etc.

72. Distributed Object Models zCombine techniques zGoal: Merge parallelism and OOP yObject Oriented Programming xEncapsulation, modularity xSeparation of concerns yConcurrency/Parallelism xIncreased efficiency of algorithms xUse objects as the basis (lends itself well to natural design of algorithms) yDistribution xBuild network-enabled applications xObjects on different machines/platforms communicate

73. Objects and Threads zC++ Model yObjects and threads are tangentially related yNon-threaded program has one main thread of control xPthreads (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++? zJava Model yObjects and threads are separate entities xThreads are objects in themselves xCan be joined together (complex object implements java.lang.Runnable) BUT: Properties of connection between object and thread are not well- defined or understood

74. Java and Concurrency zJava has a passive object model yObjects, threads separate entities xPrimitive control over interactions ySynchronization capabilities also primitive x“Synchronized keyword” guarantees safety but not liveness xDeadlock is easy to create xFair scheduling is not an option

75. Actors: A Model of Distributed Objects Thread State Procedure Thread State Procedure Thread State Procedure Interface Messages Actor system - collection of independent agents interacting via message passing An actor can do one of three things: 1.Create a new actor and initialize its behavior 2.Send a message to an existing actor 3.Change its local state or behavior Features Acquaintances initial, created, acquired History Sensitive Asynchronous communication

76. More middlewares to follow zWeb Services and Web Service Frameworks zEnterprise Service Buses zCloud Computing and Virtualization Platforms …… Intro to Distributed Systems Middleware76