Towards integration of the Data Distribution Service with the CORBA

Component ModelWilliam R. Otte, Friedhelm Wolf, Douglas C. Schmidt (Vanderbilt University)

Christian Esposito (University of Napoli, Federico II)Nawel Hamouche(PrismTech)

CORBA Component Model (CCM) � Overview� 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

SecurityReplicas NotifiersPersisting

SchedulerA/V Streams Load Balancing

…

Container

… …

Middleware Bus

Container

…

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

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

Fully Standardized Solution� Data Distribution Service (DDS) for

Real-Time Systems v1.2� RTPS, DDS Interoperability Wire

Protocol

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

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

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

Integrating Data‐Centricity into CCM (1/2)• Context

– Component interface descriptions describe provided and requiredinterfaces 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

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 QoSmeta‐data

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 preprocessorpragma language to annotate existing keywords

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)

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

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

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

Concluding Remarks• 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

The latest version of these slides is available at:http://www.dre.vanderbilt.edu/~wotte/ppt/CCM_DDS.pptx

The latest version of these slides is available at:http://www.dre.vanderbilt.edu/~wotte/ppt/CCM_DDS.pptx