1. December 3, 2003 Research Sponsored by DARPA/IXO Tutorial on CORBA Component Model (CCM) and QoS-enabled CCM Nanbor Wang Craig Rodrigues Washington University BBN Technologies St. Louis

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

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. 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 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 IDL/CIDL Compiler IDL/CIDL File Stubs, Skeletons Packaging Tool Implementation Programming Language Tools User's Code Component Descriptor Default Properties Assembly Tool Component Assembly Package Home PropertiesComponent Properties Deployment Tool Assembly Descriptor CORBA Component Package softpkg Descriptor User written file Compiler/Tool Generated files CORBA Component Package CORBA Component Package designers implementer packager assembler deployer Component Interconnection Definitions

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

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

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

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 Monolithic executor Container context Component specific context 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

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 executors for 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 through a 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); }; Executor Mappings 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; };

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

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 {}; Executor Mappings 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 { }; Executor Mappings interface position { long get_pos (); }; component GPS { provides position MyLocation; }; interface GPS : Components::CCMObject { position provide_MyLocation (); };

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

35. C++ Component “GPS” Implementation Examples class position_Impl : public virtual CCM_position { public: position_Impl (); CORBA::Long get_pos () { return /* pos encoder value */; } }; class GPS_Impl : public virtual CCM_GPS { CCM_position_ptr the_position_; public: GPS_Impl () { this->the_position_ = new position_Impl; } CCM_position_ptr get_MyLocation () { return CCM_position::_duplicate (this->the_position_); } }; Implementation 2 Using Delegation local interface CCM_position : position {}; // Component’s main 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 { };

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

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

39. Component Assembly Artifacts

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

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

42. Example Assembly Descriptors RateGenerator HiResGPS cockpitDisplay

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

44. Example Assembly Descriptors (3)... GetPosition MyLocation Refresh Pulse... Assembly descriptors also specify how component instances are connected together RateGenerator HiResGPS cockpitDisplay

45. 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) 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?

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

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

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

52. 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)

53. 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 & ACE QoS API (AQoSA)

54. 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 pools 5.Associate thread pools with components 6.Specify queuing policies 7.Specify pre-connections and private connections 8.Configure ORB components Custom protocols Priority mappings We are extending CIAO’s meta-model to make RT policies an integral part of CCM

55. RTCCM Descriptor Examples Component default priority model Can be in cpf...... Override component priority model Specify the priority level of a component instance Associate component instances with customized protocol Can also be in cpf

56. RTCCM Descriptor Examples (cont.) Define thread pools Define QoS aggregates... … Associate thread pools with components Associate QoS aggregates with connections

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

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

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

60. QuO Adds Specification, Measurement, and Adaptation into the Distributed Object Model Application Developer Mechanism Developer CLIENT Network operation() in args out args + return value IDL STUBS IDL SKELETON OBJECT ADAPTER ORB IIOP ORB IIOP CLIENT OBJECT (SERVANT) OBJECT (SERVANT) OBJ REF CLIENT Delegate Contract SysCond Contract Network MECHANISM/PROPERTY MANAGER operation() in args out args + return value IDL STUBS Delegate SysCond IDL SKELETON OBJECT ADAPTER ORB IIOP ORB IIOP CLIENT OBJECT (SERVANT) OBJECT (SERVANT) OBJ REF Application Developer QuO Developer Mechanism Developer CORBA DOC MODEL QUO/CORBA DOC MODEL

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

62. 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 CORBA IDL Code Generators Code Generators Contract Description Language (CDL) Adaptation Specification Language (ASL) QuO Runtime Delegates Contracts

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

64. “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 System Condition Objects Callback Objects Qosket Implementation Helper Methods Delegate Templates

65. Examples of Building Qoskets Example 1: Out-of-band QoS management –frame-rate qosket Example 2: In-band QoS management –frame-filter qosket

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

67. Example 1: Building a Frame-Rate Qosket QuO Contract Definition Language (CDL) specifies a contract. Contract is specified in a CDL file. In definition of contract, we specify sysconds and callback functions: contract UAVContract ( syscond quo::ValueSC quo_sc::ValueSCImpl actualFrameRate, callback UAVCallbacks::Sender_Control_Callback senderControl) {

68. Example 1: Building a Frame-Rate Qosket Next, we specify states in the contract, based on values of the sysconds state NormalLoad ( actualFrameRate = 8 -> HighLoad, actualFrameRate ExcessLoad ) { state N1 { … } state N2 { … } } state HighLoad( actualFrameRate >= 27 -> NormalLoad, actualFrameRate ExcessLoad ) { state H1 { … } state H2 { … } } etc.

69. Example 1: Building a Frame-Rate Qosket We then specify transition behaviors when going from one state to another transition any->NormalLoad { senderControlCallback.setFrameRate(30); } transition any->HighLoad { senderControlCallback.setFrameRate(10); }

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

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

72. Example 1: Building a Frame-Rate Qosket Putting it all together, control loop with out-of-band adaptation: Video Display VIDEO DISPLAY HOST 1 Video Display Proxy actualFrameRate ->longValue(x) - measures frame rate, x QuO Send Video data senderControlCallback ->setFrameRate() Video Distributor VIDEO DISTRIBUTION HOST QuO Frame Filter QuO

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

74. Example 2: Building a Frame-Filter Qosket TAO AV service uses CORBA for the control-plane, but sends data out of CORBA –Filtering frames requires use of local C++ method delegates Identify the C++ method which we want to augment with QoS management behavior: From $TAO_ROOT/orbsvcs/orbsvcs/AV/Protocol_Factory.h: class TAO_AV_Protocol_Object { int send_frame(ACE_Message_Block *frame); }

75. Example 2: Building a Frame-Filter Qosket Define the delegate behavior in the Aspect Structure Language (ASL) file: behavior Filter() { long TAO_AV_Protocol_Object::send_frame(in ACE_Message_Block message) { after PREMETHODCONTRACTEVAL { region DropBFrames { cplusplus_code #{ if ( frame_type == ‘B’ ) return 0; }#; } region DropPandBFrames { cplusplus_code #{ if ( frame_type == ‘B’ || frame_type == ‘P’) return 0; }#; }

76. Example 2: Building a Frame-Filter Qosket Define a contract to specify the regions for the frame- filter qosket: contract FilterContract (syscond quo::ValueSC ExpectedFrameRate) { region DropBFrames ( ExpectedFrameRate == 10 ) {} region DropPandBFrames ( ExpectedFrameRate == 2 ) {} // default send all frame region SendAllFrames (true ) {} }

77. Example 2: Building a Frame-Filter Qosket Combining in-band and out-of-band Qoskets for end-to-end QoS resource management Video Display VIDEO DISPLAY HOST 1 Video Display Proxy actualFrameRate ->longValue(x) - measures frame rate, x QuO Send Video data senderControlCallback ->setFrameRate() Video Distributor VIDEO DISTRIBUTION HOST QuO Frame Filter QuO expectedFrameRate ->longValue(y) send_frame(frame_data)

78. Integrating QuO in a Component Model

79. Reminder of Basic QuO Architecture Application Developer Mechanism Developer CLIENT Network operation() in args out args + return value IDL STUBS IDL SKELETON OBJECT ADAPTER ORB IIOP ORB IIOP CLIENT OBJECT (SERVANT) OBJECT (SERVANT) OBJ REF CLIENT Delegate Contract SysCond Contract Network MECHANISM/PROPERTY MANAGER operation() in args out args + return value IDL STUBS Delegate SysCond IDL SKELETON OBJECT ADAPTER ORB IIOP ORB IIOP CLIENT OBJECT (SERVANT) OBJECT (SERVANT) OBJ REF Application Developer QuO Developer Mechanism Developer CORBA DOC MODEL QUO/CORBA DOC MODEL

80. Basic Elements of QoS Management Must be Integrated into Component Model to offer Basic QoS Services QuO Delegate Component Sys cond QuO Contract 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

81. Basic Features that a Component Model Should Offer to QuO Component State 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)

82. 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)

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

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

85. 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 ComponentService B ComponentService C Component Client Component Container Get Service() QoS Management State and Services Service Broker QoS Management State and Services

86. 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 System Condition Objects Callback Objects Qosket Implementation Helper Methods Delegate Templates

87. 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). Extend CIAO to insert Qosket modules into applications transparently

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

89. 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 Tools 1.Configuring and deploying an application services end-to-end 2.Composing components into application server components 3.Configuring application component containers 4.Synthesizing application component implementations 5.Synthesizing dynamic QoS provisioning and adaptation logic 6.Synthesizing middleware-specific configurations 7.Synthesizing middleware implementations

90. Questions? Workshop on QoS-enabled Component-Oriented Programming http://www.cs.wustl.edu/~nanbor/QOSCOP/ http://www.cs.wustl.edu/~nanbor/QOSCOP/ The 2 nd Workshop on Reflective and Adaptive Middleware http://tao.doc.wustl.edu/~corsaro/RM2003/ http://tao.doc.wustl.edu/~corsaro/RM2003/ Middleware 2003 http://middleware2003.inf.puc-rio.br/ http://middleware2003.inf.puc-rio.br/ Workshop submission deadline: Feb. 20, 2003 Conference submission deadline: Dec. 22, 2002 June 16~19, 2003 @ Rio de Janeiro, Brazil