Chapter 4 Java-based CORBA Clients

This chapter describes how to develop and deploy CORBA clients that use RMI/IIOP protocol.

Developing non-ACC Java-based CORBA Clients

CORBA Client Scenarios

The 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 Application Server. This section describes the following scenarios:

Stand-alone Scenario

Server to Server Scenario

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.

Server to Server Scenario

ORB Support Architecture

CORBA client support in 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.

You can use the ORB that is bundled as part of the Application Server, or you can use a third-party ORB (ORBIX 2000 or ORBacus 4.1).

Developing non-ACC Java-based CORBA Clients

This 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

Running a Stand-alone CORBA Client

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 remote home interface to get a reference to EJB components remote 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.

Specifying the Naming Factory Class

Specifying the JNDI Name of an EJB

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.

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 JNDI name of the bean in the JNDI lookup. For example, the lookup in the rmiconverter sample could be written as follows:

The” jndiname” can be found in the sun-ejb-jar.xml file under the <ejb> element identified by the element <jndi-name>.

Implementing Load Balancing and Failover Capabilities in the Client Application (Enterprise Edition)

Sun Java Systems Application Server, Enterprise Edition supports the load balancing and failover of IIOP requests from stand-alone and ACC clients, thus providing high availability of J2EE application on the RMI/IIOP path.


Note	Sun Java System Application Server does not support authentication of Java-based stand-alone CORBA clients.

In order to enable failover of IIOP requests, IIOP endpoints that constitute the cluster in Sun Java System Application Server must be defined either using the Administration Console or using the command line interface. The IIOP endpoints definitions will be stored in the server.xml file. For more information, see the Sun Java System Application Server Administration Guide or refer to Admin Console online help.

The failover of J2EE applications happen only for those requests that cannot reach the server and cause a CORBA COMM_FAILURE exception with a return status of COMPLETED_NO on the client. When the server becomes inaccessible, the client side application server ORB will failover the request to another accessible iiop endpoint of the iiop cluster. When failing over the request, ORB randomly selects alternate accessible iiop endpoint of the cluster.

See the Sun Java System Application Server Administration Guide for more information on configuring an iiop cluster.

The properties to be set in order to enable load balancing and failover features in your stand-alone clients are:

java.naming.factory.initial

This property is used in specifying the Context Factory that should be used for load balancing the IIOP requests, Set the property to com.sun.appserv.naming.S1ASCtxFactory.

com.sun.appserv.iiop.endpoints

This property specifies the list of IIOP endpoints defined in the server.xml. An IIOP endpoint is specified as host:port where host is the host name or the IP address of the system where Sun Java System Application Server is running and port is the IIOP port number at which the server is listening for the IIOP requests.

com.sun.appserv.iiop.loadbalancingpolicy

If the endpoint property is specified, the, this property is used to specify the load balancing policy. The value for this property must be InitialContext-based load balancing policy. The value used to define this property is ic-based.

In order to implement load balancing capabilities in your client code perform the following steps:

Set the following JVM property to configure the ORB.

com.sun.CORBA.connection.ORBSocketFactoryClass=com.sun.appserv.enterpri se.iiop.EEIIOPSocketFactory

org.omg.PortableInterceptor.ORBInitializerClass=com.sun.appserv.ee.iiop .EEORBInitializer

Set the classpath to appserv-rt.jar and appserv-rt-ee.jar. These jar files are located in the install_dir/lib directory.

Use the following property of S1ASCtxFactory class, prior to the instantiation of the InitialContext:

Properties env = new Properties();

env.put(“java.naming.factory.initial”, “com.sun.appserv.naming.S1ASCtxFactory”);

env.put(“com.sun.appserv.iiop.endpoints”,”trident:3600, exodus:3700”);

env.put(“com.sun.iiop.loadbalancingpolicy”, “ic-based”);

//create an initial naming context
Context initial = new InitialContext(env);

This client code instantiates the JNDI InitialContext Object by calling the new InitialContext(env), where env is the list of JNDI SPI properties.

You can also set the stand-alone client load balancing properties as JVM start-up arguments. The properties are set using the following command syntax:

java -Dpropname1=value1 -Dpropname2=value2 <other vm options> classname program-arguments

Sun Java System ORB Configuration

Sun Java System Application Server continues to supports the following load balancing implementation used in Sun ONE Application Server 7.

If you are using built-in Sun 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 Java System 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.

env.setProperty("java.naming.factory.initial","com.sun.appserv.naming.S 1ASCtxFactory");

If you set a single URL property for the host and port above, your code would look like this:

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");

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.

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:

The host_name is the name of the host on which an ORB is listening on the specified port.

Previous Contents Index Next
Sun Java System Application Server 7 2004Q2 Update 1 Developer's Guide to Clients