1. CS 282 Principles of Operating Systems II Middleware for Distributed Real-time & Embedded Systems Dr. Douglas C. Schmidt d.schmidt@.vanderbilt.edu www.dre.vanderbilt.edu/~schmidt/cs282/ Professor of EECS Vanderbilt University Nashville, Tennessee

2. 2 CS 282 Course Philosophy Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify, human-engineered, efficient, and reliable, by the application of good design and programming practices. Careful study and imitation of good designs and programs significantly improves development skills. - Kernighan and Plauger

3. 3 Required textbook Recommended reading CS 282 Course Information CS 282 class web page www.dre.vanderbilt.edu/ ~schmidt/cs282/ My office hours in Featheringill Hall 226 Monday and Wednesday, noon to 2pm Our TA is Friedhelm Wolf (fwolf@dre.vanderbilt.edu)fwolf@dre.vanderbilt.edu His office hours are … Please send all questions to d.schmidt@vanderbilt.edu d.schmidt@vanderbilt.edu Ill send the answers to the class mailing list

4. 4 CS 282 Ground Rules Assignments must be submitted on time (including Assignment 0) Work must be your own No laptops in class You will be called upon periodically to answer questions Youll get out of this course what you put into it, so be prepared to work hard Weekly quizzes

5. 5 Technology Trends (1/4) Information technology is being commoditized i.e., hardware & software are getting cheaper, faster, & (generally) better at a fairly predictable rate These advances stem largely from standard hardware & software APIs & protocols, e.g.: TCP/IP, GSM, Link16 POSIX, Windows, & VMs Middleware & component models Intel x86 & Power PC chipsets Quality of service (QoS) aspects

6. 6 Technology Trends (2/4) Process Automation Quality Control Avionics Mission Computing Modalities e.g., MRI, CT, CR, Ultrasound, etc. Electronic Medical Imaging Software Defined Radio Hot Rolling Mills Growing acceptance of a network-centric component paradigm i.e., distributed applications with a range of QoS needs are constructed by integrating components & frameworks via various communication mechanisms

7. 7 Technology Trends (3/4) Components encapsulate application business logic Components interact via ports Provided interfaces, e.g.,facets Required connection points, e.g., receptacles Event sinks & sources Attributes Containers provide execution environment for components with common operating requirements Components/containers can also Communicate via a QoS-enabled middleware bus and Reuse common middleware services QoS-enabled Component middleware is maturing & becoming pervasive SecurityReplicationNotificationPersistence SchedulingA/V StreamingLoad Balancing … Container … … QoS-enabled Middleware Bus Container …

8. 8 e.g., standard technologies are emerging that can: 1. Model 2. Analyze 3. Synthesize & optimize 4. Provision & deploy multiple layers of QoS-enabled middleware & applications These technologies are guided by patterns & implemented by component frameworks Partial specialization is essential for inter-/intra-layer optimization Middleware Services DRE Applications Operating Sys & Protocols Hardware & Networks Distributed system Goal is not to replace programmers per se – it is to provide higher- level domain-specific languages for middleware developers & users Model driven middleware that integrates model-based software technologies with QoS-enabled component middleware Technology Trends (4/4)

9. 9 CS 282 Software Technology Focus Distribute Real- time & Embedded (DRE) Middleware Patterns & Pattern Languages GPSIFFFLIR Object Request Broker Air Frame APNavWTS Event Channel Replication Service Synchronization Persistence Fault Tolerance Memory Management Cross-cutting Concerns Multi-faceted Software Development Applications to DRE Systems Collaborative Software Development Environments Customizable Frameworks

10. 10 Getting Started with ACE+TAO This class will use ACE & TAO, which are object-oriented middleware that run on most operating systems e.g., Windows, Linux, & other UNIX platforms You can download ACE & TAO from http://download.dre.vanderbilt.edu http://download.dre.vanderbilt.edu There are instructions on how to build & use it in the release To use ACE & TAO youll need to learn a few new things e.g., Makefile Project Creator (MPC) Please let me know if you need help getting a C++ compiler installed on your machine

11. 11 Setting Up Your Environment Setting up your environment on Windows ACE_ROOT= the path to the DOC_ROOT directory TAO_ROOT=%ACE_ROOT%\TAO PATH=%ACE_ROOT%\lib;%PATH% Setting up your environment on Linux (or other UNIX platforms) ACE_ROOT=the path to the DOC_ROOT directory TAO_ROOT=$ACE_ROOT/TAO LD_LIBRARY_PATH=$ACE_ROOT/lib:$LD_LIBRARY_PATH Mac: Use DYLD_LIBRARY_PATH in lieu of LD_LIBRARY_PATH

12. 12 Configuring ACE ACE_ROOT/ace/config.h There are a number of config-*.h files in this directory Copy one that matches your platform to config.h e.g., config-linux.h or config-windows.h ACE_ROOT/include/makeinclude/ platform_macros.GNU Similarly here, e.g., platform

13. 13 Generating a Workspace for ACE & TAO Linux et al (in $TAO_ROOT$) $ACE_ROOT/bin/mwc.pl –type gnuace TAOACE.mwc Windows $ACE_ROOT/bin/mwc.pl –type vc8 TAOACE.mwc

14. 14 Generic MPC Template Generic MPC template project (*Server) : taoserver { IDL_Files { IDL_File_1.idl } Source_Files { Server_Code.cpp Servant_Code.cpp Other_Code.cpp } project (*Client) : taoclient { Source_Files { Client_Code.cpp }

15. 15 Generating Project Files & Servant Code $ACE_ROOT/bin/mwc.pl [-type vc71 | -type gnuace] $ACE_ROOT/bin/tao_idl -GI idl_file.idl

16. 16 There are multiple COTS layers & research/ business opportunities Historically, mission-critical apps were built directly atop hardware & OS Tedious, error-prone, & costly over lifecycles Standards-based COTS middleware helps: Control end-to-end resources & QoS Leverage hardware & software technology advances Evolve to new environments & requirements Provide a wide array of reuseable, off- the-shelf developer-oriented services There are layers of middleware, just like there are layers of networking protocols Component Middleware Layers

17. 17 Operating System & Protocols Operating systems & protocols provide mechanisms to manage endsystem resources, e.g., CPU scheduling & dispatching Virtual memory management Secondary storage, persistence, & file systems Local & remove interprocess communication (IPC) OS examples UNIX/Linux, Windows, VxWorks, QNX, etc. Protocol examples TCP, UDP, IP, SCTP, RTP, etc. RTP DNS HTTP UDPTCP IP TELNET EthernetATMFDDI Fibre Channel FTP INTERNETWORKING ARCH TFTP 20 th Century Win2KLinuxLynxOS Solaris VxWorks Middleware Services Middleware Applications MIDDLEWARE ARCH 21 st Century

18. 18 www.cs.wustl.edu/~schmidt/ACE.html Host Infrastructure Middleware Host infrastructure middleware encapsulates & enhances native OS communication & concurrency mechanisms to create reusable network programming components These components abstract away many tedious & error-prone aspects of programming to low-level operating system APIs Examples Java Virtual Machine (JVM), Microsoft Common Language Runtime (CLR), ADAPTIVE Communication Environment (ACE) Synchronization Memory Management Physical Memory Access Asynchronous Event Handling Scheduling Asynchronous Transfer of Control www.rtj.org

19. 19 Distribution Middleware Distribution middleware defines higher-level distributed programming models whose reusable APIs & components automate & extend the native OS network programming capabilities Examples OMG CORBA, Suns Remote Method Invocation (RMI), Microsofts Distributed Component Object Model (DCOM) Distribution middleware enables clients to program distributed applications much like stand-alone applications i.e., by invoking operations on target objects without hard- coding dependencies on their location, language, OS, protocols, & hardware

20. 20 Common Middleware Services Common middleware services augment distribution middleware by defining higher-level domain-independent services that allow application developers to concentrate on programming business logic Examples CORBA Component Model & Object Services, Suns J2EE, Microsofts.NET Common middleware services alleviate need to write the plumbing code required to develop distributed applications by using lower- level middleware directly e.g., application developers no longer need to write code that handles transactional behavior, security, database connection pooling or threading

21. 21 Domain-Specific Middleware Modalities e.g., MRI, CT, CR, Ultrasound, etc. Siemens MED Common software platform for distributed electronic medical information & imaging systems Used by all ~13 Siemens MED business units worldwide www.syngo.com Boeing Bold Stroke Common software platform for Boeing avionics mission computing systems www.boeing.com Domain-specific middleware services are tailored to the requirements of particular domains, such as telecom, e-commerce, health care, process automation, or aerospace Examples The domain- specific services layer is where system integrators can provide the most value & derive the most benefits

22. 22 Present solutions to common software problems arising within a certain context Overview of Patterns Help resolve key design forces Flexibility Extensibility Dependability Predictability Scalability Efficiency Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs The Proxy Pattern 11 Proxy service Service service AbstractService service Client Generally codify expert knowledge of design constraints & best practices www.posa.uci.edu

23. 23 Overview of Pattern Languages Benefits of Pattern Languages Define a vocabulary for talking about software development problems Provide a process for the orderly resolution of these problems Help to generate & reuse software architectures Motivation Individual patterns & pattern catalogs are insufficient Software modeling methods & tools that just illustrate how, not why, systems are designed

24. 24 Software Design Abstractions for Concurrent & Networked Applications Problem Distributed app & middleware functionality is subject to change since its often reused in unforeseen contexts, e.g., Accessed from different clients Run on different platforms Configured into different run- time contexts MIDDLEWARE Solution Dont structure distributed applications & middleware as a monoliths Instead, decompose them into modular classes, frameworks, & components Solution Dont structure distributed applications & middleware as a monoliths Instead, decompose them into modular classes, frameworks, & components

25. 25 Overview of Frameworks Framework Characteristics Application-specific functionality Frameworks exhibit inversion of control at runtime via callbacks Networking Database GUI Frameworks provide integrated domain-specific structures & functionality Mission Computing E-commerce Scientific Visualization Frameworks are semi-complete applications

26. 26 Comparing Class Libraries, Frameworks, & Components Class Libraries Frameworks Macro-levelMeso-levelMicro-level Borrow callers thread Inversion of control Borrow callers thread Domain-specific or Domain-independent Domain- specific Domain- independent Stand-alone composition entities Semi- complete applications Stand-alone language entities Components Class Library Architecture ADTs Strings Locks IPC Math LOCAL INVOCATIONS APPLICATION- SPECIFIC FUNCTIONALITY EVENT LOOP GLUE CODE Files GUI A class is a unit of abstraction & implementation in an OO programming language Framework Architecture ADTs Locks Strings Files INVOKES A framework is an integrated set of classes that collaborate to produce a reusable architecture for a family of applications Reactor GUI DATABASE NETWORKING APPLICATION- SPECIFIC FUNCTIONALITY CALLBACKS Middleware Bus Component Architecture A component is an encapsulation unit with one or more interfaces that provide clients with access to its services Naming Locking Logging Events

27. 27 Using Frameworks Effectively Observations Frameworks are powerful, but hard to develop & use effectively by application developers Its often better to use & customize COTS frameworks than to develop in- house frameworks Components are easier for application developers to use, but arent as powerful or flexible as frameworks Successful projects are therefore often organized using the funnel model

28. 28 Overview of the ACE Frameworks Features Open-source 6+ integrated frameworks 250,000+ lines of C++ 40+ person-years of effort Ported to Windows, UNIX, & real-time operating systems e.g., VxWorks, pSoS, LynxOS, Chorus, QNX Large user community www.cs.wustl.edu/~schmidt/ACE.html Acceptor Connector Component Configurator Stream Reactor Proactor Task Application- specific functionality

29. 29 The Pattern Language for ACE Pattern Benefits Preserve crucial design information used by applications & middleware frameworks & components Facilitate reuse of proven software designs & architectures Guide design choices for application developers

30. 30 CORBA is a distribution middleware standard Real-time CORBA adds QoS to classic CORBA to control: www.cs.wustl.edu/~schmidt/TAO.html 3. Memory Resources These capabilities address some (but by no means all) important DRE application development & QoS- enforcement challenges 2. Communication Resources Protocol Properties Explicit Binding Client Propagation & Server Declared Priority Models Portable Priorities Thread Pools Static Scheduling Service Standard Synchonizers 1. Processor Resources Request Buffering Example of Applying Patterns & Frameworks: Real-time CORBA & The ACE ORB (TAO)

31. 31 Key Patterns Used in TAO www.cs.wustl.edu/~schmidt/PDF/ORB-patterns.pdf Wrapper facades enhance portability Proxies & adapters simplify client & server applications, respectively Component Configurator dynamically configures Factories Factories produce Strategies Strategies implement interchangeable policies Concurrency strategies use Reactor & Leader/Followers Acceptor-Connector decouples connection management from request processing Managers optimize request demultiplexing