[tao-users] New C++ bindings
Bjørn Roald
I think I have heard or read about ongoing work on new CORBA C++ binding
in some magazine article and on this list, but I could not find it.
Does anybody have update or pointers?
There is some discussions on the boost.org developers list about
possible work on new C++ bindings for CORBA. They do not seem to be
aware of any work by others.
--
regards
Bjørn
Douglas C. Schmidt
Hi Bob,
Is there any info that you can share about the status of the CORBA
C++ binding at the OMG?
Thanks,
Doug
>
> --
> regards
> Bjørn
>
>
> _______________________________________________
> tao-users mailing list
> tao-...@list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/mailman/listinfo/tao-users
Johnny Willemsen
> > I think I have heard or read about ongoing work on new CORBA C++
> binding
> > in some magazine article and on this list, but I could not find it.
> > Does anybody have update or pointers?
> >
> > There is some discussions on the boost.org developers list about
> > possible work on new C++ bindings for CORBA. They do not seem to be
> > aware of any work by others.
>
> Is there any info that you can share about the status of the CORBA
> C++ binding at the OMG?
At the OMG Meeting in July 2007 this was discussed, also the meetings after
that people did discuss about the possibility for a new mapping. So far as I
know at this moment there is more focus on getting a new C++ mapping for DDS
(which now uses the CORBA mapping). The OMG don't want to rush things and
create a new C++ mapping that nobody has implemented. I think the best way
is that the user community/vendors try to work on a new implementation, then
use that and standardize it through the OMG. It will be a challenging task,
there are a lot of conflicting interests and several vendors. One of the
questions is whether it is econimic feasable for all the vendors to
implement a new mapping and another one is whether existing users will
upgrade to a new mapping.
Johnny
Sowayan, Abdullah (N-DUA)
> At the OMG Meeting in July 2007 this was discussed, also the meetings
> after
> that people did discuss about the possibility for a new mapping. So
far as
> I
> know at this moment there is more focus on getting a new C++ mapping
for
> DDS
> (which now uses the CORBA mapping).
DDS products (I'm using a couple now) do not adhere to the IDL->C++
mapping (I'm not referring to OpenDDS). This, of course, is very
frustrating, as it isn't clear how to deal with memory management, if
reference counting is available, etc.
I wonder why the focus on a new C++ mapping for DDS specifically. All
DDS constructs are expressed in IDL, so why couldn't OMG come up with a
new IDL->C++ mapping that would apply to both CORBA and DDS? It will be
confusing if there are two separate IDL->C++ mappings, one for CORBA and
another for DDS. Then one will have to worry in code about (oh, I'm
using this structure, etc to pass to CORBA, use _var type for memory
management, oh, now I'm using a similar structure for DDS, I need to do
something different).
> The OMG don't want to rush things and
> create a new C++ mapping that nobody has implemented. I think the best
way
> is that the user community/vendors try to work on a new
implementation,
> then
> use that and standardize it through the OMG. It will be a challenging
> task,
> there are a lot of conflicting interests and several vendors. One of
the
> questions is whether it is econimic feasable for all the vendors to
> implement a new mapping
Why would it matter if all vendors implement the new mapping or not?
Moving a newer mapping should be optional. Actually, which mapping an
ORB chooses to adopt should be left to the vendor to decide. IDL->C++
mapping does not affect interoperability.
For example, there are two different IDL->C++ mappings, one that
supports C++ exceptions and one that doesn't (when you chose the latter
mapping, you pass a parameter to each CORBA operation, that parameter
holds whether an exception was thrown by the server or not). TAO used to
support both, but now only support the real-exception model. That
doesn't mean that TAO is non-conformant or that it will not interoperate
with an ORB that doesn't support the real-exception mapping.
> and another one is whether existing users will
> upgrade to a new mapping.
Legacy, already deployed program will probably not bother with upgrading
to the newer mapping. However, new programs probably will (assuming the
new IDL->C++ mapping is more intuitive, and uses more standard C++,
which C++ developers are more familiar with). New DoD projects are
mandated to use standards based technologies (such as CORBA, and DDS),
so there will be interest in a new mapping should it become available.
Thanks,
Abdul
Douglas C. Schmidt
Hi Abdul,
> DDS products (I'm using a couple now) do not adhere to the IDL->C++
> mapping (I'm not referring to OpenDDS). This, of course, is very
> frustrating, as it isn't clear how to deal with memory management, if
> reference counting is available, etc.
If you're running into problems with the OpenSplice DDS IDL->C++ mapping
please let Angelo know the (I've cc'd him on this email).
> I wonder why the focus on a new C++ mapping for DDS specifically.
I think there are (at least) two main reasons:
. The focus on a new C++ mapping is driven by the realization that the
original C++ mapping is based on pre-STL versions of C++, which are
pretty ancient by now (i.e., "bad code smells" ;-)).
. DDS doesn't have as much "legacy" code as CORBA to act as an albatross
around its neck wrt creating a new C++ mapping.
> All DDS constructs are expressed in IDL, so why couldn't OMG come up
> with a new IDL->C++ mapping that would apply to both CORBA and DDS?
That's the ultimate goal - we're just trying to do this in a manner that
meets less resistance at first.
> It will be confusing if there are two separate IDL->C++ mappings, one
> for CORBA and another for DDS. Then one will have to worry in code
> about (oh, I'm using this structure, etc to pass to CORBA, use _var
> type for memory management, oh, now I'm using a similar structure for
> DDS, I need to do something different).
Right, I agree, but we need to deal with practicalities, one of which is
that there's a lot of legacy CORBA/C++ code out there that will take a
long time to change (if ever).
> Why would it matter if all vendors implement the new mapping or not?
> Moving a newer mapping should be optional. Actually, which mapping an
> ORB chooses to adopt should be left to the vendor to decide. IDL->C++
> mapping does not affect interoperability.
I also agree with this from a technical perspective. From a political
perspective, however, it's been hard to get all the CORBA vendors to
show enthusiasm for creating a new IDL->C++ mapping, whereas it's been
much easier to get the (smaller number of) DDS vendors to show such
enthusiasm.
> Legacy, already deployed program will probably not bother with
> upgrading to the newer mapping. However, new programs probably will
> (assuming the new IDL->C++ mapping is more intuitive, and uses more
> standard C++, which C++ developers are more familiar with). New DoD
> projects are mandated to use standards based technologies (such as
> CORBA, and DDS), so there will be interest in a new mapping should it
> become available.
I'm totally sold on a new IDL->C++ mapping for CORBA, as per my
presentation at
http://www.dre.vanderbilt.edu/~schmidt/C++-mapping.ppt
The trick is to get the rest of the world on board ;-)
Thanks,
Doug
Chris Cleeland
On Apr 2, 2008, at 1:43 PM, Sowayan, Abdullah (N-DUA) wrote:
>> The OMG don't want to rush things and create a new C++ mapping that
>> nobody has implemented. I think the best way is that the user
>> community/vendors try to work on a new implementation, then use
>> that and standardize it through the OMG. It will be a challenging
>> task, there are a lot of conflicting interests and several vendors.
>> One of the questions is whether it is econimic feasable for all the
>> vendors to implement a new mapping
>
> Moving a newer mapping should be optional. Actually, which mapping an
> ORB chooses to adopt should be left to the vendor to decide. IDL->C++
> mapping does not affect interoperability.
Specs cannot be done in a vacuum. If no vendor chooses to implement,
or if the mapping is too difficult to implement, then those who
created the spec will have wasted the time of the committee that put
together the spec as well as users who looked forward to the spec.
Beyond that, vendors are part of the team that comes up with the
spec. Vendors will not commit time to spec'ing something they're
unlikely to implement.
> For example, there are two different IDL->C++ mappings, one that
> supports C++ exceptions and one that doesn't (when you chose the
> latter
> mapping, you pass a parameter to each CORBA operation, that parameter
> holds whether an exception was thrown by the server or not). TAO
> used to
> support both, but now only support the real-exception model. That
> doesn't mean that TAO is non-conformant or that it will not
> interoperate
> with an ORB that doesn't support the real-exception mapping.
You're correct. But TAO didn't abandon the emulated exception mapping
just because it felt like it. It abandoned it because compilers
caught up and using real exceptions made implementing parts of the ORB
easier or even feasible. The mapping can (and probably will) impact
the implementation.
>> and another one is whether existing users will
>> upgrade to a new mapping.
>
> Legacy, already deployed program will probably not bother with
> upgrading
> to the newer mapping. However, new programs probably will (assuming
> the
> new IDL->C++ mapping is more intuitive, and uses more standard C++,
> which C++ developers are more familiar with). New DoD projects are
> mandated to use standards based technologies (such as CORBA, and DDS),
> so there will be interest in a new mapping should it become available.
There is also the learning curve, though. Users have an investment in
the existing mapping, however arcane.
I'm not arguing against a new mapping. I just think it's more
complicated than it might appear, or not as simple as we wish it could
be.
---
Chris Cleeland, Principal Software Engineer
http://www.theaceorb.com AND http://www.ociweb.com
Sowayan, Abdullah (N-DUA)
> > Why would it matter if all vendors implement the new mapping or not?
> > Moving a newer mapping should be optional. Actually, which mapping
an
> > ORB chooses to adopt should be left to the vendor to decide.
IDL->C++
> > mapping does not affect interoperability.
>
> Specs cannot be done in a vacuum. If no vendor chooses to implement,
> or if the mapping is too difficult to implement, then those who
> created the spec will have wasted the time of the committee that put
> together the spec as well as users who looked forward to the spec.
What I was trying to communicate is that not every single vendor has to
implement the new mapping. If some do (and hopefully TAO will be one of
them) then it will be worth while.
> Beyond that, vendors are part of the team that comes up with the
> spec. Vendors will not commit time to spec'ing something they're
> unlikely to implement.
What I was also trying to communicate is that it would be a shame if
there were two parallel IDL->C++ mappings (one for CORBA, and another
one specifically for DDS). If there is already an effort by vendors
spec'ing IDL->C++ mapping for DDS, one would hope that newer/modern
mapping would also work for CORBA. CORBA Vendors can choose if they
would like to transition to the new mapping or not.
Vendors that support both CORBA and DDS products (such as OCI) might
benefit (and their customers too) from a single mapping. Vendors that
only provide CORBA products might not have as compelling a case
initially.
> > For example, there are two different IDL->C++ mappings, one that
> > supports C++ exceptions and one that doesn't (when you chose the
> > latter
> > mapping, you pass a parameter to each CORBA operation, that
parameter
> > holds whether an exception was thrown by the server or not). TAO
> > used to
> > support both, but now only support the real-exception model. That
> > doesn't mean that TAO is non-conformant or that it will not
> > interoperate
> > with an ORB that doesn't support the real-exception mapping.
>
> You're correct. But TAO didn't abandon the emulated exception mapping
> just because it felt like it. It abandoned it because compilers
> caught up and using real exceptions made implementing parts of the ORB
> easier or even feasible.
I thought emulated exceptions were dropped because there was no user
interest in it anymore. The point is; supporting emulated exception
mapping is optional. Supporting the new mapping should be optional as
well. Actually, choosing which mapping to support (emulated exception,
old, or new) should be a vendor choice. An implementation will be
compliant if it supports at least one mapping.
> There is also the learning curve, though.
True, but for new users/project, the curve will hopefully be less than
the existing mapping.
> Users have an investment in
> the existing mapping, however arcane.
Existing, deployed project have an investment in the existing mapping.
Newer ones don't. I can tell you for projects we are starting here at
LMCO, if you told me that a newer, more intuitive, mapping that is more
aligned with standard C++ (STL containers, algorithms, etc) will be
shipping with TAO 1.6.4 (due in a week or two), we would use it.
Thanks,
Abdul
Douglas C. Schmidt
Hi Folks,
> Existing, deployed project have an investment in the existing mapping.
> Newer ones don't. I can tell you for projects we are starting here at
> LMCO, if you told me that a newer, more intuitive, mapping that is more
> aligned with standard C++ (STL containers, algorithms, etc) will be
> shipping with TAO 1.6.4 (due in a week or two), we would use it.
Right, I agree wholeheartedly. In fact, one of the main things holding
back CORBA these days is the perception that it's "old" technology. The
lack of a decent/modern C++ mapping is at the heart of this perception.
What CORBA really needs is a face lift, sort of like how aging Hollywood
actors/actresses keep themselves looking young even though they are
biologically mature (or not ;-)).
Doug
Phil Mesnier
> What CORBA really needs is a face lift, sort of like how aging Hollywood
> actors/actresses keep themselves looking young even though they are
> biologically mature (or not ;-)).
>
Careful with the analogy. Those face-lifted celebs often end up with
something quite brittle and somewhat frightening. That is *not* what I
would want from a new C++ mapping. :-)
--
Phil Mesnier
Principal Software Engineer, http://www.ociweb.com
Object Computing, Inc. +01.314.579.0066
Adam Mitz
> What I was also trying to communicate is that it would be a shame if
> there were two parallel IDL->C++ mappings (one for CORBA, and another
> one specifically for DDS).
The (envisioned) DDS C++ PSM is not an IDL -> C++ mapping, it's a PIM ->
C++ mapping. But it certainly could/should share some features of a
modern IDL -> C++ mapping. I'd expect to see std::string, std::vector,
consistent uses of reference counting, etc., show up in both.
The C++ PSM still has some relationship to IDL, I think, due to this
clause in the RFP (mars/08-03-04):
6.5.5 Proposals shall not modify the language used for user-defined
data-types
associated with published and subscribed Topics (data-type definitions)
or the
language mapping of those data-types.
(This is part of "Mandatory Requirements")
So if I'm reading this correctly, the user-defined data types would stay
defined in IDL and translated to C++ using the current IDL -> C++
rules. It seems like a DDS implementation could offer an extension here
and use a new IDL -> C++ mapping. And if/when the new IDL -> C++
mapping was approved by OMG, it would fit in with DDS.
Thanks,
Adam Mitz
Software Engineer
Object Computing, Inc.
Chris Cleeland
On Apr 2, 2008, at 4:17 PM, Phil Mesnier wrote:
> Douglas C. Schmidt wrote:
>> What CORBA really needs is a face lift, sort of like how aging
>> Hollywood
>> actors/actresses keep themselves looking young even though they are
>> biologically mature (or not ;-)).
>
> Careful with the analogy. Those face-lifted celebs often end up with
> something quite brittle and somewhat frightening. That is *not* what I
> would want from a new C++ mapping. :-)
CORBotox?
Bjørn Roald
> jwill...@remedy.nl wrote;
>> and another one is whether existing users will
>> upgrade to a new mapping.
>>
>
> Legacy, already deployed program will probably not bother with upgrading
> to the newer mapping. However, new programs probably will (assuming the
> new IDL->C++ mapping is more intuitive, and uses more standard C++,
> which C++ developers are more familiar with).
Agree in general, but if the ORB I used in a legacy system supported
both, a reenginering may be very beneficial given a certain level of
ongoing maintenence.
> New DoD projects are
> mandated to use standards based technologies (such as CORBA, and DDS),
> so there will be interest in a new mapping should it become available.
>
So, DoD projects do not really care that it is OMG standarized, just
that there is some reasonable level of standardization? Is there an
official list of approved standards or standardization bodies?
What I am searching is assertions that the following may be a roadmap
that has reasonable chances of success. With success not I do not mean
that all steps need to succeed, just that this produce real value for
the comunity:
1. A boost.org based activity implements a new C++ mapping with
implementations against one or more open source ORBs. Possibly, if
feasable, also an adapter to the legacy C++ mapping.
2. Review(s) and acceptance in boost. If or when accepted, work on
getting CORBA and DDS vendors on-board.
3. When momentum is sufficient, go for acceptance in OMG CORBA and/or DDS.
4. If failure to get OMG approved stamp on the mapping and interrest is
sufficient, then use different standardization body. See C++ comunity
note below.
C++ comunity note:
Organizations such as OMG has members that first and foremost take care
of their own interests. The members that vote on CORBA / DDS issues
does not in general think very hard on what is best for the C++
comunity. Not, it seems, even if those same solutions would be very
good for CORBA and or DDS. The C++ community is in dear need of good
and generally available, high quallity, concistant, modern, mappings to
middleware communication solutions in general, and certainly
improvements to the CORBA mappings specifically. From a C++ perspecive,
aspects of the mappings such as type system and call conventions should
ideally be conventions shared far beyond the realms of CORBA. Also
concepts such as remote-object-method-call, remote-call, etc. could be
mapped in a hieracy similar to STL iterator concepts to allow code using
the mappings to easially switch backend within concept constraints
rather than middleware product or standard constraints. I believe
people at boost.org, with hopefully some support from TAO developers and
others, are capable of pulling this off. If really successfull with
general C++ concerns in mind, then who knows, maybe ISO C++, et al. is
the standards to aim for. Then the only reason we would need the OMG
stamp is to put pressure on vendors to implement as they may want to be
CORBA compliant.
--
Bjørn
Johnny Willemsen
> Why would it matter if all vendors implement the new mapping or not?
> Moving a newer mapping should be optional. Actually, which mapping an
> ORB chooses to adopt should be left to the vendor to decide. IDL->C++
> mapping does not affect interoperability.
For interoperability between C++ ORBs this will be important. One of the
main reasons why a lot of people switch from commercial orbs to TAO is that
they don't have to reimplement all their code.
> > and another one is whether existing users will
> > upgrade to a new mapping.
>
> Legacy, already deployed program will probably not bother with
> upgrading
> to the newer mapping. However, new programs probably will (assuming the
> new IDL->C++ mapping is more intuitive, and uses more standard C++,
> which C++ developers are more familiar with). New DoD projects are
> mandated to use standards based technologies (such as CORBA, and DDS),
> so there will be interest in a new mapping should it become available.
One challenge is to get a new C++ mapping, for that we need input from the
user community and we should have a working reference implementation before
trying to standardize anything. Standardizing just ideas is not a good
thing.
The biggest challenge to my idea is how to add a new mapping to TAO without
loosing the support for the old mapping. TAO uses the mapping also
internally to implement its functionality, maybe we just should have two
implementations, or use macros like in the past. Also users of the old
mapping shouldn't have a slower performance because we support a new one.
Overall this will be a large activity which needs input in terms of ideas
and funding from a lot of sides. If there are people that want to volunteer
to make a proposal implementation we do welcome such ideas.
Johnny
Johnny Willemsen
> What I am searching is assertions that the following may be a roadmap
> that has reasonable chances of success. With success not I do not mean
> that all steps need to succeed, just that this produce real value for
> the comunity:
>
> 1. A boost.org based activity implements a new C++ mapping with
> implementations against one or more open source ORBs. Possibly, if
> feasable, also an adapter to the legacy C++ mapping.
>
> 2. Review(s) and acceptance in boost. If or when accepted, work on
> getting CORBA and DDS vendors on-board.
I would prefer to work together with vendors in step 1. We as Remedy IT did
upgrade our OMG membership last year to be able to support this kind of
efforts through the OMG. We for example made a Ruby language mapping which
we want to standardize through the OMG. Other effort we are supporting is
adding compression support to CORBA and CORBA/e. We can learn a lot from the
boost community how to get a improved C++ mapping, any cooperation is
welcome there. Personally I want to be involved in this effort, my biggest
challenge is to find enough time for supporting this.
> 3. When momentum is sufficient, go for acceptance in OMG CORBA and/or
> DDS.
>
> 4. If failure to get OMG approved stamp on the mapping and interrest is
> sufficient, then use different standardization body. See C++ comunity
> note below.
Also there is an important role for the users. If they ask the vendors for
the implementation of the new proposed C++ mapping it is up to the vendors
to react. If this for example means that customers move to a different ORB
it will probably lead to reactors from vendors soon.
Johnny
Sowayan, Abdullah (N-DUA)
> So, DoD projects do not really care that it is OMG standarized, just
> that there is some reasonable level of standardization? Is there an
> official list of approved standards or standardization bodies?
DoD projects use a wide array of technologies, such as C++, JAVA, XML, CORBA, DDS, POSIX, SQL, UML, etc. Some of those technologies (such as CORBA, DDS, UML) are OMG standards. Some (such as C++, POSIX, JAVA) are not OMG standards. Interoperability is important, open standards facilitate interoperability and portability, and avoid vendor lockin. So if a vendor goes out of business, the projects that used that vendor won't necessarily go out of business as well.
Thanks,
Abdul