180 likes | 335 Views
Dr. Douglas C. Schmidt d.schmidt@.vanderbilt.edu www.dre.vanderbilt.edu/~schmidt/cs395/. CS 395-2 QoS-enabled Middleware Design & Application. Professor of EECS Vanderbilt University Nashville, Tennessee. CS 395 Course Philosophy.
E N D
Dr. Douglas C. Schmidt d.schmidt@.vanderbilt.edu www.dre.vanderbilt.edu/~schmidt/cs395/ CS 395-2QoS-enabled Middleware Design & Application Professor of EECS Vanderbilt University Nashville, Tennessee
CS 395 Course Philosophy Good design & programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain & modify, human-engineered, efficient, & reliable, by the application of good design & programming practices. Careful study & imitation of good designs & programs significantly improves development skills. - Kernighan & Plauger
CS 395 Course Information • Recommended reading • CS 395 class web page • www.dre.vanderbilt.edu/ ~schmidt/cs395/ • My office hours in Featheringill Hall 226 • Mon 1:00 to 3:00pm • Wed 1:00 to 3:00pm • TA: Deepti Thopte • deepti.s.thopte@Vanderbilt.Edu • Deepti’s office hours will be announced shortly • Please send all questions tod.schmidt@vanderbilt.edu • I’ll send the answers to the class mailing list
The Need for QoS-enabled Technologies Scalability, Persistence, Security Throughput, Availability Determinism Parallelism Parallel Systems Distributed Systems Systemic Signal Processing Near Real-Time Fault-Tolerant Information PRocessing Complex Information Management Real-Time Information Processing Data Processing Scale Real-Timeliness
The Need for QoS-enabled Technologies • Network Centric Architectures are emerging as a key trend for next generation military & civil system of systems • Efficient, scalable & QoS-enabled technologies are an enabling technology for network-centric systems The Right Information => To the Right People => At the Right Time
Common Requirements • Interoperability • Interoperability is a key enabler for achieving better performance & enabling new operational requirements Shared Operational Picture • Increasing need in real-time access to the common operational picture • Increased Data Volumes • Real-time dissemination of massive data volumes, often over large scale • Loosely Coupled & Plug & Play • Ability seamlessly support MANET, VANET, time, & space decoupling
The Solution is in the Middleware & OS Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware Operating Systems & Protocols Historically, mission-critical apps were built directly atop hardware Applications • 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 reusable, off-the-shelf developer-oriented services Hardware There are multiple COTS middleware layers & research/business opportunities
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 & remote interprocess communication (IPC) • OS examples • UNIX/Linux, Windows, VxWorks, QNX, etc. • Protocol examples • TCP, UDP, IP, SCTP, RTP, etc.
Host Infrastructure Middleware Asynchronous Event Handling • Examples • Java Virtual Machine (JVM), Common Language Runtime (CLR), ADAPTIVE Communication Environment (ACE) Asynchronous Transfer of Control Physical Memory Access Synchronization Memory Management Scheduling www.cs.wustl.edu/~schmidt/ACE.html www.rtj.org • Host infrastructure middleware encapsulates & enhances native OS mechanisms to create reusable network programming components • These components abstract away many tedious & error-prone aspects of low-level OS APIs Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware
Distribution Middleware • Examples • OMG Real-time CORBA & DDS, Sun RMI, Microsoft DCOM, W3C SOAP realtime.omg.org/ en.wikipedia.org/wiki/Data_Distribution_Service • Distribution middleware defines higher-level distributed programming models whose reusable APIs & components automate & extend native OS capabilities Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware Distribution middleware avoids hard-coding client & server application dependencies on object location, language, OS, protocols, & hardware
Common Middleware Services • Examples • CORBA Component Model & Object Services, Sun’s J2EE, Microsoft’s .NET, W3C Web Services • Common middleware services support many recurring distributed system capabilities, e.g., • Transactional behavior • Authentication & authorization, • Database connection pooling & concurrency control • Active replication • Dynamic resource management • Common middleware services augment distribution middleware by defining higher-level domain-independent services that focus on programming “business logic” Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware
Domain-Specific Middleware • Examples • Siemens MEDSyngo • Common software platform for distributed electronic medical systems • Used by all ~13 Siemens MED business units worldwide Modalities e.g., MRI, CT, CR, Ultrasound, etc. • Boeing Bold Stroke • Common software platform for Boeing avionics mission computing systems • Domain-specific middleware services are tailored to the requirements of particular domains, such as telecom, e-commerce, health care, process automation, or aerospace Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware
Overview of CORBA • Common Object Request Broker Architecture (CORBA) • A family of specifications • OMG is the standards body • Over 800 companies • CORBA defines interfaces, not implementations • It simplifies development of distributed applications by automating/encapsulating • Object location • Connection & memory mgmt. • Parameter (de)marshaling • Event & request demultiplexing • Error handling & fault tolerance • Object/server activation • Concurrency • Security • CORBA shields applications from heterogeneous platform dependencies • e.g., languages, operating systems, networking protocols, hardware
Overview of Real-time CORBA 1.0 • Real-time CORBA adds QoS control to regular CORBA to improve application predictability, e.g., • Bounding priority inversions & • Managing resources end-to-end • Policies & mechanisms for resource configuration/control in Real-time CORBA include: • Processor Resources • Thread pools • Priority models • Portable priorities • Synchronization • Communication Resources • Protocol policies • Explicit binding • Memory Resources • Request buffering • These capabilities address some (but by no means all) important real-time application development challenges
Overview of the Data Distribution Service (DDS) • High Performance real-time data-centric publish/subscribe middleware • The right data, at the right place, at the right time—all the time • Fully distributed, multicast-enabled, high performance, highly scalable, & high availability, hot-swap/hot-hot architecture • Blends data-centric & real-time publish/subscribe technologies • Content-based subscriptions, (continuous) queries, & filters • Fine-grained, policy-based tuning of resource usage, data delivery, availability QoS • Optimal networking & computing resources usage • Loosely coupled • Plug & play architecture with dynamic discovery • Time & space decoupling • Open standard • OMG DDS v1.2 latest version www.omg.org/dds Global Data Space
DDS: Foundational Abstractions • Information Model. Defines the structure, relations, & QoS, of the information exchanged by the applications, & supports flat, relational, & object-oriented modeling • Typed Global Data Space. A logical data space in which applications read & write data anonymously & asynchronously, decoupled in space & time • Publisher/Subscriber. Produce/Consume information into/from the Global Data Space • QoS. Regulates the non-functional properties of information in the Global Data Space, e.g., reliability, availability, & timeliness, etc. Global Data Space
Comparing CORBA & DDS CORBA Characteristics Distributed object model Remote method calls Connection-oriented transport Best for Remote command processing File transfer Synchronous & asynchronous transactions Server Server Server Server Client Client Client Client • DDS Characteristics • Data distribution model • Relational collaborations • Multicast transport • Best for • Quick dissemination to many nodes • Dynamic networks • Flexible QoS & delivery requirements CORBA & DDS address different needs: Complex systems often need both
Distributed Application Planes Application Control Plane Data Plane Management Plane Data Plane • Ubiquitous, asynchronous, & real-time data access • One-to-many & many-to-many distribution patterns • Integration with Enterprise Data Layer, i.e., DBMS Control Plane • Synchronous Command/Control interactions, often to actuate commands • Mostly one-to-one interactions Management Plane • A combination of asynchronous real-time access of data & command/control interactions • One-to-one, one-to-many CORBA CORBA DDS DDS