DevPortal

What is Interoperability?

Table of Contents

What is Interoperability?

J2EE Interoperability is a set of API and specifications in the Java EE platform that lets developers build interoperable components, that work with CORBA and other non J2EE components, access systems written in non Java languages and platforms in a standard way.

What is RMI-IIOP Interoperability?

The Internet Inter ORB Protocol (IIOP) is an open, vendor independent protocol used by CORBA objects communicating over the network. CORBA IIOP allows heterogenous applications to communicate seamlessly with each other and other services. It is an Object Management Group (OMG) standard - http://www.omg.org. J2EE and CORBA can work together to provide CORBA services across the network to J2EE components like EJBs. The Java IDL mapping/RMI IIOP specification defines how normal EJB components written to work with the RMI API can be made to work over CORBA/IIOP. This requires an underlying IIOP runtime which is usually provided by the application server/EJB container. Pramati Server comes with full support for CORBA/IIOP, including EJB access over IIOP from external clients. This document describes how to configure Pramati Server to use the IIOP protocol; specifically, how to make an EJB application use IIOP.

This involves the following steps:

  1. Enable the ORB runtime in the server.
  2. Configure the EJB application to use IIOP.

Note: In this document the terms IIOP and RMI/IIOP are used interchangeably while referring to IIOP used in the EJB/J2EE context. ‘Pure’ RMI is referred to as RMI.

How do I enable ORB Runtime in Server?

The ORB runtime is a service which plugs into the extensible Pramati Services Framework. The ORBInitializer service can be used to plug in any third party ORB for use with Pramati Server. If the ORB requires additional configuration, it can also be specified in the configuration file itself. Pramati Server comes bundled with JacORB (http://www.jacorb.org), a free, high performance Java ORB. It is completely pluggable and can be replaced with any other ORB if required. However, it is recommended that JacORB be used since it has been tested well with Pramati.

The <install_dir>/server/nodes/<node_name>/config/server-config.xml file has the following entry:

<service name="ORBInitializer" enabled="true" class-name="com.pramati.iiop.ORBInitializerImpl">
      <requires/>
      <property name="orb-initial-port" value="900"/>
      <property name="com.pramati.iiop.nameservice.wrapper" value="com.pramati.iiop.jacorb.JacORBNameServiceWrapper"/>
      <property name="org.omg.CORBA.ORBClass" value="org.jacorb.orb.ORB"/>
      <property name="org.omg.CORBA.ORBSingletonClass" value="org.jacorb.orb.ORBSingleton"/>
      <property name="com.pramati.orb.ssl.port" value="5711"/>
</service>

The enabled attribute in the tag is set to false by default, indicating that the service is disabled. Set it to true. The other properties shown above are:

Starting the server after enabling the ORBInitializer service will automatically bootstrap the ORB runtime and make the server ready to deploy components over IIOP. Please note that enabling this service does not disable or interfere with the normal RMI communication subsystem of the server. EJB components can be still deployed over pure RMI. The service merely configures the server to use the proper ORB runtime.

How do I configure EJB applications to use IIOP?

An EJB application can be deployed on Pramati over only RMI (which is the default), only RMI/IIOP, or both simultaneously. This can be configured using the pramati-j2ee-server.xml file through the type tag, where type can be either rmi or iiop. If this tag is left out, the application is deployed over RMI.

The tag can occur at three levels in the XML:

This gives the application deployer the flexibility to selectively deploy select EJBs over a particular protocol if required. However, the most common scenarios would be probably where the whole application is deployed over one protocol.

IIOP configuration doesn’t require any additional tweaking. After adding this tag with the value set to iiop, the application can be deployed. Following are the differences between deployment of EJBs over RMI and RMI/IIOP.

Table 1: Deploying EJBs over RMI vs. Deploying EJBs over RMI/IIOP

RMI/JRMPRMI/IIOP
EJBs use RMI JRMP for communication.EJBs use RMI IIOP for communication.
EJBs are bound in the server’s JNDI naming service.EJBs are bound in the server’s CosNaming service.

Note: Invoking isIdentical on EJBs may not work as expected.

How do I connect to Pramati Server from Native Clients using IIOP?

J2EE components like EJBs can be deployed so as to be accessible over the IIOP protocol on Pramati Server. This means that any CORBA object can access these EJBs, using the Interoperable Naming Service or other means. This will walk you through writing, compiling and running such a client.

How do I deploy EJB on Pramati Server over IIOP?

It is assumed that the EJB is a Stateless Session Bean with the following remote interface and a JNDI name "HelloBean". 
public interface HelloRemote extends EJBObject
{public String sayHello(String name) throws RemoteException;}

On deploying the EJB, Pramati Server automatically generates the required IIOP stubs alongwith the Interface Definition Language (IDL) files for the EJB interfaces. The IDL files are required by clients written in other languages to generates stubs in their respective languages.

The IDL files and IIOP stubs are present in the <install_dir>/server/nodes/<node_name>/archives/<your EJB application name>/<your EJB application version>/classes directory.

How do I write Clients?

A C++ client is developed to access the EJB. The IDL files mentioned previously, an IDL to C++ compiler and a C++ ORB are required. 
#include 
.......                  //include headers as necessary
#include "HelloRemote.h" //Generated by the compiler
#include "HelloHome.h" //Generated by the compiler
using namespace std;
int main (int argc, char *argv[])
    {
    CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
    CORBA::Object_var ns = orb->resolve_initial_references("NameService");
    CosNaming::NamingContext_var nc = CosNaming::NamingContext::_narrow(ns);
    CosNaming::Name name;
    name.length (1);
    name[0].id = CORBA::string_dup ("HelloBean");
    name[0].kind = CORBA::string_dup ("");
      CORBA::Object_var obj;
      cout << "Looking up HelloBean in the CosNaming service" << flush;
      try {obj = nc->resolve (name);}
      catch (CosNaming::NamingContext::NotFound &exc)
      {cout << "NotFound" << endl;
       exit (1);
      }
      catch (CosNaming::NamingContext::CannotProceed &exc)
      {cout << "CannotProceed" << endl;
       exit (1);
      }
      catch (CosNaming::NamingContext::InvalidName &exc)
      {cout << "InvalidName" << endl;
       exit (1);
      }
      HelloRemoteHome_var home = HelloRemoteHome::_narrow (obj);
      HelloRemote_var remote = home->create();
      CORBA::WString_Value result = remote->sayHello("Dude");
      cout << "Result of calling HelloBean: " << result << endl;
      return 0;
}

How do I compile Clients?

Compile this client using your favorite C++ compiler, including all ORB libraries as required. The header files and classes for the EJB (earlier generated by the IDL to C++ compiler) should also be present in the include path.

How do I run Clients?

This client initializes the ORB and resolves the NamingService first. Pramati Server comes with JacORB's inbuilt naming service implementation - the IOR for should be used to initialize the C++ ORB also. On accessing the EJB using the name "HelloBean", the C++ client gets hold of a CORBA object reference which was earlier bound in the NamingService by Pramati's EJB container. Method calls on this object reference are delegated to the internal servants (actual EJBs) inside the EJB container and the result returned.

How do I connect to Pramati Server from Java Clients using RMI IIOP?

J2EE components like EJBs can be deployed on Pramati Server and made accessible over the IIOP protocol. This enables EJBs to be invoked over the IIOP protocol from Java (and other language) clients. This document will walk you through developing such a Java RMI IIOP client.

How do I deploy EJB on Pramati Server?

Please refer to relevant documentation on how to deploy an EJB over IIOP. The deployment process generates IIOP stubs as well as the required IDL (Interface Definition Language) files. These files are present in <install_dir>/server/nodes/<node>/archives/<your EJB application name>/<your EJB application version>/classes. Assume that the EJB is a Stateless Session Bean with a JNDI name "HelloBean" and the following remote interface: 
public interface HelloRemote extends EJBObject
 {public String sayHello(String name) throws RemoteException;}

How do I write Clients?

Pramati Server comes bundled with JacORB, a free, high performance Java ORB. The IIOP backbone inside Pramati Server is provided by this ORB. However, with this client you can use any ORB you want, since the client code uses only the standard CORBA Java APIs and the EJB interfaces.

Sample code for a Java client is shown below:

import java.io.*;
import java.rmi.RemoteException;
import java.util.*;
import javax.ejb.CreateException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.rmi.PortableRemoteObject;
public class JavaRMICORBAClient
{
  public static void main(String[] args) throws
    NamingException, RemoteException, CreateException
   {
    Properties props = new Properties();
    props.setProperty(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory");
    //replace this with the correct ip:port
    props.setProperty(Context.PROVIDER_URL, "iiop://localhost:900");
    InitialContext ic = new InitialContext(props);
    HelloRemoteHome home = (HelloRemoteHome)
         PortableRemoteObject.narrow(ic.lookup("HelloBean"), HelloRemoteHome.class);
    HelloRemote remote = home.create();
    String result = remote.sayHello("");
    System.out.println("Result of calling the bean deployed over IIOP: " + result);
   }
}

Replace the value of the property Context.PROVIDER_URL in the properties object with the correct IP port combination, or the IOR (or corbaloc) of the NamingService of the server. Note that the client is identical to any normal RMI client which is used to invoke EJBs - except for the fact that the PortableRemoteObject.narrow method is mandatory in case of RMI IIOP and not in plain RMI. Thus the RMI IIOP programming model allows existing EJB applications/client to be made easily accessible over IIOP to CORBA objects, without any changes in the code.

How do I compile Clients?

Compile the client after including all required EJB interfaces in the classpath.

How do I run Clients?

Run the client using java JavaRMICORBAClient.

How do I use CORBA-based Security for EJBs on Pramati Server?

EJBs can be configured to use the IIOP protocol on Pramati Server by configuring the pramati-j2ee-server.xml file. This enables the EJBs to be accessible over IIOP to both Java and non Java CORBA clients across the network and serve requests.

Such invocations need to be secured in cases where the underlying network is unsafe, or the EJB’s themselves require certain security protocols to be followed. The CSIv2 specification describes the security requirements of CORBA components. The EJB 2.1 specification describes the same with respect to EJBs and mandates a conformance level of 0 as defined in the CSIv2 specification. In order to interoperate with CORBA clients, EJBs have to be configured to use CORBA security semantics. There are three levels to this security:

How do I use Transport Layer Security?

Transport layer security is provided by the SSL/TLS protocols. To configure the EJB container to use SSL/TLS over IIOP, the following tag has to be provided in the pramati-j2ee-server.xml under the tag for the EJB whose security is being configured. 
<ior-security-descriptor>
  <transport-config integrity="required" confidentiality="required"
  establish-trust-in-client="supported" establish-trust-in-target="supported"/>
.. .. .. .. ..
.. .. .. .. ..
</ior-security-descriptor>
This specifies which secure transport options are required for that particular EJB.

Note: To enable SSL over JRMP, set the true tag to true.

What does Application Level Authentication involve?

Application level authentication involves client authentication based on tokens. The CSIv2 specification defines a GSS username password (GSSUP) mechanism for transmitting such data. 
<ior-security-descriptor>
………
   <as-context auth-method="username_password" required="true"/>
………
</ior-security-descriptor>
This tag specifies that the username-password mechanism is to be used, and that is it mandatory.

The standalone application client has to keep login.props file (which has the authentication details) under the client working directory.

A sample of login.props file follows:

java.naming.security.principal=
java.naming.security.credentials=
com.pramati.naming.realm=
If the file does not exist, then the client container will create a new file with the default properties so that you can edit it later.

What is Application Level Identity Assertion?

Identity assertion is a mechanism that enables an entity to act on behalf of another. This entity is usually an intermediate between the actual originator of the request and the target whom the request is meant for. The intermediary may or may not independently authenticate itself to the target at the transport or AS layers (according to the security settings between them), but this authentication is independent of the asserted identity. 
<ior-security-descriptor>
	………
		<sas-context caller-propagation="none"/>
	………
<ior-security-descriptor>

This tag specifies whether or not caller (or identity) propagation is supported.

Sometimes the server may act as client to another server, when forwarding the request. In that case it will not send the authentication details of the client who made the request. Instead, it will send its own authentication details to the server to which the request is getting forwarded.

In that case the server uses the authentication details provided by the Server Authentication Details provider. The default provider reads the authentication details from the remote-server-login.props file located under the server's working directory. In this release it uses the same properties to make requests to all the other servers.

It contains the same properties that kept in login.props as mentioned above.

What is the Custom Implementation for Server Authentication Details Provider?

The custom implementation of the Server Authentication Details provider must implement the interface com.pramati.security.interop.AuthenticationDetails. The implementation class name must be specified using the System property com.pramati.security.server.authenticationdetailsimpl. The implementation class must be in the classpath of the server. The client information will be propagated to the server with identity assertion token.

The identity assertion uses the following types supported by CSIv2 Specification:

The server passes the information in one of the above identity tokens, depending on how client got authenticated to it. If for example the client did not authenticated to the server, then it uses the ITT Anonymous identity token while forwarding the request.

How do I connect to CORBA Objects from Pramati Server?

Pramati Server comes with a bundled Java ORB (JacORB) and an Interoperable Naming Service. The ORB runtime in the server is initialized to use JacORB - so that any ORB initialization calls, even from inside applications will default to using this ORB. J2EE components like EJBs and JSPs can access CORBA objects on other processes/systems. These CORBA objects might be written in other languages, or might be J2EE components like EJBs themselves. In case of CORBA objects written in other languages (or even Java), a reference to the object has to be obtained using any of the following mechanisms available through CORBA:

In case of EJBs on other systems made accessible over IIOP, the normal RMI IIOP programming model or the Java IDL programming model can be used.

Additionally, EJB references in J2EE applications can be configured at deployment time to point to remote EJBs deployed over IIOP on other servers. Such links usually take the form of a corbaloc address as specified above. This configuration can be used if the remote EJBs are available over IIOP and the EJBs or Web components on the local server have ejb-refs defined which should point to those remote EJBs. These links can be added in the pramati-j2ee-server.xml file inside the EJB or Web application on Pramati Server.

© Pramati Technologies 2007 Runs on Pramati Server | Feedback | Legal