Tutorial on
CORBA Component Model (CCM)
and QoS-enabled CCM
Nanbor Wang
Washington University
St. Louis
Craig Rodrigues
BBN Technologies
December 3, 2003
Research Sponsored by DARPA/IXO
Motivation for QoS-enabled
CORBA Component Model
This slide has been removed for its size (10 MB.) You
can get it from:
http://www.cs.wustl.edu/~nanbor/presentations/TutorialCCM-Mot.ppt
Tutorial Topic Overview
MDA/MIC
Sophistication
(Increase Capability)
CIAO
QoS-CCM
CCM
RT
CORBA
DOC,
CORBA
RPC
1985
1990
1998
2003
2002
2005
• Motivations of CORBA Component
Model (CCM)
• Major CCM features*
– Component programming model
– Container Programming Model
– Component Implementation
Framework
– Packaging and deployment
• Motivations of QoS-enabled CCM
• Supporting static QoS provisioning in
CCM
• Integrating dynamic QoS provisioning
adaptive middleware with CCM
• Conclusions
Time
*Partially from: OMG CCM Tutorial by Phillipe Merle, et. al.
Limitation with the
CORBA 2.x Object Model
Interface
Repository
Client
IDL
Compiler
OBJ
REF
Object
(Servant)
in args
operation()
out args +
return
IDL
SKEL
DII
IDL
STUBS
ORB CORE
ORB
INTERFACE
• Application developers and
system integrators are forced to
play multiple roles
Implementation
Repository
– Application functional
component developers
• tightly coupled application
modules
DSI
Object Adapter
GIOP/IIOP/ESIOPS
– Computational resource
provisioners
• ensuring the availability of
common object services
• ad-hoc management
– System configurators
• Resulting in tight couplings
• boiler plate code
– Brittle, non-standard implementation
• manual application
– Hard to adapt and maintain
deployment
– Increase time-to-market
Promising Solution:
Component Models
Application
Assembler
&
Configurator
Container
Container
OS Adaptation Layer
OS
•J2EE (EJB), COM+ & CORBA Component
Model (CCM)
• Separating common concerns into aspects:
– Run-time environment configuration
– Connections between objects & run-time
– Composition of objects
• Support run-time object composition
– Component: a reusable entity
– Container: a standardized environment
for components to interact with run-time &
vice versa
– Component Server: a generic server
process (also called application server)
– Packaging and Assembling tools:
collection of tools to package and
compose components into deployable
assemblies
– Deployment mechanism: for deploying
component assemblies to component
servers
The CORBA Component Model (CCM)
Enhances CORBA Object Model
• Provides common run-time environment
– component servers
– containers
• Define Component Implementation
Framework
• Uses metadata to describe common
aspects in application composition,
resource allocation, and infrastructure
configurations
– component dependencies
– component connections
– component configuration
– component systemic requirements,
e.g., trading, transactional,
persistence state
The CCM Big Picture
implementer
designers
IDL/CIDL File User's Code
Home Properties
Component Properties
Programming
Language
Component
Interconnection
Definitions
Tools
IDL/CIDL
Default Properties
Compiler
Stubs, Skeletons Implementation
CORBA
Component
assembler
Package
Packaging
Tool
CORBA
Component
Assembly
Tool
Package
Component
Descriptor
User written file
Compiler/Tool
Generated files
packager
softpkg
Descriptor
Component
Assembly
Package
Assembly
Descriptor
CORBA
Component
Package
Deployment
Tool
deployer
Development via Composition
•
RateGenerator
RateGen
Pulse
Rate
HiResGPS
GPS
Refresh
Ready
MyLocation
cockpitDisplay
•
navDisplay
Refresh
GetLocation
Component Server
•
RateGenerator
– generates periodic “tick”
events to its “Pulse”
subscribers
HiResGPS, when receives a
“tick” event
– refreshes it’s cached
coordination which will be
available from “MyLocation”
facet
– propagates the “tick” event to
its Ready subscribers
cockpitDisplay, when receives a
“tick” event
– Reads a coordination from its
GetLocation receptacles
– Updates display
Component Features
Facets
Offered
Ports
Event
Sinks
Attributes
Event Receptacles
Sources
Component
Reference
Required
Ports
Component
Home
• Allows component designers to capture
the aspects on how CORBA
components are viewed by other
components and clients
– What a component offers to other
components
– What a component requires from
other components
– What collaboration modes are used
between components
• Synchronous via operation
invocation
• Asynchronous via event notification
– Which component properties are
configurable
– What the component life cycle
operations are (i.e. home)
• Maps to “Equivalent Interfaces”
A CORBA Component
interface rate_control
{
void start ();
void stop ();
};
component RateGen
supports rate_control
{
};
RateGen
Pulse
Rate
interface RateGen :
Components::CCMObject,
rate_control
{
};
• A component is a new CORBA meta-type
– Extension of Object
– Has an interface, and an object
reference
– Also, a stylized use of CORBA
interfaces/objects
• Provides component features (also
named ports)
• Could inherit from a single component
type
• Could supports multiple interfaces
• Each component instance is created and
managed by a unique component home
Component Attributes
typedef unsigned long
rateHz;
component RateGen
supports rate_control
{
attribute rateHz Rate;
};
RateGen
Pulse
Rate
interface RateGen :
Components::CCMObject,
rate_control
{
attribute rateHz Rate;
};
• Named configurable properties
– Vital key for successful re-usability
– Intended for component configuration
• e.g., optional behaviors, modality,
resource hints, etc.
– Could raise exceptions
– Exposed through accessors and
mutators
• Could be configured
– By visual property sheet mechanisms in
assembly or deployment environments
– By homes or during implementation
initialization
– Potentially readonly thereafter
Component Facets
interface position
{
long get_pos ();
};
component GPS
{
provides position
MyLocation;
…
};
GPS
Refresh
MyLocation
interface GPS :
Components::CCMObject
{
position
provide_MyLocation ();
…
};
Ready
• Distinct named interfaces that
provide the component’s
application functionality to
clients
• Each facet embodies a view of
the component, corresponds to
a role in which a client may act
relatively to the component
• A facet represents the
component itself, not a
separate thing contained by
the component
• Facets have independent
object references
Component Receptacles
component navDisplay
{
…
uses position GetLocation;
…
};
navDisplay
Refresh
GetLocation
interface navDisplay :
Components::CCMObject
{
…
void connect_GetLocation (in position c);
position disconnect_GetLocation();
position get_connection_GetLocation ();
…
};
• Distinct named connection points
for potential connectivity
– Ability to specialize by
delegation, compose functions
– The bottom of the Lego, if you
will
• Store a single reference or multiple
references
• Configuration
– Statically during initialization
stage or assembly stage
– Dynamically managed at
runtime to offer interactions with
clients or other components
(e.g. callback)
Component Events
eventtype tick
{
public rateHz rate;
};
valuetype tick :
Components::EventBase
{
public rateHz rate;
};
interface tickConsumer :
Components::EventConsumerBase
{
void push_tick
(in tick the_tick);
};
• Simple publish / subscribe event
model
– “push” mode only
– Sources (2 kinds) and sinks
• Events are value types
– Defined with the new
eventtype meta-type
– valuetype specialization for
component events
Component Event Sources
component RateGen
{
publishes tick Pulse;
…
• Named connection points for event
production
– Push a specified eventtype
};
RateGen
Pulse
Rate
interface RateGen :
Components::CCMObject
{
Components::Cookie
subscribe_Pulse
(in tickConsumer c);
trippedConsumer
unsubscribe_Pulse
(in Components::Cookie ck);
…
};
• Two kinds: Publisher & Emitter
– publishes = multiple client
subscribers
– emits = only one client
connected
• Client subscribes or connects to
directly component event source
• Container mediates access to
CosNotification channels
– scalability, quality of service,
transactional, etc.
Component Event Sinks
• Named connection points
into which events of a
specific type may be
pushed
component navDisplay
{
…
consumes tick Refresh;
};
navDisplay
Refresh
GetLocation
interface navDisplay :
Components::CCMObject
{
…
tickConsumer get_consumer_Refresh ();
…
};
• Subscription to event
sources
– Potentially multiple (n to 1)
• No distinction between
emitter and publisher
– Both push in event sinks
Navigation and Introspection
interface Navigation
{
Object provide_facet
(in FeatureName name);
FacetDescriptions get_all_facets();
FacetDescriptions get_named_facets
(in NameList names);
boolean same_component
(in Object object_ref);
};
interface CCMObject :
Navigation,
Receptacles,
Events
{
CORBA::IRObject
get_component_def ( );
CCMHome get_ccm_home( );
PrimaryKeyBase get_primary_key( );
void configuration_complete( );
void remove();
ComponentPortDescription
get_all_ports ();
};
•
Navigation from any facet to component base
reference with
CORBA::Object::get_component()
– Returns nil if target isn’t a component facet
– Returns component reference otherwise
•
Navigation from component base reference to
any facet via generated facet-specific
operations
•
Navigation and introspection capabilities
provided by CCMObject
– Via the Navigation interface for facets
– Via the Receptacles interface for receptacles
– Via the Events interface for event ports
•
Generic ports operations for provides, uses,
subscribes, emits, and consumes.
A CORBA Component Home
home RateGenHome
manages RateGen
{
factory create_pulser
(in rateHz r);
};
RateGenHome
RateGen
Rate
Pulse
interface RateGenHomeExplicit :
Components::CCMHome
{
RateGen create_pulser
(in rateHz r);
};
interface RateGenHomeImplicit :
Components::KeylessCCMHome
{
RateGen create ();
};
interface RateGenHome :
RateGenHomeExplicit,
RateGenHomeImplicit
{};
• home is a new CORBA meta-type
– Home definition is distinct from
component one
– Has an interface, and an object
reference
• Manages a unique component type
– More than one home type can
manage the same component
type
– But a component instance is
managed by a single home
instance
• Could inherit from a single home type
• Could supports multiple interfaces
• Is instantiated at deployment time
Component Home Features
CCMHome
+get_component_def() : IRObject
+get_home_def() : IRObject
+remove_component(in comp : CCMObject) : void
• Allows life cycle characteristics or key type to vary/evolve
without changing component definition
• Optional use of primarykey for business component identity
and persistency primary key
• Standard factory and finder business logic operations
• Extensible with arbitrary user-defined business logic operations
Primary Keys
•
Values exposed to clients to create, find, and
destroy component instances
– Uniquely identifies a component instance
within a home
– Assigned at creation time, or in pre-existing
database
– Must be a value type derived from
Components::PrimaryKeyBase (empty,
abstract)
•
Association between a primary key and a
component is defined and maintained by its home
– Different home types may define different key
types (or no key) for the same component
type
– Primary key is not necessarily a part of the
component’s state
Obj1
Obj2
Obj3
Obj4
Obj5
finder
Obj6
Object
Store Obj7
Obj8
Obj9
ObjA
ObjB
ObjC
PrimaryKey
The Container Model
Component
Home
Container
CORBA
Component
External
Interfaces
External
Interfaces
Component
Home
Callback
Interfaces
Internal
Interfaces
•
A framework for component
application servers
•
Mostly built on the Portable Object
Adaptor
– Automatic activation /
deactivation
– Resource usage optimization
•
Provides simplified interfaces for
CORBA Services
– Security, transactions,
persistence, and events
•
Uses callbacks for instance
management
Component and home references
are exported through Component
HomeFinder, Naming, or Trader
services
Container
CORBA
Component
Callback
Interfaces
Internal
Interfaces
POA
POA
ORB
•
Transaction
Persistent State
Security
Notification
Component Categories
COMPONENT CONTAINER CONTAINER EXTERNAL EJB BEAN
CATEGORY
IMPL TYPE TYPE
TYPE
EQUIVALENT
Service Stateless Session Keyless Session
(stateless)
Session Conv
Session Keyless Session
(stateful)
Process Durable Entity
Entity
Durable Entity
Keyless ----Keyfull Entity
Container Managed Policies
• Policy declarations defined for:
– Servant Lifetime
– Transaction
– Security
– Events
– Persistence
External
Interfaces
• Implemented by the container,
not the component
SSL Container
CORBA
Component
Callback
Interfaces
Internal
Interfaces
POA
Component
Home
External
Interfaces
• Specified by the deployer using
an XML vocabulary
Component
Home
Transactional Container
CORBA
Component
Callback
Interfaces
Internal
Interfaces
POA
Component Implementation Framework
•
CIF defines a programming model for
constructing component implementations
– How components should be
implemented
•
Facilitates component implementation
– “only” business logic should be
implemented
RateGen
Pulse
Rate
• Not activation, identify, port management
and introspection
=> Local server-side OMG IDL mapping
import RateGenHome;
composition session HouseBrew
{
home executor
RateGenHomeExec
{
implement RateGenHome;
manages RateGenExec;
};
};
• Interactions between implementations
and containers
•
Manages segmentation and persistency
=> Component Implementation Definition
Language
The Server-Side
OMG IDL Mapping
Component
Client
Client
Application
Component
Designer
Component
Implementer
OMG IDL
3.0
Component
Executor
uses
implemented by
OMG IDL
3.0
Compiler
Client-side
OMG IDL 2.x
User written
Compiler
Generated files
implemented by
Client
Stub
Local
server-side
OMG IDL 2.x
delegates to
ORB
Component
Skeleton
Executors and
Home Executors
• Programming artifacts implementing a
component’s or component home’s
behavior
External
Interfaces
Component
Home
Container
– Local CORBA objects with interfaces
defined by the local server-side OMG IDL
mapping
CORBA
Component
Internal
Interfaces
POA
Main
Component
Executor
Component
Specific
Context
CCMContext
Executors
Executors
Executors
CCMContext
EnterpriseComponent
– All component attributes, supported
interfaces, facet operations, and event
sinks implemented by one class
• Component executors could also be
segmented
– Component features split into several
classes
– Implements ExecutorLocator
interface
• Home executors are always monolithic
Servant
Container
• Component executors could be
monolithic
POA
A Monolithic
Component Executor
Component container
Monolithic executor
Component
specific
context
Container context
Main component executor interface
Facet or event sink executor interface
SessionComponent or EntityComponent
Component-oriented context interface
Container-oriented context interface
Context use
Container interposition
Main Server-Side
OMG IDL Mapping Rules
•
Main
Component
Executor
• Inheriting from
Components::EnterpriseComponent
Component
Specific
Context
– The monolithic component executor interface
CCMContext
• Operations to obtain facet executors and
receive events
Executors
Executors
Executors
– The component specific context interface
CCMContext
• Operations to access component receptacles
and event sources
EnterpriseComponent
Servant
POA
Container
«local»
EnterpriseComponent
•
«local»
SessionComponent
+set_session_context(in cts : SessionContext) : void
+ccm_activate() : void
+ccm_passivate() : void
+ccm_remove() : void
EntityComponent
+set_entity_context(in ctx : EntityContext) : void
+unset_entity_context() : void
+ccm_activate() : void
+ccm_load() : void
+ccm_store() : void
+ccm_passivate() : void
+ccm_remove() : void
A component type is mapped to three local
interfaces
– The main component executor interface
A home type is mapped to three local interfaces
– One for explicit operations user-defined
• Inheriting from
Components::HomeExecutorBase
– One for implicit operations generated
– One inheriting from both previous interfaces
Executors Are Hosted by Container
Main
Component
Executor
Component
Specific
Context
CCMContext
Executors
Executors
Executors
CCMContext
EnterpriseComponent
Servant
Container
POA
«local»
CCMContext
+get_caller_principal() : Principal
+get_CCM_home() : CCMHome
+get_rollback_only() : boolean(idl)
+get_user_transaction() : UserTransaction
+is_caller_in_role(in role : string(idl)) : boolean(idl)
+set_rollback_only() : void
«local»
SessionContext
+get_CCM_object() : object(idl)
«local»
EntityContext
+get_CCM_object() : object(idl)
+get_primary_key() : PrimaryKeyBase
• Container intercepts invocations on
executors
for managing activation, security,
transactions, persistency, and so
• Component executors must implement
a local callback lifecycle interface used
by the container
– SessionComponent for transient
components
– EntityComponent for persistent
components
• Component executors could interact
with their containers and connected
components through
a local context interface
Component “RateGen”
Implementation Examples
local interface CCM_rate_control :
rate_control {};
interface rate_control
{};
component RateGen
supports rate_control
{
publishes tick Pulse;
RateGen
attribute rateHz Rate;
Pulse
};
// Component’s main executor
local interface CCM_RateGen_Executor
: Components::EnterpriseComponent,
rate_control
{
attribute rateHz Rate;
};
Rate
interface RateGen :
Executor
Components::CCMObject,
Mappings
rate_control
{
Components::Cookie
subscribe_Pulse
(in tickConsumer c);
tickConsumer
unsubscribe_Pulse
(in Components::Cookie c);
attribute rateHz Rate;
};
// Monolithic
local interface CCM_RateGen
: CCM_RateGen_Executor
{
attribute rateHz Rate;
};
local interface CCM_RateGen_Context
: Components::CCMContext
{
void push_Pulse (in tick ev);
};
C++ Component “RateGen”
Implementation Examples
local interface CCM_rate_control :
rate_control {};
// Component’s main executor
local interface CCM_RateGen_Executor
: Components::EnterpriseComponent,
rate_control
{
attribute rateHz Rate;
RateGen
};
Pulse
// Monolithic
local interface CCM_RateGen
: CCM_RateGen_Executor
{
attribute rateHz Rate;
};
Rate
local interface CCM_RateGen_Context
: Components::CCMContext
{
void push_Pulse (in tick ev);
};
Implementation
class rategen : public ACE_Task
{
public:
int svc ()
{
while (active) {
sleep (idle);
push_Pulse (…);
};
}
};
class MyRateGen_Impl :
public virtual CCM_RateGen
{
public:
MyRateGen_Impl ();
void start ()
{ /* start generating pulse */; }
void stop ()
{ /* stop pulse generating */ }
};
Home “RateGenHome”
Implementation Examples
home RateGenHome manages RateGen
{};
interface RateGenHomeExplicit :
Components::CCMHome
{};
interface RateGenHomeImplicit :
Components::KeylessCCMHome
{
RateGen create ();
};
interface RateGenHome :
RateGenHomeExplicit,
RateGEnHomeImplicit
{};
local interface CCM_RateGenHomeExplicit :
Components::HomeExecutorBase
{};
local interface CCM_RateGenHomeImplicit
{
Components::EnterpriseComponent
create ();
};
local interface CCM_RateGenHome :
CCM_RateGenHomeExplicit,
CCM_RateGenHomeImplicit
{}
Impl
class RateGenHome_Impl :
public virtual CCM_RateGenHome
{
public:
Components::EnterpriseComponent_ptr
create ()
{ return new MyRateGen_Impl; }
};
extern “C” {
Components::HomeExecutorBase_ptr
create_RateGenHome ()
{ return new RateGenHome_Impl; }
}
Component “GPS”
Implementation Examples
interface position
{
long get_pos ();
};
component GPS
{
provides position
MyLocation;
};
GPS
Refresh
Ready
MyLocation
Executor
Mappings
interface GPS :
Components::CCMObject
{
position
provide_MyLocation ();
};
local interface CCM_position :
position
{};
// Component’s main executor
local interface CCM_GPS_Executor
: Components::EnterpriseComponent
{
};
// Monolithic
local interface CCM_GPS
: CCM_GPS_Executor
{
CCM_position get_MyLocation ();
};
local interface CCM_GPS_Context
: Components::CCMContext
{
};
C++ Component “GPS”
Implementation Examples
local interface CCM_position :
position
{};
class position_Impl :
public virtual CCM_position
{
public:
position_Impl ();
// Component’s main executor
local interface CCM_GPS_Executor
: Components::EnterpriseComponent
{
};
CORBA::Long get_pos ()
{ return /* pos encoder value */; }
};
GPS
// Monolithic
Refresh Ready
local interface CCM_GPS
: CCM_GPS_Executor
MyLocation
{
CCM_position get_MyLocation ();
};
local interface CCM_GPS_Context
: Components::CCMContext
{
};
Implementation 1
class GPS_Impl :
public virtual CCM_GPS,
public virtual position_Impl
{
public:
CCM_position_ptr get_MyLocation ()
{ return
CCM_position::_duplicate (this); }
};
Using
Inheritance
C++ Component “GPS”
Implementation Examples
local interface CCM_position :
position
{};
// Component’s main executor
local interface CCM_GPS_Executor
: Components::EnterpriseComponent
{
};
GPS
// Monolithic
Refresh Ready
local interface CCM_GPS
: CCM_GPS_Executor
MyLocation
{
CCM_position get_MyLocation ();
};
local interface CCM_GPS_Context
: Components::CCMContext
{
};
Implementation 2
class position_Impl :
public virtual CCM_position
{
public:
position_Impl ();
CORBA::Long get_pos ()
{ return /* pos encoder value */; }
};
class GPS_Impl :
public virtual CCM_GPS
{
CCM_position_ptr the_position_;
public:
GPS_Impl ()
{ this->the_position_ =
new position_Impl; }
CCM_position_ptr get_MyLocation ()
{ return
CCM_position::_duplicate
(this->the_position_); }
};
Using
Delegation
Component Packaging Artifacts
IDL/CIDL File
User's Code
Programming
Language
Tools
IDL/CIDL
Compiler
Home Properties
Default Properties
Stubs, Skeletons
Component Properties
CORBA
Component
Package
Implementation
Packaging
Tool
CORBA
Component
Package
Assembly
Tool
Component
Assembly
Package
Component
Descriptor
Assembly
Descriptor
softpkg
Descriptor
CORBA
Component
Package
Deployment
Tool
Packaging and Deployment
Home Properties
Default Properties
CORBA
Implementation
Package
Packaging
Tool
CORBA
Component
Package
Component
Descriptor
packager
softpkg
Descriptor
• “Classic” CORBA: No standard
means of ...
– Configuration
– Distribution
– Deployment
• Packaging and Deployment of
Components
– Components are packaged into
a self-descriptive package
– Packages can be assembled
– Assemblies can be deployed
• Helped by XML descriptors
Component Packaging
IDL
User
Code
Generated
Code
IDL/CIDL
Compiler
Compiler
Shared
Library or
Executable
Component
Descriptor
Default
Properties
Packaging
Tool
Component
Package
.zip
Component Assembly Artifacts
IDL/CIDL File
User's Code
Programming
Language
Tools
IDL/CIDL
Compiler
Default Properties
Stubs, Skeletons
Home Properties
Component Properties
CORBA
Component
Package
Implementation
Packaging
Tool
CORBA
Component
Package
Assembly
Tool
Component
Assembly
Package
Component
Descriptor
Assembly
Descriptor
softpkg
Descriptor
CORBA
Component
Package
Deployment
Tool
Component Assembly
Component
Package
Component
Package
Instance
Creation
Port
Connections
Assembly
Tool
Component
Package
Properties
...
Assembly
Archive
.aar (ZIP)
Deployment
Tool
XML Descriptors Overview
Component
Assembly
Descriptor
Software
* Package
Descriptor
• Software Package Descriptor (.csd)
– Describes contents of a component software
package
– Lists one or more implementation(s)
• CORBA Component Descriptor (.ccd)
– Technical information mainly generated from CIDL
– Some container managed policies filled by user
• Component Assembly Descriptor (.cad)
– Describes initial virtual configuration
• homes, component instances, and connections
• Component Property File Descriptor (.cpf)
– name/value pairs to configure attributes
CORBA
* Component
Descriptor
Component
Property
*
File
Descriptor
Example Assembly Descriptors
RateGen
Pulse
Rate
RateGenerator
GPS
Refresh
navDisplay
Ready
Refresh
GetLocation
MyLocation
HiResGPS
cockpitDisplay
<!– Associate components with impls -->
<componentfiles>
<componentfile id=“RateGenerator">
<fileinarchive name=“HouseRateGen.csd"/>
</componentfile>
<componentfile id=“HiResGPS">
<fileinarchive name=“aGPS.csd"/>
</componentfile>
<componentfile id=“cockpitDisplay">
<fileinarchive name=“navDisplay-if.csd"/>
</componentfile>
</componentfiles>
Example Assembly Descriptors (2)
<!– Instantiating component homes/instances -->
<partitioning>
<hostcollocation>
...
<homeplacement id=“RateGeneratorHome">
<componentfileref idref=“RateGenerator"/>
<componentinstantiation id=“NavRateGen">
<componentproperties>
<fileinarchive name=“NavRateGen.cpf"/>
</componentproperties>
</componentinstantiation>
</homeplacement>
...
</hostcollocation>
</partitioning>
• An assembly descriptor
specifies how homes and
components should be
instantiated
• A component property file
(.cpf) can be associated
with a home or a component
instantiation to override
default component
properties
Example Assembly Descriptors (3)
RateGen
Pulse
Rate
GPS
Refresh
Ready
MyLocation
navDisplay
Refresh
GetLocation
RateGenerator HiResGPS cockpitDisplay
• Assembly descriptors also
specify how component
instances are connected
together
<connections>
...
<connectinterface>
<usesport>
<usesidentifier>GetPosition</usesidentifier>
<componentinstantiationref idref=“cockitDisplay"/>
</usesport>
<providesport>
<providesidentifier>
MyLocation
</providesidentifier>
<componentinstantiationref idref=“HiResGPS"/>
</providesport>
</connectinterface>
<connectevent>
<consumesport>
<consumesidentifier>Refresh</consumesidentifier>
<componentinstantiationref idref=“HiResGPS"/>
</consumesport>
<publishesport>
<publishesidentifier>
Pulse
</publishesidentifier>
<componentinstantiationref
idref=“RateGenerator"/>
</publichesport>
</connectevent>
...
</connections>
Current CCM Fails to Address
Advanced QoS Requirements
Container
Component
Home
Callback
CORBA
Interfaces
Component
External
Interfaces
External
Interfaces
QoS-enabled CCM ≠
CCM + RT CORBA
Why doesn't running a RT ORB
beneath CCM make it a QoS-enabled
CCM implementation?
Container
Component
Home
Callback
CORBA
Interfaces
Component
Internal
Interfaces
Internal
Interfaces
RT
POA
RT-ORB
RT Component Server (?)
RT
POA
• Applications requires a wide variety of
infrastructure support, e.g., QoS guarantees
• Plain CCM has no mechanisms to specify and
enforce real-time QoS policies
• QoS policies need to be assured end-to-end
for components & connections
• Ensuring QoS policies in component
implementations leads to:
– QoS mechanisms that are hard to utilize
and go beyond component
implementations
• Component connections
– private connections
– bandwidth reservation
• Component collaborations
– Thread pools
– Thread borrowing
– Tight couplings among component
implementations
– Difficulty in reusing existing components
(without QoS knowledge)
QoS-Enabled Component Middleware
Extend component middleware
to support more advanced infrastructure and
resource management
Deployment
&
Configuration
Mechanism
Client
Configuration
Aggregate
Client
in args
•
•
– Application component developers
– QoS assurance mechanism
developers
– QoS provisioning managers
– ORB configurators
Component
Assembly
•
Component Server
out args + return
value
– Application-specific Adaptive
Trading
Component
Containers
QoS
Mechanism
Plug ins
Compose QoS assurance
mechanisms
– ORB – OS
Operation ()
QoS
Adaptation
Separate the concerns for QoS
managements
Separate the roles
ORB
QoS
Adaptation
Logging
Component
Containers
QoS
Mechanism
Plug ins
•
Specify metadata for QoS
requirements of
– components
– component connections
Specifying QoS Policies in
CCM Applications
Require highest priority
Reserve 30% processor cycles
Run at client priority
Reserve bandwidth
Do not share the connection
Deployment
&
Configuration
Metadata
Deployment
&
Configuration
Mechanism
Trading
Component
Containers
Logging
Component
Containers
Component Server
• Context:
– Delay specifying QoS policies
till application composition time
• Problems:
– CCM specification doesn’t
consider QoS policies
– QoS policies usually managed
via ad-hoc interfaces, e.g., RT
policies
– QoS Policies can bind to either
• Components
• Connections
• Solution Approach:
– Extend composition metadata to
incorporate QoS policies
Configuring Component Adaptation
Container
Component
Home
CORBA
Component
•
QoS Policies
QoS Property
Adaptor
Client
Real-time POA
ORB QoS Interfaces
(Scheduling, Timeliness, Priority,...)
•
•
Context:
– Many QoS properties need to be
enforced end-to-end
– We need to apply metaprogramming techniques to insert
adaptive behaviors
Problem:
– Components need to adapt as a
whole, not as multiple individual
interfaces
Solution Approach:
– Apply reflective middleware
technologies to containers
– Develop QoS-enabled containers
in CCM
Supporting QoS Assurance
Mechanisms
CORBA
Component
QoS Policies
QoS Property
Adaptor
Real-time POA
ORB QoS Interfaces
Scheduling
RSVP
Replicate
Service
Component
Assembly
Reflect
Container
Component
Home
ORB-specific
QoS
Assurance
Mechanisms
• Context:
– Modern applications need to
leverage various QoS
assurance mechanisms
• Problems:
– No standard way to support
these QoS mechanisms
– knowledge of ORB internals
required a priori
– Unforeseen QoS assurance
mechanisms
• Solution Approach:
– Configure the middleware
reflectively and dynamically
– Extend and implement CCM
deployment mechanisms to
describe and deploy ORB
modules
QoS Assurances Require End-to-end
Enforcement
•
CCM Container
Object
(Servant)
Client
in args
Operation ()
Smart Proxy
Client-side
meta-object
(Stub)
Client
Request
Interceptor
out args + return
value
ORB
Interfaces
Server
Request
Interceptor
Server-side
meta-object
(Skeleton,
DSI)
Servant
Manager Impl
DII
QoS Enforce
Mechanisms
Instantiates
•
QoS Control
Interfaces
Object store
meta-object
ORB Core
POA
QoS Enforce
Mechanisms
Interacts
•
Context:
Many QoS properties
– need to be enforced end-to-end
– require some degree of
adaptation
Problem:
– Lack of standard interaction
model with QoS mechanisms
Solution Approach:
– Apply meta-programming
techniques
– Extend and Implement CCM
metadata to configure and
compose interceptors/smart
proxies
Configuring Client-side Adaptation
•
www.krones.com
•
Context:
– We are applying metaprogramming techniques to insert
adaptive behaviors for QoS
requirements
– Objects with same interface may
require different adaptive
behaviors
Problem:
– Coarse-grained existing metaprogramming support
•
•
Still
Image
Camera
ImageRecognizer:ImageConsumer
QALogger:ImageConsumer
On Board Controller
•
Smart proxies – all references
Interceptors – all invocations
Solution Approach:
– Control effective metamechanisms through CORBA
policies
– Utilizing extension interface
pattern
Client-side Policy Aggregates
•
Best Effort NPA
Low B/W Adapt
NPA
Client Policy
Assembly
•
Fast Response
NPA
Logging NPA
ORB QoS Interfaces
Scheduling
RSVP
Replicate
Service
Client-side ORB
NPA: Named Policy Aggregate
ORB-specific
QoS
Assurance
Mechanisms
Context:
– Modern systems often require multiple
QoS assurance mechanisms
– Objects often require multiple
adaptive behaviors
Problem:
– Ad-hoc configuration interfaces
• Brittle client-side implementation
• Difficult to update matching
client/server policies requiring end-toend assurance
•
Solution Approach:
– Configure ORB dynamically thru a
CCM assembly-like configuration
mechanisms
– Define policy aggregates dynamically
using metadata (using Extension
Interface pattern)
Static QoS Provisioning in ComponentIntegrated ACE ORB (CIAO)
Client
Configuration
Aggregate
Component Assembly
Component & Home Impls
QoS
Adaptation
Component Connection
Specifications
QoS
Mechanism
Plug ins
Deployment
&
Configuration
Mechanism
Client
Component
Home
Operation ()
out args + return value
CORBA
Component
Named
Policy
Aggregate
Container
QoS
Adaptation
QoS Policies
QoS Property
Adaptor
QoS
Adaptation
QoS
Mechanism
Plug ins
QoS
Adaptation
Component Server
in args
Object
Reference
QoS
Mechanism
Plug ins
Reflect
Named
Policy
Aggregate
QoS Policies
Real-time POA
RT-ORB
QoS
Mechanism
Plug ins
• Extension to component
assembly descriptors
– Component and
connection QoS
specifications
– ORB modules
– Adaptation modules
• QoS-enabled containers
• Policy-based adaptation
insertion
• Client-side policy aggregates
• Integrating RT-CORBA &
ACE QoS API (AQoSA)
Examples of Static QoS Provisioning
•We are extending CIAO’s meta-model to make RT policies an integral part
of CCM
1. Component default priority model
Thread Pool A
Priority
30
Priority
60
5
Container
Component
Home
Callback
Interfaces
Container
Component
Home
External
Interfaces
External
Interfaces
5
CORBA
Component
4
CORBA
Component
Callback
Interfaces
1
Internal
Interfaces
2
RT
POA
Internal
Interfaces
6
RT 3
POA
7
RT-ORB
RT Component Server
8
2. Override component priority
model
3. Priority level of a component
instance
4. Defining thread pools
5. Associate thread pools with
components
6. Specify queuing policies
7. Specify pre-connections and
private connections
8. Configure ORB components
• Custom protocols
• Priority mappings
RTCCM Descriptor Examples
<corbacomponent>
...
<ciao:prioritymodelpolicy name=“priority_model_policy"
value=“SERVER_DECLARED”
priority=“20”/>
...
</corbacomponent>
<partitioning>
<processcollocation>
...
<homeplacement id=“RateGeneratorHome">
<componentfileref idref=“RateGenertor"/>
<componentinstantiation id=“NavRateGen">
<componentproperties>
<fileinarchive name=“NavRateGen.cpf"/>
<ciao:rtprioritylevel value="60"/>
</componentproperties>
</componentinstantiation>
</homeplacement>
...
</processcollocation>
</partitioning>
•
•
•
•
•
•
Component default priority
model
Can be in cpf
Override component priority
model
Specify the priority level of a
component instance
Associate component
instances with customized
protocol
Can also be in cpf
RTCCM Descriptor Examples (cont.)
<componentassembly>
...
<partitioning>
<ciao:createthreadpool id="tp_a" priority="30"
number="10"/>
<ciao:createthreadpoolwithlane id="tp_l">
<ciao:prioritylevel lane="30" number="3"/>
<ciao:prioritylevel lane="60" number="3"/>
<ciao:prioritylevel lane="80" number="10"/>
</ciao:createthreadpool> …
<homeplacement id=“HiResGPSHome">
<componentfileref idref=“HiRes"/>
<componentinstantiation id=“GPS">
<componentproperties>
<fileinarchive name=“HiResGPS.cpf"/>
<ciao:usethreadpool idref="tp_a"/>
</componentproperties>
</componentinstantiation>
</homeplacement>
<homeplacement id=“cockpitDisplay”>
<componentinstantiation id=“navDisplay">
<componentproperties>
<fileinarchive name=“cockpitDisplay.cpf"/>
<ciao:usethreadpoolwithlane idref="tp_l"
lane="60"/>
</componentproperties>
</componentinstantiation>
</homeplacement>
•
•
Define thread pools
Define QoS aggregates
•
Associate thread pools
with components
Associate QoS
aggregates with
connections
•
Overview of
Dynamic QoS Provisioning
• General introduction to Quality Objects (QuO)
• Code example for building a Qosket in UAV
application
• Issues for integrating QoS adaptive middleware in a
component model
The Quality Objects (QuO) Framework Supports
Development of Distributed Applications with QoS
• Specifying and enforcing stringent QoS requirements for
DRE applications is very difficult with existing middleware.
• BBN QuO works on top of DOC middleware to allow
developers to develop QoS-enabled DRE applications, such
as the UAV
What QuO Middleware
Provides the QoS Developer
• Separation of concerns between software functional
properties and QoS needs
• Consistent interfaces for QoS measurement and resource
management control
• Standard middleware interfaces between application and
QoS-provider layers
• Facilities for application level-adaptation
• Off-the-shelf mechanisms and behaviors for QoS
management
CORBA DOC MODEL
QuO Adds Specification, Measurement, and Adaptation
into the Distributed Object Model
in args
CLIENT
OBJECT
operation()
OBJ
REF
(SERVANT)
out args + return value
IDL
SKELETON
IDL
STUBS
ORB
Network
IIOP
IIOP
in args
QUO/CORBA DOC MODEL
Application
Developer
CLIENT
(SERVANT)
out args + return value
Contract
Contract
Delegate
SysCond
SysCond
IDL
SysCond
Delegate
SysCond
ORB
Network
Application
Developer
QuO
Developer
IDL
MECHANISM/PROPERTY
MANAGER
SKELETON
STUBS
IIOP
Mechanism
Developer
ORB
OBJECT
operation()
OBJ
REF
OBJECT
ADAPTER
IIOP
ORB
OBJECT
ADAPTER
Mechanism
Developer
QuO Provides In-Band and
Out-of-Band Measurement
• In-band measurement
handled by instrumentation
– A structure is transparently
passed along with the
method call/return
– Information can be
inserted, read, and
processed to record and
evaluate method call
statistics (e.g., the time
spent in marshalling)
• Out-of-band measurement
provided by system condition
objects
in args
C L IE N T
O B JE C T
op eration ()
OBJ
REF
(S E R V A N T )
ou t args + retu rn valu e
C ontract
C ontract
D eleg a te
D eleg a te
S ysC ond
S ysC ond
S ysC ond
ID L
S ysC ond
M E C H A N IS M /P R O P E R T Y
M ANAGER
ID L
SK ELETO N
STU BS
ORB
S im p le
V alu e
M easu red
V alu e
(S en so r)
IIO P
C o m p o sed
V alu e
N etw ork
C o n tro l
V alu e
C o n tro l
V alu e
IIO P
S tatu s
V alu e
O B JE C T
ADAPTER
ORB
A p p lic a tio n
D e v e lo p e r
Q oS
D e v e lo p e r
Q u O K ern el
C O R B A O b ject
RSVP
C o n tro ller
S p ecialized O R B s o r S erv ices
D ev ice
S tatu s
S erv ice
M e c h a n is m
D e v e lo p e r
The QuO Toolkit Supports Building Adaptive
Applications or Adding Adaptation to Existing Apps
CORBA IDL
Contract Description
Language (CDL)
Delegates Contracts
Code
Generators
Adaptation Specification
Language (ASL)
QuO Runtime
• QuO aspect languages
– Contract description language and
adaptive behavior description
language
– Code generators that weave QuO
code into Java and C++ applications
• System Condition Objects
– Provide interfaces to resources,
managers, and mechanisms
in args
O B JE C T
op eration ()
OBJ
REF
(S E R V A N T )
ou t args + retu rn valu e
C ontract
C ontract
D elegate
D elegate
S ysC ond
S ysC ond
ID L
S ysC ond
M E C H A N IS M /P R O P E R T Y
M ANAGER
ID L
SK ELETO N
STU BS
Client-Side ORB
ORB
IIO P
N etw ork
QuO Gateway
IIOP IIOP
IIO P
ORB
Control
Group Replication (AQuA)
IIOP IIOP
Glue Bandwidth Reservation (DIRM) Glue
IIOP over TCP/IP (default)
WAN
– Contract evaluator
– Factory object which instantiates
contract and system condition objects
O B JE C T
ADAPTER
QuO Gateway
Control
• QuO Runtime Kernel
S ysC ond
Server-Side ORB
C L IE N T
• Instrumentation library
• QuO gateway
– Insertion of special purpose transport
layers and adaptation below the ORB
QuO Provides In-Band and
Out-of-Band Adaptation and Control
• In-band adaptation provided by
the delegate and gateway
– A delegate decides what to
do with a method call or
return based upon the state
of its contract
– Gateway enables control
and adaptation at the
transport layer
• Out-of-band adaptation
triggered by transitions in
contract regions
– Caused by changes in the
system observed by system
condition objects
in args
C L IE N T
O B JE C T
op eration ()
OBJ
REF
(S E R V A N T )
ou t args + retu rn valu e
C ontract
C ontract
D eleg a te
D eleg a te
S ysC ond
S ysC ond
S ysC ond
ID L
S ysC ond
M E C H A N IS M /P R O P E R T Y
M ANAGER
ID L
SK ELETO N
STU BS
ORB
N etw o rk
IIO P
IIO P
O B JE C T
ADAPTER
ORB
in args
C L IE N T
O B JE C T
op eration ()
OBJ
REF
(S E R V A N T )
ou t args + retu rn valu e
C ontract
C ontract
D eleg a te
D eleg a te
S ysC ond
S ysC ond
S ysC ond
ID L
S ysC ond
M E C H A N IS M /P R O P E R T Y
M ANAGER
ID L
SK ELETO N
STU BS
ORB
IIO P
N etw o rk
IIO P
ORB
O B JE C T
ADAPTER
“Systemic Behaviors” are Packaged
into Reusable Bundles Called Qoskets
Adapter Interface
Qosket
Contracts
Delegate
Interface
Callback
Objects
Qosket
Implementation
System
Condition
Objects
Delegate
Templates
Helper
Methods
• The Qosket encapsulates a set of
contracts (CDL), system condition
objects (IDL), and QoS adaptive
behavior (ASL)
• The Qosket exposes interfaces to
access QuO controls and
information (specified in IDL)
• The Qosket separates the
functional adaptive behavior
(business logic) from the QoS
adaptive behavior and the
middleware controls from the QoS
mechanisms
Examples of Building Qoskets
• Example 1: Out-of-band QoS management
– frame-rate qosket
• Example 2: In-band QoS management
– frame-filter qosket
Example 1: Building a
Frame-Rate Qosket
• For UAV application, one of the adaptive behaviors is
to control frame-rate
• We will illustrate how to use QuO by describing how
we built a Qosket for this QoS management behavior
• Need:
– QuO Sysconds (sensors/actuators)
• Sensors: measure frame-rate
• Actuators: request different frame rate
– QuO Contract (QoS requirements)
• Operating regions
• Transitioning between regions invokes callbacks
Example 1: Building a
Frame-Rate Qosket
• QuO Contract Definition Language (CDL) specifies a
contract. Contract is specified in a CDL file.
• In definition of contract, we specify sysconds and
callback functions:
contract UAVContract (
{
syscond
quo::ValueSC quo_sc::ValueSCImpl
actualFrameRate,
callback
UAVCallbacks::Sender_Control_Callback senderControl)
Example 1: Building a
Frame-Rate Qosket
• Next, we specify states in the contract, based on
values of the sysconds
state NormalLoad ( actualFrameRate < 27 and actualFrameRate >= 8
actualFrameRate <= 8 -> ExcessLoad )
{
state N1 { … }
state N2 { … }
}
state HighLoad( actualFrameRate >= 27
actualFrameRate <= 8
{
state H1 { … }
state H2 { … }
}
etc.
-> NormalLoad,
-> ExcessLoad )
-> HighLoad,
Example 1: Building a
Frame-Rate Qosket
• We then specify transition behaviors when going from
one state to another
transition any->NormalLoad {
senderControlCallback.setFrameRate(30);
}
transition any->HighLoad {
senderControlCallback.setFrameRate(10);
}
Example 1: Building a
Frame-Rate Syscond
• QuO Contracts, Sysconds and Callbacks correspond
to CORBA IDL interfaces
module quo {
interface Contract {
void eval();
}
interface Callback { }
interface Syscond {}
interface ValueSC : Syscond {
attribute long longValue;
}
}
Example 1: Building a
Frame-Rate Syscond
• Application specific callbacks derive from the generic
QuO Callback interface
module UAVCallbacks{
interface Sender_ControlCallback : quo::Callback {
void setFrameRate(in long val); // specify frame rate
}
}
• CDL + IDL + code in C++ (or Java) is woven together
by a code generator to form a qosket
Example 1: Building a
Frame-Rate Qosket
• Putting it all together, control loop with out-of-band
adaptation:
Video
Distributor
QuO
Frame
Filter
Send Video data
Video
Display
Proxy
Video
Display
actualFrameRate
->longValue(x)
- measures frame rate, x
QuO
VIDEO DISTRIBUTION
HOST
QuO
senderControlCallback
->setFrameRate()
VIDEO DISPLAY HOST 1
Example 2: Building a
Frame-Filter Qosket
• Previous example illustrated development of
“out-of-band” qosket,
ie. the invocation path of a function call was not
augmented with QoS management behavior
• We will now illustrate development of an “in-band”
qosket that makes use of frame-filtering behavior in
the UAV application
• QuO delegate
– Intercepts CORBA calls (C++/Java), RMI calls (Java),
or local method calls (C++/Java)
– Can be used for filtering, compression, rate-control
Example 2: Building a
Frame-Filter Qosket
• TAO AV service uses CORBA for the control-plane,
but sends data out of CORBA
– Filtering frames requires use of local C++ method
delegates
• Identify the C++ method which we want to augment
with QoS management behavior:
From $TAO_ROOT/orbsvcs/orbsvcs/AV/Protocol_Factory.h:
class TAO_AV_Protocol_Object {
int send_frame(ACE_Message_Block *frame);
}
Example 2: Building a
Frame-Filter Qosket
• Define the delegate behavior in the Aspect Structure
Language (ASL) file:
behavior Filter() {
long TAO_AV_Protocol_Object::send_frame(in ACE_Message_Block message) {
after PREMETHODCONTRACTEVAL {
region DropBFrames {
cplusplus_code #{ if ( frame_type == ‘B’ ) return 0;
}#;
}
region DropPandBFrames {
cplusplus_code #{ if ( frame_type == ‘B’ || frame_type == ‘P’) return 0;
}#;
}
Example 2: Building a
Frame-Filter Qosket
• Define a contract to specify the regions for the framefilter qosket:
contract FilterContract (syscond quo::ValueSC ExpectedFrameRate)
{
region DropBFrames ( ExpectedFrameRate == 10 ) {}
region DropPandBFrames ( ExpectedFrameRate == 2 ) {}
// default send all frame
region SendAllFrames (true ) {}
}
Example 2: Building a
Frame-Filter Qosket
• Combining in-band and out-of-band Qoskets for
end-to-end QoS resource management
Video
Distributor
QuO
Frame
Filter
Send Video data
send_frame(frame_data)
Video
Display
actualFrameRate
->longValue(x)
- measures frame rate, x
expectedFrameRate
->longValue(y)
QuO
VIDEO DISTRIBUTION
HOST
Video
Display
Proxy
QuO
senderControlCallback
->setFrameRate()
VIDEO DISPLAY HOST 1
Integrating QuO in a
Component Model
CORBA DOC MODEL
Reminder of Basic QuO
Architecture
in args
CLIENT
OBJECT
operation()
OBJ
REF
(SERVANT)
out args + return value
IDL
SKELETON
IDL
STUBS
ORB
Network
IIOP
IIOP
in args
QUO/CORBA DOC MODEL
Application
Developer
CLIENT
(SERVANT)
out args + return value
Contract
Contract
Delegate
SysCond
SysCond
IDL
SysCond
Delegate
SysCond
ORB
Network
Application
Developer
QuO
Developer
IDL
MECHANISM/PROPERTY
MANAGER
SKELETON
STUBS
IIOP
Mechanism
Developer
ORB
OBJECT
operation()
OBJ
REF
OBJECT
ADAPTER
IIOP
ORB
OBJECT
ADAPTER
Mechanism
Developer
Basic Elements of QoS Management Must be Integrated
into Component Model to offer Basic QoS Services
QuO
Delegate
QuO
Delegate
Component
QuO
Contract
QuO
Contract
Sys
cond
external
Sys
cond
Sys
cond
external
• QuO delegates can manage interactions between services
• QuO contracts summarize QoS regions of external context
• QuO sysconds can get system properties of infrastructure and other
components
Basic Features that a Component Model Should
Offer to QuO
Component
Component
State
State
Container
Container
• Component model must allow QuO components to expose
well-defined interfaces so that components can:
– be plugged dynamically into some sort of context or container
– be given lifecycle commands (load, unload, stop, start)
– expose some kinds of QoS properties (reflection)
Important Places where QoS Can Be Inserted
in a Component-based DRE Application
• interaction between components (in-band)
• interaction between components and environment (out-ofband)
• interaction between components and containers (crosscutting)
Component Model Must Allow
In-Band QoS Management
in args
C L IE N T
O B JE C T
op eration ()
OBJ
REF
(S E R V A N T )
ou t args + retu rn valu e
C ontract
C ontract
D eleg a te
D eleg a te
S ysC ond
S ysC ond
S ysC ond
ID L
S ysC ond
M E C H A N IS M /P R O P E R T Y
M ANAGER
ID L
SK ELETO N
STU BS
ORB
IIO P
N etw o rk
IIO P
O B JE C T
ADAPTER
ORB
• In-band adaptation provided for inter-component
communication
– Component proxy decides what to do with a method
call or return based upon the state of its contract
– Used to provide control and adaptation
Component Model Must Allow
Out-of-Band QoS Management
in args
CLIEN T
O BJECT
operation()
O BJ
REF
(SERV A N T)
out args + return value
C ontract
C ontract
D elegate
D elegate
SysCond
SysCond
SysCond
ID L
SysCond
M EC H A N ISM /PR O PER TY
M A N A G ER
ID L
SK ELETO N
STU B S
ORB
IIO P
N etw ork
IIO P
O BJEC T
A D A PTER
ORB
• Out-of-band adaptation provided for
communication between components and
environment
– Caused by changes in the system observed by system
condition objects
– Causes transitions in contract regions
Component Model Should Allow QoS
Management to Cross-Cut Components
Service A Component
Client
Component
Service B Component
Service C Component
QoS Management State
and Services
QoS Management State
and Services
Get Service()
Service Broker
Get Service()
Container
• QoS is a cross-cutting concern that can affect the interaction between
multiple components
• CCM must allow for complex component interactions that will result from
implementing cross-cutting QoS management
• URI is using a similar approach with Qoskets and a Trader Service-like
interface to assign CORBA priorities to components in a system
How do we support Qosket Interfaces
in the CORBA Component Model?
Adapter Interface
Qosket
Contracts
Delegate
Interface
Callback
Objects
Qosket
Implementation
• The Qosket encapsulates a set of
contracts (CDL), system condition
objects (IDL), and QoS adaptive
behavior (ASL)
• The Qosket exposes interfaces to
access QuO controls and information
(specified in IDL)
System
Condition
Objects
Delegate
Templates
Helper
Methods
• The Qosket separates the functional
adaptive behavior (business logic)
from the QoS adaptive behavior and
the middleware controls from the QoS
mechanisms
• Qoskets are cross-cutting, their
interfaces will not map directly to CCM
interfaces
Composing Dynamic QoS Provisioning
into CCM
Component Assembly
QoS Mechanism
Plug-ins
QuO Mechanism/
property
Manager
QuO Helper
Methods
Qosket
Implementation
Component & Home Impls
Comp. Impl.
SysCond
SysCond
SysCond
Contract
Contract
QuO
Callback
Objects
QoS Adaptation
(Smart Proxies/
Interceptors)
QuO Delegate
QuO
Delegate
QuODelegate
QoS Policies
Component
Connection
Specifications
• Extend CIAO to insert Qosket modules
into applications transparently
• Smart proxies and
interceptors can implement
QuO’s delegates (in-band)
• ORB configuration
mechanism can install
Qosket specific
mechanisms and
implementations.
• Customized CCM
components can
implement QuO’s
contracts, SysConds, and
callbacks objects (out-ofband).
Middleware
QoS-Enabled
Component
Middleware
(RTCCM-CIAO,
QoS EJB Containers)
• Statically provision QoS resources end-toend
• Monitor and manage QoS of the end-to-end
functional application interaction
• Enable the adaptive and reflective decisionmaking for dynamic QoS provisioning
Dynamic QoS
Provisioning
(QuO Qosket,
dynamicTAO)
Aspect-Oriented
Languages
Programming
Languages
Abstraction
Total QoS Provisioning and
Enforcement
(AspectJ,
AspectC++)
Static
QoS Provisioning
Dynamic
• Integrating CIAO
and Qosket covers
the QoS provisioning
at the middleware
level
• Separation of
functional and
systemic paths
QoS
Descriptions
QoS
Descriptions
Applications
Interceptor
Applications
Sys
Condition
Middleware
Sys
Condition
Sys
Condition
Sys
Condition
Interceptor
Middleware
Domain-Specific Services
QoS
Systemic Path
Domain-Specific Services
Common Services
Mechanism & Properties
Manager
Common Services
Distribution Middleware
}
{
Distribution Middleware
Infrastructure Middleware
Infrastructure Middleware
Operating System
Local
Resource
Management
Operating System
Local
Resource
Management
Endsystem
Functional Path
Endsystem
Future Work
Flight
Scheduling
Chicago
Data
Center
Field Radar
Control
System
Central
Data
Store
1
Middleware Bus
Component
Repository
Compose
Deploy
Component
Assembly
Airport
Traffic
Control
2
System Development
Component
Home
1 UML Model
CoSMIC
Model
Interpreter &
Synthesizer
select
components
QoSPolicies
5
QoS Property
Adaptor
4
3
6
7
POA
ORB
Metadata
ORB QoS Interfaces
(Scheduling,
Timeliness,Priority,...)
ORB Plugins
CCM Component Library
CIAO
ORB
Reflect
Container
CORBA
Component
• CIAO and Qosket can only enforce provisioned QoS
policies and provide the supporting mechanisms
• Correct combinations of these policies are beyond the
scope of CIAO and Qosket
• Support other QoS assurance mechanisms
• Integration with Model-Integrating Computing Tools
1.Configuring and deploying an application services
end-to-end
2.Composing components into application server
components
3.Configuring application component containers
4.Synthesizing application component
implementations
5.Synthesizing dynamic QoS provisioning and
adaptation logic
6.Synthesizing middleware-specific configurations
7.Synthesizing middleware implementations
Questions?
Workshop on QoS-enabled
Component-Oriented Programming
http://www.cs.wustl.edu/~nanbor/QOSCOP/
The 2nd Workshop on
Reflective and Adaptive Middleware
http://tao.doc.wustl.edu/~corsaro/RM2003/
Middleware 2003
http://middleware2003.inf.puc-rio.br/
Workshop submission deadline: Feb. 20, 2003
Conference submission deadline: Dec. 22, 2002
June 16~19, 2003 @ Rio de Janeiro, Brazil
Descargar

Slide 1