|
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
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:
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:
|
|
The following |
<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 |
<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:
For RMI/IIOP clients you will probably want a client-side |
java.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory
java.naming.provider.url=corbaloc::server.host.name:3528/JBoss/Naming/root
|
This |
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 If you look at the source code for the IIOP testcases, you will notice that they do not have a For examples of EJB clients written in C++, check out MICO, a free C++ ORB. Within the MICO distribution, the subdirectory |
Authors
|