With what shall we replace the DCOM communication with?

Question

We currently have a number of C++/MFC applications that communicate with each other via DCOM. Now we will update the applications and also want to replace DCOM with something more modern, something that is easier to work with. But we do not know what. What do you think

Edit

The data exchanged is not something that may be of interest to others. It is only status information between the different parts of the program running on different computers.

Do you still want them to be in C++ or do you plan to rewrite them? — sharptooth, Aug 19 '11 at 12:49
Is this "Swedish nuclear power plants" code you're working on?! I'm suddenly getting rather scared. — MSalters, Aug 19 '11 at 13:07
@MSalters - why, do you think it'd be better re-written in, say, Java? — gbjbaanb, Aug 19 '11 at 13:13
@gbjbaanb: MFC only works on Operating Systems whose EULA _explicitly_ forbids their use in nuclear plants. — MSalters, Aug 19 '11 at 13:16
@ MSalters - Now I'm also a little worried. Where can I read more about it? — magol, Aug 19 '11 at 13:19
@MSalters - so does Java's, and generally most other general purpose systems. I don't think DCOM was around in the 70/80s so I don't think this question is regarding those nuclear systems mentioned in his profile. — gbjbaanb, Aug 19 '11 at 13:28
@Magol: the part in the EULA refers specifically to the java components (as Java EULA refuses licence to create critical infrastructure apps). There's also a clause saying you're not allowed to export to anyone who you know might use it for such activities too (including mass destruction weaponry etc). Search 'nuclear' in the Windows 2000 EULA http://technet.microsoft.com/en-us/library/cc976720.aspx — gbjbaanb, Aug 19 '11 at 13:31
Ow, wait. It's actually in the Windows versions that shipped with Java, because Sun specifically forbids that. @gbjbaanb: As it turns out, Java is the worse choice - all versions are incompatible with atoms (guess that's why it runs on virtual machines ;) ) ;) — MSalters, Aug 19 '11 at 13:34
No, we do not use DCOM in the data collection and presentation system that we work with (http://en.wikipedia.org/wiki/MODCOMP), but on a help system that extends the functionality of the data collecting system. But now we at least established that we should not use Java, nice that it does not affect us. — magol, Aug 19 '11 at 17:46

gbjbaanb · Accepted Answer · 2011-08-19T13:31:39.793

3

there are many C++ messaging libraries, from the old ACE to new ones like Google's Protocol Buffers or Facebook's (now Apache's) Thrift or Cisco's Etch.

Currently I'm hearing good things about ZeroMq which might give you more than you are used to.

edited Aug 19 '11 at 13:31

answered Aug 19 '11 at 13:20

gbjbaanb

51,617
12
104
148

1

Note that Protocol Buffers isn't a messaging library, but a serialisation mechanism. You still need a messaging library to send serialised protobuf messages. I'm sending messages transcoded using protobuf, via Zero MQ. I'd recommend both. – RobH Aug 19 '11 at 15:17

score 2 · Answer 2 · answered Aug 19 '11 at 12:56

2

DCOM is nothing more than sugar-coating over a messenging system.

Any proper messenging system would do, and would allow you to actually spot where messages are exchanged (which may be important to localize point of failures/performance bottlenecks in waiting).

There are two typical ways to do so, nowadays:

A pure messenging system, for example using Google Protocol Buffers as the exchange format
A webservice (either full webservice in JSON or a REST API)

answered Aug 19 '11 at 12:56

Matthieu M.

287,565
48
449
722

@magol, if it is for nuclear power plants, I **urge** you to look at DDS (Data Distribution Services), it's the kind of stuff that's used in submarines, warships etc. PrismTech provide a commercial implementation, get in touch with them. NOTE: I don't work for them... – Nim Aug 19 '11 at 13:49

score 1 · Answer 3 · edited May 23 '17 at 10:34

I've been doing lots of apps in both C++ and Java using REST and I'm pretty satisfied. Far from the complexity of CORBA and SOAP, REST is easy to implement and flexible. I had a bit of a learning curve to ged used to model things as CRUD, but now it seems even more intuitive that way.

Now, for the C++ side I don't use a specific REST library, just cURL and a XML parser (in my case, CPPDOM) because the C++ apps are only clients, and the servers are Java (using the Restlet framework). If you need one, there's another question here at SO that recommends:

Can anyone recommend a good C/C++ RESTful framework

I'd also mention my decision to use XML was arbitrary and I'm seriously considering to replace it with JSON. Unless you have a specific need for XML, JSON is simpler and lightweight. And the beauty of REST is that you could even support both, along with other representations, if you want to.

With what shall we replace the DCOM communication with?

3 Answers3