1 / 18

CS 395-2 QoS-enabled Middleware Design & Application

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.

alaire
Download Presentation

CS 395-2 QoS-enabled Middleware Design & Application

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related