Nanbor WangQoS-Enabled CCM Overview and CIAO Status Washington University, St. Louis QoS-Enabled CCM Meeting Overview Motivations of CORBA Component Model

Washington University, St. Louis

Nanbor WangQoS-Enabled CCM Overview and CIAO Status

QoS-Enabled CCM Meeting Overview

• Motivations of CORBA Component Model (CCM)

• Major CCM features– Component programming

model– Container Programming Model– Component Implementation

Framework and CIDLC– Packaging and deployment

• The state of the CIAO• Conclusions

8:15|

9:45

CCM Overview andThe State of the CIAO(WU, VU)

9:45|

12:00

QoS Supporting Strategies/Mechanisms (BBN, LMCO, WU, URI)

Lunch Break

13:30|

15:00

Integration withModel Driven Arch.(VU, KSU, UAB)

15:00|

16:00

Discussion &Conclusion

Presentation Outlines



Overview of CORBA

InterfaceRepository

IDLCompiler

ImplementationRepository

ClientOBJREF

Object(Servant)

in argsoperation()out args +

return

DIIIDL

STUBSORB

INTERFACE

IDLSKEL

DSI

Object Adapter

ORB CORE GIOP/IIOP/ESIOPS

•CORBA shields applications from heterogeneous platform dependencies•e.g., languages, operating systems, networking protocols, hardware

• It simplifies development of distributed applications by automating/encapsulating

– Object location – Connection & memory mgmt.– Parameter (de)marshaling– Event & request demultiplexing– Error handling & fault tolerance– Object/server activation– Concurrency– Security

•CORBA defines interfaces, not implementations



Boiler Plate X

Boiler Plate YBoiler Plate X

Caveat: Limitations of CORBA 2.x Specification• Requirements of non-trivial

applications:– Collaboration of multiple

objects and services– Wide-spread deployment

on diverse platforms• Limitations – Lack of

standards– Server configuration– Object/service

configuration– Application configuration– Object/service

deployment • Consequences – tight

couplings– Brittle, non-scalable

implementation– Hard to adapt and maintain– Increase time-to-market

ServerORB/POA

ObjImpl

ObjImpl

ObjImpl

ServerORB/POA

ObjImpl

ObjImpl

COS

Svc

ServerORB/POA

ObjImpl

ObjImpl

COS

Svc

Client

CORBA BUS

invoke C

onfig C

Config B

Config A



The CORBA Component Model (CCM)•Separating configuration concerns into aspects:

– Server configuration– Object/service configuration– Application configuration– Object/service deployment

•Supporting mechanisms– Component: a reusable entity– Container: a standardized environment for

components to interact with run-time & vice versa

– Component Server: a generic server process– Component Implemenation Framework:

Supports for many component features– Packaging and Assembling tools: for

collecting implementations and configurations information into deployable assemblies

– Deployment mechanism: for deploying component assemblies to component servers

`GIOP-Lite over VME

Component Server (Board 1)

Container Container

ReplicationManager Scheduler

CORBA Middleware Framework

Deployment&

ConfigurationMetadata

Component Server (Board 2)

Container Container

ReplicationManager Scheduler

CORBA Middleware Framework

Deployment&

ConfigurationMetadata

BackupConfiguration

Deployment&

ConfigurationMechanism

Deployment&

ConfigurationMechanism

HUD Airframe NAV Steering GPSMission/Route/Terrain

Data Bank

ComponentAssembly



Cockpit_Display

Cockpit_DisplayHome

HUDisplay

NavInfo_Projector

Collision_Radar

GPS

Why a New Component Metatype• Goal: Develop via composition

• Limitations of CORBA objects– Objects are merely interfaces– No concept of implementation unit– Difficult to extend – via inheritance– No standard way to navigate related

interfaces– No standard interaction models

between implementations– Ad-hoc object lifetime management

• CCM solution: components– New meta-type that extends CORBA

objects– Easy to extend – via inheritance or

aggregation– Viewed as a unit of implementation– Standard navigation and introspection

operations– Standard interaction model using

ports– Standard life cycle management

interface

Servant Implementationclass Multi_Servant_Impl{ Multi_Servant_Impl (const GPS_ptr gps, const Collision_Radar_ptr radar); …};

POA_Cockpit_Display_tie<Multi_Servant_Impl> Cockpit_Display_Servant;

POA_HUDisplay_tie<Multi_Servant_Impl> HUD_Servant;

POA_NavInfo_Projector_tie<Multi_Servant_Impl> NavInfo_Projector_Servant;

HUDisplay

Cockpit_Display

NavInfo_Projector



Development via Composition• RateGenerator

– periodic “Pulse” to subscribers

• HiResGPS, when pulsed – refreshes cached GPS

coordinates from “MyLocation” facet

– propagates “Pulse” to “Ready” subscribers

• cockpitDisplay, when pulsed– Reads GPS coordinates

from its GetLocation receptacle

– Updates display

navDisplayRefresh

GetLocation

RateGenPulse

Rate

GPS

MyLocation

Refresh Ready

Component Server

RateGenerator HiResGPS cockpitDisplay

A Representative Boldstroke Use Case



A CORBA Component• Goals

– Define a unit of reuse and implementation– Encapsulate an interaction and

configuration model

• A component is a new CORBA meta-type– Extension of Object– Has an interface, and an object

reference

• Binds component features to ports• Ports make up a component capability• 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 Facets• Goals

– Easy extension– Different views to different

client roles– Easy composition

• Component facets:– Named interfaces that provide

the component’s application functionality to clients

– 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• Goals:

– Allow easy collaboration with other components/services

– Specify required services

• Distinct named connection points for potential connectivity– Ability to specialize by

delegation, compose functions

• 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• Goal

– Provide asynchronous message passing

• Simple publish / subscribe event model– “push” mode only– Sources and sinks

• Events are value types– Defined with the new eventtype meta-type

• eventtype eventtypeConsumer interface

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• Goal

– Specify intention to generate typed events

• Event sources:– Named connection points for

event production• Push a specified eventtype

– Two kinds: Publisher & Emitter• publishes = multiple clients• emits = only one client

• Event delivery– Client subscribes/connects

directly– 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); tickConsumer unsubscribe_Pulse (in Components::Cookie ck);

…};

RateGenPulse

Rate



Component Event Sinks

• Goal– Express interest on

receiving typed events

• Named connection specifies which events 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



Component Attributes• Goals

– Define a standard mechanisms to configure components

– Make component implementations more adaptable

• Named configurable properties– Intended for component configuration

• e.g., optional behaviors, modality, resource hints, etc.

– Could raise exceptions– Exposed through accessors and

mutators

• Can 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



A CORBA Component Home• Goals:

– Provides standard component lifecycle management interfaces

– Strategize lifecycle management

• “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 one home instance

• Standard factory and finder business logic operations

• Extensible with arbitrary user-defined business logic operations

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



Navigation and Introspection• Goals:

– Provide introspection interface to discover component capability

– Provide generic port operations to compose/configure components

• 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 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 ();};

Applies the ExtensionInterface Pattern



Client-View of CCM Components• IDL3 definition of a component

from a “client-view” – What the component life cycle

operations are (i.e., home)– 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• Maps to “Equivalent IDL2

Interfaces”

Attributes

Event

Sinks

Facets

Rec

epta

cles

Eve

ntS

ourc

es

ComponentReference

ComponentHome

OfferedP

orts

Req

uire

dP

orts



The State of the CIAO – Client View

• Only involved IDL modification

• TAO_IDL already supports IDL3 syntax– Thanks to Jeff Parsons, Vanderbilt

• Most of the mappings have been tested– We will continue to scrutinize the

IDL3 related generated code

• Known issues– Eventtype’s are basically

valuetype’s. • Event sources/event sinks/event

channels may be collocated. • TAO currently does not support the

pass-by-value semantics for collocated valuetypes

Attributes

Event

Sinks

Facets

Rec

epta

cles

Eve

ntS

ourc

es

ComponentReference

ComponentHome

OfferedP

orts

Req

uire

dP

orts



ComponentServer

CCM Server-side Features • CCM is all about component –

server - application configuration

• CORBA 2.x specifications lack higher level abstractions of servant usage models

• Require programmatic configuration (more often with boiler plate-like code)

• Apply meta-programming techniques – Reusable run-time

environment– Drop in and run

Client



The Container Model• A framework in component

servers

• 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 – session states, activation,

deactivation, etc.

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

Unclassified



Container Managed Policies• Goal: decouple runtime

configuration from the component implementation

• Specified by the deployer using XML-based metadata

• 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• Component implementations need to

support introspection, navigation and manage connections.

• Different implementation may assume different run-time requirements

• Different run-time requirements use different container interfaces

• CIF defines rules and tools for developing component implementations– How components should be

implemented• Bridge between component

implementation and container

• Facilitates component implementation– “only” business logic should be

implemented manually• Not activation, identify, port management

and introspection– Local server-side OMG CIDL mapping

• Interactions between implementations and containers

import RateGenHome;

composition session HouseBrew{ home executor RateGenHomeExec { implement RateGenHome; manages RateGenExec; };};

RateGenPulse

Rate



Executors and Home Executors• Programming artifacts

implementing a component’s or component home’s behavior– Local CORBA objects with interfaces

defined by the 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 monolithic

Container

Servant

ComponentSpecificContext

CCMContext

MainComponent

Executor

ExecutorsExecutorsExecutors

POA

EnterpriseComponent

CCMContext

Container

Servant


CCMContext

MainComponent

Executor


POA

EnterpriseComponent

CCMContext

Container

CORBAComponent

ComponentHome

POA

External

Interfaces

InternalInterfaces



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


CCMContext

MainComponent

Executor


POA

EnterpriseComponent

CCMContext

Container

Servant


CCMContext

MainComponent

Executor


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



CIDL Compiler

• Jeff Parsons, Vanderbilt University



The State of the CIAO – Container & CIF• Supports a Session Container implementation

– Less the transactional behavior – So, only support Session component

category• Require handcrafted

– Servant glue code– Component-specific context– Executor mappings

• Support monolithic executors

• Next step: – CIDL compiler implementation– Enhance configurable options

• RT-POA policies• POA policies

– Support Unclassified containers– Event channel setup/configuration

• Events Synchronous calls

• Future work:– Containers are like server side smart

proxies• Explore the applications of reflection

Container

Servant


CCMContext

MainComponent

Executor


POA

EnterpriseComponent

CCMContext

Container

Servant


CCMContext

MainComponent

Executor


POA

EnterpriseComponent

CCMContext



Component Packaging Artifacts

IDL/CIDLCompiler

IDL/CIDL File

Stubs, Skeletons

PackagingTool

Implementation

ProgrammingLanguage

Tools

User's Code

ComponentDescriptor

Default Properties

AssemblyTool

ComponentAssemblyPackage

Home Properties Component Properties

DeploymentTool

CORBAComponent

Package

CORBAComponent

Package

AssemblyDescriptor

CORBAComponent

Package

softpkgDescriptor



Component Packages• Goals

– Configure components, containers, servers– Extract these aspects into metadata

• That’s a lot of stuff to be bundled together and moved around

• “Classic” CORBA: No standard means of– Configuration– Distribution– Deployment

• Packaging of components– Components are packaged into a self-

descriptive package• XML descriptors provide metadata that describe

– The content of a package– The capability of components– The dependencies to other software artifacts

PackagingTool

Implementation

ComponentDescriptor

Default Properties

Home Properties

softpkgDescriptor

CORBA

Package

CORBAComponent

Package

packager



Component Assembly Artifacts

IDL/CIDLCom piler

IDL/CIDL File

Stubs, 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 Properties

Deploym entTool

CORBACom ponent

Package

CORBACom ponent

Package

Assem blyDescriptor

CORBACom ponent

Package

softpkgDescriptor



Component Assembling and Deployment • Goals

– Configure components, containers, servers, and applications

– Extract these aspects into metadata– Provide higher level of modeling

• “Classic” CORBA: No standard means of– Configuration– Distribution– Deployment

• Packaging of component assemblies– Components are packaged into a

self-descriptive package– Packages can be assembled– Assemblies can be deployed

Properties DeploymentTool

AssemblyArchive

.aar (ZIP)

Assembly/

PackagingTool

ComponentPackage

ComponentPackage

ComponentPackage

PortConnections

InstanceCreation



The CCM Big Picture

IDL/CIDL

Compiler

IDL/CIDL File

Stubs, Skeletons

PackagingTool

Implementation

Programming

Language

Tools

User's Code

ComponentDescriptor

Default Properties

Assembly

ToolComponentAssemblyPackage

Home Properties Component Properties

Deployment

Tool

AssemblyDescriptor

CORBAComponent

Package

softpkgDescriptorUser written file

Compiler/Tool

Generated files

CORBAComponent

Package

CORBAComponent

Package

designers implementer

packager

assembler

deployer

Component Interconnection

Definitions



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/tools

• Component Assembly Descriptor (.cad)– Describes initial virtual configuration

• Implementations used• homes, component instances, and connections

• Component Property File Descriptor (.cpf)– name/value pairs to configure attributes

CORBAComponentDescriptor

ComponentProperty

FileDescriptor

SoftwarePackage

Descriptor

ComponentAssemblyDescriptor

* *

*

GoalsGoalsProvides standards for specifying aspects and

configurations at various levels of an application



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




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




The Component Deployment Process

AssemblyFactory Assembly

ServerActivator

ComponentServer

Container

CCMHome

CCMObjectComponentInstallation

«instantiates»

«instantiates»

«instantiates»

«instantiates»

«instantiates»

Deployment Tool

Goal: Provides mechanisms to realize applications as specified


Nanbor WangQoS-Enabled CCM Overview and CIAO StatusThe State of the CIAO – Packaging &

Deployment• CIAO has very limited support of packaging– There’s no tool to help packaging or create zip archive– Simply store all the files (descriptors and implementations) in filesystems

• CIAO has partial support for deployment– Daemon process

• ComponentInstallation: Only maps UUIDs to pathnames• ServerActivator: Can only pass configuration options thru command line flags

– ComponentServer: Does not take advantage of ConfigValues– Container: Can only instantiate one type of container. Only interpret limited

ConfigValues• Install_home: Create a new home, without configuraton info

– AssemblyFactory and Assembly: Prototype to install a component from a CORBA Component Softpkg Descriptor

– Descriptor handlers only extract “important” information, such as: DLL names, entry points, UUIDs and container type

• Next step: (Targeting Boeing OEP example demos)– AssemblyFactory and Assembly implementation:

• Improve XML handling capability to interpret component assembly descriptor• Add application composition code

– Extend component descriptors and assembly descriptors to include RT info– Add more configurable options to create_component_server, create_container,

and install_home• Future

– Capability to apply property files at various level



CIAO Status Summary• Full support of IDL 3 (client-view mappings)• One container type and one component usage model• Require handcrafted servant glue code, component-

specific context, and executor mapping• Component server implementation• Per-host daemon implementation

– ComponentInstallation: Implementation management– ServerActivator: ComponentServer factory

• Daemon controller: Allow managing of daemon using some scripting languages (perl)

• Limited deployment capability: Only single component

• Only extract “important information” from XML descriptors



Project Outlook• Immediate Tasks:

– Add application composition mechanism to Assembly– Add RT Containers – implementation and configuration parameters– CIDL compiler– Extend component and assembly descriptors for RT-spec.– Extend number of recognizable configuration options

• Objectives– Collaboration with KSU people - Boeing OEP examples, extension to

various XML descriptors, RT-Event channel configuration– Collaboration with VU CoSMIC people – ORB configurations

mechanisms– Collaboration with BBN people – A Qosket example, CCM general

application, ORB configuration• Future work:

– Applying Property files – dynamic CORBA– More streamlined component implementation tools– Smarter ComponentInstallation Implementation



Availability Timeline

• CCM related extension and standardization efforts:– OMG Lightweight CCM RFP– OMG QoS for CCM RFP draft

2/1 3/1 4/1 5/1 6/1 7/1 8/1 9/1 10/1 11/1 12/1

1/1/2003 12/31/2003

3/15Support Application

CompositionSimple OEP Example

4/1RT Containers

XML RT extension

6/1PI Meeting

Today

7/15Smart

ComponentInstallation

7/1Support

Property files

8/16More streamlined

componentdevelopment tools

9/2Configuration Validation/

Packaging Tools

10/15CIAO 1.0Release

4/30Support CadenaOEP examples

CIAO 0.2beta release

Integration withRT Event Channel

4/15CIDL compilerORB/Containerconfiguration

11/1CIAO Metrics

– OMG Stream for CCM RFP draft– OMG UML Profile for CCM RFP– OMG UML Profile for QoS and

FT RFP submissions



Examples of RT Policies in CIAO

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

containers6.Specify queuing policies7.Specify pre-connections and

private connections, banded-connections

8.Configure ORB components•Custom protocols•Priority mappings

RT 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



CIAO’s Contributions: MDA Integration

•Integration with MDA Tools such as Cadena and CoSMIC1.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

Re

flect

4

CCM Component Library

1

ORB

ORB QoS Interfaces(Scheduling,

Timeliness,Priority,...)

ORB Plugins

ORBMetadata

6

7

3

5

AirportTrafficControl



CIAO’s Contributions: Total QoS Provisioning and Enforcement

QoS ProvisioningStatic Dynamic

Abs

trac

tion M

iddl

ew

are

Pro

gra

mm

ing

Lan

gu

age

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



Toward Portability Across HW Configurations• A PrimaryKey

– 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

• Idea: alternative use of PrimaryKey– Map to hardware configuration

ObjectStore

Obj1

Obj2

Obj3

Obj4

Obj5

Obj6

Obj7

Obj8

Obj9

ObjA

ObjB

ObjC

finder

PrimaryKey

Documents

Nanbor WangQoS-Enabled CCM Overview and CIAO Status Washington University, St. Louis QoS-Enabled CCM Meeting Overview Motivations of CORBA Component Model