Accessing a Session Bean from CORBA and RMI Clients

Different technologies exist today that provide distributed computing for enterprise applications. Of them, Remote Method Invocation (RMI), Internet Inter-ORB Protocol (IIOP), and the Component Object Model/Distributed Component Model (COM/DCOM) are frequently used in applications. EJB is not a distributed computing technology but a distributed computing architecture. The underlying distributed computing technology that EJB 2.0 specifies is RMI over IIOP. Why is there a combination of two technologies instead of just one? To understand the reason behind this, you need to see how distributed computing technologies have evolved in Java.

The first support for writing distributed applications was provided in the Java language using RMI. RMI provides developers with the ability to write object-oriented client-server applications that communicate seamlessly over a network. The downside is that RMI supports writing client and server distributed applications using Java as the only development language. RMI internally uses the Java Remote Method Protocol (JRMP) for performing the underlying interprocess socket communication. WebLogic provides its own implementation of the RMI protocol, called the t3 protocol. Server objects as well as client applications connect to WebLogic Server's naming service using the t3 protocol via the JNDI API. Hence in the URL used to connect to the naming service, the t3 protocol is used. An example of this is

 Hashtable env = new Hashtable();  env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY); env.put(Context.PROVIDER_URL, "t3://localhost:7001"); InitialContext = new InitialContext(env); 

The next phase was the emergence of the Common Object Request Broker Architecture (CORBA) as a popular mechanism for developing distributed applications. CORBA raised the bar in the distributed computing world by enabling client-server applications of different languages to communicate with each other. This meant that now a Java application could interact with and use a C++ server application program, with both the applications communicating using CORBA. But CORBA is an architecture and not a technology. The underlying technology is IIOP, which enables the communication between the client and server applications. The downside of writing CORBA server applications is the enormous complexity involved in developing distributed, transaction-aware server applications.

Finally, EJB architecture emerged as a viable alternative for writing component-based, distributed server applications because of the simplicity of writing EJB server applications and components. The application server or the EJB container in which the EJBs are deployed and executed is responsible for the life-cycle and transaction-aware services for the EJB. Considering the need for EJB components to be accessed from applications developed in different languages or using different technologies, the EJB 2.0 specification defines the use of RMI-IIOP protocol for communication between a client application and an EJB server component. The use of RMI-IIOP protocol enables client applications developed in Java that use RMI and client applications developed in Java or C++ that use IIOP (CORBA) to interact and use the services of EJB components developed using the EJB 2.0 specification.

Note

This section assumes that you are familiar with writing client applications in CORBA and CORBA concepts such as IDL, ORB, and so on. If you are not, it is recommended that you read the section on Java IDL in the Java tutorial available at java.sun.com.

Take a look at Figure 11.9 to understand the interaction when a CORBA client accesses a stateless session bean. You will learn how to develop a Java CORBA client application that needs to access an EJB. You will access a stateless session bean because a stateless session bean is the easiest EJB to build and deploy.

Figure 11.9. Block diagram showing the interaction between a CORBA client and a session bean.

Build the EJB

The first step in this will be to develop a stateless session bean, HelloEJB, that provides a method, sayHello(), and returns a string, "Hello user!", to the client application. You will not be writing all the pieces of code for this bean; today's lesson lists only snippets of the relevant code. The following code creates the home and remote interfaces for this stateless bean.

The home interface code is as follows:

 /******************************************************************************    * Class Name   : HelloEJBHome.java   * Description  : Home interface for the HelloEJB                    HelloEJB is a simple SessionBean to say "Hello" to the user.   * @author Mandar S. Chitnis                              .       @version 1.1   * Copyright (c) by Sams Publishing. All Rights Reserved. *******************************************************************************/ package com.sams.learnweblogic7.ejb.stateless; import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.EJBHome; public interface HelloEJBHome extends EJBHome {      HelloEJB create() throws CreateException, RemoteException; } 

Remote Interface:

 /******************************************************************************    * Class Name   : HelloEJB.java   * Description  : Remote interface for the HelloEJB                    HelloEJB is a simple SessionBean to say "Hello" to the user.   * @author Mandar S. Chitnis                              .       @version 1.1   * Copyright (c) by Sams Publishing. All Rights Reserved. *******************************************************************************/ package com.sams.learnweblogic7.ejb.stateless; import java.rmi.* import javax.ejb.*; public interface HelloEJB extends EJBObject() {        public String sayHello() throws RemoteException; } 

The session bean implementation class implements this business method, as can be seen from this code snippet:

 /******************************************************************************     * Class Name   : HelloEJBBean.java   * Description  : Bean class for the HelloEJB                    HelloEJB is a simple SessionBean to say "Hello" to the user.   * @author Mandar S. Chitnis                              .       @version 1.1   * Copyright (c) by Sams Publishing. All Rights Reserved. *******************************************************************************/ package com.sams.learnweblogic7.ejb.stateless; import javax.ejb.*; import javax.naming.*; public final class HelloEJBBean implements SessionBean {    //all the setSessionContext(), ejbActivate(), ejbPassivate() etc    //methods come here ...        public String sayHello()        {               return "Hello User!";        } } 

Generate the IDL Files and Client Stubs

To use the EJB from a CORBA client written in Java or C++, you need to have generated the Interface Definition Language (IDL) file of the stateless session bean. The IDL file is a static ASCII file that contains the description and organization of the services provided by a server, in this case, the EJB stateless session bean. The IDL file will be used to generate the stub Java files for the CORBA client. To generate the IDL files for the stateless session bean, execute the weblogic.ejbc EJB compiler or weblogic.rmic RMI compiler provided with WebLogic Server, using the -idl option.

 java weblogic.ejbc  idl  idlDirectory \beanIDL          com.sams.learnweblogic7.ejb.HelloEJBBean 

For RMI clients, the preceding step is not required because WebLogic Server provides a mechanism to directly generate the client stub Java classes for an RMI client. To generate the client stubs for RMI clients, execute the weblogic.ejbc EJB compiler or the weblogic.rmic RMI compiler provided with WebLogic Server, using the -iiop option.

 java weblogic.rmic  iiop  iiopDirectory /beanStubClasses          com.sams.learnweblogic7.ejb.HelloEJBBean 

Compile and Build the CORBA and RMI Clients

After generating the IDL file for a CORBA client, you need to use the utility provided by the vendor of the ORB that you are using to generate the Java classes (Helper and so on) from the IDL. If you are using the Java IDL of JDK 1.3.1, you can use the idl2java utility to generate the Java classes from the IDLs generated in the \beanIDL directory on your machine, for example:

 idl2java \beanIDL\HellEJBBean.idl  

The IDL files generated using the WebLogic ejbc compiler contain references to the included file orb.idl, which is the IDL file provided by the vendor of the ORB that you use and that contains the mapping of the data types used in IDL and Java.

Now the Java files built after executing the idl2java utility can be compiled with the other Java files of the client application to build the final CORBA client.

The stub classes generated using the -iiop option can be used directly with RMI clients to build the final RMI client.

Accessing the EJB from CORBA and RMI Clients

The final step to be discussed is the way the CORBA and RMI clients look up the naming service to obtain the reference to the home interface of the EJB deployed in WebLogic Server.

CORBA clients need a handle for the naming service of WebLogic Server before they can obtain the home object references of the EJB. To obtain the reference of the naming service of WebLogic Server, you should use the host2ior utility provided with WebLogic Server.

 java utils.host2ior localhost 7001  

Executing the preceding command displays the Interoperable Object Reference (IOR) "stringified" reference (string value) of the naming service object in WebLogic Server, which you can redirect and save to a text file. Programmers familiar with CORBA programming will recall that IOR is akin to a unique serialized value of the naming service object. To construct the naming service from the IOR, you need to invoke the string_to_object() method of the org.omg.CORBA.ORB object. The string_to_object() method takes the IOR string as a parameter and returns the constructed naming service object, which is then typecast to the appropriate type using the narrow() method. A code snippet is given here:

 // initialize ORB  // assign the IOR string to the iorVal variable iorVal = "IORvalue"; org.omg.CORBA.Object cObj = orb.string_to_object(iorVal); org.omg.CosNaming.NamingContext nCtx =         org.omg.CosNaming.NamingContextHelper.narrow(cObj); // create the NameComponent array // now that you have obtained the NamingContext reference, // look up the EJBHome object reference using the // resolve() method of the NamingContext as you normally would 

In RMI client applications, to access the EJBHome object reference, the RMI client initializes an InitialContext object with com.sun.jndi.cosnaming.CNCtxFactory as the name of the naming service to which to connect. A code snippet is given below:

 Hashtable ht = new Hashtable()  h.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory"); h.put(Context.PROVIDER_URL, "iiop://localhost:7001"); InitialContext ctx = new InitialContext(ht); 

The URL to be used to connect to the naming service of WebLogic Server is the iiop service. Once the initial context is created, the RMI client can look up the EJBHome object using the JNDI name used to register the EJB's home interface with the naming service. A code snippet is given here:

 Object objHome = ctx.lookup("HelloEJBHome");  HelloEJBHome helloHome = (HelloEJBHome); javax.rmi.PortableRemoteObject.narrow(objHome, HelloEJBHome.class); 

Configuring the WebLogic Server for RMI-IIOP Authentication

To enable RMI-IIOP clients to access EJBs in WebLogic Server, you need to configure the settings in the config.xml file and create an identifier that can be used by RMI-IIOP clients. The following settings need to be done:

 <Server Name="localhost" NativeIOEnabled="true" DefaultIIOPUser="sams"          DefaultIIOPPassword="sams123" ListenPort="7001"> 

This will establish an identity called "sams" with the authentication password "sams123" that can connect via RMI-IIOP to the localhost server on port 7001.

Now that you are familiar with building stateful and stateless session beans, you can begin work on building the transactional part of the model layer in the Airline ticket booking system MVC application.