Upload
alaire
View
51
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Dr. Douglas C. Schmidt [email protected] 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. - PowerPoint PPT Presentation
Citation preview
CS 395-2CS 395-2QoS-enabled Middleware Design & QoS-enabled Middleware Design &
ApplicationApplication
Dr. Douglas C. [email protected]
www.dre.vanderbilt.edu/~schmidt/cs395/
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
•Recommended reading
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
•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
The Need for QoS-enabled Technologies
ScaleReal-Timeliness
Near Real-Time Fault-Tolerant Information
PRocessing
Near Real-Time Fault-Tolerant Information
PRocessing
Throughput, Availability
Real-Time Information Processing
Real-Time Information Processing
Determinism
Systemic Signal
Processing
Systemic Signal
Processing
Data Processing
Data Processing
Parallelism
Complex Information Management
Complex Information Management
Scalability, Persistence, Security
Parallel Systems Distributed Systems
• 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
The Need for QoS-enabled Technologies
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
Loosely Coupled & Plug & Play
‣ Ability seamlessly support MANET, VANET, time, & space decoupling
Interoperability
‣ Interoperability is a key enabler for achieving better performance & enabling new operational requirements
7
The Solution is in the Middleware
There are multiple COTS middleware layers & research/business
opportunities
Historically, mission-critical apps were built directly atop hardware•Tedious, error-prone, & costly over lifecycles
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
There are layers of middleware, just like there are layers of networking protocols
Hardware
Domain-SpecificServices
CommonMiddleware Services
DistributionMiddleware
Host InfrastructureMiddleware
& OS
Operating Systems & Protocols
Applications
8
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.
RTP
DNS
HTTP
UDP TCP
IP
TELNET
Ethernet ATM FDDI
Fibre Channel
FTP
INTERNETWORKING ARCH
TFTP
20th Century
Win2K Linux LynxOS
Solaris VxWorks
Middleware
MiddlewareServices
MiddlewareApplications
MIDDLEWARE ARCH
21st Century
9 www.cs.wustl.edu/~schmidt/ACE.html
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-SpecificServices
CommonMiddleware Services
DistributionMiddleware
Host InfrastructureMiddleware
Synchronization
MemoryManagement
PhysicalMemoryAccess
AsynchronousEvent Handling
Scheduling
AsynchronousTransfer of
Control
www.rtj.org
•Examples•Java Virtual Machine (JVM), Common Language Runtime (CLR), ADAPTIVE Communication Environment (ACE)
10
Distribution Middleware•Distribution middleware defines higher-level distributed programming models whose reusable APIs & components automate & extend native OS capabilities
Domain-SpecificServices
CommonMiddleware Services
DistributionMiddleware
Host InfrastructureMiddleware
Distribution middleware avoids hard-coding client & server application dependencies on object location, language, OS, protocols, & hardware
•Examples•OMG Real-time CORBA & DDS, Sun RMI, Microsoft DCOM, W3C SOAP
ClientOBJREF
Object(Servant)
in argsoperation()
out args + return
IDLSTUBS
IDLSKEL
Object Adapter
ORB CORE GIOP
Protocol Properties
End-to-End PriorityPropagation
ThreadPools
StandardSynchronizersExplicit
Binding
Portable Priorities
SchedulingService
en.wikipedia.org/wiki/Data_Distribution_Servicerealtime.omg.org/
11
Common Middleware Services•Common middleware services augment distribution middleware by defining higher-level domain-independent services that focus on programming “business logic”
Domain-SpecificServices
CommonMiddleware Services
DistributionMiddleware
Host InfrastructureMiddleware
•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
•Examples•CORBA Component Model & Object Services, Sun’s J2EE, Microsoft’s .NET, W3C Web Services
12
Domain-Specific Middleware
Modalitiese.g., MRI, CT, CR,
Ultrasound, etc.
Siemens MED Syngo• Common software platform for distributed electronic medical systems
• Used by all ~13 Siemens MED business units worldwide
•Domain-specific middleware services are tailored to the requirements of particular domains, such as telecom, e-commerce, health care, process automation, or aerospace
Domain-SpecificServices
CommonMiddleware Services
DistributionMiddleware
Host InfrastructureMiddleware
Boeing Bold Stroke • Common software
platform for Boeing avionics mission computing systems
•Examples
1313
Overview of CORBA
InterfaceRepository
IDLCompiler
ImplementationRepository
ClientOBJREF
Object(Servant)
in argsoperation()out args +
return
DIIIDL
STUBSORB
INTERFACE
IDLSKEL
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
1414
Overview of Real-time CORBA 1.0
ClientOBJREF
Object(Servant)
in argsoperation()
out args + return
IDLSTUBS
IDLSKEL
Object Adapter
ORB CORE GIOP
Protocol Properties
End-to-End PriorityPropagation
ThreadPools
StandardSynchronizersExplicit
Binding
Portable Priorities
SchedulingService
• 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
Global Data Space
• Loosely coupled• Plug & play architecture
with dynamic discovery
• Time & space decoupling
• Open standard• OMG DDS v1.2 latest
version www.omg.org/dds
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
ServerServer
ClientClient
ServerServer
ClientClient
ServerServer
ClientClient
ServerServer
ClientClient
CORBA Characteristics
• Distributed object model
• Remote method calls
• Connection-oriented transport
Best forRemote command processing
• File transfer
• Synchronous & asynchronous transactions
CORBA Characteristics
• Distributed object model
• Remote method calls
• Connection-oriented transport
Best forRemote command processing
• 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
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
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
Co
ntr
ol P
lan
eC
on
tro
l Pla
ne
Dat
a P
lan
eD
ata
Pla
ne
Man
agem
ent
Pla
ne
Man
agem
ent
Pla
ne
Application
CORBA
DDS
CORBA
DDS