Integration of DDS and Lightweight CCM



Integrating OMG DDS and Lightweight CCM

Douglas C. Schmidt

June 25th, 2007

1 Introduction

Component middleware are a popular way to structure applications in several domains, including distributed real-time and embedded (DRE) systems, such as naval combat systems [1][2]. This document describes techniques for integrating the Object Management Group (OMG)’s Lightweight CORBA Component Model (CCM) standard with the OMG’s Data Distribution Standard (DDS). After key elements in the Lightweight CCM and DDS standards are described briefly, this document presents several techniques for integrating Lightweight CCM and DDS and evaluates the pros and cons of each technique.

1.1 Overview of Lightweight CCM

OMG Lightweight CORBA Component Model (CCM) is standard component middleware that provides a subset of features of normal CCM standard. By standardizing only a subset of features, Lightweight CCM is intended to be used for DRE systems with more stringent QoS requirements. Lightweight CCM standardizes the development, packaging, configuration, and deployment of component-based DRE systems.

[pic]

Figure 1. Key Elements in the Lightweight CCM Architecture

Figure 1 shows the following key elements in the architecture of Lightweight CCM:

Components. Components in Lightweight CCM are the implementation entities that export a set of interfaces usable by conventional CORBA clients as well as other components. Components can also express their intent to collaborate with other components by defining ports that support various types of communication patterns, including:

• Point-to-point method calls between facets and receptacles. Facets define an interface that accepts point-to-point method invocations from other components, whereas receptacles indicate a dependency on point-to-point method interface provided by another component. Point-to-point method calls are designed to support a command-driven form of synchronous communication between CCM components.

• Publish/subscribe (pub/sub) message passing between event sources and sinks. Event sources and sinks indicate a willingness to exchange typed events with one or more components. Pub/sub message passing is designed to support data-driven form of asynchronous communication between components.

Each communication pattern is applicable to different types of DRE systems in different domains. For example, pub/sub messaging is useful for disseminating data from sensors to multiple users who are interested in the sensor data. Likewise, point-to-point method calls are useful for directing a specific action be performed by a particular user. Moreover, certain DRE systems can benefit from both communication patterns within the same application. For example, a naval combat system that maintains a common operating picture between multiple sensors and operators may use pub/sub message passing to disseminate sensor data to operators, some of whom may then use point-to-point method calls to direct specific human or computing resources to react to the sensor data.

Container. A container in Lightweight CCM provides a runtime environment for one or more components, and manages various pre-defined hooks and strategies, such as persistence, notification, transaction, and security that are used by the components. Each container is responsible for (1) initializing instances of the component types it manages, (2) providing a runtime execution environment called context to the components, and (3) managing the policies and lifecycle of the components. Configuration expressed as XML descriptors can be used by component deployment mechanisms to control the lifetime of these containers and the components they manage.

Component assembly. Assemblies of components in Lightweight CCM are deployed and configured via the OMG Deployment and Configuration (D&C) specification, which manages the deployment of Lightweight CCM applications onto different nodes in a target environment. A standards-based deployment framework parses the deployment metadata expressed as XML descriptors, extracts information on the binding of components to target nodes, and deploys the system by instantiating component servers, installing containers and components, and setting up the object-level connections.

Component implementation and packaging. In addition to the runtime building blocks mentioned above, Lightweight CCM also standardizes component implementation and packaging. The Component Implementation Framework (CIF) helps generate the component implementation skeletons automatically using the Component Implementation Definition Language (CIDL) compiler. The CIF consists of patterns, languages and tools that simplify and automate the development of component implementations which are called executors. Packaging involves grouping the implementation of component functionality – typically stored in a dynamic link library (DLL) – together with other metadata that describes properties of this particular implementation.

The elements in Figure 1 can be deployed and configured into one or more node applications that are responsible for aggregating physical entities (i.e., implementations of component instances) into logical entities (i.e., distributed application services and subsystems). A node application plays the role of a factory to create containers and standardizes the role of a server process in the CORBA object model. Figure 2 shows the process by which node applications are deployed and configured in Lightweight CCM.

[pic]

Figure 2. Node Application Deployment and Configuration Process

1.2 Overview of DDS

The OMG Data Distribution Service (DDS) specification provides a data-centric communication standard for a range of DRE computing environments, from small networked embedded systems to large-scale information backbones. At the core of DDS is the Data-Centric Publish-Subscribe (DCPS) model, whose specification defines standard interfaces that enable applications running on heterogeneous platforms to write/read data to/from a virtual global data space in a DRE system. Applications willing to share information can use this data space to declare their intent to publish data that is categorized into one or more topics of interest to others. Similarly, applications that are interested in certain topics can use the data space to declare their intent to become subscribers and access the data.

[pic]

Figure 3. Architecture of DDS

The underlying DCPS middleware propagates data samples written by publishing applications into the global data space, where they are disseminated to subscribing applications. The DCPS model decouples the declaration of information access intent from the information access itself, thereby enabling the DDS middleware to support and optimize QoS-enabled communication. As shown in Figure 3, a canonical DCPS model is comprised of the following elements that provide functionalities for a DDS application to publish/subscribe to data samples of interest.

Domain. DDS applications send and receive data within a Domain. A Domain is a virtual space that connects certain publishing and subscribing applications. Only applications within the same domain can communicate, and this restriction helps isolate and optimize communication within a community that shares common interests. Note that although only one domain is shown in Figure 3, a system can be divided into as many domains as needed to meet system requirements.

Entity. Within a domain, DDS defines an abstract element called Entity, which contains a few generic operations that it passes to the elements listed below that specialize it. All entities have associated QoS policies, initialized to default values unless explicitly modified.

DomainParticipant. Created by a singleton factory, a DomainParticipant is the application’s access point to a Domain. Application use DomainParticipants to create Topics, Publishers, and Subscribers, which are described next.

• Publisher. A Publisher creates and manages one or more DataWriter entities

• Subscriber. A Subscriber creates and manages one or more DataReader entities..

• DataWriter. A DataWriter is the actual object used to send data samples, and is always associated with a particular Topic.

• DataReader. A DataReader is the actual object used to receive data samples, and is always associated with a particular Topic.

• Topic. A Topic consists of a data type and a name, and it connects a DataWriter with a DataReader. Data samples start flowing only when the Topic associated with a DataWriter matches the Topic associated with a DataReader.

The DCPS middleware layer is responsible for marshaling/de-marshaling and sending/receiving the data to/from the virtual global data space using standard DDS transports, such as UDP or other protocols like shared memory. Applications simply use the DDS entities outlined above to read/write data from/to the global data space without having to wrestle with low-level implementation details, and without having to know which, or how many, entities are at the other end of the data transfer.

1.3 Addressing Limitations with Lightweight CCM

Although the Lightweight CCM specification supports the multiplicity of component communication patterns described in Section 1.1, it has certain limitations that make it sub-optimal for use in a broad range of DRE systems. In particular, Lightweight CCM’s standard pub/sub capabilities simply define interfaces that publishers and subscribers can use to exchange event types. It does not, however, define standard mechanisms for adjusting the behavior and QoS of the messages passed between event sources and sinks. As a result, it is not yet possible to integrate Lightweight CCM effectively and seamlessly with standard data-driven pub/sub technologies, such as the OMG Data Distribution Service (DDS).

To address these limitations, PrismTechnologies—in conjunction with other OMG members, such as Thales, SELEX, RTI, and Vanderbilt—are working on defining and standardizing extensions to Lightweight CCM that will enable it to work seamlessly with DDS. At the heart of the PrismTech and Vanderbilt approach is a model-driven engineering (MDE) toolsuite that will generate “glue code” to integrate CCM components with DDS data readers and data writers. This approach is designed to shield application developers from the tedious and error-prone details of programming DDS QoS policies and low-level APIs, while also exposing some or all of the features of DDS to CCM application developers. The remainder of this paper describes several techniques for integrating Lightweight CCM with DDM and evaluates the pros and cons of each technique.

2 Techniques for Integrating Lightweight CCM and DDS

There are several approaches for integrating Lightweight CCM and DDS. This section describes and evaluates these approaches from the perspective of a Lightweight CCM application developer.

2.1 Direct Integration of DDS into Lightweight CCM Application Components

One approach to integrating DDS with Lightweight CCM is simply to access DDS domain participants, such as data readers and data writers, directly from the Lightweight CCM application components themselves. This approach is shown in Figure 4.

[pic]

Figure 4. Direct Integration of DDS into

Lightweight CCM Application Components

The benefits of directly integrating DDS into Lightweight CCM application components include:

• No changes required to the DDS or Lightweight CCM specification.

• Lightweight CCM application developers can leverage all features of DDS. In particular, this approach respects the connectionless nature of DDS.

The drawbacks of this approach, however, include:

• It does not leverage the capabilities defined by the standard Lightweight CCM Deployment and Configuration (D&C) specification. In particular, DDS domain participants (e.g., data readers and data writers) cannot be transparently integrated into CCM assemblies and deployment plans.

• Lightweight CCM application developers are exposed to more of the complexity of DDS.

The latter drawback can be alleviated to some extent via the use of MDE tools for DDS, such as the OpenSplice PowerTools. Figure 5 shows a screenshot of this MDE tool, which shows how DDS application developers (whether writing native DDS applications or calling methods on DDS data readers and/or data writers from within Lightweight CCM applications) are shielded from the bulk of the complexity of the low-level DDS APIs.

[pic]

Figure 5. Screenshot of the OpenSplice PowerTools MDE Tool

2.2 Indirect Integration of DDS via Lightweight CCM Containers

An alternative approach for integrating DDS with Lightweight CCM focuses on leveraging the advanced separation-of-concern features of Lightweight CCM, particularly with respect to its support for containers and automated deployment and configuration. This approach extends Lightweight CCM containers so they are the unit of integration that enable seamless connectivity of and communication between Lightweight CCM components and DDS data readers and data writers. This approach is currently documented via a proposed Lightweight CCM container extension called DDS ports [3]. Figure 6 shows the indirect integration of Lightweight CCM and DDS via DDS ports.

[pic]

Figure 6. Indirect Integration of DDS va Lightweight CCM Containers

By focusing on containers as the unit of integration between Lightweight CCM and DDS, the DDS ports approach enables the assembly and deployment of DDS domain participants (e.g., data readers and data writers) with Lightweight CCM component(s) using the OMG Deployment and Configuration (D&C) specification. The MDE tools will generate the glue code needed to allow components to interact with DDS data readers/writers via the extended contains, thereby allowing CCM applications to concentrate their business logic, rather than wrestling with myriad DDS QoS policies and low-level APIs.

The benefits of indirectly integrating DDS into Lightweight CCM via extension to containers include:

• It leverages the capabilities defined by the standard Lightweight CCM Deployment and Configuration (D&C) specification. In particular, DDS domain participants (e.g., data readers and data writers) can be transparently integrated into CCM assemblies and deployment plans.

• Lightweight CCM application developers are shielded from most of the complexity of DDS.

• It is consistent with the direction of the current response to the OMG’s “DDS for Lightweight CCM” RFP, which has been jointly authored by Thales, SELEX, RTI, and PrismTechnologies.

The drawbacks of this approach, however, include:

• Changes required to the DDS or Lightweight CCM specification.

• Lightweight CCM application developers may not be able to leverage all features of DDS. In particular, using DDS ports implicitly embodies a “connection-oriented” perspective of linking CCM ports with DDS ports, which may be at odds with the inherently connectionless nature of DDS.

3 Proposed Technical Approach

Section 2 described two different approaches to integrating Lightweight CCM with DDS. As part of the sponsored effort, prototypes of both approaches will be developed and evaluated. Common to each approach is the use of MDE tools, such as those developed in earlier activities by Vanderbilt University [4] and PrismTechnologies [5]. For example, there is a natural fit between modeling views for the Lightweight CCM environment and the DDS, For example, the IDL standard is shared for modeling data types that Lightweight CCM components can use to communicate with the DDS Data-Centric Publish/Subscribe (DCPS) and Data Local Reconstruction Layer (DLRL). The use of shared IDL makes cohabitation of DDS and Lightweight CCM seamless within applications.

The prototypes of each approach described above are being developed by PrismTech and Vanderbilt using OpenSplice and OpenFusion CCM (which combines the D&C engine of Vanderbilt’s CIAO with the Java/C++ containers provided in Thales CARDAMOM). The MDE toolsuite will be developed in Eclipse, e.g., the Graphical Modeling Framework (GMF), and will support automatic generation of DDS-interaction code by information-, application-, deployment modeling. This approach will enable the model-level integration of CCM and DDS, which is our means of combining both technologies. We are also working with the “DDS for Lightweight CCM” initiative at the OMG to standardize the middleware-level integration of our MDE-based approach.

References

1. Jacek Skowronek and Han van 't Hag, “Principles of Future Architecture for Naval Combat Management Systems,” RTO IST Symposium on “Technology for Evolutionary Software Development,” Bonn, Germany, September 23-24, 2002.

2. Douglas C. Schmidt, Rick Schantz, Mike Masters, Joseph Cross, David Sharp, and Lou DiPalma, Towards Adaptive and Reflective Middleware for Network-Centric Combat Systems, CrossTalk, November, 2001.

3. OMG “DDS for Lightweight CCM” submission, .

4. George Edwards, Gan Deng, Douglas C. Schmidt, Anirudda Gokhale, and Balachandran Natarajan, Model-driven Configuration and Deployment of Component Middleware Publisher/Subscriber Services, Proceedings of the 3rd ACM International Conference on Generative Programming and Component Engineering, Vancouver, CA, October 2004.

5. PrismTech Announces Next Generation OpenSplice Data Distribution Service (DDS),

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download