December 3, 2003Research Sponsored by DARPA/IXO
Tutorial onCORBA Component Model (CCM)
and QoS-enabled CCMNanbor Wang Craig Rodrigues
Washington University BBN TechnologiesSt. Louis
This slide has been removed for its size (10 MB.) You can get it from:
http://www.cs.wustl.edu/~nanbor/presentations/Tutorial-CCM-Mot.ppt
Motivation for QoS-enabled CORBA Component Model
Tutorial Topic Overview• 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
RPC
DOC,CORBA
RTCORBA
CCM
CIAOQoS-CCM
MDA/MIC
Time
Sop
hist
icat
ion
(Incr
ease
Cap
abili
ty)
1985 1990 1998 2002 20052003
*Partially from: OMG CCM Tutorial by Phillipe Merle, et. al.
Limitation with the CORBA 2.x Object Model
•Application developers and system integrators are forced to play multiple roles
– Application functional component developers
• tightly coupled application modules
– Computational resource provisioners
• ensuring the availability of common object services
• ad-hoc management– System configurators
• boiler plate code• manual application
deployment
InterfaceRepository
IDLCompiler
ImplementationRepository
Client OBJREF
Object(Servant)
in argsoperation()out args +
return
DII IDLSTUBS
ORBINTERFACE
IDLSKEL DSI
Object Adapter
ORB CORE GIOP/IIOP/ESIOPS
•Resulting in tight couplings– Brittle, non-standard
implementation– Hard to adapt and maintain– Increase time-to-market
Promising Solution: Component Models
•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
Application
OS
OS Adaptation Layer
Container Container
Assembler&
Configurator
•J2EE (EJB), COM+ & CORBA Component Model (CCM)
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
`
GIOP-Lite over VME
Component Server (Board 1)
Container Container
ReplicationManager Scheduler
Middleware Framework
Deployment&
ConfigurationMetadata
Component Server (Board 2)
Container Container
ReplicationManager Scheduler
Middleware Framework
Deployment&
ConfigurationMetadata
BackupConfiguration
Deployment&
ConfigurationMechanism
Deployment&
ConfigurationMechanism
HUD Airframe NAV Steering GPSMission/Route/Terrain
Data Bank
ComponentAssembly
The CCM Big Picture
IDL/CIDL
Compiler
IDL/CIDL File
Stubs, Skeletons
PackagingTool
Implementation
ProgrammingLanguage
Tools
User's Code
ComponentDescriptor
Default Properties
AssemblyTool
ComponentAssemblyPackage
Home Properties Component Properties
DeploymentTool
AssemblyDescriptor
CORBAComponent
Package
softpkgDescriptorUser written file
Compiler/ToolGenerated files
CORBAComponent
Package
CORBAComponent
Package
designers implementer
packager
assembler
deployer
Component Interconnection
Definitions
Development via Composition• 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
navDisplayRefresh
GetLocation
RateGenPulse
Rate
GPS
MyLocation
Refresh Ready
Component Server
RateGenerator HiResGPS cockpitDisplay
Component Features• 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”
Attributes
Event
Sinks
Facets
Rec
epta
cles
Eve
ntS
ourc
esComponentReference
ComponentHome
OfferedPorts
Req
uire
dPo
rts
A CORBA Component• 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
interface rate_control{ void start (); void stop ();};
component RateGen supports rate_control{};
interface RateGen : Components::CCMObject, rate_control{};
RateGenPulse
Rate
Component Attributes• 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
typedef unsigned long rateHz;
component RateGen supports rate_control{ attribute rateHz Rate;};
interface RateGen : Components::CCMObject, rate_control{ attribute rateHz Rate;};
RateGenPulse
Rate
Component Facets• 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
interface position{ long get_pos ();};
component GPS{ provides position MyLocation; …};
interface GPS : Components::CCMObject{ position provide_MyLocation ();
…};
GPS
MyLocation
Refresh Ready
Component Receptacles• 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 navDisplay{ … uses position GetLocation; …};
interface navDisplay : Components::CCMObject{ … void connect_GetLocation (in position c); position disconnect_GetLocation(); position get_connection_GetLocation (); …};
navDisplayRefresh
GetLocation
Component Events
• 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
eventtype tick{ public rateHz rate;};
valuetype tick : Components::EventBase{ public rateHz rate;};
interface tickConsumer : Components::EventConsumerBase{
void push_tick (in tick the_tick);};
Component Event Sources• Named connection points for
event production– Push a specified eventtype
• 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 RateGen{ publishes tick Pulse; …
};
interface RateGen : Components::CCMObject{ Components::Cookie subscribe_Pulse (in tickConsumer c); trippedConsumer unsubscribe_Pulse (in Components::Cookie ck);
…};
RateGenPulse
Rate
Component Event Sinks• Named connection
points into which events of a specific type may be pushed
• Subscription to event sources– Potentially multiple (n to
1)
• No distinction between emitter and publisher– Both push in event sinks
component navDisplay{ … consumes tick Refresh;};
interface navDisplay : Components::CCMObject{
… tickConsumer get_consumer_Refresh (); …};
navDisplayRefresh
GetLocation
Navigation and Introspection• 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.
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 ();};
A CORBA Component Home• 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
home RateGenHome manages RateGen{ factory create_pulser (in rateHz r);};
interface RateGenHomeExplicit : Components::CCMHome { RateGen create_pulser (in rateHz r);};
interface RateGenHomeImplicit : Components::KeylessCCMHome { RateGen create ();};
interface RateGenHome : RateGenHomeExplicit, RateGenHomeImplicit{};
RateGenHome
RateGenPulseRate
Component Home Features
• 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
+get_component_def() : IRObject+get_home_def() : IRObject+remove_component(in comp : CCMObject) : void
CCMHome
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
ObjectStore
Obj1Obj2Obj3Obj4Obj5Obj6Obj7Obj8Obj9ObjAObjBObjC
finder
PrimaryKey
The Container Model• 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
ORB
CORBAComponent
ComponentHome
POA
Transaction
Security Notification
Persistent State
External
Interfaces
CallbackInterfaces
InternalInterfaces
Container
CORBAComponent
ComponentHome
POA
External
Interfaces
CallbackInterfaces
InternalInterfaces
Component CategoriesCOMPONENT CATEGORY
CONTAINER IMPL TYPE
CONTAINER TYPE
EXTERNAL TYPE
EJB BEAN EQUIVALENT
Service Stateless Session Keyless Session (stateless)
Session Conv Session Keyless Session (stateful)
Process Durable Entity Keyless -----
Entity Durable Entity Keyfull Entity
Container Managed Policies
• Specified by the deployer using an XML vocabulary
• Implemented by the container, not the component
• Policy declarations defined for:– Servant Lifetime– Transaction– Security– Events– Persistence
SSL Container
CORBAComponent
ComponentHome
POA
External
Interfaces
CallbackInterfaces
InternalInterfaces
Transactional Container
CORBAComponent
ComponentHome
POA
External
Interfaces
CallbackInterfaces
InternalInterfaces
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
• Not activation, identify, port management and introspection
=> Local server-side OMG IDL mapping
• Interactions between implementations and containers
• Manages segmentation and persistency=> Component Implementation
Definition Language
import RateGenHome;
composition session HouseBrew{ home executor RateGenHomeExec { implement RateGenHome; manages RateGenExec; };};
RateGenPulse
Rate
The Server-Side OMG IDL Mapping
ComponentDesigner
User writtenCompilerGenerated files
OMG IDL3.0
Localserver-sideOMG IDL 2.x
ClientStub
ComponentExecutor
ComponentSkeleton
OMG IDL 3.0
CompilerClient-side
OMG IDL 2.x
ComponentClient
ComponentImplementer
ClientApplication
uses
implemented by delegates to
implemented by
ORB
Executors and Home Executors
• Programming artifacts implementing a component’s or component home’s behavior– Local CORBA objects with interfaces
defined by the local server-side OMG IDL mapping
• Component executors could be monolithic– 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
monolithicContainer
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
CCMContext
Container
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
CCMContext
Container
CORBAComponent
ComponentHome
POA
External
Interfaces
InternalInterfaces
A Monolithic Component Executor
Monolithic executor
Container context
Componentspecificcontext
Component container
Main component executor interface
Facet or event sink executor interface
SessionComponent or EntityComponent
Component-oriented context interfaceContainer-oriented context interface
Container interpositionContext use
Main Server-Side OMG IDL Mapping Rules
• A component type is mapped to three local interfaces– The main component executor interface
• Inheriting from Components::EnterpriseComponent
– The monolithic component executor interface
• Operations to obtain facet executors and receive events
– The component specific context interface• Operations to access component
receptacles and event sources• 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
Container
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
CCMContext
Container
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
CCMContext
«local»EnterpriseComponent
+set_session_context(in cts : SessionContext) : void+ccm_activate() : void+ccm_passivate() : void+ccm_remove() : void
«local»SessionComponent
+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
EntityComponent
Executors Are Hosted by Container• Container intercepts invocations on
executorsfor 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 througha local context interface
Container
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
CCMContext
Container
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
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»CCMContext
+get_CCM_object() : object(idl)
«local»SessionContext +get_CCM_object() : object(idl)
+get_primary_key() : PrimaryKeyBase
«local»EntityContext
Component “RateGen”Implementation Examples
local interface CCM_rate_control : rate_control {};
// Component’s main executorlocal interface CCM_RateGen_Executor : Components::EnterpriseComponent, rate_control{ attribute rateHz Rate;};
// Monolithiclocal interface CCM_RateGen : CCM_RateGen_Executor{ attribute rateHz Rate;};
local interface CCM_RateGen_Context : Components::CCMContext{ void push_Pulse (in tick ev);};
ExecutorMappings
interface rate_control{};
component RateGen supports rate_control{ publishes tick Pulse; attribute rateHz Rate;};
interface RateGen : Components::CCMObject, rate_control{ Components::Cookie subscribe_Pulse (in tickConsumer c); tickConsumer unsubscribe_Pulse (in Components::Cookie c); attribute rateHz Rate;};
RateGenPulse
Rate
C++ Component “RateGen”Implementation Examples
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 */ }
};
Implementation
local interface CCM_rate_control : rate_control {};
// Component’s main executorlocal interface CCM_RateGen_Executor : Components::EnterpriseComponent, rate_control{ attribute rateHz Rate;};
// Monolithiclocal interface CCM_RateGen : CCM_RateGen_Executor{ attribute rateHz Rate;};
local interface CCM_RateGen_Context : Components::CCMContext{ void push_Pulse (in tick ev);};
RateGenPulse
Rate
Home “RateGenHome”Implementation Examples
local interface CCM_RateGenHomeExplicit : Components::HomeExecutorBase{};
local interface CCM_RateGenHomeImplicit{ Components::EnterpriseComponent create ();};
local interface CCM_RateGenHome : CCM_RateGenHomeExplicit, CCM_RateGenHomeImplicit{}
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; }}
home RateGenHome manages RateGen{};
interface RateGenHomeExplicit : Components::CCMHome {};
interface RateGenHomeImplicit : Components::KeylessCCMHome{ RateGen create ();};
interface RateGenHome : RateGenHomeExplicit, RateGEnHomeImplicit{};
Execut
or
Mappings
Impl
Component “GPS”Implementation Examples
local interface CCM_position : position{};
// Component’s main executorlocal interface CCM_GPS_Executor : Components::EnterpriseComponent{};
// Monolithiclocal interface CCM_GPS : CCM_GPS_Executor{ CCM_position get_MyLocation ();};
local interface CCM_GPS_Context : Components::CCMContext{};
ExecutorMappings
interface position{ long get_pos ();};
component GPS{ provides position MyLocation;};
interface GPS : Components::CCMObject{ position provide_MyLocation ();};
GPS
MyLocation
Refresh Ready
C++ Component “GPS”Implementation Examples
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, public virtual position_Impl{public: CCM_position_ptr get_MyLocation () { return CCM_position::_duplicate (this); }};
Implementation 1Using
Inheritance
local interface CCM_position : position{};
// Component’s main executorlocal interface CCM_GPS_Executor : Components::EnterpriseComponent{};
// Monolithiclocal interface CCM_GPS : CCM_GPS_Executor{ CCM_position get_MyLocation ();};
local interface CCM_GPS_Context : Components::CCMContext{};
GPS
MyLocation
Refresh Ready
C++ Component “GPS”Implementation Examples
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_); }};
Implementation 2 Using Delegation
local interface CCM_position : position{};
// Component’s main executorlocal interface CCM_GPS_Executor : Components::EnterpriseComponent{};
// Monolithiclocal interface CCM_GPS : CCM_GPS_Executor{ CCM_position get_MyLocation ();};
local interface CCM_GPS_Context : Components::CCMContext{};
GPS
MyLocation
Refresh Ready
Component Packaging Artifacts
IDL/CIDLCom piler
IDL/CIDL File
S tubs, Skeletons
PackagingTool
Im plem entation
Program m ingLanguage
Tools
User's Code
Com ponentDescriptor
Default P roperties
Assem blyTool
Com ponentAssem blyPackage
Hom e Properties Com ponent Properties
Deploym entTool
CO RBACom ponent
Package
CORBACom ponent
Package
Assem blyDescriptor
CORBACom ponent
Package
softpkgDescriptor
Packaging and Deployment• “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
PackagingTool
Implementation
ComponentDescriptor
Default Properties
Home Properties
softpkgDescriptor
CORBA
Package
CORBAComponent
Package
packager
Component Packaging
IDL/CIDL Compiler
UserCode
GeneratedCode
IDL
ComponentDescriptor
DefaultProperties
Compiler
SharedLibrary or
Executable
Packaging Tool
ComponentPackage
.zip
Component Assembly Artifacts
IDL/C IDLCom piler
IDL/C IDL File
S tubs, Skeletons
PackagingTool
Im plem entation
Program m ingLanguage
Tools
User's Code
Com ponentDescriptor
Default Properties
Assem blyTool
Com ponentAssem blyPackage
Hom e Properties Com ponent P roperties
Deploym entTool
CO RBACom ponent
Package
CO RBACom ponent
Package
Assem blyDescriptor
CO RBACom ponent
Package
softpkgDescriptor
Component Assembly
Properties DeploymentTool
AssemblyArchive
.aar (ZIP)Assembly Tool
ComponentPackage
ComponentPackage
ComponentPackage
PortConnections
InstanceCreation
...
XML Descriptors Overview
• 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
CORBAComponentDescriptor
ComponentProperty
FileDescriptor
SoftwarePackage
Descriptor
ComponentAssemblyDescriptor
* *
*
Example Assembly Descriptors
<!– 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>
navDisplayRefresh
GetLocation
RateGenPulse
Rate
GPS
MyLocation
Refresh Ready
RateGenerator HiResGPS cockpitDisplay
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)<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>
• Assembly descriptors also specify how component instances are connected together
navDisplayRefresh
GetLocation
RateGenPulse
Rate
GPS
MyLocation
Refresh Ready
RateGenerator HiResGPS cockpitDisplay
•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)RT Component Server (?)
Container
RT-ORB
CORBAComponent
ComponentHome
RTPOA
External
Interfaces
CallbackInterfaces
InternalInterfaces
Container
CORBAComponent
ComponentHome
RTPOA
External
Interfaces
CallbackInterfaces
InternalInterfaces
Current CCM Fails to Address Advanced QoS Requirements
QoS-enabled CCM ≠ CCM + RT CORBA
Why doesn't running a RT ORB beneath CCM make it a QoS-
enabled CCM implementation?
QoS-Enabled Component Middleware• Separate the concerns for QoS
managements• Separate the roles
– Application component developers
– QoS assurance mechanism developers
– QoS provisioning managers– ORB configurators
• Compose QoS assurance mechanisms– ORB – OS – Application-specific Adaptive
• Specify metadata for QoS requirements of– components– component connections
Client Component Server
Containers Containers
TradingComponent
LoggingComponent
Deployment&
ConfigurationMechanism
ComponentAssembly
ORB
in args
out args + returnvalue
Operation ()
QoSMechanism
Plug ins
QoSMechanism
Plug ins
ClientConfiguration
Aggregate
QoSAdaptation
QoSAdaptation
Extend component middleware to support more advanced infrastructure
and resource management
Specifying QoS Policies in CCM Applications
• 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
Component Server
Containers Containers
TradingComponent
LoggingComponent
Deployment&
ConfigurationMechanism
Deployment&
ConfigurationMetadata
Reserve bandwidthDo not share the connection
Run at client priorityRequire highest priorityReserve 30% processor cycles
Configuring Component Adaptation• Context:
– Many QoS properties need to be enforced end-to-end
– We need to apply meta-programming 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
Container
CORBAComponent
ComponentHome
Real-time POA
QoS PropertyAdaptor
Client
ORB QoS Interfaces(Scheduling, Timeliness, Priority,...)
QoS Policies
Supporting 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
Container
CORBAComponent
ComponentHome
Real-time POA
QoS PropertyAdaptor
ComponentAssembly
ORB QoS Interfaces
QoS Policies
Ref
lect
ORB-specificQoS
AssuranceMechanisms
Scheduling RSVP ReplicateService
QoS Assurances Require End-to-end Enforcement
• 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
CCM Container
Object(Servant)
ORBInterfaces
Client
Client-sidemeta-object
(Stub)
Server-sidemeta-object(Skeleton,
DSI)
ORB Core
in args
out args + returnvalue
Operation ()
POAObject storemeta-object
QoS EnforceMechanisms
QoS EnforceMechanisms
Smart Proxy ClientRequest
Interceptor
ServerRequest
Interceptor
ServantManager Impl
QoS ControlInterfaces
DII
Instantiates Interacts
Configuring Client-side Adaptation• Context:
– We are applying meta-programming techniques to insert adaptive behaviors for QoS requirements
– Objects with same interface may require different adaptive behaviors
• Problem:– Coarse-grained existing meta-
programming support• Smart proxies – all references• Interceptors – all invocations
• Solution Approach:– Control effective meta-
mechanisms through CORBA policies
– Utilizing extension interface pattern
www.krones.com
On Board Controller
StillImage
Camera
ImageRecognizer:ImageConsumer
QALogger:ImageConsumer
Client-side Policy Aggregates• 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-to-end assurance
• Solution Approach:– Configure ORB dynamically thru a
CCM assembly-like configuration mechanisms
– Define policy aggregates dynamically using metadata (using Extension Interface pattern)
Client-side ORB
Client PolicyAssembly
ORB QoS Interfaces
ORB-specificQoS
AssuranceMechanisms
Scheduling RSVP ReplicateService
Fast ResponseNPA
NPA: Named Policy Aggregate
Logging NPA
Best Effort NPA Low B/W AdaptNPA
Static QoS Provisioning in Component-Integrated ACE ORB
(CIAO)
Client Component Server
Deployment&
ConfigurationMechanism
Component Assembly
RT-ORB
in args
out args + return value
Operation ()
QoSMechanism
Plug ins
QoSMechanism
Plug ins
ClientConfiguration
Aggregate
QoSAdaptation
Container
CORBAComponent
ComponentHome
Real-time POA
QoS PropertyAdaptor
QoS Policies
Ref
lect
QoSAdaptation
QoSAdaptation
QoSMechanism
Plug ins
NamedPolicy
Aggregate
NamedPolicy
Aggregate
ObjectReference
QoSAdaptation
QoSMechanism
Plug ins
QoS Policies
Component ConnectionSpecifications
Component & Home Impls • 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
1.Component default priority model
2.Override component priority model
3.Priority level of a component instance
4.Defining thread pools5.Associate thread pools with
components6.Specify queuing policies7.Specify pre-connections and
private connections8.Configure ORB components
•Custom protocols•Priority mappingsRT Component Server
Container
RT-ORB
CORBAComponent
ComponentHome
RTPOA
External
Interfaces
CallbackInterfaces
InternalInterfaces
Container
CORBAComponent
ComponentHome
RTPOA
External
Interfaces
CallbackInterfaces
InternalInterfaces
1
2
8
63
Thread Pool A
Priority30
Priority60
4
55
7
•We are extending CIAO’s meta-model to make RT policies an integral part of CCM
RTCCM Descriptor Examples
• Component default priority model
• Can be in cpf
<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>
• 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.)
• Define thread pools• Define QoS aggregates
<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>
• 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
QuO Adds Specification, Measurement, and Adaptation into the Distributed Object Model
ApplicationDeveloper
MechanismDeveloper
CLIENT
Network
operation()in args
out args + return value
IDLSTUBS
IDLSKELETON OBJECT
ADAPTER
ORB IIOP ORBIIOP
CLIENT OBJECT(SERVANT)OBJECT(SERVANT)
OBJREF
CLIENT
DelegateContract
SysCond
Contract
Network
MECHANISM/PROPERTYMANAGER
operation()in args
out args + return value
IDLSTUBS
Delegate
SysCond
SysCond
SysCond
IDLSKELETON OBJECT
ADAPTER
ORB IIOP ORBIIOP
CLIENT OBJECT(SERVANT)OBJECT(SERVANT)
OBJREF
ApplicationDeveloper
QuODeveloper
MechanismDeveloper
CO
RB
A D
OC
MO
DE
LQ
UO
/CO
RB
A D
OC
MO
DE
L
CLIENT
DelegateContract
SysCond
Contract
Network
MECHANISM/PROPERTYMANAGER
operation()in args
out args + return value
IDLSTUBS
Delegate
SysCond
SysCond
SysCond
IDLSKELETON OBJECT
ADAPTER
ORB IIOP ORBIIOP
CLIENT OBJECT(SERVANT)OBJECT(SERVANT)
OBJREF
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
Mechanism DeveloperSpecialized ORBs or Services
SimpleValue
MeasuredValue
(Sensor)
ComposedValue
ApplicationDeveloper
QoSDeveloper
QuO Kernel
RSVPController
ControlValue
StatusValue
CORBA ObjectDeviceStatus
Service
ControlValue
The QuO Toolkit Supports Building Adaptive Applications or Adding Adaptation to Existing Apps
• 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• QuO Runtime Kernel
– Contract evaluator– Factory object which instantiates
contract and system condition objects• Instrumentation library• QuO gateway
– Insertion of special purpose transport layers and adaptation below the ORB
QuO GatewayQuO Gateway
IIOPGlue
Control
Clie
nt-S
ide
OR
B
IIOP Group Replication (AQuA)
WAN
Bandwidth Reservation (DIRM)
IIOP over TCP/IP (default)
IIOPGlue
Control
IIOP
Serv
er-S
ide
OR
B
CLIENT
DelegateContract
SysCond
Contract
Network
MECHANISM/PROPERTYMANAGER
operation()in args
out args + return value
IDLSTUBS
Delegate
SysCond
SysCond
SysCond
IDLSKELETON OBJECT
ADAPTER
ORB IIOP ORBIIOP
CLIENT OBJECT(SERVANT)OBJECT(SERVANT)
OBJREF
CORBA IDL
CodeGenerators
Contract DescriptionLanguage (CDL)
Adaptation SpecificationLanguage (ASL)
QuO Runtime
Delegates Contracts
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
CLIENT
DelegateContract
SysCond
Contract
Network
MECHANISM/PROPERTYMANAGER
operation()in args
out args + return value
IDLSTUBS
Delegate
SysCond
SysCond
SysCond
IDLSKELETON OBJECT
ADAPTER
ORB IIOP ORBIIOP
CLIENT OBJECT(SERVANT)OBJECT(SERVANT)
OBJREF
CLIENT
DelegateContract
SysCond
Contract
Network
MECHANISM/PROPERTYMANAGER
operation()in args
out args + return value
IDLSTUBS
Delegate
SysCond
SysCond
SysCond
IDLSKELETON OBJECT
ADAPTER
ORB IIOP ORBIIOP
CLIENT OBJECT(SERVANT)OBJECT(SERVANT)
OBJREF
“Systemic Behaviors” are Packaged into Reusable Bundles Called Qoskets
• 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
Qosket
Adapter Interface
Delegate Interface
Contracts SystemConditionObjects
CallbackObjects
QosketImplementation
HelperMethods
DelegateTemplates
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 -> HighLoad, actualFrameRate <= 8 -> ExcessLoad ) { state N1 { … } state N2 { … } }state HighLoad( actualFrameRate >= 27 -> NormalLoad, actualFrameRate <= 8 -> ExcessLoad ){ state H1 { … } state H2 { … }} etc.
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 Display
VIDEO DISPLAY HOST 1
VideoDisplayProxy
actualFrameRate ->longValue(x) - measures frame rate, x
QuO
Send Video data
senderControlCallback ->setFrameRate()
VideoDistributor
VIDEO DISTRIBUTIONHOST
QuOFrameFilter
QuO
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 frame-filter 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 forend-to-end QoS resource management
Video Display
VIDEO DISPLAY HOST 1
VideoDisplayProxy
actualFrameRate ->longValue(x) - measures frame rate, x
QuO
Send Video data
senderControlCallback ->setFrameRate()
VideoDistributor
VIDEO DISTRIBUTIONHOST
QuOFrameFilter
QuO
expectedFrameRate ->longValue(y)
send_frame(frame_data)
Integrating QuO in a Component Model
Reminder of Basic QuO Architecture
ApplicationDeveloper
MechanismDeveloper
CLIENT
Network
operation()in args
out args + return value
IDLSTUBS
IDLSKELETON OBJECT
ADAPTER
ORB IIOP ORBIIOP
CLIENT OBJECT(SERVANT)OBJECT(SERVANT)
OBJREF
CLIENT
DelegateContract
SysCond
Contract
Network
MECHANISM/PROPERTYMANAGER
operation()in args
out args + return value
IDLSTUBS
Delegate
SysCond
SysCond
SysCond
IDLSKELETON OBJECT
ADAPTER
ORB IIOP ORBIIOP
CLIENT OBJECT(SERVANT)OBJECT(SERVANT)
OBJREF
ApplicationDeveloper
QuODeveloper
MechanismDeveloper
CO
RB
A D
OC
MO
DE
LQ
UO
/CO
RB
A D
OC
MO
DE
L
Basic Elements of QoS Management Must be Integrated into Component Model to offer Basic QoS Services
QuO Delegate
QuO Delegate
Component
Sys cond
Sys cond
Sys cond
QuO Contract
QuO Contract
external 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
ComponentState
Container Container
ComponentState
• 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-of-band)• interaction between components and containers
(cross-cutting)
Component Model Must Allow In-Band QoS Management
• 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
CLIENT
DelegateContract
SysCond
Contract
Network
MECHANISM/PROPERTYMANAGER
operation()in args
out args + return value
IDLSTUBS
Delegate
SysCond
SysCond
SysCond
IDLSKELETON OBJECT
ADAPTER
ORB IIOP ORBIIOP
CLIENT OBJECT(SERVANT)OBJECT(SERVANT)
OBJREF
Component Model Must Allow Out-of-Band QoS Management
• 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
CLIENT
DelegateContract
SysCond
Contract
Network
MECHANISM/PROPERTYMANAGER
operation()in args
out args + return value
IDLSTUBS
Delegate
SysCond
SysCond
SysCond
IDLSKELETON OBJECT
ADAPTER
ORB IIOP ORBIIOP
CLIENT OBJECT(SERVANT)OBJECT(SERVANT)
OBJREF
Component Model Should Allow QoS Management to Cross-Cut Components
• 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
Service A Component
Service B Component
Service C Component
Client Component
ContainerGet Service() Get Service()
QoS Management State and Services
Service Broker
QoS Management State and Services
How do we support Qosket Interfaces in the CORBA Component Model?
• 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
• Qoskets are cross-cutting, their interfaces will not map directly to CCM interfaces
Qosket
Adapter Interface
Delegate Interface
Contracts SystemConditionObjects
CallbackObjects
QosketImplementation
HelperMethods
DelegateTemplates
Composing Dynamic QoS Provisioning into CCM
• 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-of-band).
Component Assembly
QoS MechanismPlug-ins
QoS Policies
ComponentConnection
Specifications
QuO Mechanism/propertyManager
QosketImplementation
QuO HelperMethods
Component & Home Impls
QoS Adaptation(Smart Proxies/
Interceptors)
QuO DelegateQuO DelegateQuO Delegate
Comp. Impl.
QuOCallbackObjects
SysCond
ContractContract
SysCondSysCond
• Extend CIAO to insert Qosket modules into applications transparently
Total QoS Provisioning and Enforcement
QoS ProvisioningStatic Dynamic
Abs
tract
ion M
iddl
ewar
eP
rogr
amm
ing
Lang
uage
s
QoS-EnabledComponentMiddleware
(RTCCM-CIAO,QoS EJB Containers)
Dynamic QoSProvisioning(QuO Qosket,dynamicTAO)
Aspect-OrientedLanguages
(AspectJ,AspectC++)
• Statically provision QoS resources end-to-end
• Monitor and manage QoS of the end-to-end functional application interaction
• Enable the adaptive and reflective decision-making for dynamic QoS provisioning
QoSSystemic Path
Operating System
Middleware
SysCondition
Mechanism & PropertiesManager
Applications
Operating System
• Integrating CIAO and Qosket covers the QoS provisioning at the middleware level
• Separation of functional and systemic paths
Future Work•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 Tools1.Configuring and deploying an application
services end-to-end2.Composing components into application
server components3.Configuring application component
containers4.Synthesizing application component
implementations5.Synthesizing dynamic QoS provisioning and
adaptation logic6.Synthesizing middleware-specific
configurations7.Synthesizing middleware implementations
ComponentRepository
Compose Deploy
Middleware Bus
CentralDataStore
1
System Development
Field RadarControlSystem
ChicagoData
Center
ComponentAssembly
FlightScheduling
2
CoSMICModel
Interpreter &Synthesizer
UML Model
selectcomponents
CIAO
ContainerCORBA
Component
ComponentHome
POA
QoS PropertyAdaptor
QoS Policies
Ref
lect
4
CCM Component Library
1
ORB
ORB QoS Interfaces(Scheduling,
Timeliness,Priority,...)
ORB Plugins
ORBMetadata
6
7
3
5
AirportTrafficControl
Questions?Workshop on QoS-enabled
Component-Oriented Programminghttp://www.cs.wustl.edu/~nanbor/QOSCOP/
The 2nd Workshop on Reflective and Adaptive Middleware
http://tao.doc.wustl.edu/~corsaro/RM2003/
Middleware 2003http://middleware2003.inf.puc-rio.br/
Workshop submission deadline: Feb. 20, 2003Conference submission deadline: Dec. 22, 2002
June 16~19, 2003 @ Rio de Janeiro, Brazil