Why you should care about IDL to C++11
On ORBzone we have an active discussion about the IDL to C++11 mapping at a technical level. But why should you care about this effort as a user? Using this article we would like to take a step back and explain why this effort is important and how it relates to some other activities at the OMG.
Everyone agrees that the current IDL to C++ language mapping is hard to use in some areas. Especially the memory management rules for the various types are not very intuitive. These rules take time to learn and it is easy to make errors initially. Therefor a lot of people rule that CCM, CORBA, and DDS are too complex for their projects, where it is really just the C++ language mapping that is hard to learn. However, people who have mastered its details have been able to successfully build complex distributed mission critical systems using CORBA, CCM and DDS (or combinations thereof).
It is undesirable (some might say impossible) to change the existing IDL to C++ language mapping due to the large investments made by vendors and users. There are a lot of products (ORB implementations and user applications) that are implemented using this mapping where it would be very uneconomical or outright impossible to upgrade to a significantly redesigned language mapping. It is clear up front that any major revision to the IDL to C++ standard will lead to a political nightmare at the OMG.
The C++ standards committee is already working for some time on a new revision of the C++ standard. This revision was called C++0x but has recently been renamed to C++11. This will be a major revision of the standard with several new language constructs added and a large number of improvements in the standard C++ library. The new features will make it much easier and safer to write applications in C++11. Some even state that these new features and enhancements make it C++11 “feel like a new language”.
The Request for Proposal (RFP) made by the OMG asks for a completely new mapping, leaving the existing IDL to C++ mapping untouched. With the features of the C++11 compilers it will be possible to make a mapping that is much more user friendly. It will be much less difficult to learn and it will be much harder to make errors. When this new mapping is in place it should be really straightforward to write applications in C++ that are using IDL to define their types and interfaces.
The DDS vendors are currently working on a new ISO/IEC C++ Platform Specific Model (PSM) for DDS. This starts from the DDS specification and directly targets C++ bypassing IDL completely. The big disadvantage is that it will be impossible to write portable code that works with different middleware solutions. If you are using for example DDS and CORBA in one application you have to learn two mappings, one for CORBA and one for DDS. Also IDL defined types aren't interchangeable anymore between, for example, DDS and CORBA. If you are only interested in DDS than this new DDS C++ PSM may be a step forward. If you want to be able to integrate DDS, CCM, CORBA or some other (future) technology that is using IDL than you really shouldn't use the new DDS C++ PSM.
At the moment we have a new IDL to C++11 language mapping it can be implemented by DDS, CORBA, CCM and other IDL based products. If you base your application code on the new language mapping the application code is easily portable between different middleware solutions. You can for example take an IDL defined type and pass it to any IDL defined API.
So the reason why you should care about a new IDL to C++11 mapping is that it will be safer, easier, faster, and cheaper to write your applications. It keeps the full Interoperable Open Architecture in place. Your applications are interoperable on the wire, but also application code can be reused between the various technologies that are using IDL.
At a technical level you can join this new effort by giving your comments on the IDL to C++11 forum at ORBzone. We are working on a draft initial submission so that you get an overview of the new language mapping. If you want to have a look at how the application code will look like, check our example section at our OSportal.
Remedy IT is working on a new CORBA product that implements this IDL to C++11 language mapping. It uses the existing TAO core and adds a new language binding to it. This binding is added in such a way that it is not another layer around TAO but replaces the existing C++ binding for TAO. We expect to have a beta version of this product available as commercial product soon. Contact us to see how this new language mapping can simplify your existing and future application code.
Comments
C++11 published
The C++11 specification has been published, see the ISO website
Presentation initial submission
Remedy IT will present their initial submission at the OMG September meeting, see here for more details about this event.
Importance of the new IDL to C++0x language mapping
Nice post. If I may, I'd like to add a few more points to further emphasize why I believe this new mapping, done correctly, is even more important and worthy of notice.
Besides the obvious advantages of a modern, more intuitive and less error-prone C++ API alternative, which Johnny has done a good job of describing, a new IDL language mapping that is independent of any specific middleware standard (i.e., CORBA 2) is the first and most important step forward in allowing the OMG CCM standard to further advance. Whether the CORBA Component Model (CCM) morphs into the Common Component Model (unlikely - not a popular name when Johnny initially presented this to the OMG in March), OCCAM, or something else, unless the language mappings first lose their dependency upon CORBA, this next step cannot be taken. This step is also consistent with other ongoing activities at the OMG, namely the extraction of the IDL related chapters/content from the CORBA specification in order to create a new standalone IDL spec that is independent of any particular middleware standard.
A real-time component framework such as a future middleware-independent CCM, enabled by new language mappings, opens up a whole new frontier. It offers the potential of more lightweight and smaller-footprint containers, which will necessarily be unencumbered by any specific middleware content. All middleware implementations would move to independent connector fragment components, following the design pattern already established by the new OMG DDS4CCM spec, and Remedy IT's submission for the OMG AMI4CCM RFP. Users would have the option to populate their components with extended ports utilizing CORBA, DDS, SOAP, JMS, or whatever, mixing and matching them as needed or desired, with consistent and workable APIs and data entity representations that could be easily shared between them.
Theoretically, CORBA pub-sub connectors utilizing the IDL-specified DDS4CCM APIs for pub-sub information exchanges could be built to use a CORBA Event Service alternative. Supplemented by new request-response connectors encapsulating CORBA 2 interface implementations, this combination would offer a modernized all-CORBA CCM solution for users so inclined. Alternatively, existing DDS4CCM connectors transparently built to use your favorite DDS vendor’s implementation could be supplemented in the future with new request-response connectors encapsulating a DDS implementation of an IDL client-server "interface," enabling an all-DDS CCM solution.
An all-DDS CCM solution is where my current project would ultimately like to go in the long term. This new language mapping represents an important first step in that direction. However, for the foreseeable future the ability to seamlessly mix & match alternative middleware implementations in a single real-time component framework is highly desirable. There are huge installed bases of software that we will probably always have to interoperate with, including subsystems/systems built to use CORBA-only, DDS-only or proprietary middleware. Per the new DDS4CCM specification, we are already working on our 3rd custom connector design utilizing the flexible and extensible CIAO connector framework. For all systems that must necessarily build cross-domain adapters, bridges, gateways or mediation services (pick your favorite term) an innate component framework ability to transparently integrate multiple flavors of middleware is quite powerful.
A modern C++11 middleware-independent language mapping applied to CCM opens the possibility of less IDL-generated source as well, making the overall disk/memory footprint of a CCM solution smaller and more efficient, and reducing compilation time. The ability for users who decide not to utilize CORBA 2 as a connector-encapsulated messaging protocol to build a homogeneous, more streamlined solution further reduces footprint. Moreover, in the case of a homogeneous DDS-only solution, system complexity is reduced for users at debug time since there is only one underlying middleware implementation. Wire-protocols are simplified from IIOP+RTPS to RTPS only, making a homogeneous software-intensive system easier to instrument, debug and secure.
A final big advantage of a new language mapping in particular is improved run-time performance for CCM/DDS4CCM connectors, and even for straight CORBA for that matter. Modern C++11 capabilities per the new mappings should eliminate deep copies, unnecessary data copies due to the current venerable C++ APIs, and add move semantics - all significant contributions to faster, more efficient and more deterministic software at run-time.
Mark Hayman
Northrop Grumman Corp.
CCM and IDL
Hi Mark,
Thanks for your lengthly reply. I agree with your ideas but a lot of work has to be done before we are at the point your project wants to be.
For everyone who hasn't seen it, our presentation about a future CCM standard is available on SlideShare. The AMI4CCM initial submission is available at the OMG website.
The separate IDL specification wasn't finished at the recent OMG meeting, we hope that it can go the the AB in the meeting in September.
Johnny
Migrating from C++ to C++0x language mapping
Hi Johnny,
interesting article. How big will be the effort to migrate a existing CCM application from the C++ to C++0x language mapping later on? There are many Corba applications around which will surely benefit from C++0x. Maybe a mixture of C++ and C++0x will be possible? And how long will it last until the C++0x language mappig will be standardized by the OMG?
Greetings,
MIchael
standardization process
Hi Michael,
The exact process dates are visible on the OMG Work In Progress (WIP) for IDL to C++0x page. This page is restricted to OMG members, so maybe you don't have access. In short, initial submissions are due August 22 and will be presented at the OMG meeting in September. Revised submissions are due February 2012 and will be presented at the OMG meeting in March.
When we presented this RFP to the OMG we agreed that we shouldn't standardize IDL to C++0x before the C++0x standard itself is formal. Also quality is more important than speed. With the schedule above we think we can deliver a good specification, but we can extend the deadlines if needed. If the OMG accepts the revised submission in March than we could have a new IDL to C++0x specification next year summer.
As Martin already pointed out, both mappings could probably coexist in one application. I see that as a vendor decision, it will not be mandated by the specification. Another approach could be to develop some kind of conversion script that converts IDL to C++ code to IDL to C++0x. The non CORBA related application code doesn't need to be updated, that will work without problems with C++0x but of course it could be simplified when using C++0x.
Johnny
Btw, if you register for an account on ORBzone you can enable an email subscription, when someone than responds to your comment you get an email.
DDS/CORBA compatibility
As Martin already pointed out, both mappings could probably coexist in one application. I see that as a vendor decision, it will not be mandated by the specification.
I agree that should be feasible for a single vendor supplying both CORBA and DDS. In that case, the vendor can tune the generated code to suit both domains. OTOH it might be impossible to mix implementations from different vendors. Granted, this difficulty is only relevant to bridge applications.
Gradual migration
Michael,
Depending on the specific implementation a gradual migration (component by component) would certainly be possible.
The CORBA C++0x mapping implementation Remedy IT is working on can easily coexist with the 'old' C++ mapping implemented by TAO currently. In this case both mappings use the same ORB core functionality so there would not even be any real problem having new and old mapping implementations coexist within the same process.
In the case of CCM there will be an additional dependency on the implementation of the containers which would have to exist in two flavors to accept components with new and old mapping alike. Remedy IT will certainly strife to make this happen for CIAO.