Transcript No Slide Title

CS 395-2
QoS-enabled Middleware Design & Application
Dr. Douglas C. Schmidt
[email protected]
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
•[email protected]
•Deepti’s office hours will be
announced shortly
•Please send all questions to
[email protected]
•I’ll send the answers to the
class mailing list
3
•Recommended reading
The Need for QoS-enabled Technologies
Scale
Real-Timeliness
Parallelism
Systemic
Signal
Processing
Data
Processing
Parallel Systems
Determinism
Real-Time Information
Processing
Throughput,
Availability
Near Real-Time FaultTolerant Information
PRocessing
Distributed Systems
Scalability, Persistence,
Security
Complex Information
Management
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
‣ 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
Interoperability
‣ Interoperability is a key enabler
for achieving better performance
& enabling new operational
requirements
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
7
There are multiple COTS
middleware layers &
research/business
opportunities
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
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
MIDDLEWARE ARCH
Middleware
Applications
HTTP
TELNET
DNS
UDP
Middleware
Services
TCP
Middleware
IP
Solaris
Fibre Channel
Ethernet
8
ATM
20th Century
FDDI
Win2K
VxWorks
Linux
LynxOS
21st Century
Host Infrastructure Middleware
•Host infrastructure middleware encapsulates & enhances
native OS mechanisms to create reusable network
programming components
Domain-Specific
Services
Common
Middleware Services
• These components abstract away many tedious & error-prone aspects of
low-level OS APIs
•Examples
•Java Virtual Machine (JVM), Common Language Runtime
(CLR), ADAPTIVE Communication Environment (ACE)
Asynchronous
Event Handling
Physical
Memory
Access
Memory
Management
9
Distribution
Middleware
Host Infrastructure
Middleware
Asynchronous
Transfer of
Control
Synchronization
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
Domain-Specific
Services
Common
Middleware Services
Distribution
Middleware
Host Infrastructure
Middleware
End-to-End Priority
Propagation
Client
OBJ
REF
Object
(Servant)
in args
operation()
out args + return
Scheduling
Service
IDL
SKEL
IDL
STUBS
Explicit
Binding
ORB CORE
Standard
Synchronizers
Thread
Pools
Object Adapter
Portable Priorities
GIOP
Protocol Properties
realtime.omg.org/
10
en.wikipedia.org/wiki/Data_Distribution_Service
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, Sun’s J2EE,
Microsoft’s .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
Boeing Bold Stroke
• Common software
platform for Boeing
avionics mission
computing systems
Modalities
e.g., MRI, CT, CR,
Ultrasound, etc.
12
Domain-Specific
Services
Common
Middleware Services
Distribution
Middleware
Host Infrastructure
Middleware
Overview of CORBA
IDL
Compiler
Interface
Repository
Client
OBJ
REF
Implementation
Repository
Object
(Servant)
in args
operation()
out args +
return
IDL
SKEL
DII
IDL
STUBS
ORB CORE
ORB
INTERFACE
DSI
Object Adapter
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
OBJ
REF
in args
operation()
Object
(Servant)
out args + return
Scheduling
Service
IDL
SKEL
IDL
STUBS
Explicit
Binding
ORB CORE
Standard
Synchronizers
Portable Priorities
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 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
Server
Server
• Distributed object model
• Remote method calls
• Connection-oriented transport
Client
Client
Server
Best for
 Remote command processing
Server
Client
Client
• File transfer
• Synchronous & asynchronous
transactions
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
Management Plane
• A combination of asynchronous real-time
access of data & command/control
interactions
• One-to-one, one-to-many
CORBA
DDS
Management Plane
Control Plane
• Synchronous Command/Control interactions,
often to actuate commands
• Mostly one-to-one interactions
Data Plane
Application
Control 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