CORBA/OMG C++11 Language Mapping

Question

I'm currently working on a [OMG13] (s. below) compliant C++11 partial facade for adapting a legacy (C++)ORB; "partial" in the sense of just server-side, no DII, no OBV etc - thus the very basic stuff only.

[OMG13] has in 6.25.6 Inheritance-Based Interface Implementation

Implementation must be derived from a generated base class based on the OMG IDL interface definition. The generated base classes are known as skeleton classes, and the derived classes are known as implementation classes. Each operation of the interface has a corresponding virtual member function declared in the skeleton class.

[emphasis mine]

That, if taken literally, implies that, for an interface A defined in the idl, A_impl shall be a descendant of A_skel

class A_impl : /* whatever, likely public */  A_skel {
    /**/
};

But the snippets given in 6.25.6 tell otherwise

// C++
class A_skel : public virtual CORBA::servant_traits<A>::base_type { ... };

// C++
class A_impl: public virtual CORBA::servant_traits<A>::base_type { ... };

So, according to the snippets, A_impl and A_skel are siblings, descending from the same ancestor.

It's not trivial to decide what to do, because the standard for the former, C++ prior to C++11, mapping [OMG12], has 5.40.3 Inheritance-Based Interface Implementation

Implementation classes can be derived from a generated base class based on the OMG IDL interface definition. The generated base classes are known as skeleton classes, and the derived classes are known as implementation classes.

so it is "can" not "must" for C++, prior to C++11, mapping, and the snippets given in are consistent with this "can"

class POA_A : public virtual PortableServer::ServantBase 
{
    /* [...] */
}

/* [...] */

class A_impl : public POA_A
{
   /* [...] */
};

and that is also what the legacy ORB, I work with, infrastructure is built for (aside of also offering [OMG12]-compliant delegation-based implementation).

So - how to relate _skel and _impl in my little c++11-compliance ORB facade to be [OMG13]-compliant and hardening impl code against possible refactoring of that part of [OMG13]?

One could e.g. consider deriving _impls from an CRTP-style inheritance-multiplexing class:

struct Snippet_Reading{};
struct Prose_Reading{};

namespace mock {

    class IA{}; 

    // impl specific, not important here  
    template<class Ifc>
    struct LoremIpsum {}; 


    template<class Ifc>
    class POA_Delegator {
         // impl specific, not important here  
    };

    namespace CORBA {
        template<class Ifc>
        struct servant_traits {
            /// @TODO meditate how to implement that
            typedef LoremIpsum<Ifc> base_type;
        };
    }
} 

namespace detail {
    using namespace mock;

    template<typename Reading, class Ifc>
    class Base {};

    template<class Ifc>
    class Base<Prose_Reading, Ifc> : public virtual POA_Delegator<Ifc> {};

    template<class Ifc>
    class Base<Snippet_Reading, Ifc> : public virtual CORBA::servant_traits<Ifc>::base_type {};
}

#if defined(PROSE_READING)
    template <class Ifc>
    using Base = detail::Base<Prose_Reading, Ifc>;
#elif  defined(SNIPPET_READING)
    template <class Ifc>
    using Base = detail::Base<Snippet_Reading, Ifc>;
#else
    #error Oh My Goodness! Don't know how to interpret OMG's IDL to C++11 Mapping!
#endif 


class IA_impl : public virtual Base<mock::IA> {};


int main() {}

but this yields not exactly a standard-compliant implementor's interface.

References

[OMG12] OMG C++ Language Mapping. OMG, 2012. http://www.omg.org/spec/CPP/1.3

[OMG13] OMG. C++11 Language Mapping. OMG, 2013. http://www.omg.org/spec/CPP11/

score 1 · Accepted Answer · edited Jun 05 '13 at 17:22

1

CORBA::servant_traits::base_type should resolve to A_skel at compile time. The user doesn't really see A_skel, that is just an implementation detail. The user defined A_impl than just derived from the CORBA::servant_traits::base_type trait.

There is an error in 6.26.6 as you pointed out. The skeleton classes should derive from each other, not from the traits, so it should be as below, also C_skel is lacking.

// C++
class A_skel : public virtual PortableServer::ServantBase {};
class B_skel : public virtual A_skel {};
class C_skel : public virtual A_skel {};
class D_skel : public virtual B_skel, public virtual C_skel {};

For the draft V1.1 mapping see http://osportal.remedy.nl. We could also assist with your challenge, feel free to contact me directly.

Could you report a formal issue to the OMG for the example in 6.26.2 so that we can resolve that in the V1.2 version of the spec

edited Jun 05 '13 at 17:22

Tom Knapen

2,277
16
31

answered Jun 05 '13 at 13:52

Johnny Willemsen

2,942
1
14
16

"CORBA::servant_traits::base_type should resolve to A_skel at compile time" Thx, Johnny, but the snippet of A_skel tells otherwise, and that's the problem I'm talking about. Btw - congrats on advancing the standardization process for C++11 mapping. CORBA is a domain that's almost "longing" for C++11. GREAT job! – Solkar Jun 05 '13 at 14:04
"Could you report a formal issue to the OMG" Feel free to report that yourself, just include a reference to this thread. pls. – Solkar Jun 06 '13 at 13:39
Submitted an issue to the OMG for the V1.2 revision of the spec, that RTF will be chartered in 2 weeks in Berlin. – Johnny Willemsen Jun 06 '13 at 17:27
> "Submitted an issue to the OMG for the V1.2 revision of the spec," Fine. Any timeline when that v1.2 will become formal? Btw - another issue: [OMG13]. 6.25.5 Skeleton Operations, snippet on p. 41: It`s not A_impl who shall implement _this(), but A_skel; again the snippet and the textual descr. differ. – Solkar Jun 07 '13 at 07:24
The RTF schedule for V1.2 will have a delivery March 2014, the V1.1 is up for adoption in a little bit more than a week in Berlin at the OMG Technical Meeting. After the adoption of V1.1 we will start the effort of a V1.2 draft for which we will post informal drafts at http://osportal.remedy.nl – Johnny Willemsen Jun 07 '13 at 08:17
So one year to go? Wow. Fortunately, I don't need this for a commercial purpose, but how do you folks deal with these inconsistencies in formal docs? – Solkar Jun 07 '13 at 08:32
The OMG process is just time consuming. When we find inconsistencies we normally raise them to the OMG and make assumptions about how things are resolved at the end. Sometimes there is a discussion on the RTF list to make sure we are making a correct assumption. – Johnny Willemsen Jun 07 '13 at 08:37

Solkar · Answer 2 · 2013-06-06T13:50:46.373

0

In response to Johnny Willemsen's answer:

OK, let's tie the pieces together:

The standard demands

class A_impl: public virtual CORBA::servant_traits<A>::base_type { ... };

and if this

CORBA::servant_traits::base_type should resolve to A_skel at compile time.

shall hold for A_skel defined this way

class A_skel : public virtual PortableServer::ServantBase {};

then there must be a specialization for A of template<T>struct CORBA::servant_traits, so I take it, the standard shall imply this sort of dependencies:

class A {
  public:
    virtual long foo() = 0;
};

namespace mock {

    namespace CORBA {
        template<class Ifc>
        struct servant_traits { /* ? */};
    }

    namespace PortableServer {
        class ServantBase { /* ... */};
    }
} 

using namespace mock;

class A_skel : public virtual PortableServer::ServantBase {
    virtual long foo() = 0;
};

namespace mock {
    namespace CORBA {
        template<>
        struct servant_traits<A> {
            typedef A_skel base_type;
            // ...
        };
    }
}    

class A_impl : public virtual CORBA::servant_traits<A>::base_type {
  public:
    virtual long foo() {
        return 42;
    }
};

int main() {}

Do I get this right?

edited Jun 06 '13 at 13:50

answered Jun 06 '13 at 13:32

Solkar

1,228
12
22

Yes, you got this right. Be aware that the client doesn't see class A, but just sees IDL::traits::ref_type which could at the end resolve to class A. – Johnny Willemsen Jun 06 '13 at 17:09
?. That's meant to be server-side only and - partly - idlgen-to-be generated. – Solkar Jun 07 '13 at 07:14
IDL::traits::ref_type is client side, but in our experience you can't just implement server side, you need also the client side because no application is purely server side only. Yes, and a lot is IDL based code generation for which you need to develop an IDL compiler/generator. – Johnny Willemsen Jun 07 '13 at 08:16
The client side is already provided by the legacy ORBs; I need the C++11 support only on the server side and just atop of the already existent C++ layers. That's of course not a general concept. but for my project that'd be good enough. – Solkar Jun 07 '13 at 08:26
How big the challenge depends a little bit on the size of your IDL, implementing the mapping completely for client and server and testing it was a big effort. – Johnny Willemsen Jun 07 '13 at 08:38
;) Nice one. You're right, of course. Fortunately I`m the one who writes the initial IDL, and I have a talent for KISSing IDLs. There anyway is no need for OBV, DII, anys etc; it's all about numerical data and just PODs and structs of PODs sent, oneway manipulated and once readied pulled back in big chunks. So - nothing esoteric, you see? ;) – Solkar Jun 07 '13 at 09:50
We have an upcoming release of evaluation package of TAOX11, see www.remedy.nl – Johnny Willemsen Sep 24 '13 at 13:14
Evaluation versions of TAOX11 will be available from today, check http://swsupport.remedy.nl – Johnny Willemsen Oct 30 '13 at 07:53

CORBA/OMG C++11 Language Mapping

2 Answers2