Safe Specialization of the LwCCM
Container for Simultaneous Provisioning of
Multiple QoS
Akshay Dabholkar & Aniruddha Gokhale
Institute of Software Integrated Systems (ISIS),
Vanderbilt University, Nashville, TN, USA
Contact : aky@dre.vanderbilt.edu
Object Management Group Real-Time Workshop
(OMG RTWS 2011)
March 22-24, 2011, Washington DC, USA
Research supported by NSF CAREER CNS# 0845789, Vanderbilt Discovery
1
Context: Distributed RealReal-time Embedded (DRE) Systems
! Large-scale, systems-of-systems
! Operation in resource-constrained
environments
! Memory-constrained
! Low processor speeds
! Low power availability
! Stringent and simultaneous QoS demands
! High availability
! Timeliness
! Efficient resource utilization
! Examples
! Intelligent Transportation Systems (ITS)
! Inventory Tracking Systems
! NASA’s Magnetospheric Multi-scale mission
(MMS)
(Images courtesy: Google)
2
2
Overcoming Variability in DRE System Domain Concerns
Direct Application
Generalization
Maximize
Throughput
Resource
Constraine
d
Group
Failover
Semantics
Reconfigurable Conveyor Belt System
Intelligent Transportation System
Real Time
Updates
! Development via Generalpurpose Middleware
! Feature-rich
! Satisfies wide range of
DRE systems
! Uses extensible
frameworks
! CORBA, .NET, J2EE, etc.
Performance Requirements
Dependability Requirements
3
Impediments to Using GeneralGeneral-purpose Middleware
" General-purpose middleware
supports a wide range of DRE
systems
" However, individual DRE systems
have streamlined requirements
" Antagonistic Design Forces
! Excessive features due to wide
applicability
! Unnecessary overhead due to high
flexibility and configurability
! Moreover, focus is on horizontal
decomposition into layers
! Incurs time and space overhead due
to rigid layered processing
! Application concerns are tangled
across middleware modularization
boundaries
Need
Need Specialization
Specialization of
of GeneralGeneralpurpose
purpose Middleware
Middleware
4
Preferred Approach to Overcome Variability in DRE Systems
Direct Application
Generalization
Maximize
Throughput
Resource
Constraine
d
Group
Failover
Semantics
Reconfigurable Conveyor Belt System
Intelligent Transportation System
Real Time
Updates
Specialization
Specific Application
Dependability Requirements
Performance Requirements
5
What is Middleware Specialization?
# Resolves the tension between Generality and Specificity
# Creates specialized forms of middleware for each system by
! Pruning away unnecessary features based on system concerns
! Augmenting application-specificity by embedding their semantics
! Optimizing performance by moving away from the rigid layered
processing by creating specialized processing paths
Protocol
Interface
OBJ
REF
in args
operation()
out args +
return
Services
Interface
Component
(Servant)
IDL
SKEL
DII
Customized Middleware Stack
Services
Client
Component
Interface
DSI
Specialization
Container
IDL
STUBS
ORB CORE
ORB
INTERFACE
Object Adapter
GIOP/IIOP/ESIOPS
Standards-based, General-purpose,
Layered Middleware Stack
Specialized Middleware Stack
6
State of Art: Component Middleware QoS Provisioning
! Focus is on provisioning only one
QoS at a time in the middleware
container results in -
Component
Reference
Container
Callback
Interfaces
POA
ORB
Transactions
Event Receptacles
Sources
Event
Sinks
Internal
Interfaces
Facets
COMPONENT
EXECUTORS
Component
Component Context
Contex t
Component
Home
! Too proprietary, ad-hoc and custom
implementations
! Redundant, repetitive efforts requiring
reinvention of existing solutions
! Expensive to develop and maintain
! Hard to evolve over application lifetime
! Difficult to test for correctness and QoS
! Lack openness and interoperability
Security
APPLICATION SERVER
7
State of Art: Component Middleware QoS Provisioning
! Container architectures lack the
flexibility necessary for -
Component
Reference
Container
Callback
Interfaces
POA
ORB
Transactions
Security
APPLICATION SERVER
Event Receptacles
Sources
Event
Sinks
Internal
Interfaces
Facets
COMPONENT
EXECUTORS
Component
Component Context
Contex t
Component
Home
! Simultaneous QoS provisioning and
configuration while minimizing footprint
and runtime overhead
! Ensuring the correct configuration and
functioning of multiple QoS mechanisms in
unison
! Resulting Consequences ! Performance degradation and increase in
memory footprint if required to combine
QoS mechanisms
! Difficult to program and configure multiple
QoS mechanisms
8
Case Study 1: Provisioning Dynamic Component Swapping
Extends SessionContainer to
provide an execution environment
where Lightweight CCM
component implementations can
be instantiated, removed &
updated
Automatically generates
glue code for updating
component
SwapCIAO Architecture
Dynamically opens & loads
component implementations
during the component
swapping process
Stores component implementations that are
9
retrieved
by the updatable component factory
9 at
i
Case Study 2: Provisioning Reliability QoS
All client & server side
entities related to
FLARe are instantiated
in a component server
Host
Monitor
CORFU Architecture
Replication
Replication
Manager
Manager
Host
Monitor
Host
Host
Host
Monitor
Monitor
Monitor
Forwarding
Agent
Request
Interceptor
Component Implementation
instances are loaded into
the Container & are
automatically integrated into
FLARe
SSA
FLARe is a lightweight
approach based on passive
replication that provides
mechanisms for
1.Grouping of replica objects as
one logical application
2.Failure detection
3.Failover to backup replica
Archive
Stream
Admin
Container
IOR
Interceptor
HM
thread
Component
Component Server
Server
10
10
Case Study 3: Provisioning RealReal-Time QoS
Extends CIAO’s meta-model to make RT policies an integral part of CCM
Thread Pool A
Priority
30
5
Container
Component
Home
Callback
Interfaces
Container
Component
Home
External
Interfaces
External
Interfaces
4
Priority
60
5
CORBA
Component
1.Component default priority model
2.Override component priority model
3.Priority level of a component
instance
4.Defining thread pools
5.Associate thread pools with
containers
6.Specify queuing policies
7.Specify pre-connections and
private connections, bandedconnections
8.Configure ORB components
• Custom protocols
• Priority mappings
CORBA
Component
Callback
Interfaces
1
Internal
Interfaces
RT
POA
Internal
Interfaces
2
6
RT 3
POA
7
RT-ORB
8
RT Component Server
11
Shortcomings of current CCM QoS implementations
Chicago
Data
Center
San Jose
IT Department
State/Country
Point-of-Sale
Processing
Centers
Market
Analysis
Team
Central
Data
Store
1
Client
Middleware Bus
Component
Repository
Compose
Deploy
Online
Ordering
Server
Component
Assembly
2
1 UML Model
CoSMIC
Model
Interpreter &
Synthesizer
Component
Home
4
QoS Policies
QoS Property
Adaptor
3
select
components
5
6
CCM Component Library
Container
CORBA
Component
Reflect
System Development
POA
ORB
Metadata
ORB QoS Interfaces
(Scheduling,
Timeliness,Priority,...)
ORB Plugins
CIAO
ORB
! Integrating individual QoS
mechanisms directly within the
container doesn’t automatically ensure
multiple QoS support e.g., RTCCM ≠
CCM + RTCORBA
! CCM only enforces the specified QoS
policies, it does not ensure they are
correctly composed together
! Doesn’t take QoS4CCM specification
into account for the runtime QoS
management
! Does not enable selective
composability of the necessary QoS
mechanisms
Efficient Design and Safe Specialization of
the CCM Container for provisioning multiple
QoS
12
Current Status of CIAO
in args
5
IDL
ORB QoS
INTERFACE
STUBS
QoS
ADAPTATION
IOP
PLUGGABLE
ORB & XPORT
PROTOCOLS
OS KERNEL
REAL- TIME I/O
6
IDL
SKELS
REAL-TIME POA
PORTABLE
2
CORBA SERVICES
(SECURITY,
EVENTS ...)
COMPONENT
out args + return value IMPLEMENTATION
4
1
7
operation ()
CALLBACKS
CLIENT
8
HOME
IDL
SKELETON
REAL-TIME
OBJECT
ADAPTER
REAL-TIME ORB CORE
PLUGGABLE
ORB & XPORT
PROTOCOLS
3
ACE
COMPONENTS
IOP
OS KERNEL
REAL- TIME I/O
SUBSYSTEM
SUBSYSTEM
HIGH- SPEED
NETWORK INTERFACE
HIGH-SPEED
NETWORK INTERFACE
NETWORK
! CIAO : A LwCCM
implementation based on the
ACE ORB (TAO)
! Extends the (component and
assembly) descriptors for
configuring RT policies
! Applies reflective middleware
techniques to support other
non-functional aspects with
CCM metadata
! Bandwidth reservation
! Memory management
! Transport selection
1) COLLOCATION STUBS 5) COMPONENT QOS
2) COLLOCATION XPORT ADAPTATION
SELECTION
6) DYNAMIC LINKING OF
COMPONENT SERVANTS
3) SHARED MEMORY
XPORT
7) DYNAMIC CONFIGURATION OF
4) ORB LEVEL QOS
COMPONENTS
INTERFACE
8) INTEGRATION OF SERVICES
13
Work In Progress: A Generic Pluggable Container Architecture
Component Server
Client
in args
Object
Reference
operation ()
Component
Home
out args + return value
QoS
Mechanism
Plug-ins
Named Policy
Aggregate
CORBA
Component
Named
Policy
Aggregate
QoS
Adaptation
Component & Home Impls
QoS
Adaptation
QoS Policies
Component Connection
Specifications
Deploy
QoS
Adaptation
QoS
Mechanism
Plug-ins
Container
QoS Property
Adaptor
Deploy
Component Assembly
Reflect
Client
Configuration
Aggregate
QoS-POA
QoS Policies
QoS
Mechanism
Plug-ins
QoS-ORB
QoS
Mechanism
Plug-ins
QoS
Adaptation
! Pluggable and highly Composable Container Infrastructure and Framework
(IaFe) that provides:
1.
2.
3.
A Composition Framework for correctly plugging in the required QoS
mechanisms within the Containers based on deployment and QoS policies
A Scheduling Framework for the correct order of the instantiation of multiple
QoS mechanisms
A Runtime Framework for enabling dynamic configuration and adaptation of
QoS mechanisms
14
Questions?
15
Backup Slides
16
Provisioning Other QoS
External
Interfaces
Component
Home
SSL Container
CORBA
Component
Callback
Interfaces
Internal
Interfaces
POA
External
Interfaces
Component
Home
Transactional Container
CORBA
Component
Callback
Interfaces
Internal
Interfaces
POA
17