CS 282 Principles of Operating Systems II Middleware for Distributed Real-time & Embedded Systems

1. CS 282Principles of Operating Systems IIMiddleware 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. 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. 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) • His office hours are … • Please send all questions tod.schmidt@vanderbilt.edu • I’ll send the answers to the class mailing list • Required textbook • Recommended reading

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 • You’ll get out of this course what you put into it, so be prepared to work hard • Weekly quizzes

5. Technology Trends (1/4) • Intel x86 & Power PC chipsets • TCP/IP, GSM, Link16 • POSIX, Windows, & VMs • Middleware & component models • Quality of service (QoS) aspects • 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.:

6. Technology Trends (2/4) Process Automation Quality Control Avionics Mission Computing Hot Rolling Mills Electronic Medical Imaging Software Defined Radio Modalities e.g., MRI, CT, CR, Ultrasound, etc. • 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. Technology Trends (3/4) … … … Container Container QoS-enabled Middleware Bus Replication Security Persistence Notification A/V Streaming Scheduling Load Balancing QoS-enabled Component middleware is maturing & becoming pervasive … • 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-enabledmiddleware bus and • Reuse common middleware services

8. Technology Trends (4/4) DRE Applications Middleware Services Middleware Operating Sys & Protocols Hardware & Networks Distributed system Model driven middleware that integrates model-based software technologies with QoS-enabled component middleware • e.g., standard technologies are emerging that can: • Model • Analyze • Synthesize & optimize • 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 <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> Goal is not to replace programmers per se – it is to provide higher-level domain-specific languages for middleware developers & users

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

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 • There are instructions on how to build & use it in the release • To use ACE & TAO you’ll 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. 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. 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. 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. 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. Generating Project Files & Servant Code • $ACE_ROOT/bin/mwc.pl [-type vc71 | -type gnuace] • $ACE_ROOT/bin/tao_idl -GI idl_file.idl

16. Component Middleware Layers Historically, mission-critical apps were built directly atop hardware & OS • Tedious, error-prone, & costly over lifecycles There are layers of middleware, just like there are layers of networking protocols • 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 multiple COTS layers & research/ business opportunities

17. Operating System & Protocols INTERNETWORKING ARCH MIDDLEWARE ARCH RTP TFTP FTP HTTP Middleware Applications DNS TELNET Middleware Services UDP TCP IP Middleware Fibre Channel Solaris VxWorks Ethernet ATM FDDI Win2K Linux LynxOS 20th Century 21st Century • 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.

18. Host Infrastructure Middleware Asynchronous Event Handling Asynchronous Transfer of Control Physical Memory Access Synchronization Memory Management Scheduling www.rtj.org www.cs.wustl.edu/~schmidt/ACE.html • 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)

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, Sun’s Remote Method Invocation (RMI), Microsoft’s 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. 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, Sun’s J2EE, Microsoft’s .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. Domain-Specific Middleware Modalities e.g., MRI, CT, CR, Ultrasound, etc. • Boeing Bold Stroke • Common software platform for Boeing avionics mission computing systems • www.boeing.com • Siemens MED • Common software platform for distributed electronic medical information & imaging systems • Used by all ~13 Siemens MED business units worldwide • www.syngo.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. Overview of Patterns • Present solutions to common software problems arising within a certain context • Help resolve key design forces • Flexibility • Extensibility • Dependability • Predictability • Scalability • Efficiency Client AbstractService Service Proxy service service service • Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs • Generally codify expert knowledge of design constraints & “best practices” 1 1 The Proxy Pattern www.posa.uci.edu

23. Overview of Pattern Languages • Motivation • Individual patterns & pattern catalogs are insufficient • Software modeling methods & tools that just illustrate how, not why, systems are designed • 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

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

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

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

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

28. Overview of the ACE Frameworks Application- specific functionality Stream Acceptor Connector Component Configurator Task Reactor Proactor • 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

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

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