| Sun ONE Application Server 7 Developer's Guide to Clients |
Chapter 3
Java-based CORBA ClientsThis chapter describes how to develop and deploy CORBA clients that use RMI/IIOP protocol.
This chapter contains the following sections:
CORBA Client ScenariosThe most common scenarios in which CORBA clients are used are when either a stand-alone program or another application server acts as a client to EJBs deployed to Sun ONE Application Server. This section describes the following scenarios:
Stand-alone Scenario
In the simplest case, a stand-alone program which does not use the ACC, running on a variety of operating systems uses IIOP to access business logic housed in backend EJB components, as shown in the figure "Stand-alone Client Accessing the EJB Components".
Figure 3-1 Stand-alone Client Accessing the EJB Components
Server to Server Scenario
CORBA objects, and other application servers can use IIOP to access EJB components housed in Sun ONE Application Server, as shown in the figure "Application Server and CORBA Objects Accessing EJB Components".
Figure 3-2 Application Server and CORBA Objects Accessing EJB Components
ORB Support Architecture
CORBA client support in Sun ONE Application Server involves the communication between the ORB on the client and the ORB on the server, as shown in the figure "ORB Support Architecture".
Figure 3-3 ORB Support Architecture
You can use the ORB that is bundled as part of the Sun ONE Application Server, or you can use a third-party ORB (ORBIX 2000 or ORBacus 4.1).
Developing Java-based CORBA ClientsThis section describes the procedure to create, assemble, and deploy a Java-based CORBA client that is not packaged using the ACC. This section describes the following topics:
Creating a Stand-alone CORBA Client
Clients do not directly access the EJB components. Instead, clients communicate with the EJB components using the JNDI to locate EJB components’s home interface. Clients invoke a method on the EJB component’s home interface to get a reference to the EJB components’s home interface.
One of the first steps in coding a CORBA client using RMI/IIOP is, to perform a lookup of an EJB components’s home interface. In preparation for performing a JNDI lookup of the home interface, you must first set several environment properties for the InitialContext. Then you provide a lookup name for the EJB component.
The steps and an example are summarized in the following sections.
Specifying the Naming Factory Class
According to the RMI/IIOP specification, the client must specify com.sun.jndi.cosnaming.CNCtxFactory as the value of the java.naming.factory.initial entry in an instance of a Properties object. This object is then passed to the JNDI InitialContext constructor prior to looking up an EJB component’s home interface. For example:
...
Properties env = new Properties();
env.put("java.naming.factory.initial","com.sun.jndi.cosnaming.CN CtxFactory");
env.put("java.naming.provider.url", "iiop://" + host +":"+port);
Context initial = new InitialContext(env);
Object objref = initial.lookup("rmiconverter");...
Specifying the JNDI Name of an EJB
After creating a new JNDI InitialContext object, your client calls the lookup method on the InitialContext to locate EJB component’s home interface. The name of the EJB components is provided on the call to lookup. When using RMI/IIOP to access remote EJB components, the parameter is referred to as the “JNDI name” of the EJB component. The supported values of the JNDI name vary, depending on how your client application is packaged.
When the client application is not packaged as part of an Application Client Container (ACC), you must specify the absolute name of the EJB component in the JNDI lookup. You must use the prefix java:comp/env/ejb/ when performing lookups using absolute references. For example, the lookup in the rmiconverter sample could be written as follows:
initial.lookup("java:comp/env/ejb/rmiconverter");
Or, with a module name, it could be written as follows:
initial.lookup("java:comp/env/ejb/rmiconverterEjb/ rmiconverter");
There is no mechanical difference between supplying this prefix and the first two approaches. You might find the java:comp/env/ejb/ confusing when used in conjunction with absolute EJB references because this notation is typically used when you are using indirect EJB references.
Note
Sun ONE Application Server does not support the authentication of Java-based stand-alone CORBA clients.
Sun ONE ORB Configuration
If you are using built-in Sun ONE ORB, you can configure client-side load balancing using the Round Robin DNS approach.
To implement a simple load balancing scheme without making source code changes to your client, you can leverage the round robin feature of DNS. In this approach, you define a single virtual host name representing multiple physical IP addresses on which server instance ORBs are listening. Assuming that you configure all of the ORBs to listen on a common IIOP port number, the client applications can use a single host_name: IIOP port during the JNDI lookup. The DNS server resolves the host name to a different IP address each time the client is executed.
You can also implement client-side load balancing using the Sun ONE Application Server-specific naming factory class SIASCtxFactory. You can use this class both on the client-side and on the server-side which maintains a pool of ORB instances in order to limit the number of ORB instances that are created in a given process.
The following code illustrates the use of S1ASCtxFactory class:
Properties env = new Properties();
env.setProperty("java.naming.factory.initial","com.sun.appserv.nami ng.S1ASCtxFactory");
env.setProperty("org.omg.CORBA.ORBInitialHost", “name service hostname");
env.setProperty("org.omg.CORBA.ORBInitialPort", "“name service port number"");
InitialContext ic = new InitialContext(env);
If you set a single URL property for the host and port above, your code would look like this:
Properties env = new Properties();
env.setProperty("java.naming.factory.initial", "com.sun.appserv.naming.S1ASCtxFactory");
env.setProperty("java.naming.provider.url", "iiop://“name service hostname:name service port number");
InitialContext ic = new InitialContext(env);
If you prefer, you may set the host and port values and the URL value as Java System properties, instead of setting them in the environment as shown in the above code illustration. The values set in your code will, however, override any System property settings. Also, if you set both the URL and the host and port properties, the URL takes precedence.
Note that the [name service hostname] value mentioned above could be a name that maps to multiple IP addresses. The S1ASCtxFactory will appropriately round robin ORB instances across all the IP addresses everytime a user calls new InitialContext() method.
You can also use the following property of S1ASCtxFactory class to implement client-side load balancing:
com.sun.appserv.iiop.loadbalancingpolicy=roundrobin,host1:port1,host2:port2,...,
This property provides you with a list of host:port combinations to round robin the ORBs. These host names may also map to multiple IP addresses. If you use this property along with org.omg.CORBA.ORBInitialHost and org.omg.CORBA.ORBInitialPort as system properties, the round robin algorithm will round robin across all the values provided. If, however, you provide a host name and port number in your code, in the environment object, that value will override any such system property settings.
Running a Stand-alone CORBA Client
As long as the client environment is set appropriately and you are using a compatible JVM, you merely need to run the main class. Depending on whether you are passing the IIOP URL components (host and port number) on the command line or obtaining this information from a properties file, the exact manner in which you run the main program will vary. For example, the rmiconverter sample is run in the following manner:
java rmiconverter.ConverterClient host_name port
The host_name is the name of the host on which an ORB is listening on the specified port.
Third Party ORB SupportSun ONE provides a built-in ORB to support IIOP access to the EJBs. You can also install and configure a third party ORB to use IIOP with Sun ONE Application Server.
For information on Configuring built-in ORB for supporting CORBA clients, see the Sun ONE Application Server Administrator’s Guide.
This section discusses the following scenarios:
Accessing EJBs in a Remote Application Server Instance From a Servlet/Enterprise JavaBean
Sun ONE Application Server supports accessing the EJBs residing in another instance of the server via RMI/IIOP. This section describes the procedure to create a client application that accesses the EJB components residing in another instance of the application server.
Clients do not directly access the EJB components. Instead, clients communicate with the EJB components using the JNDI to locate EJB component’s home interface. Clients invoke a method on the EJBs’s home interface to get a reference to the EJB component’s home interface.
One of the first steps in coding a client using RMI/IIOP is, to perform a lookup of an EJB component’s home interface. In preparation for performing a JNDI lookup of the home interface, you must first set several environment properties for the InitialContext. Then you provide a lookup name for the EJB.
The steps and an example are summarized in the following sections.
Specifying the Naming Factory Class
According to the RMI/IIOP specification, the client must specify com.sun.jndi.cosnaming.CNCtxFactory as the value of the java.naming.factory.initial entry in an instance of a Properties object. This object is then passed to the JNDI InitialContext constructor prior to looking up an EJB component’s home interface. For example:
...
Properties env = new Properties();
env.put("java.naming.factory.initial","com.sun.jndi.cosnaming.CN CtxFactory");
env.put("java.naming.provider.url", "iiop://" + host +":"+port);
Context initial = new InitialContext(env);
System.out.println("Inside other host after initialcontext");
Object objref = initial.lookup("MyConverter");...
The above code line is part of the EJB business method.
Specifying the JNDI Name of an EJB
After creating a new JNDI InitialContext object, your client calls the lookup method on the InitialContext to locate the EJB component’s home interface. The name of the EJB is provided on the call to lookup. When using RMI/IIOP to access remote EJBs, the parameter is referred to as the “JNDI name” of the EJB.
initial.lookup("ejb/ejb-name");
initial.lookup("ejb/module-name/ejb-name");
The ejb-name is the name of the EJB as it appears in the <ejb-name> element of the EJB’s deployment descriptor. For example, here is a lookup using the value Myconverter:
initial.lookup("MyConverter");
ConverterHome home = (ConverterHome)PortableRemoteObject.narrow(objref,ConverterHome.cla ss);
Converter currencyConverter = home.create();
System.out.println("Inside other host after Create");
Configuring Back End Access Using Third Party Client ORBs Within Sun ONE Application Server
J2EE components (such as Servlet and EJBs) deployed to Sun ONE Application Server can access backend CORBA objects through third party Object Request Brokers (ORBs). This support enables J2EE applications to leverage investments in the existing CORBA-based business components. In addition to supporting server side access to backend CORBA objects, you can also use the built-in Sun ONE ORB for RMI/IIOP-based access to EJB components from Java or C++ application clients as explained in the RMI/IIOP samples.
Configuring Orbix ORB with Sun ONE Application Server involves the following steps:
Installing Orbix
To install Orbix, perform the following steps:
Configuring Sun ONE Application Server to Use Orbix
You must configure the runtime environment to enable the application server to load the Orbix ORB classes. Add the following to the CLASSPATH:
Go to Application Server Instances -> server1 (or any other instance) then click on Java Options and append the following:
classpath to Class Path Suffix text field under Directory Paths option
/etc/opt/iona/:/opt/iona/orbix_art/1.2/classes/orbix2000.jar:/opt/iona/orbix_art/1.2/classes/omg.jar
After modifying Class Path Suffix click Save then click on server1 (server instance) and click on Apply Changes tab, restart the application server instance to update the changes.
Overriding the Built-in ORB
Sun ONE Application Server relies on a built-in ORB to support RMI/IIOP access to EJB components from Java application clients. When implementing servlets and EJB components that access backend CORBA-based applications residing outside of the application server, you may need to override the built-in ORB classes with the ORB classes from third party products such as Orbix 2000.
You can use any of the following approaches to override the built-in ORB classes with ORB classes from third party products:
ORB.init() Properties Approach
The code illustration given below overrides the built-in Sun ONE ORB classes with ORB classes from IONA’s ORBIX 2000.
For example:
...
Properties orbProperties = new Properties();
orbProperties.put("org.omg.CORBA.ORBClass","com.iona.corba.art.arti mpl.ORBImpl");
orbProperties.put("org.omg.CORBA.ORBSingletonClass","com.iona.corba .art.artimpl.ORBSingleton");
orb = ORB.init(args, orbProperties);
...
The advantage of this approach is that RMI/IIOP access to EJB components housed in the application server will still be performed using the built-in Sun ONE ORB classes while only access from servlets and EJB components to backend CORBA-based applications will use the third party ORB classes. This is the efficient method of supporting simultaneous use of multiple ORBs in the application server environment.
orb.properties Approach
In Java 2 1.2.1 environment, the JVM’s orb.properties file contains property settings to identify the ORB implementation classes that are used by default throughout the JVM. To override the use of the built-in Sun ONE ORB classes, you can simply modify the orb.properties file to specify third party ORB classes and restart the application server.
For example, to set the implementation classes to specify the Orbix 2000 classes, make the following modification to the orb.properties file that is located at: install_dir/jdk/jre/lib/
Before:
org.omg.CORBA.ORBClass=com.sun.corba.se.internal.Interceptors.PIOR
org.omg.CORBA.ORBSingletonClass=com.sun.corba.se.internal.corba.ORBSingleton
After:
org.omg.CORBA.ORBClass=com.iona.corba.art.artimpl.ORBImpl
org.omg.CORBA.ORBSingletonClass=com.iona.corba.art.artimpl.
ORBSingletonThe javax.rmi classes are used to support RMI/IIOP client access to EJB components housed in the application server. Since these classes are not used to access backend CORBA servers, you do not need to override these settings.
The main advantage of this approach is that it involves only one time setting for all applications deployed to the application server. There is no need for each servlet and/or EJB component that is acting as a client to a backend CORBA application to specify the ORB implementation classes.
Providing JVM Start-up Arguments
You can also specify the ORB implementation classes as server’s JVM_ARGS in the server.xml file.
Go to the
instances_dir/config
and edit the server.xml file and add these jvm options as a subelement under <java-config> tag.
<jvm-options>
-Dorg.omg.CORBA.ORBClass=com.iona.corba.art.artimpl.ORBImpl
</jvm-options>
<jvm-options>
-Dorg.omg.CORBA.ORBSingletonClass=com.iona.corba.art.artimpl.
ORBSingleton</jvm-options>
This approach gives the benefit of specifying the ORB implementation classes only once, but the main advantage when compared to changing the orb.properties file is that, the changes made to server’s configuration file are specific to server instance and are applicable to all the applications running on a particular instance only.
You can find a sample that demonstrates the third-party ORB support in Sun ONE Application Server at the following location:
install_dir/samples/corba/
