CORBA 2.5 NO IDEA Avatar
  1. OMG Issue

CORBA25 — Missing TypeCode identity

  • Key: CORBA25-37
  • Legacy Issue Number: 4386
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Steve's and my book contains a bit of code that pretty-prints a TypeCode.
    (See page 704ff, in particular, 709-711.) No big deal – just write
    a recursive function that does a depth-first traversal of a TypeCode tree
    and prints things out, except for one thing: recursive types.

    For recursive types, the code has to be careful not to get trapped in
    infinite recursion. In essence, this means that the pretty-printer has to
    remember which TypeCodes it has already seen and end the recursion if it gets
    to a TypeCode that was printed previously. This is where we run into
    problems because there is no legal way to do this:

    • I cannot rely on the repository ID in the TypeCode to determine
      TypeCode identity because the repository ID for structs and
      unions is optional prior to GIOP 1.2, but recursion happens
      via structs and unions. (A GIOP 1.2 implementation may interoperate
      with a GIOP 1.0 or 1.1 implementation and still end up sending
      TypeCodes without repository IDs.)
    • The code in the book uses is_equivalent() to determine whether
      it has seen a TypeCode previously. However, doing this is
      completely illegal (even though it happens to work with most
      ORBs) because:
    • is_equivalent() does not provide object identity.
    • TypeCode is a pseudo-object, and pseudo-objects do
      not inherit from CORBA object. This means that TypeCode
      doesn't even have an is_equivalent() operation that I
      could call.

    So, as far as I can see, there is no compliant way to reliably and portably
    determine TypeCode identity and, as a result, I can't ever reliably parse
    a TypeCode...

    I can see several solutions for this problem, all with different drawbacks:

    1) Add an identity() operation of some kind to TypeCode.

    An ORB that receives a TypeCode would have to make sure that
    it generates a unique ID for each TypeCode. But that's not
    all that easy to implement – in particular, if we have an
    older TypeCode where all the optional bits are missing, we
    can't reliably establish object identity for a TypeCode.
    (Only structural comparison is possible.)

    2) Add an identity() operation to TypeCode, but have the TypeCode's
    identity generated at the sending end instead of the receiving

    Major drawbacks: the identity would have to large because it
    needs to be globally unique (e.g. a UUID) and it would change
    the marshaling of TypeCodes.

    3) Add is_equivalent() and hash() operations to TypeCode.

    This might break existing ORB implementations because a lot
    of ORBs seem to inherit from Object for TypeCode and other PIDL
    objects, even though they shouldn't.

    4) Make PIDL objects implicitly inherit from CORBA::Object.

    Note that making the repository ID mandatory is impossible because we
    can't legislate for existing GIOP 1.0 or 1.1 implementations...

    On a related note, we seem to have further problems with the idea that
    PIDL objects don't inherit from CORBA::Object. For example, in the C++ mapping,
    pseudo-objects such as TypeCode, ORB, etc. can be passed as Object_ptr
    (for example, to CORBA::is_nil()). This really means that the C++ mapping
    (and possible mappings for other languages) are completely in conflict
    with the core spec...

    My feeling is that option 4 is really the least-intrusive one. But I'm
    not sure that I fully understand all the ramifications of making that change.

  • Reported: CORBA 2.4.2 — Thu, 28 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT