- 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
_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
orrun.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
(Thenojars
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
andAccount
) and two session beans (Bank
andTeller
);hellojrmpiiop
, a version of theHelloWorld
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.
helloiiop
, for example) by sayingtestsuite/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.