Skip Headers
Oracle® Application Server Containers for J2EE Services Guide
10g Release 2 (10.1.2) for Windows or UNIX
B14012-02
  Go To Documentation Library
Library
Go To Product List
Product
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

6 J2EE Interoperability

This chapter describes Oracle Application Server Containers for J2EE (OC4J) support for allowing EJBs to invoke one another across different containers using the standard Remote Method Invocation (RMI)/Internet Inter-Orb Protocol (IIOP).

This chapter covers the following topics:

Introduction to RMI/IIOP

Java Remote Method Invocation (RMI) enables you to create distributed Java-based to Java-based applications, in which the methods of remote Java objects can be invoked from other Java virtual machines (JVMs), possibly on different hosts.

Version 2.0 of the EJB specification adds features that make it easy for EJB-based applications to invoke one another across different containers. You can make your existing EJB interoperable without changing a line of code: simply edit the bean's properties and redeploy. "Switching to Interoperable Transport" discusses redeployment details.

EJB interoperability consists of the following:

OC4J furnishes transport, naming, and security interoperability.

Transport

By default, OC4J EJBs use RMI/Oracle Remote Method Invocation (ORMI), a proprietary protocol, to communicate as described in Chapter 5, "Oracle Remote Method Invocation".


Note:

For the OC4J 10g Release 2 (10.1.2) implementation, load balancing and failover are supported only for ORMI, not IIOP.

In OC4J, you can easily convert an EJB to use RMI/IIOP, making it possible for EJBs to invoke one another across different EJB containers. This chapter describes configuring and using RMI/IIOP.

Naming

OC4J supports the CORBA CosNaming service. OC4J can publish EJBHome object references in a CosNaming service and provides a JNDI CosNaming implementation that allows applications to look up JNDI names using CORBA. You can write your applications using either the JNDI or CosNaming APIs.

Security

OC4J supports Common Secure Interoperability Version 2 (CSIv2), which specifies different conformance levels; OC4J complies with the EJB specification, which requires conformance level 0.

Transactions

The EJB2.0 specification stipulates an optional transactional interoperability feature. Conforming implementations must choose one of the following:

  • Transactionally interoperable: transactions are supported between beans that are hosted in different J2EE containers.

  • Transactionally noninteroperable: transactions are supported only among beans in the same container.

The current release of OC4J is transactionally noninteroperable, so when a transaction spans EJB containers, OC4J raises a specified exception.

Client-Side Requirements

To access EJBs, you must do the following on the client-side:

  1. Download the oc4j_client.zip file from

    http://www.oracle.com/technology/software/products/ias/devuse.html 
    
    
  2. Unzip it into a client-side directory. (for example, d:\oc4jclient).

  3. Add d:\oc4jclient\oc4jclient.jar to your CLASSPATH.

The oc4j_client.zip file contains all the JAR files required by the client (including oc4jclient.jar and optic.jar). These JAR files contain the classes necessary for client interaction. You need to add only oc4jclient.jar to your CLASSPATH, because all other JAR files required by the client are referenced in the oc4jclient.jar manifest classpath.

If you download this file into a browser, you must grant certain permissions as described in the "Granting Permissions" section of the Security chapter in the Oracle Application Server Containers for J2EE Enterprise JavaBeans Developer's Guide.

The rmic.jar Compiler

To invoke or be invoked by CORBA objects, RMI objects must have corresponding stubs, skeletons, and Internet Description Language (IDL). Use the rmic.jar compiler to generate stubs and skeletons from Java classes or to generate IDL, as described in "Configuring OC4J for RMI".

For use with RMI/IIOP, be sure to compile using the -iiop option.

Switching to Interoperable Transport

In OC4J, EJBs use RMI/ORMI, a proprietary protocol, to communicate (as described in Chapter 5, "Oracle Remote Method Invocation"). You can convert an EJB to use RMI/IIOP, making it possible for EJBs to invoke one another across EJB containers.


Note:

RMI/IIOP support is based on the CORBA 2.3.1 specification. Applications that were compiled using earlier releases of CORBA may not work correctly.

The following four sections provide details on making the conversions.

Simple Interoperability in a Standalone Environment

Follow these steps to convert an EJB to use RMI/IIOP in a standalone environment:

  1. Restart OC4J with the -DGenerateIIOP=true flag.

  2. Deploy your application using admin.jar. You must obtain the client's stub JAR file, using the -iiopClientJar switch. Here is an example:

    java -jar $J2EE_HOME/admin.jar ormi://localhost admin welcome -deploy -file filename -deploymentName application_name -iiopClientJar stub_jar_filename 
    

    Note:

    You must use the -iiopClientJar switch to enable interoperability (IIOP) for the application you are deploying. In OC4J, interoperability is enabled on a per-application basis.

  3. Change the client's classpath to include the stub JAR file that was obtained during deployment, by running admin.jar with the -iiopClientJar switch.

    A copy of the stub JAR file that was generated by OC4J can also be found in the server's deployment directory at:

    application_deployment_directory/appname/ejb_module/module_iiopClient.jar 
    
    
  4. Edit the client's JNDI property java.naming.provider.url to use a corbaname URL instead of an ormi URL. For details on the corbaname URL, see "The corbaname URL".


    Note:

    IIOP stub and tie class code generation occurs at deployment time, unlike ORMI stub generation, which occurs at runtime. This is why you must add the JAR file to the classpath yourself. If you run in the server, a list of generated classes required by the server and IIOP stubs is made available automatically.

  5. (Optional) To make the bean accessible to CORBA applications, run rmic.jar to generate IDL describing its interfaces. See "Configuring OC4J for Interoperability" for a discussion of command-line options.

Advanced Interoperability in a Standalone Environment

This section expands upon the preceding section, describing how to convert an EJB to use RMI/IIOP in a standalone environment.

  1. Specify CSIv2 security policies for the bean in orion_ejb_jar.xml and in internal_settings.xml. See the Oracle Application Server Containers for J2EE Security Guide for more information on these security-related topics.

  2. Restart OC4J with the -DGenerateIIOP=true flag.

  3. Deploy your application using admin.jar. You must obtain the client's stub JAR file using the -iiopClientJar switch. Here is an example:

    java -jar $J2EE_HOME/admin.jar ormi://localhost admin welcome -deploy -file filename -deployment_name application_name -iiopClientJar stub_jar_filename 
    

    Note:

    You must use the -iiopClientJar switch to enable interoperability (IIOP) for the application that you are deploying. In OC4J, interoperability is enabled on a per-application basis.

  4. Change the client's classpath to include the stub JAR file that was obtained during deployment, by running admin.jar with the -iiopClientJar switch.

    You can also find a copy of the stub JAR file that was generated by OC4J in the server's deployment directory at:

    application_deployment_directory/appname/ejb_module/module_iiopClient.jar 
    
    
  5. Edit the client's JNDI property java.naming.provider.url to use a corbaname URL instead of an ormi URL. For details on the corbaname URL, see "The corbaname URL".


    Note:

    IIOP stub and tie class code generation occurs at deployment time, unlike ORMI stub generation, which occurs at runtime. This is why you must add the JAR file to the classpath yourself. If you run in the server, a list of generated classes required by the server and IIOP stubs is made available automatically.

  6. (Optional) To make the bean accessible to CORBA applications, run rmic.jar to generate IDL describing its interfaces. See "Configuring OC4J for Interoperability" for a discussion of command-line options.

Simple Interoperability in Oracle Application Server Environment

You can access an EJB using RMI/IIOP in an Oracle Application Server environment in two ways:

Configuring for Interoperability Using Oracle Enterprise Manager 10g

You can configure an EJB to be accessible by means of RMI/IIOP in an Oracle Application Server environment by using Oracle Enterprise Manager 10g. Follow these steps:

  1. Navigate to an OC4J instance in which you want to allow access to applications through RMI/IIOP. Figure 6-1 shows an OC4J instance named home.

Figure 6-1 Oracle Enterprise Manager 10g System Components

Description of emsyscp4.gif follows
Description of the illustration emsyscp4.gif

  1. Click Server Properties in the Administration section for this OC4J instance. Figure 6-2 illustrates this.

Figure 6-2 Oracle Enterprise Manager 10g Server Properties

Description of emsysdp3.gif follows
Description of the illustration emsysdp3.gif

By default, RMI/IIOP is disabled in an Oracle Application Server environment. To enable RMI/IIOP, ensure that a unique IIOP port (or port range) exists for each OC4J instance by entering the value in the IIOP ports field, as shown in Figure 6-3. Then click Apply.

Figure 6-3 Oracle Enterprise Manager 10g Port Configuration

Description of EMPorts.gif follows
Description of the illustration EMPorts.gif

Use the Oracle Enterprise Manager 10g deployment wizard to deploy your application.

Enable generation of client IIOP stubs for this application by selecting Generate IIOP stubs, as shown in Figure 6-4.

Figure 6-4 Oracle Enterprise Manager 10g Stub Generation

Description of emstbgn2.gif follows
Description of the illustration emstbgn2.gif

Finish deploying your application using the Oracle Enterprise Manager 10g deployment wizard.

Configuring for Interoperability Manually

Follow these steps to manually configure an EJB for remote access by RMI/IIOP in an Oracle Application Server environment:

  1. By default, RMI/IIOP is disabled in an Oracle Application Server environment. To enable RMI/IIOP, confirm in OPMN's configuration file, J2EE_HOME/opmn/conf/opmn.xml, that a unique IIOP port (or port range) exists for each OC4J instance to be managed by OPMN.


    Note:

    You must specify an IIOP port (or port range) for each OC4J instance in which interoperability is to be enabled. Failure to do so causes OC4J to not configure an IIOP listener, thus automatically disabling interoperability, regardless of the configuration in the internal-settings.xml file of OC4J.

    Here is an example:

    <ias-component id="OC4J">
              <process-type id="home" module-id="OC4J">
                   <port id="ajp" range="3000-3100"/>
                   <port id="rmi" range="23791-23799"/>
                   <port id="jms" range="3201-3300"/>
                   <port id="iiop" range="3401-3500"/>
                   <process-set id="default_island" numprocs="1"/>
              </process-type>
     </ias-component> 
    
    
  2. If you modify any configuration file manually, you must update the configuration with dcmctl. Use the following command:

    dcmctl updateConfig 
    
    
  3. Using opmnctl or Oracle Enterprise Manager 10g, restart all OC4J instances that are managed by OPMN.

    For information on opmnctl, use the following command:

    opmnctl help 
    
    

    To stop and restart OPMN and all OPMN-managed processes, first use the following command:

    opmnctl stopall 
    
    

    Then use this command:

    opmnctl startall
    
    

    For information on Oracle Enterprise Manager 10g, see the Oracle Application Server Containers for J2EE User's Guide.

  4. Deploy your application using dcmctl, specifying the -enableIIOP option. Here is an example:

    dcmctl deployApplication -f filename -a application_name -enableIIOP 
    
    
  5. Change the client's classpath to include the stub JAR file that was generated by OC4J. This file is normally found in the server's deployment directory:

    application_deployment_directory/appname/ejb_module/module_iiopClient.jar 
    
    
  6. Edit the client's JNDI property java.naming.provider.url to use an OPMN or corbaname URL instead of an ormi URL. For details on the corbaname URL, see "The corbaname URL". For details on the OPMN URL, see "The OPMN URL".


    Note:

    IIOP stub and tie class code generation occurs at deployment time, unlike ORMI stub generation, which occurs at runtime. This is why you must add the JAR file to the classpath yourself. If you run in the server, a list of generated classes required by the server and IIOP stubs is made available automatically.

  7. (Optional) To make the bean accessible to CORBA applications, run rmic.jar to generate IDL describing its interfaces. See "Configuring OC4J for Interoperability" for a discussion of command-line options.

Advanced Interoperability in Oracle Application Server Environment

You can access an EJB using RMI/IIOP in an Oracle Application Server environment in two ways:

Configuring for Interoperability Using Oracle Enterprise Manager 10g

The advanced configuring for interoperability using Oracle Enterprise Manager 10g differs from the simple configuring described under "Configuring for Interoperability Using Oracle Enterprise Manager 10g" only in the specification of ports. That is, you must specify an iiop, iiops1, and iiops2 port (or port range) for each OC4J instance in which interoperability with CSIv2 is to be enabled. Failure to do so causes OC4J to not configure an IIOP listener, thus automatically disabling interoperability, regardless of the configuration in the internal-settings.xml file of OC4J. Figure 6-5 shows this.

Figure 6-5 Oracle Enterprise Manager 10g Port Specifications

Description of emprtad2.gif follows
Description of the illustration emprtad2.gif

Configuring for Interoperability Manually

This section expands upon the preceding section, describing how to convert an EJB to use RMI/IIOP in an Oracle Application Server environment.

  1. Specify CSIv2 security policies for the bean in orion_ejb_jar.xml and in internal_settings.xml. See the Oracle Application Server Containers for J2EE Security Guide for more information on these security-related topics.

  2. By default, RMI/IIOP is disabled in an Oracle Application Server environment. To enable RMI/IIOP, confirm in the OPMN configuration file, J2EE_HOME/opmn/conf/opmn.xml, that a unique iiop, iiops1, and iiops2 port (or port range) exists for each OC4J instance to be managed by OPMN. These are the port meanings:

    iiop—standard IIOP port

    iiops1—IIOP/SSL port used for server-side authentication only

    iiops2—IIOP/SSL port used for both client and server authentication


    Note:

    You must specify an iiop, iiops1, and iiops2 port (or port range) for each OC4J instance in which interoperability with CSIv2 is to be enabled. Failure to do so causes OC4J to not configure an IIOP listener, thus automatically disabling interoperability, regardless of the configuration in the internal-settings.xml file of OC4J.

    Here is an example:

    <ias-component id="OC4J">
        <process-type id="home" module-id="OC4J">
            <port id="ajp" range="3000-3100"/>
            <port id="rmi" range="23791-23799"/>
            <port id="jms" range="3201-3300"/>
            <port id="iiop" range="3401-3500"/>
            <port id="iiops1" range="3501-3600"/> 
            <port id="iiops2" range="3601-3700"/>
            <process-set id="default_island" numprocs="1"/>
        </process-type>
    </ias-component>
    
    

    Note:

    If you choose to configure your client's JNDI property java.naming.provider.url to use an OPMN URL, then your client cannot connect to iiops1 or iiops2 ports because OPMN-allocated ports are not reported to OC4J.

  3. Using opmnctl or Oracle Enterprise Manager 10g, restart all OC4J instances that are managed by OPMN.

    For information on opmnctl, use the following command:

    opmnctl help
    
    

    To stop and restart OPMN and all OPMN-managed processes, first use the following command:

    opmnctl stopall 
    
    

    Then use this command:

    opmnctl startall 
    
    

    For information on Oracle Enterprise Manager 10g, see the Oracle Application Server Containers for J2EE User's Guide.

  4. Deploy your application using dcmctl, specifying the -enableIIOP option. Here is an example:

    dcmctl  deployApplication -f filename -a application_name -enableIIOP 
    
    
  5. Change the client's classpath to include the stub JAR file that was generated by OC4J. This is normally found in the server's deployment directory:

    application_deployment_directory/appname/ejb_module/module_iiopClient.jar 
    
    
  6. Edit the client's JNDI property java.naming.provider.url to use an OPMN or corbaname URL instead of an ormi URL. For details on the corbaname URL, see "The corbaname URL". For details on the OPMN URL, see "The OPMN URL".


    Note:

    IIOP stub and tie class code generation occurs at deployment time, unlike ORMI stub generation, which occurs at runtime. This is why you must add the JAR file to the classpath yourself. If you run in the server, a list of generated classes required by the server and IIOP stubs is made available automatically.

  7. (Optional) To make the bean accessible to CORBA applications, run rmic.jar to generate IDL describing its interfaces. See "Configuring OC4J for Interoperability" for a discussion of command-line options.

The corbaname URL

To interoperate, an EJB must look up other beans using CosNaming. This means that the URL for looking up the root NamingContext must use the corbaname URL scheme instead of the ormi URL scheme. This section discusses the corbaname subset that EJB developers use most often. For a full discussion of the corbaname scheme, see section 2.5.3 of the CORBA Naming Service specification. The corbaname scheme is based on the corbaloc scheme, which section 13.6.10.1 of the CORBA specification discusses.

The most common form of the corbaname URL scheme is:

corbaname::host[:port] 

This corbaname URL specifies a conventional DNS host name or IP address, and a port number. For example,

corbaname::example.com:8000 

A corbaname URL can also specify a naming context by following the host and port by # and NamingContext in string representation. The CosNaming service on the specified host is responsible for interpreting the naming context.

corbaname::host[:port]#namingcontext 

For example:

corbaname::example.com:8000#Myapp 

The OPMN URL

This section describes OPMN URL details that are specific to RMI/IIOP. For general information about the OPMN URL, see "JNDI Properties for RMI".

In an Oracle Application Server environment, IIOP ports for all OC4J processes within each Oracle Application Server instance are dynamically managed by OPMN. Because of this, it may not be possible for clients to know the ports on which OC4J processes are actively listening for IIOP requests. To enable clients to successfully make RMI/IIOP requests in an Oracle Application Server environment without having to know the IIOP ports for all active OC4J processes, modify the jndi.naming.provider.url property (in the client's jndi.properties file) with a URL of the following format:

opmn:corbaname::opmn_host[:opmn_port]:]:OC4J_instance_name#naming_context 

For example:

opmn:corbaname::dlsun74:6003:home#stateless 


Notes:

  • For the OC4J 10g Release 2 (10.1.2) implementation, load balancing and failover are supported only for ORMI, not IIOP.

  • If you use an OPMN URL, your client cannot connect to iiops1 or iiops2 (ssl-port or ssl-client-server-auth-port) ports.


Exception Mapping

When EJBs are invoked over IIOP, OC4J must map system exceptions to CORBA exceptions. Table 6-1 lists the exception mappings.

Table 6-1 Java-CORBA Exception Mappings

OC4J System Exception CORBA System Exception
javax.transaction.

TransactionRolledbackException

TRANSACTION_ROLLEDBACK
javax.transaction.

TransactionRequiredException

TRANSACTION_REQUIRED
javax.transaction.

InvalidTransactionException

INVALID_TRANSACTION
java.rmi.NoSuchObjectException OBJECT_NOT_EXIST
java.rmi.AccessException NO_PERMISSION
java.rmi.MarshalException MARSHAL
java.rmi.RemoteException UNKNOWN

Invoking OC4J-Hosted Beans from a Non-OC4J Container

EJBs that are not hosted in OC4J must add the file oc4j_interop.jar to the classpath to invoke OC4J-hosted EJBs. OC4J expects the other container to make the HandleDelegate object available in the JNDI name space at java:comp/HandleDelegate. The oc4j_interop.jar file contains the standard portable implementations of home and remote handles, and metadata objects.

Configuring OC4J for Interoperability

To add interoperability support to your EJB, you must specify interoperability properties. Some of these properties are specified when starting OC4J and others in bean properties that are specified in deployment files.

The following security-related topics are now covered in the Oracle Application Server Containers for J2EE Security Guide:

Interoperability OC4J Flags

The following OC4J startup flags support RMI interoperability:

  • -DGenerateIIOP=true generates new stubs and skeletons whenever you redeploy an application.

  • -Diiop.debug=true generates deployment-time debugging messages, most of which have to do with code generation.

  • -Diiop.runtime.debug=true generates runtime debugging messages.

Interoperability Configuration Files

Before EJBs can communicate, you must configure the parameters in the configuration files listed in Table 6-2.

Table 6-2 Interoperability Configuration Files

Context File Description
Server server.xml The <sep-config> element in this file specifies the path name, normally internal-settings.xml, for the server extension provider properties. For example:

<sep-config path="./internal-settings.xml">


internal-settings.xml This file specifies server extension provider properties that are specific to RMI/IIOP. See the Oracle Application Server Containers for J2EE Security Guide for more information on these security-related topics.
Application orion-ejb-jar.xml The <ior-security-config> subentity of the <session-deployment> and <entity-deployment> entities specifies Common Secure Interoperability Version 2 (CSIv2) security properties for the server.

See the Oracle Application Server Containers for J2EE Security Guide for more information on these security-related topics.


ejb_sec.properties This file specifies client-side security properties for an EJB. See the Oracle Application Server Containers for J2EE Security Guide for more information on these security-related topics.

jndi.properties This file specifies the URL of the initial naming context used by the client. See "JNDI Properties for Interoperability (jndi.properties)" for details.

JNDI Properties for Interoperability (jndi.properties)

The following RMI/IIOP properties are controlled by the client's jndi.properties file:

  • java.naming.provider.url may be an OPMN or a corbaname URL for the bean to be interoperable. For details on corbaname URLs, see "The corbaname URL". For details on the OPMN URL, see "The OPMN URL".

  • contextFactory can be either ApplicationClientInitialContextFactory or the class IIOPInitialContextFactory.

    If your application has an application-client.xml file, then leave contextFactory set to ApplicationClientInitialContextFactory. If your application does not have an application-client.xml file, then change contextFactory to IIOPInitialContextFactory.

Context Factory Usage

com.evermind.server.ApplicationClientInitialContextFactory is used when looking up remote objects from standalone application clients. It uses the refs and ref-mappings found in application-client.xml and orion-application-client.xml. It is the default initial context factory when the initial context is instantiated in a Java application.

com.oracle.iiop.server.IIOPInitialContextFactory is used when looking up remote objects between different containers using the IIOP protocol.

Enabling IIOP in OC4J

This tutorial describes the steps necessary to enable IIOP applications in OC4J. After completing this exercise you should be able to:

  • Access a remote EJB over IIOP

  • Secure EJB invocations with IIOP over SSL

  • Secure corbaname lookups by remote clients with IIOP over SSL

To minimize deployment and configuration changes, the tutorial uses the demo "helloworld" EJB application available through the installation and on Oracle's OTN site:

http://www.oracle.com/technology/sample_code/tech/java/ejb_corba/index.html

Building and deploying the helloworld application with a default OC4J installation results in an application that is only accessible over ORMI. To enable IIOP for a given application you must make the following changes to OC4J's server configuration and the client application. The required changes include:

  • Configure the IIOPServerExtensionProvider

  • Change the java.naming.provider.url

  • Deploy the application using the -iiopClientJar argument

The following sections describe the steps in more detail.

Getting Started

Expand the EJB demos to your development environment. The helloworld application should be under <install-dir>/demo/ejb/helloworld with the following structure:

|-------dist
|-------etc
|       |-------application-client.xml
|       |-------application.xml
|       |-------ejb-jar.xml
|       |-------jndi.properties
|-------src
|       |-------ejb
|       |       |-------client
|       |       |       |-------HelloClient.java
|       |       |-------helloworld-ejb
|       |               |-------Hello.java
|       |               |-------HelloBean.java
|       |               |-------HelloHome.java
|       |               |-------HelloLocal.java
|       |               |-------HelloLocalHome.java
|------build.xml

Applications other than the helloworld example can be ignored for the remainder of the tutorial, but should be unaffected by changes required for enabling IIOP. This tutorial installs the demos to the root partition, so the application is under /demo/ejb/helloworld.

The supplied Ant build file provides targets for compiling the src, building the jar and ear, and running the client application. This tutorial assumes you are familiar with Ant build files. If you are unfamiliar with Ant, please see Apache's Ant documentation site: http://ant.apache.org/manual/index.html

Configure IIOP in OC4J

Edit the server.xml file as follows:

  <install-dir>j2ee/home/config/internal-settings.xml

Make sure the server.xml file contains the following line:

<sep-config path="./internal-settings.xml" />

If the line is missing, or commented out, remove the comments or add the line below the following line:

<rmi-config path="./rmi.xml" />

This configures the IIOPServerExtensionProvider for OC4J.

Now edit the internal-settings.xml file as follows to configure your IIOP settings:

<install-dir>j2ee/home/config/internal-settings.xml

Make sure the file contains the following settings:

<server-extension-provider name="IIOP"
   class="com.oracle.iiop.server.IIOPServerExtensionProvider">
   <sep-property name="port" value="5555" />
   <sep-property name="host" value="localhost" />
   <sep-property name="ssl" value="false" />
   <sep-property name="trusted-clients" value="*" />
</server-extension-provider>

If necessary, you can modify the host and port to match your environment. If your file contains entries for SSL, temporarily comment them out:

<!--
   <sep-property name="ssl-port" value="5556" />
   <sep-property name="ssl-client-server-auth-port" value="5557" />
   <sep-property name="keystore" value="keystore.jks" />
   <sep-property name="keystore-password" value="->pwForSSL" />
   <sep-property name="truststore" value="truststore.jks" />
   <sep-property name="truststore-password" value="->pwForSSL" />
-->

Now OC4J is configured for IIOP. The final step to enable IIOP on the server side is to start OC4J with the JVM argument: -DgenerateIIOP=true. This can be done on the command line for OC4J standalone, and in the ${ORACLE_HOME}/opmn/opmn.xml file for Oracle Application Server installs.

Configure the JNDI provider URL

Edit the jndi.properties file as follows for the helloworld application:

<install-dir>/demo/ejb/helloworld/etc/jndi.properties

java.naming.factory.initial=com.evermind.server.ApplicationClientInitialContextFactory
java.naming.provider.url=corbaname:iiop:localhost:5555#helloworld
#java.naming.provider.url=ormi://localhost:23791/helloworld
java.naming.security.principal=admin
java.naming.security.credentials=welcome

Comment out the line containing the ORMI provider URL, and add a line matching the corbaname provider URL in the example.

Build and deploy the application

From the <install-dir>/demo/ejb/helloworld directory, run the default ant target to build the application:

<install-dir>/demo/ejb/helloworld > ant

Start OC4J if you have not done so already, then execute the following deploy command:

java -jar ${J2EE_HOME}/admin.jar ormi://localhost:23791 admin welcome -deploy -file dist/helloworld.ear -deploymentName helloworld -iiopClientJar dist/helloworld_iiop_client.jar 

This deploys the helloworld application and generates the client EJB JAR containing the client IIOP stubs in dest/helloworld_iiop_client.jar.

Run the application

Edit the <install-dir>/demo/ejb/common.xml file, and make sure the environment settings for ORACLE_HOME, JAVA_HOME, and J2EE_HOME match your environment.

Execute > ant run

You should see the appropriate "Hello ..." response from the client application. To verify that communication is running over IIOP, you can set the following JMV arg on both the client and the server:

-Diiop.runtime.debug=true

Enable IIOP over SSL on the server

Edit the internal-settings.xml file and uncomment or add the SSL settings (indicated by the bold lines in the following example):

<server-extension-provider name="IIOP"
   class="com.oracle.iiop.server.IIOPServerExtensionProvider">
   <sep-property name="port" value="5555" />
   <sep-property name="host" value="localhost" />
   <sep-property name="ssl" value="true" />
   <sep-property name="trusted-clients" value="*" />
   <sep-property name="ssl-port" value="5556" />
   <sep-property name="ssl-client-server-auth-port" value="5557" />
   <sep-property name="keystore" value="keystore.jks" />
   <sep-property name="keystore-password" value="yourPWD" />
   <sep-property name="truststore" value="truststore.jks" />
   <sep-property name="truststore-password" value=" yourPWD " />
</server-extension-provider>

If necessary, you can modify the host and port to match your environment. The keystore and truststore files may be the same physical file. The names above are only for illustration. If you do not have a keystore file, you can use the following Sun example for using the keytool:

http://java.sun.com/docs/books/tutorial/security1.2/summary/tools.html

Add the absolute path and filename to the keystore and truststore properties in the example.

Enable SSL on the client

Edit the jndi.properties file for the helloworld application:

<install-dir>/demo/ejb/helloworld/etc/jndi.properties
java.naming.factory.initial=com.evermind.server.ApplicationClientInitialContextFactory
java.naming.provider.url=corbaname:iiop:localhost:5556#helloworld
java.naming.security.principal=admin
java.naming.security.credentials=welcome

Change the port in the provider URL to be the SSL port from internal-settings.xml.

Create a file called ejb_sec.properties for the helloworld application:

oc4j.iiop.trustedServers=*
nameservice.useSSL=true
oc4j.iiop.trustStoreLoc=<path to server's keystore>
oc4j.iiop.trustStorePass=<password for server's keystore file>

This file communicates the applications security requirements to the OC4J client bootstrap classes. The properties in this example indicate that SSL should be used for EJB lookups, and that all servers supporting SSL should be trusted. The truststore setting is a quick way of using the same keystore configured for OC4J instead of exporting the certificate in the servers keystore and importing it into a second truststore file.

Run the application with IIOP over SSL

Execute > ant run

You should see the appropriate "Hello ..." response from the client application. To verify that communication is running with IIOP over SSL, set the -Diiop.runtime.debug=true for both the client and the server.