CORBA 2.6 NO IDEA Avatar
  1. OMG Issue

CORBA26 — Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping

  • Key: CORBA26-23
  • Legacy Issue Number: 3419
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    he following sub-issues need to be addressed to make sure that CCM/EJB
    bridge implementations are interoperable. In particular, these sub-issues
    have in common that the current definition of the bridge relies on the
    Java-to-IDL mapping, which in certain cases does not match the requirements
    of the EJB-to-CCM mapping.

    Sub-issue: METHOD NAMES IN STANDARD INTERFACES

    The names for some methods defined on standard interfaces, for example
    <home-name>Implicit.find_by_primary_key or <home-name>Implicit.create,
    differ from the names that their EJB counterparts get mapped to under
    Java-to-IDL (in the example these would be
    <home-name>.findByPrimaryKey and create__keytype, respectively). When
    this happens, the translation from one form of the name to the other
    can happen at either the client or the server side of the bridge. FOR
    INTEROPERABILITY, it is necessary to eliminate this ambiguity. Choices
    for doing this include requiring the client stub to always do the
    translation or requiring the server skeleton to take into account both
    name forms.

    The actual problem we are getting hit by here is overloaded names. Methods
    like remove and create in EJBHome and user-defined EJB homes can only be
    mapped to remove_XXX and create_XXX under Java-to-IDL, yet the
    definitions of the corresponding methods in <home-name>Implicit are remove
    and create, respectively. I can understand that these implicit home names
    were defined as such because <home-name>Implicit is a standard interface
    (although the fact that its name is prefixed by <home-name> is a bit
    troubling) and, if for no other reason, because the XXX in create_XXX
    cannot be known in general. So, if we stick to the standard names, there is
    a mismatch. Notice however that I said that the mapping is done under
    Java-to-IDL. Perhaps I should not say that but the CCM spec is not clear
    about this and in fact it states that the create methods in an EJB home are
    mapped to factory names under Java-to-IDL. So we may actually be talking
    about two different issues: (1) use different mapping rules for create with
    no primary key, in which case we need to ammend the spec to this effect;
    (2) perform a translation, in which case we have an interoperability issue.

    Sub-issue: HANDLING STANDARD EXCEPTIONS

    Standard exceptions thrown by EJB methods, such as
    DuplicateKeyException, have a mapping specification to IDL (under the
    current Java-to-IDL specification) that does not match the exceptions
    that they map to under the CCM spec (in the example this would be
    DuplicateKeyValue). This requires that the bridge perform a run-time
    translation of exceptions from the Java-to-IDL mapping to the CCM
    mapping at either the client stub or the server skeleton. FOR
    INTEROPERABILITY, it is further necessary that the location of the
    translation be fixed. Early prototype implementation suggests that it
    is more advantageous for the client stub to perform the translation
    since otherwise the server skeleton would need to know what kind of
    client it is talking to: a CCM client or an EJB client. A larger issue
    that this falls under is the reconciliation of the Java-to-IDL mapping
    with the EJB-to-CCM mapping. If and when the larger issue is resolved,
    this issue would largely disappear.

    This also falls under the Java-to-IDL mismatch. Our choices seem to be: (1)
    define the standard exceptions, e.g. Components::DuplicateKeyValue, as if
    they had been mapped from Java under Java-to-IDL, (2) map the exceptions
    from Java under rules different from those on Java-to-IDL; (3) perform a
    translation. Choice (1) may be too intrusive but it could be rationalized
    with a "integration with EJB" argument. Choices (2) and (3) are similar to
    the above.

    Sub-issue: PASSING A PRIMARY KEY PARAMETER

    A number of methods defined by standard interfaces, such as remove
    defined by EJBHome, include in their signature a primary key value and
    define its type to be java.lang.Object, which under RMI-IIOP is mapped
    to CORBA::Any. Since the primary key is actually an object passed by
    value and thus mapped to an IDL value type, a run-time translation
    must be performed from the value type to Any and viceversa whenever a
    method that includes a primary key is called. FOR INTEROPERABILITY, it
    is necessary that the location of this translation be fixed. Choices
    for doing this include requiring the client stub to always do the
    translation or requiring the server skeleton to take into account both
    a value or an Any that could possibly be coming from any given
    client. In additon, if a primary key is returned it may be more
    advantageous for the client to perform this translation, since the
    server skeleton may not know what form the client is expecting.

    Here again the problem is that, under Java-to-IDL, java.lang.Object gets
    mapped to ::java::lang::Object (not CORBA::Any actually, as per the actual
    Java-to-IDL I am looking at) for methods like EJBHome.remove, whereas the
    key is expected to be passed as a value type. So the choices seem to be:
    (1) use rules other than those in Java-to-IDL for the mapping or (2)
    perform a translation.

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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