The CORBA Component Model

1
The CORBA Component Model

• Nanbor Wang
• Department of Computer Science and Engineering
• Washington University in St. Louis
• nanbor_at_cse.wustl.edu

2
Overview of CORBA

• 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

3
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 at various layers
• Brittle, non-scalable implementation
• Hard to adapt and maintain
• Increase time-to-market

Server
Server
ObjImpl
ObjImpl
ObjImpl
ObjImpl
ObjImpl
COS Svc
ORB/POA
ORB/POA
CORBA BUS
Server
Client
ObjImpl
ObjImpl
COS Svc
invoke
ORB/POA
4
The Emergence of Component Middleware

• Development via composition
• Components encapsulate application core logic
• Components possess
• Event sinks sources
• Connection points e.g., receptacles
• Interfaces e.g., facets
• attributes
• Containers provide execution environment for
  components with common operating requirements
• Containers communicate via a middleware bus

5
The CORBA Component Model (CCM)

• Supporting mechanisms
• Component Server a generic server process for
  hosting containers and components/homes
• Component Implemenation Framework automate the
  implementation of many component features
• Packaging and Assembling tools for collecting
  implementations and configurations information
  into deployable assemblies
• Deployment mechanism automate the deployment of
  component assemblies to component servers
• Goals Separating configuration concerns into
  aspects
• Server configuration
• Object/service configuration
• Application configuration
• Object/service deployment

6
Why a New Component Metatype

• Context To support development 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

Servant Implementation class Multi_Servant_Impl
Multi_Servant_Impl (const GPS_ptr gps,
const Collision_Radar_ptr radar)
POA_Cockpit_Display_tieltMulti_Servant_Implgt
Cockpit_Display_Servant POA_HUDisplay_tieltMulti_
Servant_Implgt HUD_Servant POA_NavInfo_Projecto
r_tieltMulti_Servant_Implgt NavInfo_Projector_Serv
ant
7
Why a New Component Metatype

• 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

8
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

9
Application Development via Composition

• Rate Generator
• Sends periodic Pulse events to subscribers
• Positioning Sensor
• Refreshes cached coordinates available thru
  MyLocation facet
• Notifies subscribers via Ready events
• Displaying Device
• Reads current coordinates via its GPSLocation
  receptacle
• Updates display

Rate Generator
PositioningSensor
DisplayingDevice
Component Server
A typical use case for industrial/automotive/avion
ics control
10
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
ComponentsCCMObject, rate_control
11
Providing Different Views of Components

• Context
• Components need to collaborate with several
  different kinds of components/systems
• These collaborating components/systems may
  understand different interface types
• Problems
• Difficult to extend an interface
• No standard way to acquire new interfaces
• CCM Solution
• Define facets, aka., provided interfaces

12
Component Facets

• Component facets
• Named interfaces that provide the components
  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
ComponentsCCMObject position
provide_MyLocation ()
13
Using Other Components

• Context
• Components need to collaborate with several
  different kinds of components/systems
• These collaborating components/systems may
  provide different types of interface
• Problems
• No standard way to specify capability to handle,
  or dependency to use other interfaces
• No standard way connect an interface to a
  component
• CCM Solution
• Define receptacles

14
Component Receptacles

• 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
GPSLocation interface NavDisplay
ComponentsCCMObject void
connect_GPSLocation (in position c) position
disconnect_GPSLocation() position
get_connection_GPSLocation ()
15
Passing Events

• Context
• Components may also communicate using anonymous
  publishing/subscribing message passing syntax
• Problems
• Non-trivial to extend existing interface to
  support event passing
• Standard CORBA Event Service is non-typed ? no
  type-checking connecting publishers-consumers
• No standard way to specify components capability
  to generate and process events
• CCM Solution
• Standard eventtype/eventtype consumer interface
• Event sources
• Event sinks

16
Component Events

• Simple publish/subscribe event model
• push mode only
• Sources and sinks
• Events are value types
• Defined with the new eventtype metatype
• eventtype ? eventtypeConsumer interface

eventtype tick public rateHz
rate valuetype tick
ComponentsEventBase public rateHz
rate interface tickConsumer
ComponentsEventConsumerBase void push_tick
(in tick the_tick)
17
Component Event Sources
component RateGen publishes tick Pulse
interface RateGen ComponentsCCMObje
ct ComponentsCookie subscribe_Pulse
(in tickConsumer c) tickConsumer
unsubscribe_Pulse (in ComponentsCookie
ck)

• Event sources
• Named connection points for event production
• Push a specified eventtype
• Two kinds Publisher Emitter
• publishes multiple consumers
• emits only one consumer
• Event delivery
• Consumer subscribes/connects directly
• Container mediates access to CosNotification
  channels
• scalability, quality of service, transactional,
  etc.

18
Component Event Sinks
component NavDisplay consumes tick
Refresh interface NavDisplay
ComponentsCCMObject tickConsumer
get_consumer_Refresh ()

• 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

19
The Need to Configure Components

• Context
• To make component implementations more adaptable,
  components should be reconfigurable
• Problems
• Should not commit to a configuration too early
• No standard way to specify components
  configurable knobs
• Need standard mechanisms to configure components
• CCM Solution
• Use component attributes for component
  configurations
• Configuration mechanisms

20
Component Attributes

• 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
ComponentsCCMObject, rate_control
attribute rateHz Rate
21
Managing Component Lifecycle

• Context
• Components need to be created by the CCM run-time
• Problems
• No standard way to manage components lifecycle
• Need standard mechanisms to strategize lifecycle
  management
• CCM Solution
• Using different component homes to provide
  different lifecycle managing strategies

22
A CORBA Component Home
home RateGenHome manages RateGen factory
create_pulser (in rateHz r) interface
RateGenHomeExplicit ComponentsCCMHome
RateGen create_pulser (in rateHz r)
interface RateGenHomeImplicit
ComponentsKeylessCCMHome RateGen create
() interface RateGenHome
RateGenHomeExplicit, RateGenHomeImplicit

• home is a new CORBA meta-type
• Home definition is distinct from component one
• Has an interface, and an object reference
• Manages a unique component type
• More than one home type can manage the same
  component type
• But a component instance is managed by one home
  instance
• Standard factory finder business logic
  operations
• Extensible with arbitrary user-defined business
  logic operations

23
Configuring and Connecting Components

• Context
• Components need to be configured and connected
  together to form application
• Problems
• Components have different ports of different
  types and names
• Non-scalable to generate code to connect a
  specific set of components
• CCM Solution
• Provide introspection interface to discover
  component capability
• Provide generic port operations to
  compose/configure components

24
Navigation and Introspection

• Navigation from any facet to component base
  reference with CORBAObjectget_component()
• Returns nil if target isnt a component facet
• Returns the object reference of the component
  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) inte
rface CCMObject Navigation, Receptacles,
Events CORBAIRObject get_component_def
( ) CCMHome get_ccm_home( ) PrimaryKeyBase
get_primary_key( ) void configuration_complete(
) void remove() ComponentPortDescription
get_all_ports ()
Applies the ExtensionInterface Pattern
25
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
ComponentServer
26
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.

27
Component Categories
28
Container Managed Policies

• Goal decouple runtime configuration from the
  component implementation configuration
• 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

29
Difficulties in Implementing Components
Component and homeDefinitions

• 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

• Component and home servants
• Navigation interface operationsReceptacles
  interface operationsEvents interface operations
• CCMObject interface operationsCCMHome interface
  operations
• Implied equivalent IDL2 port operations
• Application-related operations (in facets,
  supported interfaces, event consumers)

30
Component Implementation Framework (CIF)

• CIF defines rules and tools for developing
  component implementations
• How components should be implemented
• Bridge between component implementation and
  container
• Automate most component implementation
• only business logic should be implemented
  manually (or by MDA tools)
• Activation, identify, port management and
  introspection are generated
• Local server-side OMG CIDL mapping
• Interactions between implementations and
  containers

// RateGen.cidl include RateGen.idl composition
session RateGenImpl home executor
RateGenHomeExec implement RateGenHome
manages RateGenExec
RateGenHome servant
RateGenHomeExec
Manages
RateGen servant
RateGenExec
31
Executors and Home Executors

• Executors programming artifacts implementing a
  components or component homes 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

user implemented code
32
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

33
The CCM Big Picture
implementer
designers
Programming
Home Properties
Component Properties
IDL/CIDL File
User's Code
Language
Tools
IDL/CIDL
Default Properties
Compiler
CORBA
Stubs, Skeletons
Implementation
Component
Package
Assembly
Packaging
Component
CORBA
Tool
Tool
Assembly
Component
Package
Package
Component
packager
assembler
Descriptor
Assembly
Descriptor
User written file
softpkg
Deployment
CORBA
Descriptor
Compiler
deployer
Tool
Component
Package
Generated files
34
CIDL Overview

• Extends CCM-related declarations in IDL files.
• Describes component implementations.
• Helps CCM address limitations of the Object
  Model.
• Is a superset of both PSDL and IDL3, which are in
  turn supersets of IDL2.
• Has 200 production rules.

CIDL
PSDL
IDL3
IDL2
35
Some Object Model Limitations

• Support for server programming patterns.
• Availability of CORBA services.
• Management of object lifecycles.
• Problem
• All the above must be handled in handwritten
  server code.
• Ad hoc design
• Code bloat
• No reuse

36
Addressing Object Model Limitations

• Solution CIDL is part of CCM strategy for
  managing complex applications.
• Helps separation of concerns.
• Helps coordination of tools.
• Increases the ratio of generated to hand-written
  code.
• Server code is now generated, startup automated
  by other CCM tools.

uses
37
CIDL Features and Support

• Complete feature set grammar are large, mostly
  unused by DRE systems.
• Subset of features, production rules targeted
  first.
• Sufficient for existing examples.
• Additional features and grammar supported
  incrementally as needed.
• Focus on requirements for OEP problems.

- Executors - Session composition

• Service composition
• Process composition
• Entity composition
• Segmented executors
• Feature delegation
• Executor delegation
• Proxy homes
• Persistent state features

38
Component Packaging Artifacts

• Packaging bundling a component implementation
  with associate metadata

39
Component Packages

• Goals
• Configure components, containers, servers
• Extract these aspects into metadata
• Thats 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 as a compressed archive
• XML descriptors provide metadata that describe
• The content of a package
• The capability of components
• The dependencies to other software artifacts

Home Properties
Default Properties
CORBA
Implementation
Package
Packaging
CORBA
Tool
Component
Package
Component
packager
Descriptor
softpkg
Descriptor
40
Component Assembly Artifacts

• Assembly A collection of components packages and
  metadata that specify the composition of an
  application

41
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

Port Connections
Instance Creation
Component Package
Component Package
Assembly/ PackagingTool
Component Package
Assembly Archive .aar (ZIP)
Properties
DeploymentTool
42
XML Descriptors Overview
GoalsProvides standards for specifying aspects
and configurations at various levels of an
application

• 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

43
Component Implementation Specifications
Rate Generator
PositioningSensor
DisplayingDevice
lt! Assembly descriptors associate components
with implementations --gtlt!- in software packages
defined by softpkg descriptors (.csd) files --gt
ltcomponentfilesgt ltcomponentfile
idcom-RateGen"gt ltfileinarchive
nameRateGen.csd"/gt lt/componentfilegt
ltcomponentfile idcom-GPS"gt ltfileinarchive
nameGPS.csd"/gt lt/componentfilegt
ltcomponentfile idcom-Display"gt
ltfileinarchive nameNavDisplay.csd"/gt
lt/componentfilegt lt/componentfilesgt
44
Component Home/Instances Installation
Specifications
lt! Instantiating component homes/instances
--gtltpartitioninggt lthostcollocationgt ...
lthomeplacement ida_RateGenHome"gt
ltcomponentfileref idrefcom-RateGen"/gt
ltcomponentinstantiation ida_RateGen"gt
ltcomponentpropertiesgt ltfileinarchive
nameNavRateGen.cpf"/gt
lt/componentpropertiesgt lt/componentinstantiat
iongt lt/homeplacementgt ...
ltdestinationgtA_Remote_Hostlt/destinationgt
lt/hostcollocationgtlt/partitioninggt

• An assembly descriptor specifies how where
  homes components should be instantiated
• A component property file (.cpf) can be
  associated with a home or a component
  instantiation to override default component
  properties

45
CCM Connection Specification
ltconnectionsgt ... ltconnectinterfacegt
ltusesportgt ltusesidentifiergtGPSPositionlt/uses
identifiergt ltcomponentinstantiationref
idrefa_NavDisplay"/gt lt/usesportgt
ltprovidesportgt ltprovidesidentifiergt
MyLocation lt/providesidentifiergt
ltcomponentinstantiationref idrefa_GPS"/gt
lt/providesportgt lt/connectinterfacegt
ltconnecteventgt ltconsumesportgt
ltconsumesidentifiergtRefreshlt/consumesidentifiergt
ltcomponentinstantiationref idrefa_GPS"/gt
lt/consumesportgt ltpublishesportgt
ltpublishesidentifiergt Pulse
lt/publishesidentifiergt ltcomponentinstantiati
onref idrefa_RateGen"/gt
lt/publishesportgt lt/connecteventgt
...lt/connectionsgt
Rate Generator
PositioningSensor
DisplayingDevice

• Assembly descriptors also specify how component
  instances are connected together

46
Component Deployment Artifacts

• Deploy Realization of a single component or a
  assembly specification

47
The CCM Component Deployment Process
Goal provides mechanisms to realize applications
as specified
instantiates
AssemblyFactory
Assembly
ServerActivator
uses
instantiates
ComponentServer
instantiates
Container
instantiates
uses
CCMHome
instantiates
ComponentInstallation
CCMObject
48
CIAO Deployment Mechanisms

1. Deployment Configuration specifies ltdestination
   name, daemon locationgt mappings
2. Assembly_Deployer requests Assembly_Manager to
   deploy an application based on an XML
   specification
3. Assembly_Manager interacts with various daemons
   to instantiate homes/components

2
3
1
49
Two Deployment Examples

• Making configuring, assembling, deploying of
  applications easy
• Component configurations
• Component implemenations
• Inter-connections
• Distribution/topology of applications

RemoteDisplayGUI.cad
DuelDisplay.cad
50
Static QoS Provisioning in Component-Integrated
ACE ORB (CIAO)

• 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

51
Examples of RT Policies in CIAO

• We are extending CIAOs meta-model to make RT
  policies an integral part of CCM

• Component default priority model
• Override component priority model
• Priority level of a component instance
• Defining thread pools
• Associate thread pools with containers
• Specify queuing policies
• Specify pre-connections and private connections,
  banded-connections
• Configure ORB components
• Custom protocols
• Priority mappings

52
CIAOs Contributions Total QoS Provisioning and
Enforcement

• 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

• Integrating CIAO and Qosket covers the QoS
  provisioning at the middleware level
• Separation of functional and systemic paths

53
CIAOs Contributions MDA Integration

• Integration with MDA Tools such as CoSMIC and
  Cadena
• Configuring and deploying an application services
  end-to-end
• Composing components into application server
  components
• Configuring application component containers
• Synthesizing application component
  implementations
• Synthesizing dynamic QoS provisioning and
  adaptation logic
• Synthesizing middleware-specific configurations
• Synthesizing middleware implementations

54
Summary

• The CORBA Component Model
• Extend CORBA object model to support application
  development via composition
• CIF defines ways to automate the implementation
  of many component features
• Defines standard runtime environment with
  Containers and Component Servers
• Specifies packaging and deployment framework
• Separating configuration concerns
• Server configuration
• Object/service configuration
• Application configuration
• Object/service deployment

http//www.cs.wustl.edu/nanbor/projects/CIAO/