schmidt/DDS/DDS-CCM_Integration.doc · Web viewProductivity Tools & Middleware PRISMTECH FRANCE...

PRODUCTIVITY TOOLS & MIDDLEWARE

PRISMTECH FRANCE SARL4 Rue Angiboust91460 MarcoussisFRANCE

TEL: +33 (0)1 69 01 53 54Fax : +33 (0)1 69 01 53 55WEB:http://www.prismtech. com

Proposal for DDS integration in CCM

Nawel Hamouche, Friedhelm Wolf, and Will OtteMOSIC project, WP1.1

PrismTech FranceMarch 2008

SARL Au capita l de 94 177,60 € RCS Evry B 382 565 422 00039 – maison mère : PRISMTECH LTD, REGISTERED IN ENGLAND : NO 2664365. REGISTERED OFFICE : PRISMTECH HOUSE, 5 T H AVENUE BUSINESS PARK, TEAM VALLEY, GATESHEAD, NE11 0NG

http://www.prismtech.com/



1 From DDS Patterns towards DDS ports in CCMDDS patterns (see the PT or Mosic Wiki) have revealed a set of roles whose characteristics and interactions make up the pattern. A CORBA component is a structured entity having a specified behaviour and is able to communicate with the outside world via ports. It seems clear that if a component is involved in a DDS pattern, each component can have several roles but it is not expected that several components collaborate to make up one role. A role is supported consistently by one component. Besides, a component can support multiple roles. There are no reason to prevent that. By definition, a CORBA component can have multiple facets letting him to have multiple views and multiple behaviours, so making him supporting multiple DDS roles is not too far from its nature. As a DDS role is basically a communication role, to support it the CORBA component must involve its ports. So, DDS-specific ports should be specified. This specification should be driven by the role definition to ease the support of the role. For convenience reasons, a role is henceforth associated to a port and this association is one-to-one; one DDS role is supported by one DDS port. A port cannot support multiple roles and a role cannot be supported by multiple ports.

2 DDS Ports DefinitionA component having a DDS port describes first of all the ability of the component to publish and/or consumes data following the DDS model. This ability is described in the IDL declaration of the component. The IDL description of the port is completed by a XML description that contains information related to the DDS infrastructure needed to allow the DDS port to be operational. More details are given in the following subsections.

2.1 IDL DeclarationA topic definition is introduced in IDL as an association of a data structure and a key. This is declared using the topic keyword. The topic key is specified using the key keyword and the topic structure is specified using the struct keyword, knowing that a topic can have one or many keys. In this way the same data structure can be used with multiple topics and different keys. A topic IDL declaration would be as follows :

topic <topic name> {struct <topic_struct>;key <field_id>{,<field_id>}*;

}

A DDS port is defined using the ddsport keyword. This defines a declaration block enclosing a set of publishes and consumes statements, followed by a topic type and identifier. We have intentionally reused the publishes and consumes CCM standard keywords to limit the introduction of new keywords to the IDL3 language, and to show that DDS ports are an extension to the standard CCM event ports and a mapping between the two is possible in some way. The ddsport block allow to declare the publishing/consuming of both multiple topics and multitopics, by declaring multiple publishes/consumes statements for the first case and declaring one publishes/consumes statement with a set of topics for the second case.The IDL declaration of a DDS port is as follows:

ddsport <port_type> {{publishes <topic_name> <topic_identifier>{,<topic_name> <topic_identifier>}* ;}*{consumes <topic_name> <topic_identifier>{,<topic_name> <topic_identifier>}* ;}*

}

The DDS port is then associated to a component using the port keyword declared inside the CCM component declaration block. Hence, multiple components may share the same DDS port definition.

component <identifier> {...


port <port_type> <port_identifier>;}

example: struct topic_stc {...};topic topic1{

struct topic1_stc;key id;

};topic topic2{...};topic topic3 {...};topic topic4 {...};

//ports declarationddsport portExample {

publishes topic1 t1;consumes topic2 t2;publishes topic3 t3, topic4 t4 ;

};

component compExample {port portExample portId;

} Hence, the IDL declaration of a DDS port describes only the data that passes in that port. It seems to be very suitable for a data-centric application. IDL declaration would be the responsibility of the data modeller. 2.2 IDL ExamplesThis section gives the IDL declaration of the different DDS patterns. We omit to declare the different topics structures as they are just IDL structures whose fields are application-specific. These descriptions are just examples and will be refined in the existing pattern description documents later once an agreement on the syntax is got.

2.2.1 State PatternThe State pattern has two roles: Observable and Observer that respectively publishes and subscribes state data. This is declared in IDL as follows:ddsport dds_StateObservable {

publishes State s;};ddsport dds_StateObserver {

consumes State s;};

2.2.2 Event PatternThe Event pattern has two roles : Supplier and Consumer that respectively publishes and subscribes events. This is declared in IDL as follows:ddsport dds_EventSupplier {

publishes EvenDatat e;};ddsport dds_EventConsumer {

consumes EventData e;};


2.2.3 Continuous DataThe Continuous Data Supplier and the Continuous Data Consumer roles of the Continuous Data pattern may be declared as follows :ddsport dds_ContinuousDataSupplier {

publishes ContData cd;};ddsport dds_ContinuousDataConsumer {

consumes ContData cd;};

2.2.4 Alarm PatternThe Alarm Activator and the Alarm Handler roles of the Alarm pattern may be declared as follows :ddsport dds_AlarmActivator {

publishes ActivationTopic at;consumes ClearingTopic ct;

};ddsport dds_AlarmHandler {

consumes ActivationTopic at;publishes ClearingTopic ct;

};

2.2.5 WatchDog PatternThe Watchdog and the Monitor roles of the Watchdog pattern may be declared as follows :

ddsport dds_watchdog {publishes LivelinessData ld;

};ddsport dds_Monitor {

consumes LivelinessData ld;};

2.2.6 ConsensusThe Consensus pattern introduces the Participant role that may be declared as follows:ddsport dds_ConsensusParticipant {

publishes SessionState ss;publishes ConsensusData cd;consumes Ballot cb;publishes Ballot pb;

};

2.2.7 Load BalancingThe Client and the Server roles of the Load Balancing pattern may be declared as follows:ddsport dds_LBClient {

publishes Request rq;consumes Reply rp;

};ddsport dds_LBServer {

consumes Request rq;publishes Reply rp;

};

2.3 An Alternative #pragma based Approach


The following approach enables the use of DDS within CCM without creating new IDL keywords. An advantage of this approach is that it restricts changes necessary to the CORBA and CCM specifications, which will ease acceptance by users, vendors, and the OMG. Some DDS implementations already use #pragma directives to provide additional information to their code generation tools. The proposed directives described below would be used in addition to these.

Each pragma directive will have a field that indicates which IDL entity is connected to this pragma. This enables position independent pragmas and allows the enhancement of existing IDL files without editing them. The reference will be passed as a parameter to the pragma name itself. E.g. for a topic, it will be: #pragma ccm_dds topic (<referenced IDL struct name>) …

The topic pragma describes DDS topics. It references a struct and gives it a unique name (e.g. ActivationTopic), associating a set of struct members as keys. It is therefore possible to describe several topics based on the same struct, that have different key sets.

To express a role in IDL we use the eventtype and annotate it with the #pragma “ccm_dds role”, and describe the publish/subscribe statements from the perspective of the ‘active’ participant in a role. Each member within the eventtype represents a topic struct, defined earlier. To determine whether the role will publish a topic or subscribe to it, we introduce two #pragma directives: ccm_dds provide indicates that a topic is published ccm_dds use indicates that this role subscribes to a topic

Components can declare that they play a certain role by using the standard event port keywords (publishes and consumes) on the eventtype representing the role. The #pragma directive “ccm_dds port” is used to distinguish this type of port from common event ports. Components that ‘publish’ a particular role indicate that they are the ‘active’ participant, while components that ‘consume’ a role indicate that they are the ‘passive’ participant and thus get the inverse of the indicated role.

The following pragmas are proposed. All of them have the prefix #pragma ccm_dds :

Syntax Parameters Descriptiontopic (<IDL struct>) name (<name>) keys (<key>, […])

Identifies a DDS topic

IDL struct Name of the struct that describes the topic data

name Unique name for the topickey Field within the struct, that denotes one

element of the keyrole (<eventtype>) Identifies an eventtype as representation

of a DDS role. The only relevant members are structs that are part of a topic.

eventtype Name of the referenced eventtypeprovides (<eventtype member>) type (<topic name>)

Indicates that a topic is published as part of a role

eventtype member

This name references a member in a role eventtype uniquely. Thus it has the format “<eventtype name>.<member field name>”

type References a topic name defined in a ccm dds topic statement

uses (<eventtype member>) type (<topic name>)

Indicates that a role implies subscription to a topic.

eventtype This name references a member in a role SARL Au capita l de 94 177,60 € RCS Evry B 382 565 422 00039 – maison mère : PRISMTECH LTD, REGISTERED IN ENGLAND : NO 2664365. REGISTERED OFFICE : PRISMTECH HOUSE, 5 T H AVENUE BUSINESS PARK, TEAM VALLEY, GATESHEAD, NE11 0NG

member eventtype uniquely. Thus it has the format “<eventtype name>.<member field name>”

type References a topic name defined in a ccm dds topic statement

port (<event port name>) Indicates that a component port is a DDS port

Event port name This name uniquely references an event port within a component. Thus it has the format “<component name>.<port name>”

We will use the AlarmActivator role as an example here to demonstrate the different aspects of the pragma directive based approach:

#pragma ccm dds topic (ActivationData) name (ActivationTopic) keys(id[, …])struct ActivationData {

string reason;int id;

};

// another possible topic based on the above struct:#pragma ccm dds topic (ActivationData) name (DifferentActivationTopic) keys (reason)

#pragma ccm dds topic (ClearingData) name (ClearingTopic) keys (id)struct ClearingData {

int id;};

#pragma ccm dds role (AlarmActivator)eventtype AlarmActivator{

#pragma ccm dds provides (AlarmActivator.at) type (ActivationTopic)public ActivationData at;

#pragma ccm dds uses (AlarmActivator.ct) type (ClearingTopic)public ClearingData ct;

};

component AlarmActivator {#pragma ccm dds port (AlarmActivator.alarm_out)publishes AlarmActivator alarm_out;

};

component AlarmHandler{#pragma ccm dds port (AlarmHandler.alarm_in)consumes AlarmActivator alarm_in;

};

2.4 XML descriptionThe XML description of a DDS port completes its IDL declaration to describe its operational environment in terms of DDS entities and QoS policies. As we have profiled different operational DDS environments thanks to pattern role concept, the XML description of a DDS port mainly describes the SARL Au capita l de 94 177,60 € RCS Evry B 382 565 422 00039 – maison mère : PRISMTECH LTD, REGISTERED IN ENGLAND : NO 2664365. REGISTERED OFFICE : PRISMTECH HOUSE, 5 T H AVENUE BUSINESS PARK, TEAM VALLEY, GATESHEAD, NE11 0NG

port role. According to our DDS patterns, we will define a set of standard roles that can be directly used by applications and possibly extended to define application-specific roles.

2.4.1 Role descriptionA port role is described using the <DDSrole> XML element that encloses the different DDS entities and their QoS policies that make up the role. DDS entities indicates the set of publishers and/or subscribers ,and the set of datawriters and/or datareaders associated to the different topics. As topics are application-specific, they are just name-referenced. Those references are used by the application to indicate the topics names when describing their DDS ports (as described in the next section). QoS policies can be associated to each DDS entity using the <DDSqos> XML element either by putting this tag inside each entity description (<datawriter>, <datareader>, ...), or by putting it directly as a child of the <DDSentities> element to apply it on all the entities description.

If applications use standard DDS roles, they do not have to describe them. The standard roles XML description will be provided to the application. The following example shows the description of the AlarmActivator role. Typically the AlarmActivator role XML description is imported by the application and has not to be changed. The following XML snippet describes the AlarmActivator role :

<DDSroles xmlns:prismtech=”www.prismtech.com/DDSpatterns/roles”><DDSrole name=”AlarmActivator”>

<DDSqos policy=”” value=”” /> <DDSentities>

<publishes name=”Publisher” > <DDSqos policy=”” value=”” />  <topic ref=”ActivationTopicRef”>

<DDSqos policy=”” value=”” /> <datawriter name=”DW” >

<DDSqos policy=”” value=”” /> </datawriter>

</topic></publishes><consumes name=”Subscriber”> <topic ref=”ClearingTopicRef”>

<datareader name=”DR” ><DDSqos policy=”” value=”” /> 

</datareader> </topic></consumes>

</DDSentities> </DDSrole><DDSroles>

2.4.2 Port descriptionThe application should describe its DDS ports using the <DDSport> element. It specifies the port name as declared in IDL and the port role. This latter is described using the <DDSport_role> child element. The port role has a name that can be standard or not. A standard role name is a predefined name already described by a <DDSrole> element as shown in the previous section. Typically, in this case, the application will import a role XML description file. In the example below, this file is named prismtech_roles.xml and the role name belongs to the prismtech namespace.Inside the DDSport_role element, the application should specify the topic names (types) that the port will manipulate according to its role. Each published or consumed topic is described by the <topic> element that must give the topic reference (topic ref attribute) of that topic as given by the role description. For instance, the AlarmActivator role description references the published topic as “ActivationTopicRef”. This reference is an abstraction of the real topic to allow the settings of attributes on it without having yet the knowledge of the real definition. The application must reuse this reference to indicate that the published topic name is “ActivationTopic”. Topics data can need a management-related action such as caching, conversion, filtering and so on. The <datamanagement> element is used to express that need.SARL Au capita l de 94 177,60 € RCS Evry B 382 565 422 00039 – maison mère : PRISMTECH LTD, REGISTERED IN ENGLAND : NO 2664365. REGISTERED OFFICE : PRISMTECH HOUSE, 5 T H AVENUE BUSINESS PARK, TEAM VALLEY, GATESHEAD, NE11 0NG

http://www.prismtech.com/DDSpatterns/roles

<DDSports><include href=”prismtech_roles.xml”/><DDSport name=”Elevator_AlarmActivator” >

<DDSport_role name=”prismtech:AlarmActivator”><publishes topicref=”ActivationTopicRef ” topicname=”ActivationTopic”>

<datamanagement><filter name=”Filter1” condition=”alarm_level=0” />

</datamanagement></publishes><consumes topicref=”ClearingTopicRef” topicname=”ClearingTopic”></consumes>

</DDSport_role> </DDSport>

A second port is described that is the Elevator_EnhancedAlarmHandler port that illustrate how we can extend a standard role...To be developed.

<DDSport name=”Elevator_EnhancedAlarmHandler”><DDSport_role name=”MyAlarmHandler” baserole=”prismtech:AlarmHandler”>

<consumes topicref=”” topicname=””/><publishes topicref=”” topicname=””/>??....To specify later how to extend the role ....??

<DDSport_role></DDSport></DDSports>

2.5 A Configuration Approach based on the Deployment & Configuration Specification PropertiesThe D&C Platform Specific Mapping describes configuration metadata for component applications in terms of IDL data structures that may be represented in XML via a well-defined mapping. Configuration information used to configure system services (such as DDS) is represented by configProperties, which are name/value pairs, with values being CORBA Anys.

The DDS_Infrastructure struct is provided as a value of a configProperty to a component instance. Its intent is to define which publishers and subscribers exist within a component and which topics are managed by each of them. The D&C infrastructure is responsible for creating the necessary entities (e.g. publishers, subscribers, topics, data readers and data writers) and for configuring the QoS policies as indicated within the data structures. It is also possible to provide additional configuration properties (which are name/value pairs) to the configuration engine to provide for future enhancements or varying capabilities of particular implementations.

This structure does not have an explicit concept of roles. Those can be described by the XML described in Section 2.4, for higher level planning tools. This information is not germane to the deployment and configuration process, however, and yields the following data mapping that provides all necessary information in a structured and uniform way:

// we use the QoS policy IDL definitions as given by the DDS specificationtypedef sequence <DDS::QoSPolicy> QoSPolicies;

struct Topic_Configuration {string topic_id; // “<port name>.<topic_name>” e.g. “alarm_out.at”QoSPolicies topic_qos; // QoS policies for the topic itselfQoSPolicies data_rw_qos; // will be set on the associated data reader or data writer.

// each topic has exactly one data reader or data writersequence <Property> config; // additional config properties, e.g. filter statements…

};

Each topic has exactly one associated data reader or data writer. Whether it is one or the other is determined by the fact that the topic is either contained in a publisher description ( data writer) or a subscriber description ( data reader). The member data_rw_qos described above contains QoS policies for either the data writer or the data reader depending on the role of the topic in context of the component (published or subscribed).

struct Publisher_Configuration {string publisher_id;QoSPolicies publisher_qos;sequence <Topic_Configuration> topics; // topics that are managed by this publishersequence <Property> config; // additional config properties

};

struct Subscriber_Configuration {string subscriber_id;QoSPolicies subscriber_qos;sequence <Topic_Configuration> topics; // topics that are managed by this subscribersequence <Property> config; // additional config properties

};

struct DDS_Infrastructure {sequence <Publisher_Configuration> publishers;


sequence <Subscriber_Configuration> subscribers;};

3 DDS Ports ConnectibilityDDS ports are connectible at the DDS fashion. It means that DDS ports are said connectible if and only if :

ALL the topics subscribed by one of them are published by another one. It means that all consumes statements of one port IDL declaration have their corresponding publishes statements of the same topic definition in another port declaration.

ALL ports are deployed in the same DDS domain. Ports QoS policies are mutually compatible.

Knowing that DDS ports connection is obviously not one-to-one, but many-to-many. Each port is connected to a DDS domain and can interact with other ports connected to the same domain.

Using DDS patterns and their standard roles will transpose ports connectibility to roles connectibility. In fact, each DDS pattern has identified a couple of connectible roles that allows the designer to think about ports connectibility in term of roles matching and not in terms of DDS entities matching. An Observable port cannot be connected to an other port than a observer one; An Alarm Handler cannot be connected to an other port than an Activator one; ...etc. This does not prevent the designer to define specific roles that have to be connectible to allow ports to be connectible.

4 DDS ports and data managementAs mentioned in the XML description, a DDS ports can need some transversal processing that we have classified as data management aspects. They are actions that neither participate to the port role functionalities nor disturb it. They are related to some quality of service aspects that acts on the port data for optimization, reshaping, filtering, ...etc.A set of data management aspects were identified. They are:

1. Filtering2. Joining3. Conversion4. Caching5. Observation

Additional information about these will be added in the next version of this document.

5 Language Mapping and Code GenerationIn order to simplify the development of components using this DDS/CCM integration, it is necessary to also define how the descriptions indicated in IDL and XML translate into code. This translation must take into account several goals:

provide enough abstraction so that trivial use of a role corresponds to a minimal developer effort

allow DCPS or DLRL to be used if meaningful give the possibility to the container to add any additional setting and to control the data flow keep the possibility to access underlying DDS entities to ease the use of direct call on the DDS

API thus allowing even the most complex usage of the role.

5.1 ddsport mappingGiven a DDS port declared as depicted in the left side of the following picture:


Illustration 1: ddsport language mapping

ddsport dds_AlarmActivator {publishes ActivationTopic at ;consumes ClearingTopic ct;

};

dds_AlarmActivatorcreate_topic_instance_at (key);create_topic_instance_ct (key);remove_topic_instance_at(key);remove_topic_instance_ct (key);...

the resulting language mapping is a class having the same ddsport name that is dds_AlarmActivator. This class serves as a factory for the different topics instances exchanged via the port. It provides creation and removal operations for the topics instances involved in the ddsport and only these topics. They are specific operations whose names results from the concatenation of “create_topic” word and the declared topic identifier.

5.2 port mappingThe following schema shows the resulting classes from IDL port declaration and the XML description of the port.The IDL and XML description are used to generate port-specific classes for the different DDS entities, namely Publishers, Subscribers, Datareaders and Datawriters.

For each port topic, the XML description describes one or many associated datawriters (<datawriter> element) or datareaders (<datawriter> element) with their names. The port name, the topic name and the datawriter/datareader name are concatenated to form the datawriter/datareader class name. The same rational is used to generate publishers and subscribers classes.

For each DDS port a facade class is generated, this is the activatorPort class. Its name is formed by the port identifier (activator) and the “Port” word. It is a facade class that provides convenient methods for data writing and reading. This class hides the generated DDS entities and uses them as DDS applications commonly does it. write_at operation allows to write a topic at instance of type ActivationTopic without caring about the involved DDS entities. This does not prevent the usage of the generated DDS entities classes. In fact, the facade class provides also getter operations that provides access to the different DDS entities.

A callback interface is generated for each DDS port; named <port-identifier>Listener (activatorListeners in the above schema). This interface must be implemented by the component and acts as a listener to be notified of data availability. ct_data_available operation notifies the component of the availability of a new information held by the topic instance ct (of type ClearingTopic). This operation provides effectively the data to the component via one of its arguments. It means that the component does not have to invoke the read operation to get the data. Instead, the container reads or takes the data, depending on the pattern behaviour, and provide it to the component. The container can use either a listener or a wait-set pattern to read the data from DDS. This is implementation-dependant. The component can also use directly DDS entities and provide its own datareader or subscriber listeners to read data.


6 Component Programming ModelThe component programming model involves mainly the generated classes previously presented.

6.1 Publication model(1) the component code requests the facade class activatorPort to have the reference of the

dds_AlarmActivator class that gives access to topics creation.(2) The component requests to create a topic of type ActivationTopic by giving the data structure as

an argument. Note that the creation operation is specific to the topic to create.(3) The component writes the topic into the shared data space using a topic-specific writing

operation.

6.2 Subscription modelThe schema below depicts listener-based subscription model.(1) the container provides the read data, when it is updated, to the component.


7 Additional Comments

This chapter contains comments from the DOC group on the previously described approach.

7.1 Relationship of DDS Roles and Components

If a role must be completely implemented by one component, this ignores assembly, which is an important concept in the CCM world, i.e., that several components may collaborate to realize a given IDL interface of a component.

7.2 Redundancy in the XML Schema

The DDSrole and DDSport XML entities in Section 2.4 seem partly redundant. To restructure this in order to have orthogonal descriptions might be beneficial.

7.3 Data Managment Description

It is not clear what the different data management capabilities described in Section 4 do and how they use existing DDS features to do it. These capabilities should be described in more detail.

7.4 IDL and C++ Mapping

The mapping described in Section 5 is very rough and does not provide much abstraction. The graphics explaining it are also hard to read and incomplete. This part should be improved.


schmidt/DDS/DDS-CCM_Integration.doc · Web viewProductivity Tools & Middleware PRISMTECH FRANCE...

Documents

Transcript of schmidt/DDS/DDS-CCM_Integration.doc · Web viewProductivity Tools & Middleware PRISMTECH FRANCE...