OMG CORBA Component Model tutorial

1. Tutorial on the LightweightCORBA Component Model (CCM)Industrializing the Development Distributed Real-time & Embedded SystemsDr. Douglas C. [email protected]://www.dre.vanderbilt.edu/~schmidt/Professor of EECS Vanderbilt University Nashville, TennesseeOther contributors include Tao Lu, Gan Deng, Jai Balasubramanian, Kitty Balasubramanian, Bala Natarajan, William R. Otte, Jeff Parsons, Frank Pilhofer, Craig Rodrigues,Nanbor Wang, & Johnny Willemsen

2. Tutorial on the LightweightCORBA Component Model (CCM)Industrializing the Development of Distributed Real-time & Embedded SystemsDouglas C. SchmidtVanderbilt University Nashville, TennesseeFrank PilhoferMercury Computer SystemsBoston, MassachusettsOther contributors include Jai Balasubramanian, Kitty Balasubramanian, Gan Deng, Tao Lu, Bala Natarajan, Jeff Parsons, Craig Rodrigues,Nanbor Wang, & Johnny Willemsen

3. Tutorial OverviewThe purpose of this tutorial is toMotivate the need for the CORBA Component Model (CCM) & contrast it with the CORBA 2.x distributed object computing (DOC) modelIntroduce CCM features most relevant to distributed real-time & embedded (DRE) applicationse.g., Lightweight CCM & the new OMG Deployment & Configuration specShow how to implement DRE applications using CCM & C++Illustrate status of CCM & Lightweight CCM support in existing platformsbut not toEnumerate all the CCM C++ or Java mapping rules & featuresProvide detailed references of all CORBA & CCM interfacesMake you capable of implementing CORBA & CCM middleware

4. 4Motivation & Overview of Component Middlewarewww.cs.wustl.edu/~schmidt/cuj-16.doc

5. class Xoperation1()operation2()operation3()operationn()Associating related data & operationsdataDecoupling interfaces & implementationsWhere We Started: Object-Oriented ProgrammingObject-oriented (OO) programming simplified software development through higher level abstractions & patterns, e.g.,Well-written OO programs exhibit recurring structures that promote abstraction, flexibility, modularity, & elegance

6. ClientProxyServiceAbstractServiceserviceserviceservice11Object : Interface X: Clientoperation()MiddlewareNext Step: Distributed Object Computing (DOC)Applies the Broker pattern to abstract away lower-level OS & protocol-specific details for network programmingCreates distributed systems that are easier to model & build using OO techniquesResult: robust distributed systems built with distributed object computing (DOC) middlewaree.g., CORBA, Java RMI, etc.We now have more robust software & more powerful distributed systems

7. Overview of CORBA 2.x StandardCORBA 2.x is DOC middleware that shields applications from dependencies on heterogeneous platforms

8. e.g., languages, operating systems, networking protocols, hardware

9. CORBA 2.x automates

10. Object location

11. Connection & memory mgmt.

12. Parameter (de)marshaling

13. Event & request demultiplexing

14. Error handling & fault tolerance

15. Object/server activation

16. Concurrency & synchronization

17. SecurityCORBA 2.x defines interfaces & policies, but not implementations

18. Example: Applying OO to Network ProgrammingCORBA 2.x IDL specifies interfaces with operations Interfaces map to objects in OO programming languages e.g., C++, Java, Ada95, Ruby, etc.Operations defined in interfaces can be invoked on local or remote objectsinterface Foo { void bar (in long arg);};IDLC++class Foo : public virtual ::CORBA::Object { virtual void bar (CORBA::Long arg);};

19. ApplicationInterfaceDevelopment &DesignDeploymentIDLObject“Other”DefinitionsImplementationsImplementationsIDLLanguageCompilerApplicationsToolsStubs&SkeletonsLibrariesDrawbacks of DOC-based CORBA 2.x MiddlewareCORBA 2.x application development is unnecessarily tedious & error-proneCORBA 2.x IDL doesn’t provide a way to group together related interfaces to offer a service family

20. Such “bundling” must be done by developers via CORBA idioms & patterns CORBA 2.x doesn’t specify how configuration & deployment of objects should be done to create complete applicationsProprietary infrastructure & scripts are written by developers to enable this

21. Boiler Plate YBoiler Plate XConfig BConfig ACORBA BUSBoiler Plate XConfig CExample: Limitations of CORBA 2.x SpecificationRequirements of non-trivial DRE systems:Collaboration of multiple objects & servicesDeployment on diverse platformsCORBA 2.x limitations – lack of standards forServer/node configurationObject/service configurationApplication assemblyObject/service deployment Consequences: Brittle, non-scalable implementationHard to adapt & maintainIncreased time-to-marketServerServerObjImplObjImplObjImplObjImplObjImplCOSSvcORB/POAORB/POAServerClientObjImplObjImplCOSSvcinvokeORB/POA

22. …………ContainerSolution: Component MiddlewareCreates a standard “virtual boundary” around application component implementations that interact only via well-defined interfaces

23. Define standard container mechanisms needed to execute components in generic component servers

24. Specify the infrastructure needed to configure & deploy components throughout a distributed system…<ComponentAssemblyDescription id="a_HUDDisplay"> ... <connection> <name>GPS-RateGen</name> <internalEndPoint><portName>Refresh</portName><instance>a_GPS</instance></internalEndPoint> <internalEndPoint><portName>Pulse</portName><instance>a_RateGen</instance></internalEndPoint> </connection> <connection> <name>NavDisplay-GPS</name> <internalEndPoint><portName>Refresh</portName><instance>a_NavDisplay</instance></internalEndPoint> <internalEndPoint><portName>Ready</portName><instance>a_GPS</instance></internalEndPoint> </connection> ...</ComponentAssemblyDescription>

25. ………ContainerContainer Middleware BusSecurityReplicationNotificationPersistenceSchedulingA/V StreamingLoad BalancingBirdseye View of Component MiddlewareComponents encapsulate application “business” logic

26. Components interact via ports

27. Provided interfaces, e.g.,facets

28. Required connection points, e.g., receptacles

29. Event sinks & sources

30. Attributes

31. Containers provide execution environment for components with common operating requirements

32. Components/containers can also

33. Communicate via a middleware bus &

34. Reuse common middleware services…Component middleware defines interfaces, policies, & some implementations

35. 13Overview of the CORBA Component Model (CCM)

36. ComponentComponentReferenceReferenceContainerContainerComponentComponentHomeHomessCOMPONENTCOMPONENTtteexxllFFcceeaEXECUTORSEXECUTORSattaattncncppeeooteteCCsssscclleettaeaeccnnnnRRaaeerrffeennrrsstteeoottnnteteppIInnnnccESESIIrreemmiivvuuvvnnoeoeooEEkkCallbackCallbacknCnCSSssttInterfacesInterfacesPOAPOAORBTransactionPersistentSecurityNotificationCOMPONENT SERVER 1COMPONENT SERVER 2Capabilities of CORBA Component Model (CCM)Component Server

37. A generic server process for hosting containers & component/home executors

38. Component Implementation Framework (CIF)

39. Automates the implementation of many component features

40. Component packaging tools

41. Compose implementation & configuration information into deployable assemblies

42. Component deployment tools

43. Automate the deployment of component assemblies to component servers

44. Containers define operations that enable component executors to access common middleware services & runtime policiesCapabilities of CORBA Component Model (CCM)Component Server

51. Automate the deployment of component assemblies to component serversCapabilities of CORBA Component Model (CCM)Component Server

58. Automate the deployment of component assemblies to component serversCapabilities of CORBA Component Model (CCM)Component Server

65. Automate the deployment of component assemblies to component serversAvailable CCM Implementations

66. CCM Compared to EJB, COM, & .NETLike Sun Microsystems’ Enterprise Java Beans (EJB)CORBA components created & managed by homes

67. Run in containers that manage system services transparently

68. Hosted by generic application component servers

69. But can be written in more languages than Java

70. Like Microsoft’s Component Object Model (COM)

71. Have several input & output interfaces per component

72. Both point-to-point sync/async operations & publish/subscribe events

73. Component navigation & introspection capabilities

74. But has more effective support for distribution & QoS properties

75. Like Microsoft’s .NET Framework

76. Could be written in different programming languages

77. Could be packaged to be distributed

78. But runs on more platforms than just Microsoft Windows20Comparing Application Development with CORBA 2.x vs. CCM

79. CORBA 2.x User RolesObject interface designersServer developersClient application developers

80. CORBA 2.x Application Development LifecycleSpecification of IDL interfaces of objectsImplement servants & write all the code required to bootstrap & run the serverCORBA 2.x supports programming by development (engineering) rather than programming by assembly (manufacturing)

81. CCM User RolesComponent designersComponent clientsComposition designersComponent implementersComponent packagersComponent deployersComponent end-users

82. CCM Application Development LifecycleSpecification of IDL 2 types, e.g., supported interfaces

83. CCM Application Development LifecycleSpecification of IDL 3 types, e.g., provided & required interfaces

84. CCM Application Development LifecycleImplementation of component executors, plus association of components with component executors & their homes via the Component Implementation Definition Language (CIDL)

85. CCM Application Development LifecycleGrouping of component implementation artifacts & metadata descriptors into component packages

86. CCM Application Development LifecycleSpecification of component interconnections & composition of component assembly packages

87. CCM Application Development LifecycleSpecification of deployment target domain & configuration of component assembly

88. CCM Application Development LifecycleDeploy component assembly packages onto target nodes according to a deployment plan

89. CCM Application Development LifecycleCCM makes explicit steps performed implicitly in CORBA 2.x

90. 2010-8-2332CORBA Component Model (CCM) Features

91. Example CCM DRE ApplicationRate GeneratorSends periodic Pulse events to consumersPositioning SensorReceives Refresh events from suppliersRefreshes cached coordinates available thru MyLocation facetNotifies subscribers via Ready eventsDisplay DeviceReceives Refresh events from suppliersReads current coordinates via its GPSLocation receptacleUpdates displayAvionics example used throughout tutorial as typical DRE applicationRate GeneratorPositioningSensorDisplayDeviceComponent Server$CIAO_ROOT/examples/Display/

92. Interface & Component Design StageGoal: Specify supported, provided, & required interfaces & event sinks/sources

93. Unit of Business Logic & Composition in CCMContextDevelopment via compositionProblems CORBA 2.x object limitationsObjects just identify interfacesNo direct relation w/implementations CCM Solution Define CORBA 3.0 component meta-typeExtension of CORBA 2.x Objectinterface Has interface & object referenceEssentially a stylized use of CORBA interfaces/objectsi.e., CORBA 3.x IDL maps onto equivalent CORBA 2.x IDL………

94. Simple CCM Component Example// IDL 3interface rate_control{ void start (); void stop ();};component RateGen supports rate_control {};// Equivalent IDL 2interface RateGen :::Components::CCMObject, rate_control {};Roles played by CCM componentDefine a unit of composition, reuse, & implementationEncapsulate an interaction & configuration model A CORBA component has several derivation options, i.e., It can inherit from a single component typecomponent E : D {};It cansupport multiple IDL interfacesinterface A {}; interface B {}; component D supports A, B {};

95. CORBA Component PortsA CORBA component can contain ports:Facets (provides)Offers operation interfacesReceptacles (uses)Required operation interfacesEvent sources (publishes & emits)Produced eventsEvent sinks (consumes) Consumed eventsAttributes (attribute) Configurable propertiesEach component instance is created & managed by a unique component home“Receives From” “Sends To”

96. Managing Component LifecycleContext Components need to be created by the CCM run-timeProblems with CORBA 2.xNo standard way to manage component’s lifecycleNeed standard mechanisms to strategize lifecycle managementCCM Solution

97. Integrate lifecycle service into component definitions

98. Use different component home’s to provide different lifecycle managing strategies

99. Based on Factory & Finder patternsA CORBA Component Home// IDL 3homeRateGenHome manages RateGen{ factory create_pulser (in rateHz r);};// Equivalent IDL 2interface RateGenHomeExplicit: Components::CCMHome { RateGen create_pulser (in rateHz r);}; interface RateGenHomeImplicit: Components::KeylessCCMHome { RateGen create ();}; interface RateGenHome : RateGenHomeExplicit, RateGenHomeImplicit {}; home is new CORBA meta-typeA home has an interface & object referenceManages one type of component More than one home type can manage same component typeHowever, a component instance is managed by one home instanceStandard factory & finder operationse.g., create()home can have user-defined operations

100. 2010-8-2340A Quick CCM Client Example

101. Component & Home for Simple HelloWorldinterface Hello { void sayHello (in string username);};interface Goodbye { void sayGoodbye (in string username);};component HelloWorld supports Hello { provides Goodbye Farewell;};home HelloHome manages HelloWorld {};IDL 3 definitions for

102. Component: HelloWorld

103. Managing home: HelloHomeThe Client OMG IDL MappingAs we’ve seen, each OMG IDL 3.0 construction has an equivalent in terms of OMG IDL 2.xComponent & home types are viewed by clients through the CCM client-side OMG IDL mappingThis mapping requires no change in CORBA’s client programming language mappingi.e., clients still use their favorite IDL-oriented tools, such as CORBA stub generators, etc.Clients need not be “component-aware”i.e., they can just invoke interface operationsOMG IDL 2.xextendsOMG IDL3.0generatesStandard C++/JavaMappings

104. Simple Client for HelloWorld ComponentLines 4-10: Perform standard ORB bootstrapping

105. Lines 11-12: Obtain object reference to home via Naming Service

106. Line 13: Use home to create component

107. Line 14: Invoke remote operation

108. Line 15: Remove component instance

109. Clients don’t always need to manage component lifecycle directly1 int 2 main (int argc, char *argv[]) 3 { 4 CORBA::ORB_var orb = 5 CORBA::ORB_init (argc, argv); 6 CORBA::Object_var o = 7 orb->resolve_initial_references 8 ("NameService"); 9 CosNaming::NamingContextExt_var nc =10 CosNaming::NamingContextExt::_narrow (o);11 o = nc->resolve_str (“myHelloHome");12 HelloHome_var hh = HelloHome::_narrow (o);13 HelloWorld_var hw = hh->create ();14 hw->sayHello (“Dennis & Brian”);15 hw->remove ();16 return 0;17 }$ ./hello-client # Triggers this on the server:Hello World! -- from Dennis & Brian.

110. 2010-8-2344CCM Component Features in Depthwww.cs.wustl.edu/~schmidt/cuj-17.doc

111. Components Can Offer Different ViewsContext Components need to collaborate with other types of componentsThese collaborating components may understand different interfacesProblems with CORBA 2.xHard to extend interface without breaking/bloating itNo standard way to acquire new interfacesCCM Solution

112. Define facets, a.k.a. provided interfaces, that embody a view of the component & correspond to roles in which a client may act relatively to the component

113. Represents the “top of the Lego”Component Facets// IDL 3interface position{ long get_pos ();};component GPS{provides position MyLocation; …};// Equivalent IDL 2interface GPS : Components::CCMObject{ position provide_MyLocation (); …};Facet characteristics:Define provided operation interfacesSpecified with provides keywordLogically represents the component itself, not a separate entity contained by the componentHowever, facets have independent object references obtained from provide_*() factory operationCan be used to implement Extension Interface pattern

114. : Client_get_component()operation()Extension Interface PatternThe Extension Interface design pattern (POSA2) allows multiple interfaces to be exported by a component to prevent breaking of client code &

115. bloating of interfaces when developers extend or modify component functionalityAsk for a reference to an interfaceClientRootcueryInterfacecallServiceCall an operation on an interface*CreateInstance<<extends>>*ComponentFactory1*newcreateComponentcreateComponentExtensionInterface i1+ServerImplemented byqueryInterfaceservice_iinitializeuninititialize

116. Using Other ComponentsContext Components need to collaborate with several different types of components/applicationsThese collaborating components/applications may provide different types of interfacesProblems with CORBA 2.xNo standard way to specify interface dependenciesNo standard way to connect an interface to a componentCCM Solution Define receptacles, a.k.a. required interfaces, which are distinct named connection points for potential connectivityRepresents the “bottom of the Lego”

117. Component Receptacles// IDL 3component NavDisplay{ …uses position GPSLocation; …};// Equivalent IDL 2interface NavDisplay : Components::CCMObject{ … void connect_GPSLocation (in position c); position disconnect_GPSLocation(); position get_connection_GPSLocation (); …};Receptacle characteristicsDefine a way to connect one or more required interfaces to this componentSpecified with uses (multiple) keywordCan be simplex or multiplexConnections are established statically via tools during deployment phaseConnections are managed dynamically at run-time by containers to offer interactions with clients or other components via callbacksCCM also enables connection establishment during run-time

118. Event PassingContext Components often want to communicate using publisher/subscriber message passing mechanismProblems with CORBA 2.xStandard CORBA Event Service is dynamically typed, i.e., there’s no static type-checking connecting publishers/subscribeNon-trivial to extend request/response interfaces to support event passingNo standard way to specify an object’s capability to generate & process eventsCCM Solution Standard eventtype & eventtype consumer interface (which are based on valuetypes)Event sources & event sinks (“push mode” only)

119. CORBA ValuetypesContextParameters of IDL operations that are an interface type always have pass-by-reference semantics (even in parameters)IDL interfaces hide implementations from clientsProblems Clients cannot instantiate CORBA objectsIDL structs are passed by value, but don’t support operations or inheritanceCORBA Solution The IDL valuetypeAlways passed by valueCan have both operations & stateSupports inheritance

120. Component Events// IDL 3eventtype tick{ public rateHz Rate;};// Equivalent IDL 2valuetype tick : Components::EventBase{ public rateHz Rate;};interface tickConsumer : Components::EventConsumerBase { void push_tick (in tick the_tick);};Events are implemented as IDL valuetypesDefined with the new IDL 3 eventtype keywordThis keyword triggers generation of additional interfaces & glue code

121. Component Event Sources// IDL 3component RateGen{publishes tick Pulse;emits tick Trigger; …};// Equivalent IDL 2interface RateGen : Components::CCMObject { Components::Cookie subscribe_Pulse (in tickConsumer c); tickConsumer unsubscribe_Pulse (in Components::Cookie ck); …};Event source characteristicsNamed connection points for event productionTwo kinds of event sources: publisher & emitterpublishes = may be multiple consumersemits = only one consumerTwo ways to connect with event sinksConsumer connects directlyCCM container mediates access to CosEvent channels

122. CCM Cookiesmodule Components{ valuetype Cookie{ private CORBA::OctetSeq cookieValue; }; interface Receptacles {Cookie connect (…); void disconnect (in Cookie ck); }; interface Events {Cookie subscribe (…); void unsubscribe (in Cookie ck); };};ContextEvent sources & receptacles correlate connect() & disconnect() operationsProblemObject references cannot reliably be tested for equivalenceCCM SolutionCookievaluetypeGenerated by receptacle or event source implementationRetained by client until needed for disconnect()Used as a unique id

123. Component Event Sinks// IDL 3component NavDisplay{ …consumes tick Refresh;};// Equivalent IDL 2interface NavDisplay : Components::CCMObject{ … tickConsumer get_consumer_Refresh (); …};Event sink characteristicsNamed connection points into which events of a specific type may be pushedMultiple event sinks of same type can subscribe to the same event sourcesNo distinction between emitter & publisherConnected to event sources via object reference obtained from get_consumer_*() factory operation

124. CCM EventsContextGeneric event push()operation requires a generic event typeProblemUser-defined eventtypes are not genericCCM SolutionEventBaseabstractvaluetype// IDL 2valuetype tick : Components::EventBase {…};interface tickConsumer :Components::EventConsumerBase {…};module Components { abstract valuetype EventBase {}; interface EventConsumerBase { void push_event (in EventBase evt); };};// C++ mappingclass tickConsumer : // ...{ virtual void push_event (Components::EventBase *evt); …};Enables both statically- & dynamically-typed event passing

125. The Need to Configure ComponentsContextTo make component implementations more adaptable, components properties should be (re)configurable, e.g., color, size, strategies, etc.ProblemsApplications shouldn’t commit to a configuration too earlyNo standard way to specify component’s configurable parameters in CORBA 2.xNeed standard mechanisms to configure componentsCCM SolutionConfigure components via attributes in assembly/deployment environment, by homes, and/or during component initializationEthernetVIDEO

126. Component Attributes// IDL 3typedef unsigned long rateHz;component RateGen supports rate_control{attribute rateHz Rate;};// Equivalent IDL 2interface RateGen : Components::CCMObject, rate_control{ attribute rateHz Rate;};Attribute characteristicsNamed configurable properties intended for component configuratione.g., optional behaviors, modality, resource hints, etc.Can raise user-defined exceptions (new CCM capability)Exposed through accessors & mutatorsCan be set by various configuration mechanismse.g., XML descriptor files generated by modeling tools

127. Connecting ComponentsContext Components need to be connected together to form complete applicationsProblems Components can have multiple ports with different types & namesIt’s not scalable to write code manually to connect a set of components for a specific applicationCCM Solutions

128. Provide introspection interface to discover component capability

129. Provide generic port operations to connect components using external deployment & configuration tools

130. Represents snapping the lego bricks togetherCCM Navigation & IntrospectionNavigation & introspection capabilities provided by CCMObjecti.e., via Navigation interface for facets, Receptacles interface for receptacles, & Events interface for event portsNavigation from component base reference to any facet(s) via generated facet-specific operationse.g., Components::CCMObject::get_all_facets() & Components::CCMObject::provide()Navigation from any facet to component base reference with CORBA::Object::_get_component()Returns nil if not a component facet, else component reference All this navigation & introspection code is auto-generated by the CIDL compiler in the form of servant!: Client_get_component()operation()

131. Using Navigation Interfaces of a Component1 int 2 main (int argc, char *argv[]) 3 { 4 CORBA::ORB_var orb = 5 CORBA::ORB_init (argc, argv); 6-10 // Get the NameService reference… CORBA::Object_var o = ns->resolve_str (“myHelloHome"); HelloHome_var hh = HelloHome::_narrow (o.in ()); HelloWorld_var hw = hh->create (); // Get all facets & receptacles Components::FacetDescriptions_var fd = hw->get_all_facets (); Components::ReceptacleDescriptions_var rd = hw->get_all_receptacles (); // Get a named facet with a name “Farewell” CORBA::Object_var fobj = hw->provide (“Farewell”); // Can invoke sayGoodbye() operation on Farewell after // narrowing to the Goodbye interface. ... 24 return 0;25 }

132. Generic Port OperationsGeneric port operations for provides, uses, subscribes, emits, & consumeskeywords are auto-generated by the IDL compilerApply the Extension Interface patternUsed by CCM deployment & configuration toolsLightweight CCM spec doesn’t include equivalent IDL 2 operations

133. Example of Connecting ComponentsCCM components are connected via deployment tools during launch phaseComponent ServerFacet  Receptacleobjref = GPS->provide (“MyLocation”);NavDisplay->connect (“GPSLocation”, objref);Event Source  Event Sinkconsumer = NavDisplay-> get_consumer (“Refresh”) GPS->subscribe (“Ready”, consumer);Connected object references are managed by containers

134. Recap – CCM Component FeaturesIDL 3 component from a client perspectiveDefine component life cycle operations (i.e.,home)Define what a component provides to other componentsDefine what a component requires from other componentsDefine what collaboration modes are used between componentsPoint-to-point via operation invocationPublish/subscribe via event notificationDefine which component attributes are configurableIDL 3 maps to “equivalent IDL 2 Interfaces”“Recevies From”“Sends To”

135. Summary of Client OMG IDL Mapping RulesA component type is mapped to an interface inheriting from Components::CCMObjectFacets & event sinks are mapped to a factory operation for obtaining the associated referenceReceptacles are mapped to operations for connecting, disconnecting, & getting the associated reference(s)Event sources are mapped to operations for subscribing & unsubscribing for produced eventsAn event type is mapped to

136. A value type that inherits from Components::EventBase

137. A consumer interface that inherits from Components:: EventConsumerBase

138. A home type is mapped to three interfaces

139. One for explicit user-defined operations that inherits from Components::CCMHome

140. One for generated implicit operations

141. One inheriting from both interfacesWe explored all of these mappings in detail in previous slides

142. 2010-8-2366CCM Component Run-time Environment & Containerswww.cs.wustl.edu/~schmidt/cuj-18.doc

143. Component Implementation StageGoal 1: Implement components in the context of containers

144. ContainerCCM Component Server Features ContainerCallbackCallbackInterfacesInterfacesInternalInternalInternalInternalInterfacesInterfacesExternalExternalInterfacesInterfacesInterfacesInterfacesPOAPOACCM’s primary enhancement to CORBA 2.x is its focus on component servers & application deployment/configurationCCM extends CORBA 2.x viaHigher-level abstractions of common servant usage modelsTool-based configuration & meta-programming techniques, e.g.:Reusable run-time environmentDrop in & runTransparent to clientsThe CCM container framework is central to this supportClientClientComponentComponentHomeHomeCORBACORBAComponentComponentComponent Server

145. The CCM Container FrameworkComponentComponentReferenceReferenceContainerContainerComponentComponentHomeHomessCOMPONENTCOMPONENTtteexxllFFcceeEXECUTORSEXECUTORSaattaattnnccppooeeeettCCsssscclleetteaeacncnnRnRaaeerrffenrenrsstetoeotnttentepIpnnInnccESESIerrmIemiivvuvuvnoneoeoEoEkkCallbackCallbackCnnCSsSsttInterfacesInterfacesPOAPOAORBTransactionPersistentSecurityNotificationCOMPONENT SERVER 1COMPONENT SERVER 2A standard framework within CCM component serversExtends the Portable Object Adaptor (POA) with common patterns, e.g.,Automatic activation & deactivation of componentsOptimize resource usageProvides simplified access to CORBA Common Servicese.g., security, transactions, persistence, & eventsUses callbacks to manage component instances

146. e.g., session states, activation, deactivation, etc.External, Internal, & Container InterfacesInternal interfaces are used by components to access container facilitieslocal interface CCMContext { CCMHome get_CCM_home ();};local interface SessionContext : CCMContext { Object get_CCM_object ();};Callback interfaces are used by containers to call into the component’s executorlocal interface EnterpriseComponent{};local interface SessionComponent : EnterpriseComponent {void set_session_context (in SessionContext ctx)void ccm_activate ();void ccm_passivate (); void ccm_remove (); };ContainerComponentHomesleacnarfertCallbackeCORBAxtEnInterfacesIComponentInternalInterfacesPOAExternal APIs are interfaces provided to clients

147. Container APIs are internal interfaces & callback interfaces used by component developers to build applications CCM Component/Container CategoriesIn CCM these categories can be specified declarativelyvia a CIDL file, rather than programmed imperatively

148. Container-managed CORBA PoliciesGoal: decouple install-/run-time configuration policies from component implementationCORBA policy declarations defined for:Servant lifetimeTransactionSecurityEventsPersistenceSpecified by component/composition developers using XML metadata and/or CIDL directivesImplemented by the container, not the componentUses Interceptor pattern (POSA2)SSL ContainerComponentHomesleacnarferCallbackteCORBAxtnEInterfacesIComponentInternalInterfacesPOATransactional ContainerComponentHomesleacnarfertCallbackeCORBAxtEnInterfacesIComponentInternalInterfacesPOA

149. 2010-8-2373Component Implementation Framework (CIF) & Component Implementation Definition Language (CIDL)www.cs.wustl.edu/~schmidt/cuj-18.doc

150. Component Implementation StageGoal 2: Implement components & associate them with their homes

151. Difficulties with Implementing CORBA 2.x ObjectsProblemsGeneric lifecycle & initialization server code must be handwritten, e.g.Server initialization & event loop code Support for introspection & navigation of object interfacesServer application developers mustKeep track of dependencies their objects have on other objects Manage the policies used to configure their POAs & manage object lifecyclesConsequences are ad hoc design, code bloat, limited reuseApproach for Implementing ComponentsApproach: Generate as Much Code as Possible from Declarative SpecsGenerated Component & Home ServantsNavigation interface operations

152. Receptacle interface operations

153. Event interface operations

154. CCMObject interface operations

155. CCMHome interface operations

156. Implied equivalent IDL 2 port operations

157. Application-related operations

158. i.e., facets, supported interfaces, event consumersIDL 3 & CIDLIDL 3 compilerComponent & homedefinitionsRequirementsComponent implementations may need to support introspection, navigation, & manage connectionsDifferent component implementations may have different run-time requirements

159. Different component run-time requirements may necessitate the use of different container policiesCCM Component Implementation Framework (CIF)Defines rules & tools for implementing components

160. i.e., specifies how to implement components via executors

161. Simplifies component implementation

162. Developers only implement business logic, not activation, identification, port management, introspection, etc.

163. Auto-generates much component “glue” codeComponent Executors & Home ExecutorsServer-side programming artifacts that implement components & homesLocal CORBA objects with interfaces defined by a local server-side OMG IDL mappingComponent executors can beMonolithic, where all component ports implemented by one class, orSegmented, wherecomponent ports split into several classesHome executors are always monolithicHelloHome servantWritten by developersHelloHome_ExecManagesHelloWorld servantHelloWorld_ExecGenerated by IDL compiler

164. MainMainComponentComponentComponentComponentSpecificSpecificExecutorExecutorContextContextCCMContextCCMContextExecutorsExecutorsExecutorsExecutorsExecutorsExecutorsCCMContextCCMContextEnterpriseComponentEnterpriseComponentServantServantPOAPOAContainerContainerExecutors (& Servants) Are Hosted by ContainersContainers intercept invocations on executors & manage activation, security, transactions, persistency, etc.Component executors must implement a local callback lifecycle interface used by the containerSessionComponent for transient components EntityComponent for persistent componentsComponent executors can interact with their containers & connected components through a context interfacesContainerleacnarefrteCORBAxtEnIComponentuser implemented codeInternalInterfacesPOA

165. A Monolithic Component ExecutorComponent containerComponentspecificcontextMonolithic executorCCM contextComponent-oriented context interfaceMain component executor interfaceContainer-oriented context interfaceFacet or event sink executor interfaceContext useSessionComponent or EntityComponentContainer interposition

166. A Segmented Component ExecutorComponent containerComponentspecificcontextMain segmentSeg2Seg4Seg3CCM contextExecutorLocatorSegmented executors are deprecated in favor of assembly-based components

167. Overview of Component Implementation Definition Language (CIDL)CIDLDescribes a component’s compositionAggregate entity that associates interfaces with all artifacts required to implement a particular component & its home executorsCan also manage component persistence stateVia OMG Persistent State Definition Language (PSDL)(Not part of Lightweight CCM)PSDLIDL3IDL2

168. Facilitating Component Implementation via CIDLCIDL is part of the CCM strategy for managing component-based applicationsEnhances separation of concerns

169. Helps coordinate tools

170. Increases the ratio of generated to hand-written code

171. Server glue code is generated, installation & startup automated by other CCM toolsdelegates

172. Connecting Components & Containers with CIDLOMG 3.0 IDLfile + CIDLCIDL & IDL 3.x compiler(s) generate infrastructure “glue” code that connects together component implementations (executors & servants) & containers that hosts themInfrastructure code in container intercepts invocations on executors

173. e.g., can be used to manage activation, security, transactions, persistency, & so on

174. CCM CIF defines “executor mappings”

175. CIDL file declaratively expresses container typeComponent executorServer-side MappingServant managingports, life cycle, etc.Compilingfor CIF/C++

176. Facilitating Component Composition via CIDLComposition featurescategorySpecifies container (lifecycle) type (session, entity, etc.)composition nameSpecifies namespace for executor declarationshome executor nameSpecify generated home nameexecutor nameSpecify generated interface or class nameshome typeImplicitly specifies managed component type

177. Facilitating Component Composition via CIDLComposition featuressessionKeyless, conversation type of containerHello_ExampleSpecifies namespace for executor declarationsHelloHome_ExecSpecify generated home nameHelloWorld_ExecSpecify generated interface or class namesHelloHomeImplicitly specifies managed component type

178. 2010-8-2387CCM Component Application Exampleswww.cs.wustl.edu/~schmidt/cuj-19.doc

179. Define your interfaces using IDL 2.x features, e.g., use the familiar CORBA types (such as struct, sequence, long, Object, interface, raises, etc.) to define your interfaces & exceptionsDefine your component types using IDL 3.x features, e.g., use the new CCM keywords (such as component, provides, uses, publishes, emits, & consumes) to group the IDL 2.x types together to form componentsUse IDL 3.x features to manage the creation of the component types, e.g., use the new CCM keyword home to define factories that create & destroy component instancesImplement your components, e.g., using C++ or Java & the Component Implementation Definition Language (CIDL), which generates component servants, executor interfaces, associated metadata, & compositionsAssemble your components, e.g., group related components together & characterize their metadata that describes the components present in the assemblyDeploy your components & run your application, e.g., move the component assembly packages to the appropriate nodes in the distributed system & invoke operations on components to perform the application logicSteps for Developing CCM Applications

180. Example 1: Hello World// hello.idlinterface Hello { void sayHello (in string name);};interface Goodbye { void sayGoodbye (in string name);};component HelloWorld supports Hello { provides Goodbye Farewell;};home HelloHome manages HelloWorld {};// hello.cdl#include “hello.idl”composition session Hello_Example{ home executor HelloHome_Exec { implements HelloHome; manages HelloWorld_Exec; };};IDL 3 & CIDL definitions placed in hello.idl & hello.cdl, respectivelyHelloWorld Component Executorsclass HelloHome_Exec_Impl : public virtual HelloHome_Exec, public virtual ::CORBA::LocalObject{public:HelloHome_Exec_Impl () {} ~HelloHome_Exec_Impl () {} Components::EnterpriseComponent_ptr create () { return new HelloWorld_Exec_Impl; }};class HelloWorld_Exec_Impl : public virtual HelloWorld_Exec,public virtual ::CORBA::LocalObject {public:HelloWorld_Exec_Impl () {} ~HelloWorld_Exec_Impl () {} void sayHello (const char *name) {cout << “Hello World! -- from ” << name << endl; }};HelloWorld_Exec_Impl executor implements HelloWorld component via HelloWorld_Exec executor IDL

181. HelloHome_Exec_Implexecutor implements lifecycle management of HelloWorld component

182. CORBA::LocalObject is a variant of CORBA::Object

183. Instances of of type CORBA:: LocalObject cannot generate remote references$CIAO_ROOT/docs/tutorial/Hello/

184. Overview of CCM Tool Chain for HelloWorld ExamplehelloS.hhelloS.cpphello.idlFilenames may differ for different ORBshello.cdlhelloC.hhelloC.cpphello_svnt.hhello_svnt.cpphelloEC.hhelloEC.cpphelloE.idlhello_exec.hhello_exec.cpp

185. HelloWorld IDL 3 File & Generated Stub/Skel Code// hello.idl#include <Components.idl>interface Hello{ string sayHello (in string name);};component HelloWorld supports Hello{ /* ... */};home HelloHome manages HelloWorld{};// helloC.h – Stub file class HelloWorld : public virtual ::Components::CCMObject, public virtual ::Hello {};// helloC.h – Stub file class HelloHomeImplicit : public virtual ::Components::KeylessCCMHome {};// helloC.h – Stub fileclass HelloHomeExplicit : public virtual ::Components::CCMHome {};// helloC.h – Stub fileclass HelloHome : public virtual HelloHomeExplicit, public virtual HelloHomeImplicit {};IDL file has IDL 3 keywordse.g., component, home,supports, & managesProcessed by IDL compiler that supports IDL 3 featuresOther tools could generate equivalent IDL 2 // helloS.h – Skeleton/Servant fileclass POA_Hello : public virtual PortableServer::ServantBase {};// helloS.h – Skeleton/Servant fileclass POA_HelloWorld : public virtual POA_Components::CCMobject, public virtual POA_Hello { /* ... */ };

186. HelloWorld CIDL & Generated Servant CodeCIDL compiler generatesServant code, which is transparent to developersExecutor IDL, which developers then implementServant code is generated forComponentsHelloWorld_ServantHelloWorld_ContextHomesHelloHome_ServantFacets<facet name>_Servant// hello.idl#include <Components.idl>interface Hello { /* ... /* };component HelloWorld supports Hello { /* ... */ };home HelloHome manages HelloWorld {};// hello.cdl#include “hello.idl”composition session Hello_Example{ home executor HelloHome_Exec { implements HelloHome; manages HelloWorld_Exec; };};Servant code also contains generated component-specific context classes

187. HelloWorldCIDL-Generated Servants (hello_svnt.*)// hello.cdl#include “hello.idl”composition session Hello_Example{ home executor HelloHome_Exec { implements HelloHome; manages HelloWorld_Exec; };};class HelloWorld_Context : public virtual ::CCM_HelloWorld_Context, public virtual ::CORBA::LocalObject{ // Operations from Components::CCMContext // Operations from Components::SessionContext // Operations from CCM_HelloWorld_Context};class HelloWorld_Servant : public virtual POA_HelloWorld{ // Supported operations // Operations on the navigation interface // Operations for the receptacle interfaces};class HelloHome_Servant : public virtual POA_HelloHome{ // Supported interface operations // Home operations // Factory & attribute operations // ImplicitHome operations ::HelloWorld_ptr create ();};Compilingfor CIF/C++

188. HelloWorldCIDL-Generated Servant Details (1/6)// hello.idl#include <Components.idl>interface Hello{};component HelloWorld supports Hello {};home HelloHome manages HelloWorld{};// hello_svnt.h#include "helloEC.h“#include “helloS.h”namespace Hello_Example{ class HelloWorld_Servant; class HelloWorld_Context : public virtual CCM_HelloWorld_Context { friend class HelloWorld_Servant; // Operation overrides from base classes - // Components::SessionContext and // Components::CCMContext };}// hello.cdl#include “hello.idl”composition session Hello_Example{ home executor HelloHome_Exec { implements HelloHome; manages HelloWorld_Exec; };};Composition name maps to C++ namespace

189. Not spec-required

190. Helps implementors avoid name clashes

191. CIDL compiler navigates through implements & (IDL) manages

192. Gets component name

193. Maps name to servant, context, & base class namesHelloWorldCIDL-Generated Servant Details (2/6)// hello.idl#include <Components.idl>interface Hello {};interface Goodbye {};eventtype MsgTrigger {};component HelloWorld supports Hello { uses Goodbye GetGoodbye; publishes MsgTrigger GotMsg;};home HelloHome manages HelloWorld {};// hello_svnt.h#include "helloEC.h“#include “helloS.h”namespace Hello_Example { class HelloWorld_Servant; class HelloWorld_Context : public virtual CCM_HelloWorld_Context { public: friend class HelloWorld_Servant; virtual Goodbye_ptr get_connection_GetGoodbye (); virtual void push_GotMsg (MsgTrigger *ev); protected: virtual void connect_GetGoodbye (Goodbye_ptr obj); virtual Goodbye_ptr disconnect_GetGoodbye (); virtual Components::Cookie * subscribe_GotMsg (MsgTriggerConsumer_ptr c); virtual MsgTriggerConsumer_ptr unsubscribe_GotMsg (Components::Cookie *ck); };}Receptacle (uses) declarations

194. Interface type maps to context op params

195. Name maps to context op names

196. Event source (publishes) declarations

197. Type maps to params (event consumer)

198. Port name maps to subscribe/unsubscribe operationsHelloWorldCIDL-Generated Servant Details (3/6)// hello.idl#include <Components.idl>interface Hello{ void SayHello (in string msg);};interface Goodbye{ void SayGoodbye (in string msg);};component HelloWorld supports Hello { provides Goodbye Farewell; attribute string Message; consumes Trigger Listener;};home HelloHome manages HelloWorld{};// hello_svnt.h#include "helloEC.h“#include “helloS.h”namespace Hello_Example{ class Goodbye_Servant : public virtual POA_Goodbye { public: virtual void SayGoodbye (const char *msg); };}Facet (provides) declarations maps to C++ servant class

199. Separate servant class is implementation-specific

200. Helps C++ compiler reduce footprint

201. Facet type maps to servant & base class name generation

202. Facet interface operations mapped directly to servant class

203. Operation names map directly

204. Operation parameters map with the usual CORBA rules

205. If no port declarations or supported interface operations

206. No new operations generated in servant classHelloWorldCIDL-Generated Servant Details (4/6)// hello_svnt.h#include "helloEC.h“#include “helloS.h”namespace Hello_Example { class HelloWorld_Servant : public virtual POA_HelloWorld { public: virtual void SayHello (const char *msg); virtual Goodbye_ptr provide_Farewell (); virtual char *Message (); virtual void Message (const char *Message); class TriggerConsumer_Listener_Servant : public virtual POA_TriggerConsumer { public: virtual void push_Trigger (Trigger *evt); virtual void push_event (Components::EventBase *e); }; virtual TriggerConsumer_ptr get_consumer_Listener (); };}// hello.idl#include <Components.idl>interface Hello{ void SayHello (in string msg);};interface Goodbye{ void SayGoodbye (in string msg);};component HelloWorld supports Hello { provides Goodbye Farewell; attribute string Message; consumes Trigger Listener;};home HelloHome manages HelloWorld{};Attribute maps to get/set ops in the component servant

207. Event sink (consumes) maps to nested class (impl-specific)

208. Also maps to accessor op for the event consumer

209. Supported op maps directly to component servant op

210. Facet type maps to the return type of the accessor op

211. Facet name maps to component servant accessor opHelloWorldCIDL-Generated Servant Details (5/6)// hello.idl#include <Components.idl>interface Hello{};component HelloWorld supports Hello {};home HelloHome manages HelloWorld{};// hello_svnt.h#include “helloEC.h”#include “helloS.h”namespace Hello_Example{ class HelloHome_Servant : public virtual POA_HelloHome { // Operation overrides from base class // Components::CCMHome };}// hello.cdl#include “hello.idl”composition session Hello_Example{ home executor HelloHome_Exec { implements HelloHome; manages HelloWorld_Exec; };};CIDL compiler navigates through implements to home type

212. Maps home type to home servant class

213. Also to generated base class name

214. If home has no supported interfaces, operations, attributes, factories or finders

215. No new operations generated in servant classHelloWorldCIDL-Generated Servant Details (6/6)// hello_svnt.h#include "helloEC.h“#include “helloS.h”namespace Hello_Example { class HelloHome_Servant : public virtual POA_HelloHome { public: virtual void utilityOp (); virtual HelloWorld_ptr generate (const char *msg); virtual HelloWorld_ptr lookup (CORBA::Long key);virtual ::CORBA::Long defaultKey (); virtual void defaultKey (CORBA::Long default_key); };}// hello.idl#include <Components.idl>interface Hello{};component HelloWorld supports Hello { attribute string Message;};home HelloHome manages HelloWorld{ void utilityOp (); factory generate (in string msg); finder lookup (in long key); attribute long defaultKey;};Component type maps to implicit return type of

216. Operations generated from factory declarations

217. Operations generated from finder declarations

218. Factory & finder operations can have only in parameters (if any)

219. Home operations map directly to home servant

220. attribute maps the same as for componentsHelloWorldCIDL & Generated Executor CodeExecutor interfaces are IDL or C++/Java codeGenerated by CIDL compilerMust be implemented by component developersGenerated code has interfaces forImplicit & explicit homesMain home executorMain and/or monolithic component executorsFacet & consumer executorComponent context// hello.idl#include <Components.idl>interface Hello { /* ... /* };component HelloWorld supports Hello { /* ... */ };home HelloHome manages HelloWorld {};// hello.cdl#include “hello.idl”composition session Hello_Example { home executor HelloHome_Exec { implements HelloHome; manages HelloWorld_Exec; };};All executor interfaces are “locality constrained,” i.e., use localkeyword Component application developers extend & implement executor interfaces

221. HelloWorldCIDL-Generated Executor IDL (helloE.idl)// hello.cdl#include “hello.idl”composition session Hello_Example{ home executor HelloHome_Exec { implements HelloHome; manages HellowWorld_Exec; };};Component Executor Interfacelocal interface CCM_HelloWorld : Components::EnterpriseComponent, ::Hello {};local interface CCM_HelloWorld_Context : ::Components::SessionContext {};Component Context InterfaceExplicit Home interfacelocal interface CCM_HelloHomeImplicit{ ::Components::EnterpriseComponent create () raises (::Components::CCMException);};Implicit Home interfacelocal interface CCM_HelloHome : CCM_HelloHomeExplicit, CCM_HelloHomeImplicit {};local interface CCM_HelloHomeExplicit : ::Components::HomeExecutorBase {};These interface names are spec-compliant & generated by examining the CIDL file & included IDL filesMain Component Interfacelocal interface HelloWorld_Exec : CCM_HelloWorld, Components::SessionComponent {};local interface HelloHome_Exec : ::CCM_HelloHome {};Main Home Interface

222. HelloWorldCIDL-Generated Executor IDL Details (1/3)// hello.idl#include <Components.idl>interface Hello{};component HelloWorld supports Hello {};home HelloHome manages HelloWorld{};// helloE.idl#include "hello.idl“local interface CCM_HelloWorld : Components::EnterpriseComponent, ::Hello {};local interface CCM_HelloWorld_Context : Components::SessionContext {};local interface CCM_HelloHomeImplicit { Components::EnterpriseComponent create () raises (Components::CCMException);};local interface CCM_HelloHomeExplicit : Components::HomeExecutorBase {};local interface CCM_HelloHome : CCM_HelloHomeExplicit, CCM_HelloHomeImplicit {};// hello.cdl#include “hello.idl”composition session Hello_Example{ home executor HelloHome_Exec { implements HelloHome; manages HelloWorld_Exec; };};Component type is mapped to 2 local interfaces

223. Home type is mapped to 3 local interfaces

224. Implicit home interface declares spec-defined operations

225. Explicit home interface maps user-defined operations (if any)

226. Equivalent home interface inherits from both

227. Composition type (session) maps to executor context base class

228. Supported (supports) interface maps to component interface base interfaceHelloWorldCIDL-Generated Executor IDL Details (2/3)// hello.idl#include <Components.idl>interface Hello{};component HelloWorld supports Hello {};home HelloHome manages HelloWorld{};// helloE.idl#include “hello.idl”module Hello_Example{ local interface HelloWorld_Exec : CCM_HelloWorld, Components::SessionComponent {}; local interface HelloHome_Exec : CCM_HelloHome {};};// hello.cdl#include “hello.idl”composition session Hello_Example{ home executor HelloHome_Exec { implements HelloHome; manages HelloWorld_Exec; };};Composition name maps to IDL module

229. Home executor name maps to IDL local interface

230. Implemented home type maps to base interface (shown in previous slide)

231. Component executor name maps to local interface

232. Managed component type maps to base interface (shown in previous slide)

233. Composition type (session) maps to a middleware base interface of the component executorHelloWorldCIDL-Generated Executor IDL Details (3/3)// hello.idl#include <Components.idl>interface Hello { void SayHello (in string msg);};interface Goodbye { void SayGoodbye (in string msg);};component HelloWorld supports Hello { provides Goodbye Farewell; attribute long uuid;};home HelloHome manages HelloWorld{ factory genComp (in long id);};// helloE.idl#include "hello.idl“local interface CCM_Goodbye : Goodbye {};local interface CCM_HelloWorld : Components::EnterpriseComponent, Hello { CCM_Goodbye get_Farewell (); attribute long uuid;};local interface CCM_HelloWorld_Context : Components::SessionContext {};local interface CCM_HelloHomeImplicit { Components::EnterpriseComponent create () raises (Components::CCMException);};local interface CCM_HelloHomeExplicit : Components::HomeExecutorBase { Components::EnterpriseComponent genComp (in long id);};local interface CCM_HelloHome : CCM_HelloHomeExplicit, CCM_HelloHomeImplicit {};Facet name maps to accessor operation

234. attribute maps with no change to component executor IDL

235. factory declaration maps to implicit (base class) return type

236. Factory name maps to IDL operation

237. Factory parameters map with no change

238. Facet (provides) type maps to local interface, base class, & return type of accessor operationImplementingHelloWorld Executor (hello_exec.*) An executor is where a component/home is implemented

239. The component/home’s servant forwards a client’s business logic request to component’s executor

240. Developers subclass & implement the following *_Execlocal interfaces generated by CIDL:

241. HelloHome_Exec

242. HelloWorld_Exec

243. Our (CIAO’s) convention is to give these executor implementations stylized names, such as

244. HelloHome_Exec_Impl

245. HelloWorld_Exec_Impl// hello.cdl#include “hello.idl”composition session Hello_Example{home executor HelloHome_Exec{ implements HelloHome; manages HelloWorld_Exec; }};HelloHome servantHelloHome_ExecManagesHelloWorld servantHelloWorld_Exec

246. Example 2: Heads Up Display (HUD)Component developers must implement Executors for “provided” ports that are invoked by its clientsFacetsEvent sinksExecutors that invoke operations on the component’s “required” portsReceptaclesEvent sourcesRate GeneratorPositioningSensorDisplayingDeviceComponent ServerThis is the majority of the code implemented by component developers!

247. Implementing GPS Facet Local Interface // Executor IDL generated by CIDL compilerlocal interface CCM_position : position {};local interface GPS_Exec : CCM_GPS, Components::SessionComponent{ CCM_position get_MyLocation ();};// IDL 3interface position{ long get_pos ();};component GPS{provides position MyLocation; …};// Equivalent IDL 2interface GPS : Components::CCMObject{ position provide_MyLocation (); …};// Implemented by executor developersclass position_Exec_Impl : public CCM_position, … { virtual ::CORBA::Long get_pos () { return cached_current_location_; }};class GPS_Exec_Impl : public virtual GPS_Exec, public virtual ::CORBA::LocalObject {public: virtual CCM_position_ptrget_MyLocation () { return new position_Exec_Impl; }};Factory method

248. NavDisplay Component Event Sink// IDL 3component NavDisplay{ …consumes tick Refresh;};// Equivalent IDL 2interface NavDisplay : Components::CCMObject{ … tickConsumer get_consumer_Refresh (); …};Components can be connected to event consumer interfaces, similar to facets CIDL generates event consumer servantsExecutor mapping defines typed push operations directlyclass NavDisplay_Exec_Impl : public virtual NavDisplay_Exec, public virtual ::CORBA::LocalObject {public: ... virtual void push_Refresh (tick *ev) { // Call a user-defined method // (see next page) to perform some // work on theevent. this->refresh_reading (); } ...};

249. Using NavDisplay Receptacle ConnectionsComponent-specific context manages receptacle connectionsExecutor acquires its connected receptacle reference from its component-specific context// IDL 3component NavDisplay{ …uses position GPSLocation; …};// Equivalent IDL 2interface NavDisplay : Components::CCMObject{ … void connect_GPSLocation (in position c); position disconnect_GPSLocation(); position get_connection_GPSLocation (); …};class NavDisplay_Exec_Impl : public virtual NavDisplay_Exec, public virtual ::CORBA::LocalObject {public: ... virtual void refresh_reading (void) { // Local callposition_var cur = this->context_->get_connection_GPSLocation (); // Remote call long coord = cur->get_pos (); ... } ...};

250. MainMainComponentComponentComponentComponentSpecificSpecificExecutorExecutorContextContextCCMContextCCMContextExecutorsExecutorsExecutorsExecutorsExecutorsExecutorsCCMContextCCMContextEnterpriseComponentEnterpriseComponentServantServantPOAPOAContainerContainerInitializing NavDisplay Component ContextCalls to set context information are invoked automatically as callbacks from containers during deploymentComponent developers implement these callbacks in their executor codeclass NavDisplay_Exec_Impl : public virtual NavDisplay_Exec, public virtual ::CORBA::LocalObject {private:CCM_NavDisplay_Context_var context_;public: ... // Called back by container void set_session_context (Components::SessionContext_ptr c) { this->context_ =CCM_NavDisplay_Context::_narrow (c); } ...};Component-specific context manages connections & subscriptions

251. Container passes component its context via callbacks, e.g.

252. set_session_context()

253. set_entity_context()Pushing Events from a RateGen Component// IDL 3component RateGen{publishes tick Pulse; // emits tick Trigger; …};// Equivalent IDL 2interface RateGen : Components::CCMObject{ Components::Cookie subscribe_Pulse (in tickConsumer c); tickConsumer unsubscribe_Pulse (in Components::Cookie ck); …};Component-specific context also

254. Manages consumer subscriptions (for publishers) & connections (for emitters)

255. Provides the event pushing operations & relays events to consumers class RateGen_Exec_Impl : public virtual RateGen_Exec, public virtual ::CORBA::LocalObject {public: ... virtual void send_pulse (void) {tick_varev = new tick; this->context_->push_Pulse (ev.in ()); } ...};Runs in a loop at rateHz Rate

256. Summary of Server OMG IDL Mapping RulesA component type is mapped to three local interfaces that correspond to different component roles/portsThe component executor interfaceInherits from Components:: EnterpriseComponent& provides operations for attributes, supported interfaces, & receiving eventsA facet executor interfaceOperations to obtain facet object referencesThe component-specific context interfaceOperations to publish events & access component receptaclesA home type is mapped to four local interfaces

257. An explicitexecutor interface for user-defined operations

258. Inherits from Components:: HomeExecutorBase

259. An implicitexecutor interface for create() operation

260. A main executor interface inheriting from both previous interfaces

261. A composition executor interface inheriting from the main executor interfaceWe explored all of these mappings in detail in previous slides

262. 2010-8-23114Component Packaging, Assembly, & Deployment

263. Overview of Deployment & Configuration Process GoalsEase component reuseBuild complex applications by assembling existing componentsDeploy component-based application into heterogeneous domain(s)Separation of concerns & rolesComponent development & packagingApplication assemblyApplication configurationApplication deploymentServer configurationDeployerDeploymentApplication

264. Component Configuration Problem Component middleware & applications are characterized by a large configuration space that maps known variations in the application requirements space to known variations in the solution spaceComponents interact with other software artifacts & environment to achieve specific functionse.g., using a specific run-time library to encrypt & decrypt dataSome prior knowledge of the run-time environment may be required during developmente.g., rates of certain tasks based on the functional role playedNeed to configure the middleware for specific QoS propertiese.g., transport protocols, timeouts, event correlation, concurrency/synchronization models, etc.Adding environment & interaction details with the business logic leads to overly tight coupling e.g., tightly coupled code leads to poor reusability & limited QoS

265. CCM Configuration Concept & SolutionSolutionWell-defined exchange formats to represent configuration properties

266. Can represent a wide variety of data types

267. Well-defined semantics to interpret the data

268. Well-defined interfaces to pass configuration data from “off-line” tools to components

269. Well-defined configuration boundary between the application & the middleware ConceptConfigure run-time & environment properties late in the software lifecycle, i.e., during the deployment process

270. Component Deployment ProblemComponent implementations are usually hardware-specific

271. Compiled for Windows, Linux, Java – or just FPGA firmware

272. Require special hardware

273. e.g., GPS sensor component needs access to GPS device via a serial bus or USB

274. e.g., Navigation display component needs … a display

275. not as trivial as it may sound!

276. However, computers & networks are often heterogeneous

277. Not all computers can execute all component implementations

278. The above is true for each & every component of an application

279. i.e., each component may have different requirementsSW Creator1SWCreator2InfrastructureInterfacesA2A1ImplementationsDeploymentrequirementsShippingDeploymentInterfacesDeploymentInfrastructureDeployment Tools (generic)SW DeployerOMG Component Deployment & Configuration Spec (1/2)Goals of D&C PhasePromote component reuse

280. Build complex applications by assembling existing components

281. Automate common services configuration

282. Declaratively inject QoS policies into applications

283. Dynamically deploy components to target heterogeneous domains

284. Optimize systems based on component configuration & deployment settingsOMG Deployment & Configuration (D&C) specification (ptc/05-01-07)

285. OMG D & C Spec(PIM & PSMs)SW Creator1SWCreator2XMLSchemaGenerationD & CProfileInfrastructureInterfacesIDLGenerationA2A1ImplementationsInterchangeFormatsDeploymentrequirementsShippingDeploymentInterfacesDeploymentInfrastructureDeployment Tools (generic)SW DeployerOMG Component Deployment & Configuration Spec (1/2)OMG Deployment & Configuration (D&C) specification (ptc/05-01-07)

286. CCM Deployment SolutionWell-defined exchange format

287. Defines what a software vendor delivers

288. Requires “off-line” data format that can be stored in XML files

289. Well-defined interfaces

290. Infrastructure to install, configure, & deploy software

291. Requires “on-line” IDL data format that can be passed to/from interfaces

292. Well-defined software metadata model

293. Annotate software & hardware with interoperable, vendor-independent, deployment-relevant information

294. Generate “on-line” & “off-line” data formats from models

295. e.g., CoSMIC at www.dre.vanderbilt.edu/cosmic122Overview of Lightweight CCM Specificationwww.omg.org/cgi-bin/doc?realtime/2003-05-05

296. Motivation for Lightweight CCM (LwCCM)Many DRE CORBA applications can’t use “enterprise” CCM due to constraints e.g., small code size in embedded environments & limited processing overhead for performance-intensive applicationsThese constrained environments need “lightweight” CCM functionality ORB vendors, or other third-party vendors, can then support this lightweight version in a standard packageIn the Lightweight CCM specification, each section is explicitly treated & either retained as is, profiled, or removed

297. CCM Features Retained in LwCCM SubsetAll types of ports, i.e.,FacetsReceptaclesEvent sources & sinksAttributesComponent homesGeneric port management operations in CCMObjectMonolithic implementationsSession/service component/ container types“Receives From” “Sends To” Container

298. CCM Features Excluded from LwCCM SubsetKeyed homesLarge overhead & complexityProcess & Entity containersPersistence often not relevant in DRE systems domainComponent segmentationUnnecessary with introduction of D&CCIDLMay not be needed after removal of PSDL & segmentationIDL 3 may be sufficientCCMObject introspection

299. Useful in managing dynamic applications & debugging

300. Debugging can be done in full CCM

301. Application management can be done using D&C

302. Dynamic applications often not relevant in DRE systems domain

303. Equivalent IDL for port management

304. Redundant, can use generic port operations

305. Generic interface is required for D&CLightweight CCM should be treated like Minimum CORBA, i.e., advisory

306. IDL 3+126

307. Grouping Related ServicesContext - Components may have one or more facets or receptacles that are related as part of the implementation of a cohesive serviceProblemNo semantic information about these groupings are captured in IDLMakes it difficult and error prone to plan deployments that are correct by constructionSolution – Create an ‘extended’ port type that may be offered by a componentRequires new IDL keywords to define a grouping of related facets and receptaclesProvides for parameterization for services that may be generic with respect to its data type.

308. IDL3+Extension of the IDL3 languageDefined in the DDS for Lightweight CCM specification (DDS4CCM)Provides an IDL3 equivalent mapping so the new constructs can be converted to IDL3Provides new keywords forSpecifying grouping of related facets/receptacles (porttype)Declaring ports within a component (port, mirrorport)Support for new entity intended to provide “glue” between several ports (connector)A template syntax for parameterized modules

309. interface Data_Pusher { void push(in Data dat);};interface FlowControl { void suspend (); void resume(); readonly attribute nb_waiting; };// extended port definitionporttype ControlledConsumer { provides Data_Pusher consumer; uses FlowControl control;}; // Component supporting a portcomponent Sender{ port ControlledConsumer data_out;};Facets/Receptacles are declared in the same way as a regular componentPort and mirrorport are used to define opposite ends of the connection.component Receiver { mirrorport ControlledConsumer data_in;};Fixed Extended Ports

310. Fixed Extended Port Equivalent IDL3Facets/Receptacles map directly into the component in place of port declaration// extended port definitionporttype ControlledConsumer { provides Data_Pusher consumer; uses FlowControl control;}; // Component supporting a portcomponent Sender{ port ControlledConsumer data;};component Receiver{ mirrorport ControlledConsumer input;};Name of port prepended to new facet/receptacle namescomponent Sender{ provides Data_Pusher data_consumer; uses FlowControl data_control;};component Receiver{ uses Data_Pusher input_consumer; provides FlowControl input_control;};Mirrorport keyword inverts facets and receptacles

311. module Typed <typename T>{ interface Pusher { void push(in T data); }; porttype Consumer { provides Pusher consumer; uses FlowControl control; };};module Typed < Data> DataModule;component Sender { port DataModule::Consumer data;};component Receiver { mirrorport DataModule::Consumer data;}Parameterized Extended PortSome IDL construct may vary in only the data type used as a parameterNeed to avoid proliferation of type-specific port type declarationsSyntax similar to C++ template programmingAll parameterized types are contained in a typed moduleTyped modules is instantiated

312. Parameterized Port Equivalent IDL3module DataModule{ interface Pusher { void push(in Data data); }; porttype Consumer { provides Pusher consumer; uses FlowControl control; };component Sender { provides DataModule::Pusher data_consumer; uses FlowControl data_control};module Typed <typename T>{ interface Pusher { void push(in T data); }; porttype Consumer { provides Pusher consumer; uses FlowControl control; };};module Typed < Data> DataModule;component Sender { port DataModule::Consumer data;};

313. Connectors133

314. Motivating Connectors (1/2)Context – Many applications must leverage non-CORBA communication mechanismsInterfacing with legacy codeComplying with mandated architectural standardsHigh level systems integrationProblemExisting CCM ports (pub/sub or facet/receptacle) may not properly capture communication semanticsAddition of new communication middleware/semantics requiresMixing communication logic with business logicModifying the container to extend/change semantics of existing portsPrecludes use of D&C middleware for configuration

315. Motivating Connectors (2/2)Solution – Create a separate, deployable entity to contain communication logicLeverage extended ports to create well-defined interfacesCan be re-used across different applicationsAllows D&C infrastructure to coordinate configurationImplemented using new connector IDL3+ keywordCollects ports (regular and extended) into a coherent interfaceCan have attributes which may be used for D&CCan be placed in a parameterized module

316. Fixed and parameterized connectors are possibleConnectors support ports, attributes, and inheritanceconnector Cnx {mirrorport Data_ControlledConsumer cc; provides Data_Pusher p; attribute string configuration;};module Typed <typename T> { connector Cnx { port ControlledConsumer cc; mirrorport Pusher p; attribute T configuration; };};Defining Connectors

317. Implementing and Deploying ComponentsConnectors may be divided into fragmentsEach fragment is co-located with the component instance it is connected toOne or more fragments may be associated with a particular componentConnector fragment is derived from CCMObjectConnector fragment can be deployed as a regular componentConfiguration takes place via standard attributes defined in the interfaceFragment must implement Navigation, Receptacles, and, KeylessCCMHome

318. Connector Modeling vs. Deployment (1/2)From a modeling standpoint, connectors appear monolithicNeed not be concerned with ‘fragments’ or how they are deployedConnections are made from a component to the desired port on the connector

319. Connector Modeling vs. Deployment (2/2)The modeling tool will generate descriptors for the appropriate fragmentsEach application component is deployed collocated with a dedicated fragment for communicationApplication components and their connectors communicate over local interfaces

320. Connector fragment instantiationApplication components cannot share connector fragment instancesAn application component that defines multiple extended port connectors to the same unique connector should utilize a single connector fragment instance to connectA single extended port of an application component cannot connect to more than one connector fragmentWhen a model uses a connection to an extended port the generated CDP file will connect all basic portsWhen a receptacle is tagged as “asynchronous” a collocated AMI4CCM connector fragment is only deployed with the component that has the client portFor each connection as part of a uses multiple an ami4ccm connector fragment is deployed

321. DDS for Lightweight CCM141

322. DDS for Lightweight CCM (1/3)The Data Distribution Service (DDS) provides robust and high performance communicationAccommodates any flavor of pub/sub communicationRich API for configuring behavior and Quality of Service (QoS)Flexibility and robustness comes at the price of increased complexityConfiguration can be tedious and error-proneDevelopers must write boilerplate code to bootstrap and configure their applicationMust develop ad-hoc and proprietary ways to store and apply configuration dataThe DDS for Lightweight CCM (DDS4CCM) resolves these challenges

323. DDS for Lightweight CCM (2/3)Provides a simpler API to the application developerCompletely removes configuration from the scope of the application developerDefines ready-to-use ports intended to hide complexityWell-defined DDS patterns are codified in connectors with associated QoS settingsProvides robust deployment and configuration support to DDSProvides a container (via CCM) to perform application bootstrapping and configurationApplication binary distribution to distributed, heterogeneous domainsCoordinated application startup and teardown across distributed nodes

324. DDS for Lightweight CCM (3/3)Specification tries not to prevent advanced DDS usageAll ports provide access to a more detailed interfaceAll involved DDS entities can be discovered using this starting point

325. DDS4CCM Basic Ports (1/3)The basic ports are grouped into three categories: Data Access – Publishing, Data Access – Subscribing, and Status AccessData Access – PublishingWriter – Allows publication of data on a topic without regard to the instance lifecycle.Updater– Allows publication of data with management of instance lifecycle. Allows creation, update, and deletion of instances.

326. DDS4CCM Basic Ports (2/3)Data Access – SubscribingReader – Allows access to one or more instances with non-blocking semantics.Getter – Allows access to one or more instances with blocking semantics.Listener – Provides a callback mechanism to the application when new data arrives, regardless of instance stateStateListener – Provides a callback mechanism to the application when new data arrives, with different operations depending on state

327. DDS4CCM Basic Ports (3/3)Status AccessPortStatusListener – Delivers status related to ports, this information is relevant to data subscribers. ConnectorStatusListener – Delivers status updates that are relevant system-wide.

328. DDS4CCM Extended Ports (1/2)The extended ports – in most cases – combine a basic port with the corresponding DCPS IDL interfaceProvides the opportunity to access advanced DDS featuresIncreases code portability by not exposing DDS implementation directlySubscriber ports also include a PortStatusListenerporttypeDDS_Read { uses Reader data; attribute QueryFilter filter; uses ContentFilterSettingfilter_config; uses DDS::DataReaderdds_entity; provides PortStatusListener status;};porttypeDDS_Write { uses Writer data; uses DDS::DataWriterdds_entity;};

329. DDS4CCM Extended Ports (2/2)Listener ports (updates are pushed to the component) contain both Reader and Listener ports‘Reader’ portion of the extended port is used to configure criteria used to select updatesSelected updates are pushed to the componentporttypeDDS_StateListen { uses Reader data; uses ListenerControldata_control; provides StateListenerdata_listener; attribute QueryFilter filter; uses ContentFilterSettingfilter_config; uses DDS::DataReaderdds_entity; provides PortStatusListener status;}; porttypeDDS_Listen { uses Reader data; uses DataListenerControl control; provides Listener data_listener; attribute QueryFilter filter; uses ContentFilterSettingfilter_config; uses DDS::DataReaderdds_entity; provides PortStatusListener status;};

330. DDS4CCM Standard Connectors (1/2)Gathers connectors for all roles in a given use patternOne or more DDS4CCM Extended Ports (as mirrorports)Configuration meta-data (domain ID, topic name, QoS profiles)Two standard defined ‘base connectorsDDS_BaseDDS_TopicBaseTwo standard defined connectorsPattern State TransferPattern Event Transferconnector DDS_Base { uses ConnectorStatusListener error_listener; attribute DDS::DomainId_t domain_id setraises (NonChangable); attribute string qos_profile setraises (NonChangable);};connector DDS_TopicBase : DDS_Base { attribute string topic_name setraises (NonChangable); attribute StringSeq key_fields setraises (NonChangable);};

331. DDS4CCM Standard Connectors (2/2)Standard provides two predefined connectorsEach connector corresponds to a DDS usage patternPattern State TransferObservable – Components that publish stateObserver – Components that subscribe to that informationPattern Event TransferSupplier – Components that send events over DDSConsumer – Components that subscribe to those eventsconnector DDS_State : DDS_TopicBase { mirrorport DDS_Update observable; mirrorport DDS_Read passive_observer; mirrorport DDS_Get pull_observer; mirrorport DDS_Listen push_observer; mirrorport DDS_StateListen push_state_observer};connector DDS_Event : DDS_TopicBase { mirrorport DDS_Write supplier; mirrorport DDS_Get pull_consumer; mirrorport DDS_Listen push_consumer; };End users are free to define connectors more appropriate for their use cases!

332. CCM/DDS Entity Mapping (1/3)ConnectorConnectorTopic <A> QoS Profile X DataReader<A> DataWriter<A>Topic <A> QoS Profile X DataReader<A>Domain 0Domain Participant QoS Profile X Publisher SubscriberDomain Participant QoS Profile X Publisher SubscriberApplication Process 2Application Process 1Raw_Listener Port <A>Raw_Listener Port <A>WriterPort <A>

333. CCM/DDS Entity Mapping (2/3)ConnectorConnectorTopic <A> QoS Profile X DataReader<A> DataWriter<A>Topic QoS Profile X DataReader DataReader’Domain 0Domain 1ConnectorConnectorTopic <A> QoS Profile Y DataWriter <A>Topic <A> QoS Profile X DataReader<A>Domain Participant QoS Profile X Publisher SubscriberApplication Process 2Domain Participant QoS Profile X Publisher SubscriberDomain Participant QoS Profile Y Publisher SubscriberApplication Process 1Raw_Listener Port <A>Raw_Listener Port <A>WriterPort <A>Raw_Listener Port Raw_Listener Port ’Writer Port <A>

334. CCM/DDS Entity Mapping (3/3)ConnectorConnectorTopic <A> QoS Profile X DataReader<A> DataWriter<A>Topic QoS Profile X DataReader DataReader’Domain 0Domain 1ConnectorConnectorConnectorTopic <A> QoS Profile Y DataWriter <A>Topic <A> QoS Profile X DataReader<A>Topic <A> QoS Profile Y DataReader<A>Domain Participant QoS Profile X Publisher SubscriberApplication Process 2Domain Participant QoS Profile X Publisher SubscriberDomain Participant QoS Profile Y Publisher SubscriberApplication Process 3Domain Participant QoS Profile Y Publisher SubscriberApplication Process 1Raw_Listener Port <A>Raw_Listener Port <A>WriterPort <A>Raw_Listener Port Raw_Listener Port ’Writer Port <A>Raw_Listener Port <A>

335. ExampleInitial proof of concept is a derivation of the “Hello, World!” CCM example

336. The example uses DDS to communicate a simple string between two components

337. Example includes a connector implemented as two fragments to accomplish DDS communicationHello, World! IDL//DatastructstructHello {stringmsg;};component Sender {port Hello::DDS_Writemsg;}componentReceiver { portHello::DDS_Listenmsg;}module ::CCM_DDS::Typed < ::Hello, ::Hello_Seq> Hello;The connector code is completely generated! We will focus on the component code.

338. Connector IDL Sender$CIAO_ROOT/connectors/dds4ccm/idl/ccm_dds.idlmodule CCM_DDS {module Typed <typename T, sequence<T> TSeq> {local interface Writer : InstanceHandleManager {voidwrite_one (in T datum, in DDS::InstanceHandle_tinstance_handle) raises (InternalError); /* ………… */ } /* ………… */porttypeDDS_Write {uses Writer data;uses DDS::DataWriterdds_entity; };connectorDDS_Event : DDS_TopicBase {mirrorportDDS_Write supplier; /* ………… */ }; };};Typed module with T=HelloDDS Writer port. Writer interface is called ‘data’We’re using an Event connector. The extended DDS_Write port is called ‘supplier’.

339. Implementing the Sender Componentccm_activate is invoked on a component instance to indicate that it may begin executionA component-specific context maintains connection info// Equivalent IDL3module CCM_DDS{ module Typed <typename T, sequence<T> TSeq> { local interface Writer:InstanceHandleManagervoidwrite_one (in T datum, in DDS::InstanceHandle_tinstance_handle) raises (InternalError); /* … */ }; /* … */porttypeDDS_Write {uses Writer data;uses DDS::DataWriterdds_entity; };};module Hello {componentSender {port Hello::Writer msg;};};void Sender_exec_i::ccm_activate (){ ::Hello::Writer_varwriter = this->context_-> get_connection_msg_data(); Hello * new_msg; new_msg.msg = "Hello World!"; writer->write_one (new_msg, ::DDS::HANDLE_NIL);}This passes the Hello structover the local interface to the connector. All DDS setup (domain, QoS, topic, etc) is handled by the connector and is entirely hidden from the application developerObtaining the writer interface of the DDS4CCM connector.

340. Connector IDL Receiver$CIAO_ROOT/connectors/dds4ccm/idl/ccm_dds.idlmodule CCM_DDS {module Typed <typename T, sequence<T> TSeq> { local interface Listener {void on_one_data (in T datum, in ReadInfo info);void on_many_data (in TSeq data, in ReadInfoSeqinfos); } /* ………… */porttypeDDS_Listen { /* ………… */provides Listener data_listener; /* ………… */ };connectorDDS_Event : DDS_TopicBase {mirrorportDDS_Listenpush_consumer; /* ………… */ }; };};Typed module with T=HelloDDS_Listen port. Listener interface is called ‘data_listener’This time the DDS4CCM connector uses the Receiver component to callback to.

341. Receiver Equivalent IDL3module Hello {component Receiver {port Hello::DDS_Listeninfo_out;provides CCM_DDS::ConnectorStatusListenerinfo_out_connector_status; };};Pushes new instance updates to the receiver upon receiptProvides status information to the receiver (e.g., missed deadlines, lost samples, etc.)The Hello, World prototype currently implements the Listener port

342. Implementing the ReceiverType-specific Listener InterfaceListener Facet ImplementationclassReceiver_exec_i : publicvirtualReceiver_Exec,publicvirtual ::CORBA::LocalObject{virtual ::Hello::CCM_Listener_ptrget_msg_data_listener(void) { return new DDSHello_Listener_exec_i (); } };classDDSHello_Listener_exec_i : public virtual ::CCM_DDS::CCM_Listener,public virtual ::CORBA::LocalObject{public:virtualvoid on_one_data (const Hello & an_instance,const ::CCM_DDS::ReadInfo & info) {ACE_DEBUG ((LM_DEBUG, “Received message <%C>\n”, an_instance.msg); }};Component executor get_msg_data_listenernavigation method. This methods is invoked by the DDS4CCM connector in order to retrieve the callback interface (which the Receiver component provides)

343. Hello, World Prototype$CIAO_ROOT/connectors/dds4ccm/examples/HelloA full implementation has been createdSender component and connector fragmentReceiver component and connector fragmentNon-CCM DDS senderNon-CCM DDS receiverMultiple test scenariosOne to oneMany to oneOne to manyInteroperability with non-CCM DDS programs

344. Prototype Entity MappingDomain 0ConnectorConnectorDomain Participant QoS Profile X Publisher SubscriberDomain Participant QoS Profile X Publisher SubscriberTopic <A> QoS Profile X DataReader<A>Topic <A> QoS Profile X DataReader<A> DataWriter<A>Application Process 2Application Process 1Raw_Listener Port <A>WriterPort <A>

345. DDS4CCM LifeCycle

346. Writing and receiving one sample

347. Debugging DDS4CCMThe environment variable DDS4CCM_NDDS_LOG_VERBOSITY controls the output of RTI NDDSDDS4CCM’s internal logging can be set by setting the CIAO_LOG_LEVEL environment variable (1=error/10=info).One should use the ACE_DEBUG and ACE_ERROR logging macros in the user code.

348. Implementation remarksStateListenerControl::is_filter_interpreted is onlyworkingfortrueThe qos_profile string is interpreted as library_name#profile_name, which is RTI specificThe core of DDS4CCM is not vendor independent yet, part of the code (including all *_with_profile) are specific to RTIFor now, the only supported DDS implementation is version 4.5b Rev 01 of RTI. Add ndds=1 and dds4ccm_ndds=1 to your default.features and platform_macros.GNU file before you generate your makefilesAdditional DDS vendors have to be added through partial template specialization using the DDS4CCM Vendor enum

349. Decisions (1/2)The life cycle of the DDS4CCM connector entities differ from the life cycle of the DDS entities (see previous sheets).RTI DDS entities are defined, using DDS as prefix. DDS4CCM implements a DDS module in IDL in which the interface to DDS is defined. Therefore the DDS4CCM representation of a DDS entity is defined as ::DDS::xxxInternally every DDS entity has got an DDS4CCM proxy class (prefixed with CCM_DDS_xxx). These proxy classes store a pointer to the actual DDS entity.Extended ports are created on demand. When an extended is not configured as a connection in the deployment plan, it is not created.

350. Decisions (2/2)The DDS4CCM basic port maps the DDS API to the userThe DDS4CCM extended ports group the basic ports. They share the DataReader and QueryCondition (if defined)DomainParticipants with the same QoS profile are shared because of performance reasons.

351. ThreadingAll DDS4CCM callbacks are delivered to the user component using the CCM threadsWhen all callbacks have to be delivered on the DDS middleware threads add the following define to your ace/config.h file #define CIAO_ DDS4CCM_CONTEXT_SWITCH 1

352. AMI for CCM171

353. Motivating Asynchronous Method InvocationContext – Asynchronous Method Invocation (AMI) can be extremely useful in component applicationsDecrease end-to-end latency for multiple requestsEfficiently communicate with large numbers of connected componentsAvoid unreliable and non-scalable workarounds (e.g., oneway operations, multi-threading synchronous invocations) Problem – CCM has no built-in support for AMIUsing AMI requires access to the ORB to register reply handlersThere is no standards-based way for an executor implementation to directly access all TAO entities neededUsing AMI directly introduces many of the complexities CCM attempts to avoid!

354. Asynchronous Method Invocation forCCM (AMI4CCM)Solution – Implement connectors to provide AMI services to components, similar to the DDS4CCM specificationProvide a standardized AMI mechanism to CCMUses IDL3 and IDL3+ language featuresExtends the implicit IDL2 rules for AMI to IDL3Use templated modules for the AMI4CCM connectorSupports only the callback AMI model

355. AMI for CCM Overview (AMI4CCM)Tooling will generate an AMI connectorAMI connector will handle details of executing the asynchronous invocation and callback to the user componentConnector could use alternate communication middleware to accomplish AMIServer side components aren’t aware of any AMI clients!Reply Handler is local IDL and not in the cdp

356. AMI4CCM Implied IDL (1/7)#pragma ciao ami4ccm interface “MyFoo“#pragma ciao ami4ccm interface “MyFoo” exception InternalError{ long id; string error_string;}interface MyFoo{ long foo (in string in_str, out string answer) raises (InternalError); attribute short rw_attribgetraises (InternalError)setraises (InternalError; };The interface the application programmer created (Hello.idl) :Used for enabling AMI4CCM per interface

357. AMI4CCM Implied IDL (2/7)Implied base idl (HelloA.idl) defining the AMI4CCM implied interfaces// Implied ReplyHandler interface from AMI connector// to Sender-Componentlocal interface AMI4CCM_MyFooReplyHandler : ::CCM_AMI::ReplyHandler{ void foo ( in long ami_return_val, in string answer); void foo_excep ( in CCM_AMI::ExceptionHolder exception_holder); void get_rw_attrib ( in short rw_attrib); void get_rw_attrib_excep ( in CCM_AMI::ExceptionHolder exception_holder); void set_rw_attrib (); void set_rw_attrib_excep ( in CCM_AMI::ExceptionHolder exception_holder);};Type-specific reply handler

358. AMI4CCM Implied IDL (3/7)continuation implied base idl (HelloA.idl) // AMI interface. Sender calls AMI interface on the AMI connector. The AMI connector// calls Receiver using the MyFoo interface.local interface AMI4CCM_MyFoo{ void sendc_foo ( in AMI4CCM_MyFooReplyHandler ami4ccm_handler, in string in_str); void sendc_get_rw_attrib ( in AMI4CCM_MyFooReplyHandler ami4ccm_handler); void sendc_set_rw_attrib ( in AMI4CCM_MyFooReplyHandler ami4ccm_handler);, in short rw_attrib );};module CCM_AMI::Connector_T<MyFoo, AMI4CCM_MyFoo> AMI4CCM_MyFoo_Connector;Type-specific asynch interface for making invocationsConnector : uses MyFoo, the interface of the receiver.provides AMI4CCM_MyFoo, the interface for the sender.

359. AMI4CCM Implied IDL (4/7)The interface to write for the Sender (Hello_Sender.idl) :#pragma ciao ami4ccm receptacle “Sender::run_my_foo"// SENDER COMPONENTcomponent Sender { // For synchronous invocation uses MyFoo run_my_foo; };For asynchronous invocations, the Sender component uses the AMI4CCM_MyFoo interface of the AMI component and provides the AMI4CCM_MyFooReplyHandler interface to the AMI component.For synchronous invocations, the Sender component uses the MyFoo interface (which the Receiver provides).Pragma is used for implying the asynch receptacle. local interface CCM_Sender_Context: ::Components::SessionContext { ::MyFoo get_connection_run_my_foo (); ::AMI4CCM_MyFoo get_connection_sendc_run_my_foo (); };Part of the implied interface for the Sender(Hello_SenderE.idl)

360. AMI4CCM Implied IDL (5/7)The Connector, the AMI-Component, will be generated completely by the IDL compiler by implying ami4ccm.idlconnector AMI4CCM_Base{};module Connector_T<interface T, interface AMI4CCM_T>{ porttype AMI4CCM_Port_Type { provides AMI4CCM_T ami4ccm_provides;uses T ami4ccm_uses; };connector AMI4CCM_Connector : AMI4CCM_Base { port AMI4CCM_Port_Type ami4ccm_port; };};Part of ami4ccm.idl, defining the connector interface

361. AMI4CCM Implied IDL (6/7)The Receiver just implements the interface provided by the application programmer. The Receiver component has no idea which component (in this case Sender or AMI) uses his interface!The interface to write for the Receiver ( Hello_Receiver.idl) :// RECEIVER COMPONENTcomponent Receiver { provides MyFoo do_my_foo; };

362. AMI4CCM Implied IDL (7/7)The ExceptionHolder only delivers the functionality to rethrow the original exceptionnative UserExceptionBase;local interface ExceptionHolder { void raise_exception() raises (UserExceptionBase); };

363. Overview of the implied ports// SENDER COMPONENT// For synchronousinvocationusesMyFoo run_my_foo;// For asynchronousinvocation uses AMI4CCM_MyFoo sendc_run_my_foo// RECEIVER COMPONENT// Provides provides MyFoo do_my_foo;//AMI connector // Provides the interface for Sender: provides AMI4CCM_MyFoo ami4ccm_provides;// Uses the interface of the Receiver ('server') uses MyFoo ami4ccm_uses;

364. The implied ports with ‘uses multiple’For asynchronous invocation, with uses multiple , one Sender (client) is connected with N AMI connectors to N Receivers (servers). The connection section of the deployment plan defines the N connections between the client and the N connectors and between the N connectors and the N servers. // SENDER COMPONENT// For asynchronousinvocation uses multiple AMI4CCM_MyFoo sendc_run_my_foo// RECEIVER COMPONENT 1// Provides provides MyFoo do_my_foo;//AMI connector 1// Provides the interface for Sender: provides AMI4CCM_MyFoo ami4ccm_provides;// Uses the interface of the Receiver uses MyFoo ami4ccm_uses;// RECEIVER COMPONENT 2// Provides provides MyFoo do_my_foo;//AMI connector 2// Provides the interface for Sender: provides AMI4CCM_MyFoo ami4ccm_provides;// Uses the interface of the Receiver uses MyFoo ami4ccm_uses;…….…….//AMI connector N// Provides the interface for Sender: provides AMI4CCM_MyFoo ami4ccm_provides;// Uses the interface of the Receiver uses MyFoo ami4ccm_uses;// RECEIVER COMPONENT N// Provides provides MyFoo do_my_foo;

365. AMI4CCM Example Implementation (1/3)Implied Reply Handler IDL.Implementation Sender_exec.hclassMyFoo_RH_exec_i : public virtual ::Hello::AMI4CCM_MyFooReplyHandler, public virtual ::CORBA::LocalObject { public:MyFoo_RH_exec_i ();virtual ~ MyFoo_RH_exec_i (); virtual void foo (::CORBA::Long ami_return_val, const char * answer);virtualvoidfoo_excep ::CCM_AMI::ExceptionHolder_ptrexcep_holder);AMI4CCM_MyFooReplyHandler : ::CCM_AMI::ReplyHandler{ void foo ( in long ami_return_val, in string answer); void foo_excep ( in CCM_AMI::ExceptionHolderexception_holder); void get_rw_attrib ( in short rw_attrib); void get_rw_attrib_excep ( in CCM_AMI::ExceptionHolderexception_holder);};

366. AMI4CCM Example Implementation (2/3)Implementation Sender_exec.cppImplied Reply Handler IDL.MyFoo_RH_exec_i :: MyFoo_RH_exec_i(void){}MyFoo_RH_exec_i :: ~ MyFoo_RH_exec_i (void){} voidMyFoo_RH_exec_i ::foo ( ::CORBA::Long ami_return_val, constchar * answer){ printf (“Answer <%s>\n", answer); }voidMyFoo_RH_exec_i ::foo_excep (const ::CCM_AMI::ExceptionHolder * exception_holder);{try { exception_holder->raise_exception (); } catch (…) { } }AMI4CCM_MyFooReplyHandler : ::CCM_AMI::ReplyHandler{ void foo ( in long ami_return_val, in string answer); void foo_excep ( in CCM_AMI::ExceptionHolder exception_holder); void get_rw_attrib ( in short rw_attrib); void get_rw_attrib_excep ( in CCM_AMI::ExceptionHolder exception_holder);};

367. AMI4CCM Example Implementation (3/3)Implementation in Sender_exec.cpp:Get the asynchreceptacle::AMI4CCM_MyFoo_var my_foo_ami = this->context_->get_connection_sendc_run_my_foo();my_foo_ami_->sendc_foo (new MyFoo_RH_exec_i (), "Do something asynchronous"); ::MyFoo_varmy_foo = this->context_->get_connection_run_my_foo();my_foo_->foo ("Do something synchronous“, answer);Reply handler, can be a global one or one per requestMake the asynch invocationGet the synch receptacleMake the synch invocation

368. AMI4CCM Example Implementation with “uses multiple” (1/1)// The implementation of Sender_exec.cpp:Get all of the asynchreceptacles::Sender::sendc_run_my_fooConnections_var my_foo_ami_ = this->context_->get_connections_sendc_run_my_foo (); for (CORBA::Ulong I = 0; I < my_foo_ami_->length (); ++i) {my_foo_ami_[i].objref_>sendc_foo(new MyFoo_RH_exec_i (), "Do something asynchronous"); }Make multiple asynchinvocations

369. AMI4CCM Prototype$CIAO_ROOT/connectors/ami4ccm/examples/HelloSender componentReceiver componentAMI connector Deployment plan for these 3 componentsAMI4CCM ‘uses multiple’ example$CIAO_ROOT/connectors/ami4ccm/tests/UsesMulti

370. 1 Sender component

371. 3 Receiver components

372. 3 AMI connectors

373. Deployment plan for these components189Overview of CIAO & Future R&D Directions

374. Overview of CIAOComponent Integrated ACE ORB

375. Lightweight CCM implementation atop TAO

376. Supports component-oriented paradigm for DRE applications

377. Provides Real-time CORBA policies & mechanisms required for DRE applications

378. Key DRE aspects are supported as first-class metadata

379. First official release (CIAO 0.4) was at end of December 2003

380. Latest release is downloadable from download.dre.vanderbilt.edu

381. CIAO Status………ContainerContainerComponents can be built as shared libs or static libsComponent server supportedMDD tools to install, host, load, & manage component implementations are availableThe CIAO Deployment and Configuration Engine (DAnCE) provides support for component assemblies in compliance with ptc/06-04-01CIAO also supports Real-time CCM extensions www.cs.wustl.edu/~schmidt/CIAO.htmlSupport for IDL 3 (component, home& related keywords) & most CIDL features have been added

382. Support for all types of ports: facets (provides), receptacles (uses, uses multiple), event sources (emits, publishes) & event sinks (consumes)

383. Support for the Session container via IDL compilerCIAO Next StepsDeployment & Configuration (Leads: Will Otte & Johnny Willemsen)Implementing the new deployment & configuration specification, ptc/06-04-02Changes to the deployment & assembly toolset to support lightweight components, as prescribed by ptc/06-04-01Core CCM Infrastructure (Leads: Will Otte & Johnny Willemsen)Additional support for Real-time CORBA Policies at the ORB level & object leveli.e., at the object reference level of a component receptacleIntegration of different event propagation mechanisms (such as Event & Notification Services) within the containerModeling tool support for CIAO (Leads: James Hill & Jeff Parsons)See www.dre.vanderbilt.edu/cosmic for details

384. How to Learn about CCM & CIAO ProgrammingExamples available with the distributionCIAO/docs/tutorial/Hello, a simple example that illustrates the use of some basic CCM conceptsCIAO/examples/BasicSPA simple example that shows the interaction between 4 componentsCIAO/examples/DisplaySimilar to the BasicSP, but has an additional feature showing integration with Qt toolkitStep-by-step to create & deploy components based on CIAO available atCIAO/examples/Hello“Quick CORBA 3”, Jon Siegel, John Wiley & Sons provides a quick startC/C++ User Journal articles with Steve Vinoskiwww.cs.wustl.edu/~schmidt/report-doc.html

385. 2010-8-23194WrappingUp

386. Tutorial SummaryCCM specExtends the CORBA object model to support application development via compositionCORBA Implementation Framework (CIF) defines ways to automate the implementation of many component featuresDefines standard run-time environment with Containers & Component ServersSpecifies deployment & configuration frameworkDeployment & Configuration specification separates key configuration concernsServer configurationObject/service configurationApplication configurationObject/service deployment

387. Additional Information on CORBA & CCMOMG specifications pertaining to CCMCORBA Component Model (CCM) formal/06-04-01QoS for CCMformal/08-10-02Streams for CCM ptc/05-07-01UML Profile for CCMformal/08-04-07Deployment & Configuration (D&C)formal/06-04-02DDS4CCMptc/10-05-08Books pertaining to CCMCORBA 3 Fundamentals & Programming, Dr. John Siegel, published at John Wiley & SonsWeb resources pertaining to CCM“The CCM Page” by Diego Sevilla Ruiz

388. www.ditec.um.es/~dsevilla/ccm/

389. OMG CCM specification

390. www.omg.org/technology/ documents/formal/components.htm

391. CUJ columns by Schmidt & Vinoski

392. www.cs.wustl.edu/~schmidt/report-doc.html197Overview of an Conventional Component Application Development Lifecycle

393. Component Application Development LifecycleManually specify IDL 2 types, e.g., supported interfaces

394. Component Application Development LifecycleManually specify IDL 3 types, e.g., provided & required interfaces

395. Component Application Development LifecycleManually implement component executors; associate components with component executors & their homes via the Component Implementation Definition Language (CIDL)

396. Component Application Development LifecycleManually write XML to group component implementation artifacts & metadata descriptors into component packages

397. Component Application Development LifecycleManually write XML to specify component interconnections & composition of component assembly packages

398. Component Application Development LifecycleManually decide how to configure & deploy component assembly onto target domain

399. Component Application Development LifecycleManually deploy component assembly packages onto target nodes according to deployment plan; Manually develop & run benchmarks to evaluate system QoS

400. 2010-8-23205Overview of an MDD-based Component Application Development Lifecycle

401. MDD-based Component Application Development LifecycleUse PICML to define IDL 2 types, e.g., supported interfaces

402. MDD-based Component Application Development LifecycleUse PICML to specify IDL 3 types, e.g., provided & required interfaces

403. MDD-based Component Application Development LifecycleUse Rhapsody to implement component executors; associate components with component executors & their homes via the Component Implementation Definition Language (CIDL)www.ilogix.com/webinar-detail.aspx?id=56&webtype=od&sem_title=WEB-VOD-CORBA-NOV05-DESC1.TXT

404. MDD-based Component Application Development LifecycleUse PICML to group component implementation artifacts & metadata descriptors into component packages

405. MDD-based Component Application Development LifecycleUse PICML to specify component interconnections & composition of component assembly packages

406. MDD-based Component Application Development LifecycleUse PICML & OCML to decide how to configure & deploy the component assembly onto target domain

407. MDD-based Component Application Development LifecycleUse PICML & RACE to deploy component assembly packages onto target nodes according to a deployment plan; use CUTS to develop & run benchmarks that evaluate system QoS

408. Summary of MDD-based Component Development Lifecycle

OMG CORBA Component Model tutorial

More Related Content

What's hot (20)

Similar to OMG CORBA Component Model tutorial (20)

Recently uploaded (20)

OMG CORBA Component Model tutorial