4

I've always been a big fan of asynchronous messaging and pub/sub implementations, but coming from a Java background, I'm most familiar with using JMS based messaging systems, such as JBoss MQ, HornetQ, ActiveMQ, OpenMQ, etc. I've also loosely followed the discussion of AMQP. But I recently became aware of the Data Distribution Service Specification from the Object Management Group, and found there are a couple of open-source implementations:

OpenSplice

OpenDDS

It sounds like this stuff is focused on the kind of high-volume scenarios one tends to associate with financial trading exchanges and what-not. My current interest is more along the lines of notifications related to activity stream processing (think Twitter / Facebook) and am wondering if the DDS servers are worth looking into further.

Could anyone who has practical experience with this technology, and/or a deep understanding of it, comment on how useful it is, and what scenarios it is best suited for? How does it stack up against more "traditional" JMS servers, and/or AMQP (or even STOMP or OpenWire, etc?)

Edit: FWIW, I found some information at this StackOverflow thread. Not a complete answer, but anybody else finding this question might also find that thread useful, hence the added link.

Community
  • 1
mindcrime
  • 520
  • 4
  • 6

3 Answers3

2

I have used DDS quite a lot, specifically the RTI implementation of DDS. I have spent a lot of effort and time in making the RTI library usable to ordinary devs who just want to produce and comsume the data without worrying about the Quality of Service issues or how their data gets to its destination. This involves wrapping the RTI implementation up into a library that provides a call back interface for subscribers and a thread safe way of publishing data, all in a platform indepentent way. And all this is created using automated code generation tools supporting Windows 32/64 bit, Linux 64 bit and Java.

Trying to use the raw DDS classes is just asking for trouble IMHO. The code to set everything up and maintain compatible QoS between publishers and subscribers is just not nice. And having a team of developers try use it directly will mean you'll have a full time job supporting them.

I honestly can't understand why they don't provide out of the box a wrapper solution similar to what I've created, because it's a lot easier to use. - Probably because they want to sell you a big fat support contract.

The biggest issue you'll have will be in tuning the QoS in a way that meets your needs. If you look at the published statistics on the RTI website they are all on very small messages, which may suit you. Our use case scenario scales from infreqent small messages to constant high rate high throughput messages in the order of 70MB/s. Tuning your QoS to meet this demand is difficult! You will almost certainly need support almost all the way until you have something that hangs together.

But on the positive side it does give you a platform independent way of transfering data and the discovery service is nice because it lets you move services between machines very easily with literally no configuration changes. Its ability to support multicast and shared memory means it can run efficiently when you have multiple subscribers to the same data, but you'll have to set your switches up correctly to achieve this. You also have the option of sending data in a reliable or unrelaible manner, depending on your requirements.

One downside that can hit you if you're using reliable communication is that if a subscriber has an issue and stops taking data off its queue it can have a knock on effect to ther subscribers running on other machines.

1

DDS, like JMS, is only an API specification.

What I think you need to compare are the specific implementations in terms of how well they suit your specific needs, which you didn't describe, except to say you want to do activity stream processing.

do you need point-to-point or pub/sub? transient or persistent endpoints? ephemeral, transactional, guaranteed, or exactly once delivery semantics?

here's a blog post I wrote that might help you out: http://blog.pasker.net/2008/06/16/you-might-need-messaging-if/

rbp
  • 156
  • 8
0

No experience with this ( and I would be surprised if anyone has!).

The de-facto enterprise messaging standard is IBM's MQSeries (or now hidden as Websphere something or other by IBMs marketing dorks).

It was first in the field, its available on nearly all platforms, its usable from most common languages and is reasonably priced. As well as its own API it supports AMQP and JMS.

The OMG spec is dead in the water.

James Anderson
  • 18,049
  • 1
  • 42
  • 72