Not Either, But Both?
I recently dug up an old DDS tutorial pitch by distributed system middleware expert extraordinaire, Doug Schmidt. The last slide in the pitch shows a side-by-side, high-level feature comparison of CORBA and DDS:
High performance middleware technologies like CORBA and DDS are big, necessarily complex beasts that have high learning curves. Thus, I’m not so sure I agree with Doug’s assessment that complex software systems (like sensor-based command and control systems) need both. One can build a pub-sub mechanism on top of CORBA (using the notification, event, or messaging services) and one can build a client-server, request-response mechanism on top of DDS (using the TCP/IP-like “reliability” QoS). What do you think about the tradeoff? Fill the holes yourself with a tad of home-grown infrastructure code, or use both and create a two-headed, fire-breathing dragon?
Dr. Doug will defend his creation until he dies.
Corba is not situable for safety-critical systems. This middleware architecture is outdated, but the US market seems to need it. Why? In my oppinion, is because a lot of device/component systems rely on its translations mechanism, even degradating the response time. Use it or your business will collapse!
DDS came recently to slowly replace this dinosaur. Despite of having a corba plu-in just in case… its seems to be a better middleware architecture.
Lets the product be tested, then we can tell…
Doug’s a good guy. I’ve listened to several podcast interviews and technical webinars with him. He’s actually a paid consultant to one of the premier DDS vendors – PrismTech.
Like COBOL, CORBA has been around for a long time. There are lots of legacy CORBA-based systems out there and they’ll need maintenance for years to come. However, I don’t think many new projects are using CORBA, but as usual, I have no data to backup my claim.