CS 395-2

QoS-enabled Middleware Design & Application

Dr. Douglas C. Schmidt
d.schmidt@.vanderbilt.edu www.dre.vanderbilt.edu/~schmidt/cs395/ 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
2

CS 395 Course Information

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 Recommended reading

deepti.s.thopte@Vanderbilt.Edu
Deeptis office hours will be announced shortly Please send all questions to d.schmidt@vanderbilt.edu Ill send the answers to the class mailing list
3

The Need for QoS-enabled Technologies

Real-Timeliness
Scale

Parallelism

Determinism

Throughput, Availability
Near Real-Time FaultTolerant Information PRocessing

Scalability, Persistence, Security

Complex Information Management

Systemic Signal Processing

Data Processing

Real-Time Information Processing

Parallel Systems

Distributed Systems

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
Shared Operational Picture Interoperability

Increasing need in real-time

access to the common operational picture

Interoperability is a key enabler

for achieving better performance & enabling new operational requirements

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

Applications Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware Operating Systems & Protocols Hardware

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 reusable, offthe-shelf developer-oriented services

There are multiple COTS middleware layers & research/business opportunities

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 & remote interprocess communication (IPC) OS examples UNIX/Linux, Windows, VxWorks, QNX, etc. Protocol examples TCP, UDP, IP, SCTP, RTP, etc.
INTERNETWORKING ARCH RTP TFTP FTP HTTP MIDDLEWARE ARCH Middleware Applications

DNS UDP IP

TELNET TCP

Middleware Services
Middleware Solaris VxWorks Linux LynxOS

Fibre Channel Ethernet

8

ATM

FDDI

Win2K

20th Century

21st Century

Host Infrastructure Middleware

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

Examples Java Virtual Machine (JVM), Common Language Runtime (CLR), ADAPTIVE Communication Environment (ACE)
Asynchronous Event Handling Physical Memory Access

Asynchronous Transfer of Control

Synchronization

Memory Management
9

Scheduling

www.rtj.org

www.cs.wustl.edu/~schmidt/ACE.html

Distribution Middleware
Distribution middleware defines higher-level distributed programming models whose reusable APIs & components automate & extend native OS capabilities Examples OMG Real-time CORBA & DDS, Sun RMI, Microsoft DCOM, W3C SOAP
End-to-End Priority Propagation Client
in args operation() out args + return

Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware

OBJ REF

Object (Servant)

Scheduling Service IDL STUBS Explicit Binding ORB CORE Standard Synchronizers Portable Priorities IDL SKEL Thread Pools

Object Adapter

GIOP

Protocol Properties

realtime.omg.org/

en.wikipedia.org/wiki/Data_Distribution_Service

10

Distribution middleware avoids hard-coding client & server application dependencies on object location, language, OS, protocols, & hardware

Common Middleware Services

Common middleware services augment distribution middleware by defining higher-level domain-independent services that focus on programming business logic Examples CORBA Component Model & Object Services, Suns J2EE, Microsofts .NET, W3C Web Services
Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware

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
11

Domain-Specific Middleware
Domain-specific middleware services are tailored to the requirements of particular domains, such as telecom, ecommerce, health care, process automation, or aerospace
Examples Siemens MED Syngo Common software platform for distributed electronic medical systems Used by all ~13 Siemens MED business units worldwide
Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware

Boeing Bold Stroke Common software platform for Boeing avionics mission computing systems Modalities
e.g., MRI, CT, CR, Ultrasound, etc.
12

Overview of CORBA
Interface Repository IDL Compiler Implementation Repository

Client

OBJ REF

in args operation() out args + return

Object (Servant)

IDL SKEL DII IDL STUBS ORB INTERFACE

DSI

Object Adapter

ORB CORE

GIOP/IIOP/ESIOPS

CORBA shields applications from heterogeneous platform dependencies e.g., languages, operating systems, networking protocols, hardware

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

Overview of Real-time CORBA 1.0

Real-time CORBA adds QoS
End-to-End Priority Propagation Client
in args operation() out args + return

OBJ REF

Object (Servant)

Scheduling Service IDL STUBS Explicit Binding ORB CORE Standard Synchronizers Portable Priorities IDL SKEL Thread Pools

Object Adapter

GIOP

Protocol Properties

These capabilities address some (but by no means all) important real-time application development challenges

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

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

Server Server Client Server Server Client Client
CORBA Characteristics

Distributed object model Remote method calls Connection-oriented transport

Best for
Remote command processing

Client
DDS Characteristics Data distribution model Relational collaborations Multicast transport Best for Quick dissemination to many nodes Dynamic networks Flexible QoS & delivery requirements

File transfer Synchronous & asynchronous

transactions

CORBA & DDS address different needs: Complex systems often need both

Distributed Application Planes

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

Application
Management Plane

Control Plane

CORBA DDS

Data Plane