|
|
|
|
|
|
There are several packages shipped as part of WebLogic Enterprise (WLE) RMI on IIOP. The public application programming interface (API) includes the WLE implementation of the Java RMI base classes and, for compatibility, the equivalent WebLogic Server (WLS) packages (weblogic.rmi
). The WLE implementation also includes the WebLogic RMI code generator (weblogic.rmic
).
Writing an application that uses remote method invocation (RMI) is essentially characterized by using the RMI API.
This topic includes the following sections:
For detailed API reference information on the packages described in this topic, see the the WebLogic Enterprise API Javadoc page You can use either the Sun Microsystems, Inc. JavaSoft RMI related packages and classes or the BEA WebLogic RMI packages and classes to create WLE RMI applications. For compatibility with BEA WebLogic Server (WLS) the java.rmi
classes are also implemented as weblogic.rmi
classes.
Table 7-1 shows the Sun JavaSoft and BEA WebLogic packages that make up the "WebLogic Enterprise RMI API." The packages shown are generally supported in WLE but with some differences which are summarized in the table. Details on how WLE RMI differs from Sun JavaSoft RMI are provided in the section What is different in WebLogic Enterprise RMI API?. Please be sure to read this section.
Overview of WebLogic Enterprise RMI Packages
Table 7-2 shows other J2EE packages that provide additional functionality needed to create WLE RMI classes.
The WebLogic Enterprise (WLE) RMI API is a subset of the Java Development Kit 2 RMI API. As such, it supports most aspects of the Java Enterprise Edition (J2EE) including use of Java Naming and Directory Interface (JNDI) and transactions services which are needed to interact with EJBs. In WLE, RMI is hosted on IIOP which means firewalls configured to support IIOP traffic will accept WebLogic RMI on IIOP messages as standard IIOP messages.
WLE RMI supports use of RMI classes in java.rmi
, but you need to be aware of the specific implementation of these packages in the WLE RMI development environment. WLE RMI differs from the Sun JavaSoft RMI implementation. Keep these differences in mind when you are:
What is different in WebLogic Enterprise RMI API?
The differences are summarized in the following sections:
In WLE RMI, connection bootstrapping is achieved by creating an InitialContext
via the Java Naming and Directory Interface (JNDI) with javax.naming
.
Optionally, the JNDI WLEContext.SECURITY_AUTHENTICATION
property can be used for security. Also, the property keys shown in the topic JNDI Property Keys for BEA Tuxedo Style Authentication can be used for BEA Tuxedo style authentication.
For more information about JNDI, see Using the WLE SPI Implementation for JNDI in the WebLogic Enterprise online documentation.
For more information about using JNDI for security, see Writing a WLE Enterprise JavaBean that Implements Security in Using Security in the WebLogic Enterprise online documentation.
All J2EE Java remote client applications must first create environment properties. The initial context factory uses the various properties to customize the InitialContext
for a specific environment. You can set these properties by using a Hashtable. These properties, which are name-to-value pairs, determine how the WLEInitialContextFactory
creates the WLEContext
:
Set this property to the WLE initial context factory "com.beasys.jndi.WLEInitialContextFactory
" to access the WLE domain and remote naming services.
The class com.beasys.jndi.WLEInitialContextFactory
provides the implementation for delegating JNDI methods to the WLE JNDI implementation. The com.beasys.jndi.WLEInitialContextFactory
provides an entry point for a client into the WLE domain namespace. (See Listing 7-1 for an example.)
Listing 7-1
WLEContext.INITIAL_CONTEXT_FACTORY Property Example
Hashtable env = new Hashtable(); Connection Bootstrapping and Security Differences
JNDI Environment Properties
WLEContext.INITIAL_CONTEXT_FACTORY
/*
* Specify the initial context implementation to use.
* The service provider supplies the factory class.
*/
env.put(WLEContext.INITIAL_CONTEXT_FACTORY,
"com.beasys.jndi.WLEInitialContextFactory");
.
.
.
Set the URL of the service provider with the property name java.naming.provider.url . This property value should specify an IIOP Listener/Handler for the desired WLE target domain. (See Listing 7-2 for an example.)
Listing 7-2 WLEContext.PROVIDER_URL Property Example
.
.
.
env.put(WLEContext.PROVIDER_URL,
"corbaloc://myhost:1000");
.
.
.
The host and port combination that is specified in the URL must match the ISL parameter in the WLE domain's UBBCONFIG file. The format of the host and port combination, as well as the capitalization, must match. If the addresses do not match, the communication with the WLE domain fails.
A WLE server that acts as a client must set the WLEContext.PROVIDER_URL property as an empty string or null. The server client connects to the current application in which it is booted.
The WLE system supports different levels of authentication. The SECURITY_AUTHENTICATION value determines whether certificate-based SSL authentication authentication is attempted or BEA TUXEDO style authentication is used.
Valid values for this property key are "none ", "simple ", or "strong ", as recommended by the Sun Microsystems Inc. JNDI specification. (See Listing 7-3 for an example.)
Listing 7-3 WLEContext.SECURITY_AUTHENTICATION Example
.
.
.
env.put(WLEContext.SECURITY_AUTHENTICATION,
"strong");
.
.
.
If "none " is specified then no authentication is attempted.
If "strong " is specified then certificate-based authentication is attempted using SSL protocols.
If the SECURITY_AUTHENTICATION "simple " or not specified, then the BEA Tuxedo style authentication is used. See the next section for information about the WLE specific keys used to support BEA TUXEDO style authentication.
WLE supports use of the several keys from javax.naming.Context for security as shown in Table 7-4.
Listing 7-4 includes the WLE keys used to define Username/Password authentication.
Listing 7-4
WLE Keys for Username/Password Authentication
...
//Password-Based Authentication
env.put(WLEContext.SECURITY_AUTHENTICATION, "simple");
env.put(WLEContext.SYSTEM_PASSWORD, "RMI");
env.put(WLEContext.SECURITY_PRINCIPAL, "sams");
env.put(WLEContext.CLIENT_NAME, "writers");
env.put(WLEContext.SECURITY_CREDENTIALS, "password");
Listing includes the WLE keys used to define certificate-based authentication.
Listing 7-5 WLE Keys for Certificate-Based Authentication
...
//Certificate-Based Authentication
env.put(WLEContext.SECURITY_AUTHENTICATION, "strong");
env.put(WLEContext.SYSTEM_PASSWORD, "SSL");
env.put(WLEContext.SECURITY_PRINCIPAL, "sams");
env.put(WLEContext.SECURITY_CREDENTIALS, "credentials");
...
Stubs and skeletons for WLE RMI applications are generated by running the Weblogic RMI compiler (weblogic.rmic ) against the remote class. A stub is the client-side proxy for a remote object that forwards each WLE RMI call to its matching server-side skeleton, which in turn forwards the call to the actual remote object implementation.
WLE does not support java.rmi.Naming and therefore has no rmiregistry tool. (Use of JNDI is supported instead.)
The only RMI configuration property used for WLE RMI is weblogic.system.startupClass. <virtualName> which is used to register the RMI implementation at startup time. An example of using a startup properties file is provided in Using a Startup Properties File.
The Javasoft RMI specification defines several properties. None of these have any effect on the WLE RMI implementations.
|
|
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|