Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Application Server 7 2004Q2 Developer's Guide to Clients 

Chapter 4
Java-based CORBA Clients

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

This chapter contains the following sections:

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

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 4-1  Stand-alone Client Accessing the EJB Components

Figure shows how a Java-based CORBA client uses RMI/IIOP to access the EJBs residing inside the application server.

Server to Server Scenario

CORBA objects, and other application servers can use IIOP to access EJB components housed in Application Server, as shown in the figure Application Server and CORBA Objects Accessing EJB Components.

Figure 4-2  Application Server and CORBA Objects Accessing EJB Components

Figure shows how the application server objects and CORBA objects uses RMI/IIOP to access the EJBs residing inside Sun ONE Application Server.

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.

Figure 4-3  ORB Support Architecture

Figure shows how the client-side ORB communicates with the ORB on the server side using RMI/IIOP.

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

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.

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.CNCtxFact ory");

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

initial.lookup("rmiconverter");

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

Note

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

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.

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:

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.

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.

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:

  1. Set the following JVM properties to configure the ORB.

    2. com.sun.CORBA.connection.ORBSocketFactoryClass=com.sun.appserv.ee.iiop. EEIIOPSocketFactory

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

    org.omg.CORBA.ORBClass=com.sun.enterprise.iiop.POAEJBORB

    org.omg.CORBA.ORBSingletonClass=com.sun.corba.ee.internal.corba.ORBSing leton

    javax.rmi.CORBA.UtilClass=com.sun.corba.ee.internal.POA.ShutdownUtilDel egate

  2. Set the classpath to appserv-rt.jar and appserv-rt-ee.jar. These jar files are located in the install_dir/lib directory.
  3. Use the following property of S1ASCtxFactory class, prior to the instantiation of the InitialContext:

    4. 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:

-D<Propertyname>=<Propertyvalue>

The Java command will look something like the following command:

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.

The following code illustrates the use of S1ASCtxFactory class:

Properties env = new Properties();

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

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.

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 Support

Sun Java System 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 Application Server.

For information on Configuring built-in ORB for supporting CORBA clients, see the Sun Java System Application Server Administration Guide.

This section discusses the following scenarios:

Accessing EJBs in a Remote Application Server Instance From a Servlet/Enterprise JavaBean

Sun Java System 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.CNCtxFact ory");

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 JNDI 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. You can find the exact JNDI name of the bean by looking at the sun-ejb-jar.xml deployment descriptor of the EJB. The JNDI name of the bean is represented by the <jndi-name> element under the <ejb> element.

initial.lookup("ejb/jndi-name"); initial.lookup("ejb/module-name/jndi-name");

For example, here is a lookup using the value rmiConverter:

initial.lookup("rmiConverter");

ConverterHome home = (ConverterHome)PortableRemoteObject.narrow(objref,ConverterHome.class);

Converter currencyConverter = home.create();

System.out.println("Inside other host after Create");

Configuring Back End Access Using Third Party Client ORBs Within Sun Java System Application Server

J2EE components (such as Servlet and EJBs) deployed to Sun Java System 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’s 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 Java System Application Server involves the following steps:

Installing Orbix

To install Orbix, perform the following steps:

Configuring Sun Java System 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 Java System 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 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.artimpl.ORB Impl");

orbProperties.put("org.omg.CORBA.ORBSingletonClass","com.iona.corba.art.ar timpl.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 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 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.
ORBSingleton

The 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 Java System Application Server at the following location:

install_dir/samples/corba/



Previous      Contents      Index      Next     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.