Client-side programming tips for the Java Object Request Broker service
This article includes programming tips for applications that communicate with the client-side Object Request Broker that is part of the Java ORB service.
Resolution of initial references to services
Client applications can use the properties ORBInitRef and ORBDefaultInitRef to configure the network location that the Java ORB service uses to find a service such as naming. Once set, these properties are included in the parameters used to initialize the ORB, as follows:
org.omg.CORBA.ORB.init(java.lang.String[] args, java.util.Properties props)One can set these properties in client code or by command-line argument. It is possible to specify more than one service location by using multiple ORBInitRef property settings (one for each service), but only a single value for ORBDefaultInitRef may be specified.
For setting in client code, these properties are com.ibm.CORBA.ORBInitRef.service_name and com.ibm.CORBA.ORBDefaultInitRef, respectively. For example, to specify that the naming service (NameService) is located in sample.server.com at port 2809, set the com.ibm.CORBA.ORBInitRef.NameService property to corbaloc::sample.server.com:2809/NameService .
For setting by command-line argument, these properties are -ORBInitRef and -ORBDefaultInitRef , respectively. To locate the same naming service specified previously, use the following Java command (split here for publication only):
java program -ORBInitRef NameService=corbaloc::sample.server.com:2809/NameServiceAfter these properties have been set for services supported by the ORB, J2EE applications obtain the initial reference to a given service by calling the resolve_initial_references function on the ORB as defined in the CORBA/IIOP specification.
Preferred API for obtaining an ORB instance
For J2EE applications, you can use either of the following approaches. However, it is strongly recommended that you use the JNDI approach to ensure that the same ORB instance is used throughout the client application; you will avoid the unintended inconsistencies that might occur when different ORB instances are used.
JNDI approach: For J2EE applications (including enterprise beans, J2EE clients and servlets), you can obtain an ORB instance by creating a JNDI InitialContext object and looking up the ORB under the name java:comp/ORB , as follows:
javax.naming.Context ctx = new javax.naming.InitialContext(); org.omg.CORBA.ORB orb = (org.omg.CORBA.ORB)javax.rmi.PortableRemoteObject.narrow(ctx.lookup("java:comp/ORB"), org.omg.CORBA.ORB.class);The ORB instance obtained using JNDI is a singleton object, shared by all J2EE components running in the same Java Virtual Machine process.
CORBA approach: Because thin-client applications do not run in a J2EE container, they cannot use JNDI interfaces to look up the ORB. In this case, you can obtain an ORB instance by using CORBA programming interfaces, as follows:
java.util.Properties props = new java.util.Properties(); java.lang.String[] args = new java.lang.String[0]; org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, props);In contrast to the JNDI approach, the CORBA specification requires that a new ORB instance be created each time the ORB.init method is called. If necessary to change the ORB's default settings, you can add ORB property settings to the Properties object that is passed in the ORB.init() call.
The use of com.ibm.ejs.oa.EJSORB.getORBinstance(), supported in previous releases of this product, has been deprecated.
API restrictions with sharing an ORB instance among J2EE application components
For performance reasons, it often makes sense to share a single ORB instance among components in a J2EE application. As required by the J2EE Specification, Version 1.3, all web and EJB containers provide an ORB instance in the JNDI namespace as java:comp/ORB . Each container can share this instance among application components but is not required to. For proper isolation between application components, application code must comply with the following restrictions:
- Do not call the ORB shutdown method
- Do not call org.omg.CORBA_2_3.ORB methods register_value_factory or unregister_value_factory
In addition, an ORB instance should not be shared among application components in different J2EE applications.
Required use of rmic and idlj shipped with the IBM Developer Kit
The Java Runtime Environment (JRE) used by this product includes the tools rmic and idlj. You use the tools to generate Java language bindings for the CORBA/IIOP protocol.
During product installation, the tools are installed in...
/opt/WebSphere/AppServer/java/ibm_binVersions of these tools included with Java development kits in $JAVA_HOME/bin other than the IBM Developer Kit installed with this product are incompatible with this product.
When you install this product, the directory
/opt/WebSphere/AppServer/java/ibm_binis included in the $PATH search order to enable use of the rmic and idlj scripts provided by IBM. Because the scripts are in...
/opt/WebSphere/AppServer/java/ibm_bin...instead of the JRE standard location.../opt/WebSphere/AppServer/java/bin...it is unlikely that you will overwrite them when applying maintenance to a JRE not provided by IBM.In addition to the rmic and idlj tools, the JRE also includes Interface Definition Language (IDL) files. The files are based on those defined by the Object Management Group (OMG) and can be used by applications that need an IDL definition of selected ORB interfaces. The files are placed in...
/opt/WebSphere/AppServer/java/ibm_libBefore using either the rmic or idlj tool, ensure that...
/opt/WebSphere/AppServer/java/ibm_bin...is included in the proper PATH variable search order in the environment. If your application will use IDL files in.../opt/WebSphere/AppServer/java/ibm_libAlso ensure that the directory is included in the PATH variable.
Object Request Brokers: Links
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.