| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > Programming WebLogic RMI over IIOP > Configuring WebLogic Server for RMI-IIOP |
|
Programming WebLogic RMI over IIOP
|
Configuring WebLogic Server for RMI-IIOP
The following sections describe concepts and procedures relating to configuring WebLogic Server for RMI-IIOP:
Because insufficient standards exist for propagating client identity from a CORBA client, the identity of any client connecting over IIOP to WebLogic Server will default to "guest." 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="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. EJBean 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.
WebLogic Server 7.0 supports RMI-IIOP corbaname and corbaloc JNDI references. Please refer to 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.
Note the iiop:1.2 contained in the <jndi-name> section. WebLogic Server 7.0 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 interoperatability with many other ORBs and application servers. The GIOP version can be controlled by the version number in a corbaname or corbaloc reference.
Using RMI-IIOP with SSL and a Java Client
The Java clients that support SSL are the thin client and theWLS-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.
Here are the main steps to create the objects that work together to delegate CORBA calls to an object hosted by WebLogic Server.
The following is a diagram of a CORBA client invoking an EJBean by delegating the call to an implementation class that connects to the server and operates upon the EJBean. 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 througout the JNDI tree and delegate the appropriate calls to the CORBA object.
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:
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();
}
}
}
For more information on how to implement a startup class, see Starting and Stopping WebLogic Servers.
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:
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
BEA Systems 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 seaparate. 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 specification at http://cgi.omg.org/cgi-bin/doc?formal/99-10-07 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 (see the SAMPLES_HOME/server/src/examples/iiop/ejb/entity/server/wls and SAMPLES_HOME/server/src/examples/iiop/ejb/entity/cppclient directories).
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 unmarshall it.
Examples of this in the sample SAMPLES_HOME/server/src/examples/iiop/ejb/entity/cppclient are EJBObjectEnum and Vector. 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 unmarshall the value type manually. See SAMPLES_HOME/server/src/examples/iiop/ejb/enity/tuxclient/ArrayList_i.cpp for an example of how to do so.
Note: 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.
RMI-IIOP Code Examples Package
The examples.iiop package is in the SAMPLES_HOME/server/src/samples/examples/iiop directory and demonstrates connectivity between numerous clients and applications. The examples demonstrate using EJB's with RMI-IIOP, connecting to C++ clients, and setting up interoperability with a Tuxedo Server. Refer to the example documentation for more details. For examples pertaining specifically to WebLogic Tuxedo Connector, see the /wlserver6.1/samples/examples/wtc directory.
WebLogic RMI-IIOP is intended to be a complete implementation of RMI. Please refer to the release notes for any additional considerations that might apply to your version.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||