RMI

  

The Remote Method Invocation protocol was designed to perform simple and powerful networking used by Java for distributed objects to communicate across JVMs and physical systems.

Recall from Chapter 26 that distributed objects are assembled into components to provide a distributed solution. Distributed protocols typically use three components : the business object, the skeleton, and the stub . Each business object class has an associated skeleton and stub classes. For instance, the business object Order class is associated with the Order_Skeleton and Order_Stub classes. The business object and skeleton reside in the server, and the stub resides in the client. Using the RMI protocol, the stub and skeleton classes make the business object appear as if it is running locally in the client's machine. The skeleton and stub are connected via the network.

The business object contains business logic and implements an interface that represents the exposed business methods . The stub implements the same interface. The stub implementation does not contain business logic. Instead, it implements the logic to communicate with the skeleton across the network. At the server side, the skeleton is associated to a port and IP address and listens for requests . When the client calls a method to be serviced by the business object, the stub receives the request. The stub then uses object serialization to marshal (and unmarshal ) the method invoked and the parameters passed to the method to send the information to the skeleton.

Because the skeleton is listening, it receives the request, unmarshals it, and identifies which method on the business object to invoke. Any return value is processed similarly: The skeleton receives the value from the business object, streams it, and passes it to the stub. The stub, in turn , passes it to the client as if it were processed locally. Figure 28-2 shows this interaction among the different parts of a distributed object using RMI.

click to expand
Figure 28-2: Parts of a distributed object using RMI

RMI security overview

To do remote invocation, RMI tries , in turn, the following. Whichever one succeeds first is used for subsequent communications. If none succeeds, the communication fails.

  • Communicate with the server's ports directly by using sockets. You can create any type of sockets you need, including encrypted sockets, via a socket factory provided by RMI.

  • Build a URL to the server's host and port and use an HTTP post request on the URL (using the skeleton information as the body). The return information is sent back in the body of the HTTP response.

  • Build a URL to the server's host using port 80 and a CGI script that forwards the posted RMI request.

The last two techniques allow the communication across a firewall and are significantly slower than the direct socket communication. The java.rmi.server.disableHttp property, if set to true , disables the use of HTTP for RMI calls; the default value is false .

You may want to log information of your RMI application for both client-side and server-side logging. You can use a logging configuration file and the java.util.logging API (new in J2SE v1.4) to configure RMI implementation logging. For instance, the java.rmi.server.logCalls property corresponds to the sun.rmi.server.call logger name and logs server-side remote calls and exceptions; and java.rmi.client.logCalls corresponds with the sun.rmi.client.call for the client.

RMI security is, not surprisingly, based on the Java security technologies such as automatic bytecode verification and secure class load at runtime. Therefore, the next section explores security managers and class loaders.

The RMISecurityManager

RMI requires that you install a security manager before exporting any server object or invoking a method on a server. You have the option to use the provided RMISecurityManager or to write your own. The RMISecurityManager restricts downloaded implementations from reading or writing from the computer or connecting to other systems behind your firewall. If you create your own, your classes are loaded using the default Class.forName.

Note  

The primordial class loader is used when java.lang.Class.forName is directly called. You can think of the primordial class as the root of the class loading tree.

The RMISecurityManager class extends the java.lang.SecurityManager class and provides the same security features. Chapter 18 describes the SecurityManager in more detail. Recall that at this time, the SecurityManager class does not provide mechanisms to regulate resources, and so the RMISecurityManager does not prevent resource abuse. This means that the RMI system operates within the policies established by the server defined via the security manager and class loader.

The RMIClassLoader

In RMI, the RMIClassLoader attempts to load classes from the network and throws an exception if a security manager is not in place. The security manager ensures that loaded classes satisfy Java safety.

Tip  

Applications must either define their own security managers or use the restrictive RMISecurityManager. If no security manager is in place, an application cannot load classes from network sources.

The property java.rmi.server.useCodebaseOnly is used to indicate if it is permitted to download a class from the URL embedded in the stream with a serialized object. This property is applicable to the client and server but not to applets. Classes directly accessed by a class already loaded by the RMIClassLoader are subject to the security manager's restrictions because RMIClassLoader also loads them. Some static methods of the java.rmi.server.RMIClassLoader delegate to an instance of a java.rmi.server.RMIClassLoaderSpi (new in J2SE v1.4) Service Provider Interface. This SPI can be configured to augment RMIClassLoader.

RMI over IIOP

Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) simply means that the program uses RMI interfaces and uses IIOP as the transport. It was developed by Sun and IBM and is based on the Java Language Mapping to OMG IDL ( http://cgi.omg.org/cgi-bin/doc?ptc/00-01-06 ) specification and the CORBA/IIOP 2.3.1 specification, formal/99-10-07 ( http://cgi.omg.org/cgi-bin/doc?formal/99-10-07 ).

RMI-IIOP uses the Java CORBA ORB and IIOP to allow you to write all the code in Java. You do not need to learn a separate IDL or mapping because RMI-IIOP allows developers to pass serializable Java objects between application components. You use the rmic compiler to generate the code necessary for connecting your application to any other CORBA-compliant code using IIOP including stubs, skeletons, and OMG IDL. For more information on rmic you can visit the http://java.sun.com/j2se/1.4/docs/tooldocs/solaris/rmic.html site.

The RMI-IIOP API is supported by the following packages:

  • org.omg.CORBA : Provides the mapping of the OMG CORBA APIs to the Java programming language, including the class ORB , which is implemented so that a programmer can use it as a fully functional Object Request Broker (ORB).

  • org.omg.PortableServer : Provides classes and interfaces for making the server side of your applications portable across multivendor ORBs.

In Java, Portable Object Adaptor (POA)-based Dynamic Skeleton Interface (DSI) servants inherit from the standard DynamicImplementation class, which inherits from the Servant class. The PortableServer module defines the native Servant type for the POA. In Java, the Servant type is mapped to the Java org.omg.PortableServer.Servant class. It serves as the base class for all POA servant implementations and provides a number of methods that may be invoked by the application programmer, as well as methods that are invoked by the POA itself, and may be overridden by the user to control aspects of servant behavior.

  • org.omg.CosNaming : Provides a naming service for Java IDL. The Object Request Broker Daemon (ORBD) also includes both a transient and persistent naming service.

The package and all its classes and interfaces are generated by running the idlj tool on the file nameservice.idl , which is a module written in OMG IDL.

  • javax.rmi.CORBA : Contains portability APIs for RMI-IIOP. These APIs provide a standard interface between the generated stubs and ties and the RMI-IIOP runtime. They also allow third-party ORBs to be used for RMI over IIOP as an alternative to the ORB supplied by Sun. They are not intended to be called directly from RMI-IIOP applications. See also the javax.rmi package.

  • javax.rmi : Contains user APIs for RMI-IIOP. These APIs are provided for use by RMI-IIOP applications, and provide equivalent semantics when running over either IIOP or JRMP. See also the javax.rmi.CORBA package.

Note  

For more information you can visit the RMI-IIOP site at http://java.sun.com/j2se/1.4/docs/guide/rmi-iiop/index.html .

  


Java Security Solutions
Java Security Solutions
ISBN: 0764549286
EAN: 2147483647
Year: 2001
Pages: 222

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net