Tutorial on CORBA Component Model (CCM) and QoS-enabled CCM

1. Tutorial onCORBA Component Model (CCM)and QoS-enabled CCM Nanbor Wang Craig Rodrigues Washington University BBN Technologies St. Louis

2. Motivation for QoS-enabled CORBA Component Model This slide has been removed for its size (10 MB.) You can get it from: http://www.cs.wustl.edu/~nanbor/presentations/Tutorial-CCM-Mot.ppt

3. 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 *Partially from: OMG CCM Tutorial by Phillipe Merle, et. al.

4. 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 • Resulting in tight couplings • Brittle, non-standard implementation • Hard to adapt and maintain • Increase time-to-market

5. 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 Promising Solution: Component Models • J2EE (EJB), COM+ & CORBA Component Model (CCM)

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

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

8. 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 RateGenerator HiResGPS cockpitDisplay Component Server

9. 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”

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

11. 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;};

12. 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 (); …};

13. 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 (); …};

14. 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);};

15. 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); …};

16. 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 (); …};

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

18. A CORBA Component Home 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{}; • 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

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

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

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

22. Component Categories

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

24. 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; };};

25. OMG IDL 3.0 Component Implementer Component Designer Component Client Client-side OMG IDL 2.x Local server-side OMG IDL 2.x Component Executor Client Application Client Stub Component Skeleton The Server-Side OMG IDL Mapping uses implemented by OMG IDL 3.0 Compiler implemented by delegates to User written Compiler ORB Generated files

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

27. A Monolithic Component Executor Component container Component specific context Monolithic executor Container context Component-oriented context interface Main component executor interface Container-oriented context interface Facet or event sink executor interface Context use Container interposition SessionComponent or EntityComponent

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

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

30. Component “RateGen”Implementation Examples local interface CCM_rate_control : rate_control {}; // Component’s main executor local interface CCM_RateGen_Executor : Components::EnterpriseComponent, rate_control { attribute rateHz Rate; }; // Monolithic local interface CCM_RateGen : CCM_RateGen_Executor { attribute rateHz Rate; }; local interface CCM_RateGen_Context : Components::CCMContext { void push_Pulse (in tick ev); }; 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;}; ExecutorMappings

31. C++ Component “RateGen”Implementation Examples local interface CCM_rate_control : rate_control {}; // Component’s main executor local interface CCM_RateGen_Executor : Components::EnterpriseComponent, rate_control { attribute rateHz Rate; }; // Monolithic local interface CCM_RateGen : CCM_RateGen_Executor { attribute rateHz Rate; }; local interface CCM_RateGen_Context : Components::CCMContext { void push_Pulse (in tick ev); }; 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

32. 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{}; ExecutorMappings Impl

33. Component “GPS”Implementation Examples local interface CCM_position : position {}; // Component’s main executor local interface CCM_GPS_Executor : Components::EnterpriseComponent { }; // Monolithic local interface CCM_GPS : CCM_GPS_Executor { CCM_position get_MyLocation (); }; local interface CCM_GPS_Context : Components::CCMContext { }; interface position{ long get_pos ();}; component GPS{ provides position MyLocation;}; interface GPS : Components::CCMObject{ position provide_MyLocation ();}; ExecutorMappings

34. C++ Component “GPS”Implementation Examples local interface CCM_position : position {}; // Component’s main executor local interface CCM_GPS_Executor : Components::EnterpriseComponent { }; // Monolithic local interface CCM_GPS : CCM_GPS_Executor { CCM_position get_MyLocation (); }; local interface CCM_GPS_Context : Components::CCMContext { }; 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); }}; Using Inheritance Implementation 1

35. C++ Component “GPS”Implementation Examples local interface CCM_position : position {}; // Component’s main executor local interface CCM_GPS_Executor : Components::EnterpriseComponent { }; // Monolithic local interface CCM_GPS : CCM_GPS_Executor { CCM_position get_MyLocation (); }; local interface CCM_GPS_Context : Components::CCMContext { }; class position_Impl : public virtual CCM_position{public: position_Impl (); CORBA::Long get_pos () { return /* pos encoder value */; }};class GPS_Impl : public virtual CCM_GPS { CCM_position_ptr the_position_; public: GPS_Impl () { this->the_position_ = new position_Impl; } CCM_position_ptr get_MyLocation () { return CCM_position::_duplicate (this->the_position_); }}; Using Delegation Implementation 2

36. Component Packaging Artifacts

37. 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 Home Properties Default Properties CORBA Implementation Package Packaging CORBA Tool Component Package Component packager Descriptor softpkg Descriptor

38. Component Packaging IDL User Code Compiler Generated Code Shared Library or Executable IDL/CIDL Compiler Component Descriptor Component Package .zip Packaging Tool Default Properties

39. Component Assembly Artifacts

40. Component Assembly Instance Creation Port Connections Component Package Component Package Assembly Archive .aar (ZIP) Assembly Tool Component Package Properties DeploymentTool ...

41. Component Assembly Descriptor Software Package Descriptor CORBA Component Descriptor * * Component Property File Descriptor * 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

42. Example Assembly Descriptors RateGenerator HiResGPS cockpitDisplay <!– Associate components with impls --><componentfiles> <componentfile id=“RateGenerator"> <fileinarchive name=“HouseRateGen.csd"/> </componentfile> <componentfile id=“HiResGPS"> <fileinarchive name=“aGPS.csd"/> </componentfile> <componentfile id=“cockpitDisplay"> <fileinarchive name=“navDisplay-if.csd"/> </componentfile> </componentfiles>

43. Example Assembly Descriptors (2) • 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 <!– 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>

44. Example Assembly Descriptors (3) • Assembly descriptors also specify how component instances are connected together <connections> ... <connectinterface> <usesport> <usesidentifier>GetPosition</usesidentifier> <componentinstantiationref idref=“cockitDisplay"/> </usesport> <providesport> <providesidentifier> MyLocation </providesidentifier> <componentinstantiationref idref=“HiResGPS"/> </providesport> </connectinterface> <connectevent> <consumesport> <consumesidentifier>Refresh</consumesidentifier> <componentinstantiationref idref=“HiResGPS"/> </consumesport> <publishesport> <publishesidentifier> Pulse </publishesidentifier> <componentinstantiationref idref=“RateGenerator"/> </publichesport> </connectevent> ...</connections> RateGenerator HiResGPS cockpitDisplay

45. Current CCM Fails to Address Advanced QoS Requirements QoS-enabled CCM ≠ CCM + RT CORBAWhy doesn't running a RT ORB beneath CCM make it a QoS-enabled CCM implementation? • 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)

46. 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 Extend component middleware to support more advanced infrastructure and resource management

47. Specifying QoS Policies in CCM Applications • Context: • Delay specifying QoS policies till applicationcomposition 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

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

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

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