Feb 5, 2009

Choosing OpenSplice DDS

Yesterday I gave a webcast, now available here, which first goes through the strategic, technical, and financial reasons for moving to OpenSplice DDS, and then shows some migration use cases as well as migration tactics.
Strategic vs Tactical Perspective
One of the key point I made in the first part of the webcast was trying to ensure that people look at Open Source in from a strategic as opposed to tactical perspective. In essence, now that OpenSplice DDS is Open Source many people will just see it as a cost effective manner of procuring the best DDS implementation available on the market. This perspective, although correct, is tactical and misses the strategic implication of Open Source, which if properly exploited are those that will bring the highest benefits.

An example, Open Source is a key element in enabling and catalyzing lead-user innovation; some visionary companies in domains characterized by lead-users innovations, such as Aerospace and Defense, have already realized and mastered the strategic relevance of Open Source. Other company are starting to understand its potential and are quickly embracing the new way.

Embracing OpenSplice DDS

The second part of the webcast, focused on showing some use cases motivating a move to OpenSplice DDS. For instance, I showed how OpenSplice DDS can be used to scale-out a data tier by either completely replacing a DBMS, or by offloading or fully federating the DBMS. I also showed how OpenSplice DDS can be used to replace another DDS implementation of yet another pub/sub technology.

From DDS-XYZ to OpenSplice DDS
Finally, one of the topic covered on the webcast was how to actually port applications developed on a DDS-XYZ to OpenSplice DDS. As explained in the webcast this is typically just an exercise of finding and removing calls to proprietary API that might be required by DDS-XYZ. Indeed, as shown by the example below, OpenSplice DDS does not require the use of any custom API for configuring transport or anything else. Configuration completely taken care by external tools. Below is an example that shows the code necessary to write a publisher for a TempSensor Topic.

// -- IDL --
module demo {
module tc {

struct TempSensor {
long tID;
float temp;
float humidity;
#pragma keylist TempSensor tID

// -- Publisher Implementation --

package demo.tc;

import DDS.*;

public class TempSensorApp {

static final String PARTITION = "SensorData";

public static void main(String[] args) {

if (args.length <> ");

int tid = Integer.parseInt(args[0]);
int samples = Integer.parseInt(args[1]);

DomainParticipantFactory dpf =

* Create Domain Participant
DomainParticipant part =

* Regiter Type Support for TempSensor
TempSensorTypeSupport tempSensorTS = new TempSensorTypeSupport();
String tempSensorTN = tempSensorTS.get_type_name();
tempSensorTS.register_type(part, tempSensorTN);

* Create the TempSensor Topic
TopicQosHolder topicQoS = new TopicQosHolder();
Topic tempSensorTopic = part.create_topic("Demo_TempSensor",

* Create a Publisher
PublisherQosHolder pubQoS = new PublisherQosHolder();
pubQoS.value.partition.name = new String[1];
pubQoS.value.partition.name[0] = PARTITION;

Publisher pub =
part.create_publisher(pubQoS.value, null, ANY_STATUS.value);

* Create a Writer
DataWriter writer =

TempSensorDataWriter tempWriter =

* Register Instance
TempSensor temp = new TempSensor();
temp.tID = tid;

long handle = tempWriter.register_instance(temp);

* Write Sample
temp.temp = 12.1F;
temp.humidity = 0.45F;

for (int i = 0; i <> Temperature = " + temp.temp
+ " - Humidity = " + temp.humidity);

try {
catch (InterruptedException e) { }
temp.temp += 0.1;
temp.humidity += 0.01;

* Cleanup
tempWriter.dispose(temp, handle);
tempWriter.unregister_instance(temp, handle);




No comments: