Towards integration of the Data Distribution Service with the CORBA Component Model

Transcription

1 Towards integration of the Data Distribution Service with the CORBA Component Model William R. Otte, Friedhelm Wolf, Douglas C. Schmidt (Vanderbilt University) Christian Esposito (University of Napoli, Federico II) Nawel Hamouche(PrismTech)

2 CORBA Component Model (CCM) Overview Replicas Container A/V Streams Middleware Bus Security Scheduler Persisting Container Notifiers Load Balancing Components encapsulate application business logic Components interact via ports Provided interfaces, e.g.,facets Required connection points, e.g., receptacles Event sinks & sources Attributes Containers provide execution environment for components with common operating requirements Components/containers can also Communicate via a middleware bus & Reuse common middleware services

3 OMG s Data Distribution Service (DDS) Data Distribution Service (DDS) for Real Time Systems Leap forward in Topic based Publish/Subscribe Middleware state of the art Carefully specified to allow very high performance, scalable, predictable & high availability implementations Language Independent, OS & HW architecture independent Fully Standardized Solution Data Distribution Service (DDS) for Real-Time Systems v1.2 RTPS, DDS Interoperability Wire Protocol The OMG Data Distribution Service satisfies the most challenging information dissemination requirements across a wide set of application domains, ranging from multi board systems to system of systems

4 Motivating CCM as Vehicle for DDS Applications Many distributed application challenges are not addressed by DDS Deployment of applications to nodes Configuration of DDS entities (QoS, subscribed topics) Bootstrapping and launch of the application Application developers must address these in unsatisfactory ways Proprietary and ad hoc solutions Early binding decisions and hard coded configuration CCM provides standardized solutions Container model provides for configuration, bootstrap, and access to system services Standardized packaging, deployment and configuration infrastructure and meta data

5 Challenges Integrating DDS with CCM Resolving conflicting views of connections and data DDS treats data as a first class citizen CCM considers connections to be the first class citizen Need to be able to express data as part of a connection oriented component interface Expressing and enforcing QoS policies Need to develop standards for storage and communication of meta data to the configuration run time DDS has very strong support for modifying QoS at run time, need to determine how application can influence this

6 Motivating DDS Patterns Widespread adoption and usage of DDS as revealed a number of usage patterns DDS Patterns include a number of elements One or more participants Specified elements of data interaction Most importantly, Quality of Service (QoS) properties for each participant and topic Natural mapping assigns participants to components Each participant maps to a single component Each component supports may support many participants

7 Integrating Data Centricity into CCM (1/2) Context Component interface descriptions describe provided and required interfaces and event connections Each port represents a view or service provided or required Problem Since DDS is a data centric protocol, provided and required data needs to be described as part of the component interface Several individual topics may be used as a group to provide a view or service

8 Integrating Data Centricity into CCM (2/2) Solution Create a new DDS specific port type based on concept of DDS Patterns Several topics that are provided/required are grouped in a single port Each port represents a single participant in a DDS pattern Provides a logical grouping, easing modeling, deployment analysis, and description of QoS meta data

9 Describing DDS Ports in IDL (1/4) Context: DDS ports will require code to be generated to support topic specific configuration interaction with component business logic Problem: Component interfaces are described in IDL, which currently lacks language elements to describe DDS Ports SolutionApproaches Introduce new IDL keywords into the language specifically for DDS Ports Standardize a preprocessor pragma language to annotate existing keywords

10 Describing DDS Ports in IDL (2/4) Context: Data structures need to be identified as DDS topics Problem: Topic definition, including selection of keys is non normative Solution Approaches Describe data types using IDL struct, and identify them as topics using a new topic keyword Use a location independent #pragmadirective to create a named topic consisting of data described in an IDL struct structt_data{ intid; long data; }; // Identify topics using // new keywords topic new_topic{ structt_data; key id; }; // Identify topic using // #pragma directives #pragmaccmdds\ topic(::t_data)\ name(new_topic) \ keys(id)

11 Describing DDS Ports in IDL (3/4) Context: Participants in DDS patterns may have several topics they provide/require Problem: Neither DDS nor IDL have standard facilities to describe such a grouping Solution Approaches: Define a new keyword ddsportwhich contains one or more publishes/consumes statements Utilize preprocessor pragmas Group related topics as public members of an eventtype Annotate members as being publishes or subscribes Use a pragma to indicate the eventtyperepresents a role // Solution using IDL Keywords topic t1 {/**/}; topic t2 {/**/}; ddsportthe_port { publishes t1 pub_1; consumes t2 con_1; }; // Solution using #pragmas #pragmaccmdds\ topic(t_data) name(t1)/**/ #pragmaccmdds\ topic(t_data) name(t2) /**/ eventtypeevt { public t_data pub_1; public t_data con_1; } #pragmaccmddsrole(evt) #pragmaccmdds\ publishes(evt.pub_1) type(t1) #pragmaccmdds\ consumes(evt.con_1) type(t2)

12 Describing DDS Ports in IDL (3/4) Context: DDS Ports need to be included in the component IDL definition Problem: Existing keywords may not provide enough information to the IDL compiler to distinguish DDS ports Solution Approaches Define a new IDL keyword that indicates that the component provides a given DDS port Annotate extant publish/consume statements with #pragma directives to distinguish them from regular event ports // IDL Keyword based approach ddsporttype_one; ddsporttype_two; component App_Comp { port type_one p1; port type_two p2; }; // Preprocessor pragma based approach #pragmaccmddsrole(type_one) #pragmaccmddsrole(type_two) component App_Comp { provides type_one p1; consumes typw_two p2; }; #pragmaccmddsport(type_one) #pragmaccmddsport \ (type_two)

13 Comparison of Keyword vs. Pragma IDL Keywords Use of new keywords is straightforward Changes to IDL may face substantial opposition from CORBA stakeholders Future integration of a new port type will require additional IDL changes Preprocessor Pragmas Does not require changes to CORBA/CCM standard New communication standards may use similar mechanisms Pragmas may be tedious and error prone due to loose syntactic coupling

14 CCM provides container and deployment/configuration standards to DDS Two proposed pattern based integration approaches Modifying IDL specification to include new keywords Leveraging preprocessor macros to annotate existing IDL3 Integration approaches presented here represent preliminary ideas Feedback from CCM and DDS communities is actively encouraged Concluding Remarks The latest version of these slides is available at: