December 3, 2003 Research Sponsored by DARPA/IXO Tutorial on CORBA Component Model (CCM) and...

December 3, 2003

Research 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

(Inc

reas

e C

apab

ility

)

1985 1990 19982002

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

ClientOBJREF

Object(Servant)

in argsoperation()out args +

return

DIIIDL

STUBSORB

INTERFACE

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&


BackupConfiguration

Deployment&

ConfigurationMechanism

Deployment&


HUD Airframe NAV Steering GPSMission/Route/Terrain

Data Bank

ComponentAssembly

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

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

es

ComponentReference

ComponentHome

OfferedP

orts

Req

uire

dP

orts

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

Obj1

Obj2

Obj3

Obj4

Obj5

Obj6

Obj7

Obj8

Obj9

ObjA

ObjB

ObjC

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 written

Compiler

Generated 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 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

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 interface

Container-oriented context interface

Container interposition

Context 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


CCMContext

MainComponent

Executor


POA

EnterpriseComponent

CCMContext

Container

Servant


CCMContext

MainComponent

Executor


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


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

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{};

Exec

utor

Mappi

ngs

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 1

Using Inheritance





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





GPS

MyLocation

Refresh Ready

Component Packaging Artifacts

IDL/CIDLCom piler

IDL/CIDL F ile

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 P roperties

Deploym entTool

CO RBACom ponent

Package

CO RBACom ponent

Package

Assem blyDescriptor

CO RBACom 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/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 Assembly

PropertiesDeploymen

tTool

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


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


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


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&


Deployment&


Reserve bandwidthDo not share the connection

Run at client priorityRequire highest priority

Reserve 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 RSVPReplicateService

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 RSVPReplicateService

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&


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

Re

flect

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


IDLSTUBS

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP

CLIENT OBJECT(SERVANT)OBJECT(SERVANT)

OBJREF

CLIENT

DelegateContract

SysCond

Contract

Network

MECHANISM/PROPERTYMANAGER

operation()

in args


IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP


OBJREF


QuODeveloper

MechanismDeveloper

CO

RB

A D

OC

MO

DE

LQ

UO

/CO

RB

A D

OC

MO

DE

L

CLIENT

DelegateContract

SysCond

Contract

Network


operation()

in args


IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON OBJECT

ADAPTER

ORB IIOP ORBIIOP


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 Developer

Specialized ORBs or Services

SimpleValue

MeasuredValue

(Sensor)

ComposedValue


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


operation()

in args


IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON OBJECT

ADAPTER

ORB IIOP ORBIIOP


OBJREF

CORBA IDL

CodeGenerators

CodeGenerators

Contract DescriptionLanguage (CDL)

Adaptation SpecificationLanguage (ASL)

QuO RuntimeQuO 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


operation()

in args


IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP


OBJREF

CLIENT

DelegateContract

SysCond

Contract

Network


operation()

in args


IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON OBJECT

ADAPTER

ORB IIOP ORBIIOP


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


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

{


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


• 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


• 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


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

}


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

}#;

}


• 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 ) {}

}


• 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


MechanismDeveloper

CLIENT

Network

operation()

in args


IDLSTUBS

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP


OBJREF

CLIENT

DelegateContract

SysCond

Contract

Network


operation()

in args


IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP


OBJREF


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

Component

State

Container Container

Component

State

• 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


operation()

in args


IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON

OBJECTADAPTER

ORB IIOP ORBIIOP


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


operation()

in args


IDLSTUBS

Delegate

SysCond

SysCond

SysCond

IDLSKELETON OBJECT

ADAPTER

ORB IIOP ORBIIOP


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


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


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

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

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

Re

flect

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 Programming

http://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






http://middleware2003.inf.puc-rio.br/

December 3, 2003 Research Sponsored by DARPA/IXO Tutorial on CORBA Component Model (CCM) and...

Documents

Transcript of December 3, 2003 Research Sponsored by DARPA/IXO Tutorial on CORBA Component Model (CCM) and...