Configuring WebLogic Server for RMI-IIOP

Programming WebLogic RMI

Configuring WebLogic Server for RMI-IIOP

The following sections describe concepts and procedures relating to configuring WebLogic Server for RMI-IIOP:

Set the Listening Address
Setting Network Channel Addresses
Using a IIOPS Thin Client Proxy
Using RMI-IIOP with SSL and a Java Client
Accessing WebLogic Server Objects from a CORBA Client through Delegation
Configuring CSIv2 authentication
Using RMI over IIOP with a Hardware Load Balancer
Limitations of WebLogic RMI-IIOP
Propagating Client Identity

Set the Listening Address

To facilitate the use of IIOP, always specify a valid IP address or DNS name for the Listen Address attribute in the configuration file (config.xml) to listen for connections.
The Listen Address default value of null allows it to “listen on all configured network interfaces”. However, this feature only works with the T3 protocol. If you need to configure multiple listen addresses for use with the IIOP protocol, then use the Network Channel feature, as described in “Configuring Network Resources” in Configuring Server Environments.

Setting Network Channel Addresses

The following sections provide information to consider when implementing IIOP network channel addresses for thin clients.

Considerations for Proxys and Firewalls

Many typical environments use firewalls, proxys, or other devices that hide the application server's true IP address. Because IIOP relies on a per-object addressing scheme where every object contains a host and port, anything that masks the true IP address of the server will prevent the external client from maintaining a connection. To prevent this situation, set the PublicAddress on the server IIOP network channel to the virtual IP that the client sees.

Considerations for Clients with Multiple Connections

IIOP clients publish addressing information that is used by the application server to establish a connection. In some situations, such as running a VPN where clients have more than one connection, the server cannot see the IP address published by the client. In this situation, you have two options:
Use a bi-directional form of IIOP. Use the following WebLogic flag:
-Dweblogic.corba.client.bidir=true
In this instance, the server does not need the IP address published by the client because the server uses the inbound connection for outbound requests.
Use the following JDK property to set the address the server uses for outbound connections:
-Dcom.sun.CORBA.ORBServerHost=client_ipaddress
where client_ipaddress is an address published by the client.
Using a IIOPS Thin Client Proxy

The IIOPs Thin Client Proxy provides a WebLogic thin client the ability to proxy outbound requests to a server. In this situation, each user routes all outbound requests through their proxy. The user's proxy then directs the request to the WebLogic Server. You should use this method when it is not practical to implement a Network Channel. To enable a proxy, set the following properties:
   -Diiops.proxyHost=<host>
   -Diiops.proxyPort=<port>
where:
hostname is the network address of the user's proxy server.
port is the port number. If not explicitly set, the value of the port number is set to 80.
hostname and port support symbolic names, such as:
-Diiops.proxyHost=https.proxyHost
-Diiops.proxyPort=https.proxyPort
You should consider the following security implications:

This feature does not change the behavior of WebLogic Server. However, using this feature does expose IP addresses though the client's firewall. As both ends of the connection are trusted and the linking information is encrypted, this is an acceptable security level for many environments.
Some production environments do not allow enabling the CONNECT attribute on the proxy server. These environments should use HTTPS tunneling. For more information, see “Setting Up WebLogic Server for HTTP Tunneling” in Configuring Server Environments.

Using RMI-IIOP with SSL and a Java Client

The Java clients that support SSL are the thin client and the WLS-IIOP client. To use SSL with these clients, simply specify an ssl url.

Accessing WebLogic Server Objects from a CORBA Client through Delegation

WebLogic Server provides services that allow CORBA clients to access RMI remote objects. As an alternative method, you can also host a CORBA ORB (Object Request Broker) in WebLogic Server and delegate incoming and outgoing messages to allow CORBA clients to indirectly invoke any object that can be bound in the server.

Overview of Delegation

Here are the main steps to create the objects that work together to delegate CORBA calls to an object hosted by WebLogic Server.

Create a startup class that creates and initializes an ORB so that the ORB is co-located with the JVM that is running WebLogic Server.
Create an IDL (Interface Definition Language) that will create an object to accept incoming messages from the ORB.
Compile the IDL. This will generate a number of classes, one of which will be the Tie class. Tie classes are used on the server side to process incoming calls, and dispatch the calls to the proper implementation class. The implementation class is responsible for connecting to the server, looking up the appropriate object, and invoking methods on the object on behalf of the CORBA client.

Figure 8-1 is a diagram of a CORBA client invoking an EJB by delegating the call to an implementation class that connects to the server and operates upon the EJB. Using a similar architecture, the reverse situation will also work. You can have a startup class that brings up an ORB and obtains a reference to the CORBA implementation object of interest. This class can make itself available to other WebLogic objects throughout the JNDI tree and delegate the appropriate calls to the CORBA object. Figure 8-1 CORBA Client Invoking an EJB with a Delegated Call

Example of Delegation

The following code example creates an implementation class that connects to the server, looks up the Foo object in the JNDI tree, and calls the bar method. This object is also a startup class that is responsible for initializing the CORBA environment by:
Creating the ORB
Creating the Tie object
Associating the implementation class with the Tie object
Registering the Tie object with the ORB
Binding the Tie object within the ORB's naming service
import org.omg.CosNaming.*;

import org.omg.CosNaming.NamingContextPackage.*;

import org.omg.CORBA.*;

import java.rmi.*;

import javax.naming.*;

import weblogic.jndi.Environment;
public class FooImpl implements Foo
{ 

  public FooImpl() throws RemoteException {

    super();
  }
  public void bar() throws RemoteException, NamingException {

    // look up and call the instance to delegate the call to...

    weblogic.jndi.Environment env = new Environment();

    Context ctx = env.getInitialContext();

    Foo delegate = (Foo)ctx.lookup("Foo");

    delegate.bar();

    System.out.println("delegate Foo.bar called!");
  }
  public static void main(String args[]) {

    try {

      FooImpl foo = new FooImpl();
      // Create and initialize the ORB

      ORB orb = ORB.init(args, null);
      // Create and register the tie with the ORB

      _FooImpl_Tie fooTie = new _FooImpl_Tie();

      fooTie.setTarget(foo);

      orb.connect(fooTie);
      // Get the naming context

      org.omg.CORBA.Object o = \

      orb.resolve_initial_references("NameService");

      NamingContext ncRef = NamingContextHelper.narrow(o);
      // Bind the object reference in naming
      NameComponent nc = new NameComponent("Foo", "");

      NameComponent path[] = {nc};

      ncRef.rebind(path, fooTie);
      System.out.println("FooImpl created and bound in the ORB       registry.");
    }

    catch (Exception e) {

      System.out.println("FooImpl.main: an exception occurred:");

      e.printStackTrace();
    }
  }
}
Configuring CSIv2 authentication

The Common Secure Interoperability Specification, Version 2 (CSIv2) is an Open Management Group (OMG) specification that addresses the requirements of Common Object Request Broker Architecture (CORBA) security for interoperable authentication, delegation, and privileges. See “Common Secure Interoperability Version 2 (CSIv2)” in Understanding WebLogic Security.
Use the following steps to use CSIv2 to authenticate an inbound call from a remote domain:

Update the Identity Asserter. See “Configuring Identity Assertion Providers” in Securing WebLogic Server.
Update the User Name Mapper. See “Configuring a User Name Mapper” in Securing WebLogic Server.
Add all users required by the application in the remote domain to the WebLogic AuthenticationProvider. See “Create User” in Administration Console Online Help.

Using RMI over IIOP with a Hardware Load Balancer

This feature works correctly only when the bootstrap is through a hardware load-balancer.
An optional enhancement for WebLogic Server Oracle ORB and higher, supports hardware load balancing by forcing reconnection when bootstrapping. This allows hardware load-balancers to balance connection attempts
In most situations, once a connection has been established, the next NameService lookup is performed using the original connection. However, since this feature forces re-negotiation of the end point to the hardware load balancer, all in-flight requests on any existing connection are lost.
Use the -Dweblogic.system.iiop.reconnectOnBootstrap system property to set the connection behavior of the Oracle ORB. Valid values are:

true —Forces re-negotiation of the end point.
false—Default value.

Environments requiring a hardware load balancer should set this property to true.

Limitations of WebLogic RMI-IIOP

The following sections outline various issues relating to WebLogic RMI-IIOP.

Limitations Using RMI-IIOP on the Client

Use WebLogic Server with JDK 1.3.1_01 or higher. Earlier versions are not RMI-IIOP compliant. Note the following about these earlier JDKs:

Send GIOP 1.0 messages and GIOP 1.1 profiles in IORs.
Do not support the necessary pieces for EJB 2.0 interoperation (GIOP 1.2, codeset negotiation, UTF-16).
Have bugs in its treatment of mangled method names.
Do not correctly unmarshal unchecked exceptions.
Have subtle bugs relating to the encoding of valuetypes.

Many of these items are impossible to support both ways. Where there was a choice, WebLogic supports the spec-compliant option.

Limitations Developing Java IDL Clients

Oracle strongly recommends developing Java clients with the RMI client model if you are going to use RMI-IIOP. Developing a Java IDL client can cause naming conflicts and classpath problems, and you are required to keep the server-side and client-side classes separate. Because the RMI object and the IDL client have different type systems, the class that defines the interface for the server-side will be very different from the class that defines the interface on the client-side.

Limitations of Passing Objects by Value

To pass objects by value, you need to use value types (see Chapter 5 of the CORBA/IIOP 2.4.2 Specification for further information) You implement value types on each platform on which they are defined or referenced. This section describes the difficulties of passing complex value types, referencing the particular case of a C++ client accessing an Entity bean on WebLogic Server.
One problem encountered by Java programmers is the use of derived datatypes that are not usually visible. For example, when accessing an EJB finder the Java programmer will see a Collection or Enumeration, but does not pay attention to the underlying implementation because the JDK run-time will classload it over the network. However, the C++, CORBA programmer must know the type that comes across the wire so that he can register a value type factory for it and the ORB can unmarshal it.
Simply running ejbc on the defined EJB interfaces will not generate these definitions because they do not appear in the interface. For this reason ejbc will also accept Java classes that are not remote interfaces—specifically for the purpose of generating IDL for these interfaces. Review the /iiop/ejb/entity/cppclient example to see how to register a value type factory.
Java types that are serializable but that define writeObject() are mapped to custom value types in IDL. You must write C++ code to unmarshal the value type manually.

When using Tuxedo, you can specify the -i qualifier to direct the IDL compiler to create implementation files named FileName_i.h and FileName_i.cpp. For example, this syntax creates the TradeResult_i.h and TradeResult_i.cpp implementation files:
  idl -IidlSources -i   idlSources\examples\iiop\ejb\iiop\TradeResult.idl
The resulting source files provide implementations for application-defined operations on a value type. Implementation files are included in a CORBA client application.

Propagating Client Identity

Until recently insufficient standards existed for propagating client identity from a CORBA client. If you have problems with client identity from foreign ORBs, you may need to implement one of the following methods:
The identity of any client connecting over IIOP to WebLogic Server will default to <anonymous>. You can set the user and password in the config.xml file to establish a single identity for all clients connecting over IIOP to a particular instance of WebLogic Server, as shown in the example below:
<Server

Name of="myserver"

NativeIOEnabled="true"

DefaultIIOPUser="Bob"

DefaultIIOPPassword="Gumby1234"

ListenPort="7001">
You can also set the IIOPEnabled attribute in the config.xml. The default value is "true"; set this to "false" only if you want to disable IIOP support. No additional server configuration is required to use RMI over IIOP beyond ensuring that all remote objects are bound to the JNDI tree to be made available to clients. RMI objects are typically bound to the JNDI tree by a startup class. EJB homes are bound to the JNDI tree at the time of deployment. WebLogic Server implements a CosNaming Service by delegating all lookup calls to the JNDI tree.
This release supports RMI-IIOP corbaname and corbaloc JNDI references. See the CORBA/IIOP 2.4.2 Specification. One feature of these references is that you can make an EJB or other object hosted on one WebLogic Server available over IIOP to other Application Servers. So, for instance, you could add the following to your ejb-jar.xml:
<ejb-reference-description>

<ejb-ref-name>WLS</ejb-ref-name>

<jndi-name>corbaname:iiop:1.2@localhost:7001#ejb/j2ee/interop/foo</jndi-name>

</ejb-reference-description>
The reference-description stanza maps a resource reference defined in ejb-jar.xml to the JNDI name of an actual resource available in WebLogic Server. The ejb-ref-name specifies a resource reference name. This is the reference that the EJB provider places within the ejb-jar.xml deployment file. The jndi-name specifies the JNDI name of an actual resource factory available in WebLogic Server.

The iiop:1.2 contained in the <jndi-name> section. This release contains an implementation of GIOP (General-Inter-Orb-Protocol) 1.2. The GIOP specifies formats for messages that are exchanged between inter-operating ORBs. This allows interoperability with many other ORBs and application servers. The GIOP version can be controlled by the version number in a corbaname or corbaloc reference.
These methods are not required when using WLInitialContextFactory in RMI clients or can be avoided by using the WebLogic C++ client.