4 Replies Latest reply on Nov 16, 2003 12:02 PM by flitzie

    CORBA 2.0 friendly EJB

    flitzie Newbie

      Hallo

      did anybody managed to write an CORBA-friendly EJB with complex types (IDL struct, sequences, ...) and accessed it with a CORBA 2.0 client?

      The problem is that IDL structs or sequences of CORBA-friendly EJB's are boxed as valuetypes. Is it possible to enforce JBoss/JacORB to use non-valuetyped binarystreams to communicate with clients? I mean I cannot imagine that it won't be possible, because JacORB already sends "normal" UserException (JBoss 3.2.2 RC4) which CORBA 2.0 clients can unmarshall. To send simple IDL structs I could use UserExceptions, because IDL structs and IDL exceptions are equal, but this would be an ugly way of developing.

      Any comments or suggestions are appreciated

      flitzie

        • 1. Re: CORBA 2.0 friendly EJB
          flitzie Newbie

          Hello developers,

          I managed to access an EJB with an CORBA 2.0 client successfully. I re-defined the IDL file for the client to marshall and demarshall the additional valuetype information.

          For example:

          typedef sequence Binary;

          /*
          // this is the original struct used in the EJB
          struct TestBean {
          long count;
          string name;
          Binary data;
          };
          */

          // struct for the client to unmarshall the boxed valutyped struct
          struct getBoxedTestBean {
          long ser;
          string host;
          string id;
          long count;
          string name;
          Binary data;
          };

          // struct for the client to marshall a boxed valutyped struct
          struct setBoxedTestBean {
          long ser; // = 2147483394
          string id; // = #pragma ID TestBean "RMI:ejb.corba.test.TestBean:84F24825D7BD12E9:07B7D087B58E218E"
          long count;
          string name;
          Binary data;
          };


          I am not a CORBA ORB developer so I am asking me why does this work because the corba binarystream of an corba 2.0 and 2.3 client still differs? I want to understand the meaning of these additional valuetype information compared to non-valuetype. I read some CORBA Specs but I couldn't find any usefull information. It would be great if someone of you could post some links with detailed information about marshalling and demarshalling of valuetypes.

          TIA

          flitzie

          • 2. Re: CORBA 2.0 friendly EJB
            Francisco Reverbel Novice

            Hi,

            > did anybody managed to write an CORBA-friendly EJB
            > with complex types (IDL struct, sequences, ...) and
            > accessed it with a CORBA 2.0 client?

            The MICO distribution (www.mico.org) includes such an example, with the CORBA-friendly EJB being accessed by a C++ client.

            > The problem is that IDL structs or sequences of
            > CORBA-friendly EJB's are boxed as valuetypes. Is it
            > possible to enforce JBoss/JacORB to use
            > non-valuetyped binarystreams to communicate with
            > clients?

            No, as valuetype boxing is standardized behavior. The Java to IDL mapping specification defines that an IDL struct (or sequence) is mapped to a valuebox containing the IDL struct (or sequence).

            The rationale for valuetype boxing is preserving the semantics of null parameters. Suppose that Foo is an IDL struct, and consider an IDL operation that takes a Foo parameter:

            void myOperation(in Foo foo); // IDL

            This operation must receive a Foo instance! CORBA/IDL semantics disallow you to pass some sort of null value instead of a Foo. In Java, if you try to pass the null reference when you invoke myOperation on a CORBA stub, you will get a client-side exception from the stub.

            By contrast, consider a similar thing in Java. The following
            method could appear in a Remote interface:

            void myJavaOperation(Foo foo) throws RemoteException;

            Here Foo is the Java class generated (by an IDL to Java translator) from the IDL struc Foo. The point to be noted is that that RMI semantics allow you to pass null to myJavaOperation.
            So what would be the (reverse) mapping of myJavaOperation to IDL? I cannot be

            void myJavaOperation(in Foo foo); // IDL

            because this would rule out null as a valid paramete value.
            The OMG-defined mapping is

            void myJavaOperation(in ValueboxedFoo foo); // IDL

            where ValueboxedFoo is a valuebox that contains a (possibly null) Foo instance. This standard mapping thus preserves the semantics of null parameters, at the expense of valueboxing complexity.

            For a very good discussion of the forces that drove the Java to IDL mapping specification to its current state, see

            http://www.iona.com/whitepapers/CORBA-EJB-Interoperability-WP-V00-02.pdf

            Cheers,

            Francisco

            • 3. Re: CORBA 2.0 friendly EJB
              Francisco Reverbel Novice

              > I managed to access an EJB with an CORBA 2.0 client
              > successfully. I re-defined the IDL file for the
              > client to marshall and demarshall the additional
              > valuetype information.

              There is no point in doing this. Just use IDL file that the rmic utility ("rmic -idl -noValueMethods") generates from the EJB interfaces and deal with the valueboxes that appear there. Dealing with these valueboxes might be a bit unpleasant, but is is better than twisting the actual IDL definitions.

              In case you're doing the CORBA client in Java: Use idlj to translate to Java the IDL files with rmic-generated valuebox definitions, as JacORB's IDL compiler does not handle the "#pragma ID" directives these definitions contain. After you've generated your client-side stubs with idlj, you can (and should!) use jacorb.jar at runtime. The idlj-generated valuebox code and the JacORB library will work together with no problems.

              Cheers,

              Francisco

              • 4. Re: CORBA 2.0 friendly EJB
                flitzie Newbie

                Hi Reverbel

                great thanks for your report about valuetypes and boxes, but this won't help me because I have a dynamic perl client and its orb doesn't support valuetypes. That's why I am looking for a solution accessing the EJB with the perl client. Due to the fact that you cannot create an CORBA-friendly EJB without valuetypes, the client has to marshall and demarshall the information transferd in a valuetyped binarystream. So I redefined the idls. But now I want to understand the meaning of additional information send in the binarystream during the orb communication. I want to find out chances and risks of this "workaround" for a product system.

                TIA

                flitzie