Steps to Integrate DDS Into CCM

Statement of Work for Integrating DDS and CCM

Distributed Object Computing Group, Vanderbilt University

The integration of DDS transport capabilities into the CORBA Component Model (CCM) container will take advantage of the existing publisher/subscriber event ports already present in the CCM specification [1]. The advantage of this approach is that it requires no changes to existing IDL tools to support new constructs. Moreover, this approach will require minimal, if any, changes to existing CCM code generation infrastructure, like the IDL and XSLT CodeGen engine. Our proposed plan will integrate OpenSplice DDS into the CARDAMOM CCM implementation provided by Prism Technologies in two phases:

·  An initial prototyping phase that will implement only the essential functionality necessary to connect extant event ports to DDS topics.

·  A more detailed implementation phase that will address dynamic and advanced DDS functionality and behavior, including quality of service (QoS) alterations to deployed systems, multi topic and filtered topic subscriptions, and listener- and condition-based monitoring of communication status changes.

The remainder of this document describes the activities the DOC group proposes to perform for each phase. The current funding from PrismTech will only cover Phase One, however.

Phase One

The first phase will create a prototype whose purpose is to act as a proof of concept and to expose the accidental and inherent complexities with DDS/CCM integration. As this phase is a prototype, it will be subject to the following intentionally chosen restrictions:

·  Utilization of CCM event port type. The existing CCM publisher/subscriber event ports will be used to define ports for DDS communication in IDL. This approach will minimize changes necessary to existing CCM code generation infrastructure and for the time being simplify our prototype.

·  Static use of DDS Quality of Service Properties. One of the most compelling features of DDS is its rich vocabulary for describing quality of service requirements. QoS can be attached to most of the DDS entities (such as Domain Participants, Publishers, Subscribers, Data Readers, and Data Writers), so graceful integration of these QoS configuration features is critical to our efforts. Many of these policies can be changed dynamically at run time, including USER_DATA, TOPIC_DATA, GROUP_DATA, DEADLINE, LATENCY_BUDGET, TRANSPORT_PRIORITY, LIFESPAN, and TIME_BASED_FILTER. Other policies, however, only apply when the entities mentioned above are created, including PRESENTATION, DURABILITY, OWNERSHIP, LIVELINESS, RELIABILITY, DESTINATION_ORDER, HISTORY, and RESOURCE_LIMITS.

Because the policies enumerated in the latter set are configured at deployment time, they can be represented in XML meta-data. Our prototype implementation will only support this static type of QoS policy. As a result, no new APIs for dynamic QoS configuration need be integrated into the CCM container during phase one (though this may be necessary in phase two). Appendix A contains a detailed listing of all DDS entity creation parameters (including applicable QoS policies).

With these two restrictions in mind, it is possible to define a manageable mapping of DDS entities to CCM elements, which is shown in Figure 1 and described below.

Figure 1 shows the planned relationship between DDS and CCM entities during our first integration efforts of the prototype phase. All DDS entities are integrated into the component container. While every DDS related component port has its own data reader or writer, every component container instantiates only one domain participant, one subscriber and one publisher. As discussed in depth later, one port is always associated with exactly one topic in the DDS data space. The numbered arrows show the interactions between the different DDS and CCM entities when executor code initiates delivery of DDS data.

We have made the following design choices to reconcile the flexibility of DDS with the descriptive power of CCM.

Mapping DDS Topics onto CCM Event Types

Context. DDS topics must be mapped into CCM event types so that they can be used by CCM applications.

Problem. DDS Topics and CCM events use different models, e.g., DDS topics are information-oriented, whereas CCM event ports are connection-oriented.

Solution. One CCM event port consumes/publishes data whose type will correspond to the data type for one topic. This approach makes it possible to infer the data consumed by a component from its event port declaration. DDS topics, which are typed using IDL, will be mapped to a simple event type containing a single public member representing the topic type. For example, assuming we have a topic with the type stock_quote:

struct stock_quote {

string name;

double value;

};

the corresponding event will be:

eventtype stock_quote_event {

stock_quote stock_quote_topic;

};

And the corresponding declaration of a DDS port in a component:

component StockDistributor {

publishes stock_quote quote_out;

};

component StockBroker {

consumes stock_quote quote_in;

};

This approach will minimize changes necessary to the CCM code generation infrastructure and place most of the implementation burden on the container. A prototype can therefore be developed quickly to inform design decisions for the second phase of CCM/DDS integration.

Assocating DDS Readers/Writers with CCM Event Sources/Sinks

Context. The event ports must be enabled to send DDS data.

Problem. The right granularity for messages that can be sent and received through a port must be found. Data readers and writers must be associated with CCM ports.

Solution. Exactly one DDS data reader/writer is associated with exactly one event source/sink port. Several data writers/readers per port is not necessary and shared writers/readers between ports would violate the one-to-one relationship between topics and ports.

Incorporating DDS Publishers/Subscribers into the CCM Infrastructure

Context.The DDS subscriber and publisher entities must be incorporated into the CCM infrastructure.

Problem. DDS publishers and subscribers allow the grouping of writers and the setting of QoS policies for such groups. These entities must be mapped to the CCM infrastructure in a way that makes these QoS policies accessible to component developers.

Solution. All event source ports of one component share one DDS publisher instance and all event sinks share one DDS subscriber instance. This design implies that the DDS data readers and data writers corresponding to these ports are all created by one publisher or subscriber, respectively. Only one publisher and one subscriber will exist per CCM component container. In this way, all QoS policies of the publisher or subscriber will map to all ports and thus provide a natural grouping for QoS that should be applied to all ports of a component.

Further steps and Project work packages

Based on the prototype implementation described above, the following deliverables have been defined for the phase one:

1.  Language definition for static configuration aspects

All QoS policies that are configurable at the startup of a DDS application and static in their nature will be configured through metadata. A format for expressing these properties in well-formed deployment metadata will be defined.

2.  DDS support in CARDAMOM CCM Container

CCM container code necessary for configuring DDS entities and enforcing the configuration directives captured in XML metadata from the previous deliverable will be developed.

3.  Implementation of a sample application

To ensure that the prototype is working, a concrete scenario will be implemented to give a proof of concept of the design choices described above. This example application will be a modification of the prototypical stock quoter example shown in Figure 2, with several producers and consumers with differing QoS requirements.

Figure 2 illustrates one possible example application that addresses several aspects of a CCM application which makes use of the DDS infrastructure:

·  Several Quoters contribute information to the same STOCK information space.

·  Several Components make use of this information for different purposes (Shareholder, Analyst, Investmentfund Quoter).

·  Another entity called FUNDS aggregates information of different stocks and can be seen as a collection of stocks, which is created by a Investmentfund quoter and observed by Analyst and Investmentbanker.

·  In addition to DDS communication, synchronous calls are used by the different components to act as a response to the stock information received: A Shareholder may buy or sell stocks, an Analyst sells sophisticated information distilled from the stock market, and an Investmentfund quoter buys stocks into the fund and allows his customers to buy shares of the fund at the same time.

This application therefore reflects the needs of a CCM application utilizing DDS data dissemination in real world applications. It is complex enough to include many critical use cases, but simple enough to be comprehensible and illustrative.

Phase Two

Phase two of this integration effort will focus on supporting dynamic configuration of DDS entities at run time, either through interaction with the deployment runtime or through directives issued by component business logic. Lessons learned from phase one, particularly the inherent and accidental complexities encountered, will drive the needed changes to IDL, container API, or the CIF. In particular, we propose to address the following items:

1.  Definition of enhanced container API for dynamic configuration aspects

All configuration and communication aspects that can not be captured through XML metadata will result in enhancements to the CCM container API to enable component developers to configure DDS entities dynamically. This will be necessary, for example, to enable QoS changes to DDS entities at runtime, to support multi topic subscription, and to facilitate automatic detailed monitoring of communication status changes.

2.  Evaluation of a separate port type

After static and dynamic aspects are addressed, it will be possible to determine if it is necessary and appropriate to introduce a new type of component port, as described in the nascent DDS for CCM specification [2]. If so, it will also be determined what characteristics are needed.

3.  Refactoring of the system prototype

The existing prototype implementation will then be generalized to create a complete implementation of DDS/CCM integration. This generalization is likely to involve modifications to both static and generated code associated with the CCM container implementation, the XSLT CodeGen engine, and the CCM deployment tools. The Container implementation, for example, is responsible for initializing DDS entities, like the subscriber and data readers. The deployment tools on the other hand have to be able to read in configuration metadata and use some extended interfaces in the component container to pass the metadata, which will contain QoS policies and other data relevant for DDS initialization.

References

[1]  Object Management Group, “CORBA Component Model”, OMG Available Specification formal/06-04-01 edition, April 2006

[2]  OMG “DDS for Lightweight CCM” submission, http://www.omg.org/docs/mars/06-06-13.pdf.

Appendix A – Settings for DDS Entities including Applicable QoS Policies

DDS entity / Parameters / QoS Policies / Dynamic?
DDS::DomainParticipant / DomainId,
DomainParticipantQos / USER_DATA / yes
ENTITY_FACTORY / yes
DDS::Publisher / PublisherQos / PRESENTATION / no
GOUP_DATA / yes
PARTITION / yes
ENTITY_FACTORY / yes
DDS::Subscriber / SubscriberQos / PRESENTATION / no
GOUP_DATA / yes
PARTITION / yes
ENTITY_FACTORY / yes
DDS:Topic / Topic Name,
Type Name,
TopicQos / DURABILITY / no
DURABILITY_SERVICE / no
OWNERSHIP / no
LIVELINESS / no
RELIABILITY / no
DESTINATION_ORDER / no
HISTORY / no
RESOURCE_LIMITS / no
USER_DATA / yes
TOPIC_DATA / yes
DEADLINE / yes
LATENCY_BUDGET / yes
TRANSPORT_PRIORITY / yes
LIFESPAN / yes
DDS::DataWriter / DDS::Topic,
DataWriterQos / DURABILITY / no
DURABILITY_SERVICE / no
OWNERSHIP / no
LIVELINESS / no
RELIABILITY / no
DESTINATION_ORDER / no
HISTORY / no
RESOURCE_LIMITS / no
USER_DATA / yes
DEADLINE / yes
LATENCY_BUDGET / yes
OWNERSHIP_STRENGTH / yes
TRANSPORT_PRIORITY / yes
LIFESPAN / yes
WRITER_DATA_LIFECYCLE / yes
DDS::DataReader / DDS::Topic,
DataReaderQos,
DDS::DataReaderListener / DURABILITY / no
OWNERSHIP / no
LIVELINESS / no
RELIABILITY / no
DESTINATION_ORDER / no
HISTORY / no
RESOURCE_LIMITS / no
USER_DATA / yes
DEADLINE / yes
LATENCY_BUDGET / yes
TIME_BASED_FILTER / yes
READER_DATA_LIFECYCLE / yes
DDS::DataReaderListenerImpl / callback functions:
on_requested_deadline_missed
on_requested_incompatible_qos
on_sample_rejected
on_liveliness_changed on_data_available
on_subscription_match
on_sample_lost / --