jboss.org: community driven

JBoss IIOP

JBoss IIOP supports CORBA/IIOP access to enterprise beans deployed in a JBoss Application Server, as defined by the EJB specification. It makes enterprise bean methods available to both

RMI/IIOP clients written in Java and
CORBA clients written in Java, C++, or other languages.

While the JBoss IIOP module effectively turns JBoss Application Server into a CORBA server, it does so the in the JBoss way: the result is a CORBA server easy to use, easy to set up, and developer-friendly. No IDL compiler, no additional steps to generate Java skeletons and stubs... Everything is done automagically, in the best JBoss tradition. Just drop your enterprise beans in the deploy directory and there you go!

Features

Full CORBA compliance is achieved by the use of a third-party IIOP engine, which must be a Java ORB compliant with the CORBA 2.3 specification. This engine is pluggable and may be replaced by expert users.
JacORB, a free Java implementation of the CORBA standard, is the default IIOP engine that comes bundled with the JBoss IIOP distribution.
JBoss IIOP automatically generates IIOP stubs at bean deployment time.
Java clients can download IIOP stubs from the JBoss server. Dynamic stub downloading is transparent to the client code. It relies on codebase information embedded into the object references handed out by JBoss IIOP.
JBoss IIOP includes a CORBA naming server that runs in the same VM as the JBoss server. EJB homes are registered with this naming server.
An in-VM CORBA interface repository is activated for each IIOP-enabled EJB deployed in JBoss. The interface repository of an enterprise bean handles _get_interface_def invocations on the bean home and on its instances.

Quick start guide

To build and run JBoss IIOP:

Check out jboss-3.2 from the CVS repository.
Perform a default build:
```
        build/build.sh
        
```
JBoss IIOP is built as part of the default build process.

Build the testsuite:

        build/build.sh -Dmodules=testsuite

Use a run script (run.sh or run.bat) to start the JBoss server:
```
        build/output/jboss-3.2.2RC3/bin/run.sh -c all
        
```
(The "-c all" switch tells the run script to use the configuration "all", which includes the IIOP module.)
To run all the IIOP stress testcases, say
```
        testsuite/build.sh -Dnojars=true tests-iiop-stress
        
```
(The nojars switch is just to avoid rebuilding the test jars again and again.)
Currently there are four IIOP testcases:
- helloiiop, a simple stateless session bean (HelloWord);
- bankiiop, the IIOP version of the JBoss "bank test", which includes two entity beans (Customer and Account) and two session beans (Bank and Teller);
- hellojrmpiiop, a version of the HelloWorld session bean that is simultaneously accessible to JRMP clients and to IIOP clients (multiple protocols per EJB is a new feature of JBoss 3.2.);
- excepiiop, which tests propagation of Java exceptions and IDL exceptions over IIOP.
You can run a specific IIOP testcase (helloiiop, for example) by saying
```
        testsuite/build.sh -Dtest=helloiiop -Dnojars=true iiop-test
        
```

To specify that an EJB should support IIOP invocations, you overide the default invoker in a standard container configuration. The following container configurations can be used with the IIOP invoker:

Standard CMP 2.x EntityBean
Standard CMP EntityBean
Standard Stateless SessionBean
Standard Stateful SessionBean
Standard BMP EntityBean

The following jboss.xml file specifies that a stateless session bean should take IIOP invocations:

   <jboss>
      <enterprise-beans>
         <session>
            <ejb-name>HelloWorld</ejb-name>
            <jndi-name>helloworld/Hello</jndi-name>
            <configuration-name>Standard Stateless SessionBean</configuration-name>
            <invoker-bindings>
               <invoker>
                  <invoker-proxy-binding-name>iiop</invoker-proxy-binding-name>
               </invoker>
            </invoker-bindings>
         </session>
      </enterprise-beans>
   </jboss>

The example above was taken from the helloiiop testcase. It uses the Standard Stateless SessionBean configuration and replaces this configurations's default invoker (which uses JRMP) by the IIOP invoker. The next example is a jboss.xml file taken from the hellojrmpiiop testcase:

   <jboss>
      <enterprise-beans>
         <session>
            <ejb-name>HelloWorld</ejb-name>
            <jndi-name>helloworld/Hello</jndi-name>
            <configuration-name>Standard Stateless SessionBean</configuration-name>
            <invoker-bindings>
               <invoker>
                  <invoker-proxy-binding-name>stateless-rmi-invoker</invoker-proxy-binding-name>
               </invoker>
               <invoker>
                  <invoker-proxy-binding-name>iiop</invoker-proxy-binding-name>
               </invoker>
            </invoker-bindings>
         </session>
      </enterprise-beans>
   </jboss>

Now the default invoker of the standard configuration is replaced by a pair of invokers: stateless-rmi-invoker, which is the default invoker for stateless session beans and uses JRMP, and the iiop invoker. In this example the session bean is simultaneously accessible via JRMP and via IIOP:

For RMI/IIOP clients you will probably want a client-side jndi.properties file that makes EJB homes to be looked up in the CORBA naming context. If you are using JDK 1.4 or newer, your client-side jndi.properties file should look like this:

    java.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory
    java.naming.provider.url=corbaloc::server.host.name:3528/JBoss/Naming/root

This jndi.properties does not work with JDK 1.3.x, whose CosNaming JNDI provider does not take 'corbaloc' URLs. If you are using JDK 1.3.x, you must specify the root naming context with an IOR:


    java.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory
    java.naming.provider.url=IOR:...some_long_string_of_hex_digits...

In the JDK 1.3.x case the naming provider URL must be set to the IOR of the CORBA naming service, which is printed out by the JBoss server at boot time. (This also works for more recent JDK versions, but these support 'corbaloc' URLs, which are much more convenient.)

Plain CORBA clients (not RMI/IIOP ones) can just use the naming service IOR (or its 'corbaloc' URL) as their initial CosNaming context.

If you look at the source code for the IIOP testcases, you will notice that they do not have a jndi.properties file as indicated above. The reason is that they are not "pure RMI/IIOP" clients. Rather than using the CORBA naming service, they use JRMP to get an EJB home IOR from the JBoss JRMP naming provider. When they use this IOR they start to talk IIOP.

For examples of EJB clients written in C++, check out MICO, a free C++ ORB. Within the MICO distribution, the subdirectory doc/mico/examples/interop/jboss contains C++ clients that access enterprise beans deployed in JBoss.

Authors

Ole Husgaard implemented the mapping from RMI types to IIOP types and the JBoss IIOP interface repository.
Francisco Reverbel wrote the IIOP container invoker and implemented the support for dynamic generation and downloading of IIOP stubs. He currently leads the JBoss IIOP project.