RMI System Architecture

[TOC] [Prev] [Next]

Topics:

OverviewArchitectural OverviewThe Stub/Skeleton LayerThe Remote Reference LayerThe Transport LayerGarbage Collection of Remote ObjectsSecurityDynamic Stub Loading

The RMI system consists of three layers: the stub/skeleton layer, the remote reference layer, and thetransport layer. The boundary at each layer is defined by a specific interface and protocol; each layer,therefore, is independent of the next and can be replaced by an alternate implementation without affectingthe other layers in the system. For example, the current transport implementation is TCP-based (using Javasockets), but a transport based on UDP could be substituted.

To accomplish transparent transmission of objects from one address space to another, the technique of objectserialization (designed specifically for the Java language) is used. Object serialization is described in thischapter only with regard to its use for marshaling primitives and objects. For complete details, see the RMIsystem's companion specification, Object Serialization in the Java System.

Another technique, called dynamic stub loading, is used to support client-side stubs which implement thesame set of remote interfaces as a remote object itself. This technique, used when a stub of the exact type isnot already available to the client, allows a client to use the Java language's built-in operators for casting andtype-checking.

The RMI system consists of three layers:

The stub/skeleton layer - client-side stubs (proxies) and server-side skeletonsThe remote reference layer - remote reference behavior (e.g. invocation to a single object or to areplicated object)The transport layer - connection set up and management and remote object tracking

The application layer sits on top of the RMI system. The relationship between the layers is shown in thefollowing figure.

System Architecture http://www.tns.lcs.mit.edu/manuals/java-rmi-alpha2/rmi-spec/rmi-arch.do...

1 of 9 3/23/2014 8:20 AM

A remote method invocation from a client to a remote server object travels down through the layers of theRMI system to the client-side transport, then up through the server-side transport to the server.

A client invoking a method on a remote server object actually makes use of a stub or proxy for the remoteobject as a conduit to the remote object. A client-held reference to a remote object is a reference to a localstub. This stub is an implementation of the remote interfaces of the remote object and forwards invocationrequests to that server object via the remote reference layer.

The remote reference layer is responsible for carrying out the semantics of the invocation. For example theremote reference layer is responsible for determining whether the server is a single object or is a replicatedobject requiring communications with multiple locations. Each remote object implementation chooses its ownremote reference semantics-whether the server is a single object or is a replicated object requiringcommunications with multiple locations.

Also handled by the remote reference layer are the reference semantics for the server. The remote referencelayer, for example, abstracts the different ways of referring to objects that are implemented in (a) servers thatare always running on some machine, and (b) servers that are run only when some method invocation is madeon them. At the layers above the remote reference layer, these differences are not seen.

The transport is responsible for connection set-up, connection management, and keeping track of anddispatching to remote objects (the targets of remote calls) residing in the transport's address space.

In order to dispatch to a remote object, the transport forwards the remote call up to the remote referencelayer. The remote reference layer handles any server-side behavior that needs to be done before handing offthe request to the server-side skeleton. The skeleton for a remote object makes an up-call to the remote objectimplementation which carries out the actual method call.

The return value of a call is sent back through the skeleton, remote reference layer and transport on the serverside, and then up through the transport, remote reference layer and stub on the client side.

The stub/skeleton layer is the interface between the application layer and the rest of the RMI system. Thislayer does not deal with specifics of any transport, but transmits data to the remote reference layer via theabstraction of marshal streams. Marshal streams employ a mechanism called object serialization whichenables Java objects to be transmitted between address spaces. Objects transmitted using the objectserialization system are passed by copy to the remote address space, unless they are remote objects, in whichcase they are passed by reference.


2 of 9 3/23/2014 8:20 AM

A stub for a remote object is the client-side proxy for the remote object. Such a stub implements all theinterfaces that are supported by the remote object implementation. A client-side stub is responsible for:

Initiating a call to the remote object (by calling the remote reference layer).Marshaling arguments to a marshal stream (obtained from the remote reference layer).Informing the remote reference layer that the call should be invoked.Unmarshaling the return value or exception from a marshal stream.Informing the remote reference layer that the call is complete.

A skeleton for a remote object is a server-side entity that contains a method which dispatches calls to theactual remote object implementation. The skeleton is responsible for:

Unmarshaling arguments from the marshal stream.Making the up-call to the actual remote object implementation.Marshaling the return value of the call or an exception (if one occurred) onto the marshal stream.

The appropriate stub and skeleton classes are determined at run time and are dynamically loaded as needed.Dynamic Stub Loading describes in detail how the stubs are located and how their actions are constrained.

The remote reference layer deals with the lower level transport interface. This layer is also responsible forcarrying out a specific remote reference protocol which is independent of the client stubs and serverskeletons.

Each remote object implementation chooses its own remote reference subclass that operates on its behalf.Various invocation protocols can be carried out at this layer, for example:

Unicast point-to-point invocation.Invocation to replicated object groups.Support for a specific replication strategy.Support for a persistent reference to the remote object (enabling activation of the remote object).Reconnection strategies (if remote object becomes inaccessible).

The remote reference layer has two cooperating components: the client-side and the server-side components.The client-side component contains information specific to the remote server (or servers, if the remotereference is to a replicated object) and communicates via the transport to the server-side component. Duringeach method invocation, the client and server-side components perform the specific remote referencesemantics. For example, if a remote object is part of a replicated object, the client-side component canforward the invocation to each replica rather than just a single remote object.

In a corresponding manner, the server-side component implements the specific remote reference semanticsprior to delivering a remote method invocation to the skeleton. This component, for example, could handleensuring atomic multiple delivery by communicating with other servers in the replica group.

The remote reference layer transmits data to the transport layer via the abstraction of a stream-orientedconnection. The transport takes care of the implementation details of connections. Although connectionspresent a streams-based interface, a connectionless transport may be implemented beneath the abstraction.


3 of 9 3/23/2014 8:20 AM

In general, the transport layer of the RMI system is responsible for:

Setting up connections to remote address spaces.Managing connections.Monitoring connection "liveness."Listening for incoming calls.Maintaining a table of remote objects that reside in the address space.Setting up a connection for an incoming call.Locating the dispatcher for the target of the remote call and passing the connection to this dispatcher.

The concrete representation of a remote object reference consists of an endpoint and an object identifier. Thisrepresentation is called a live reference. Given a live reference for a remote object, a transport can use theendpoint to set up a connection to the address space in which the remote object resides. On the server side,the transport uses the object identifier to look up the target of the remote call.

The transport for the RMI system consists of four basic abstractions:

An endpoint is the abstraction used to denote an address space or Java virtual machine. In theimplementation, an endpoint can be mapped to its transport. That is, given an endpoint, a specifictransport instance can be obtained.A channel is the abstraction for a conduit between two address spaces. As such, it is responsible formanaging connections between the local address space and the remote address space for which it is achannel.A connection is the abstraction for transferring data (performing input/output).The transport abstraction manages channels. Each channel is a virtual connection between two addressspaces. Within a transport, only one channel exists per pair of address spaces, the local address spaceand a remote address space. Given an endpoint to a remote address space, a transport sets up a channelto that address space. The transport abstraction is also responsible for accepting calls on incomingconnections to the address space, setting up a connection object for the call, and dispatching to higherlayers in the system.

A transport defines what the concrete representation of an endpoint is, so multiple transport implementationsmay exist. The design and implementation also supports multiple transports per address space, so both TCPand UDP can be supported in the same virtual machine.

In a distributed system, just as in the local system, it is desirable to automatically delete those remote objectsthat are no longer referenced by any client. This frees the programmer from needing to keep track of theremote objects clients so that it can terminate appropriately. RMI uses a reference counting garbage collectionalgorithm similar to Modula-3's Network Objects. (see "Network Objects" by Birrell, Nelson, and Owicki,Digital Equipment Corporation Systems Research Center Technical Report 115, 1994)

To accomplish reference-counting garbage collection, the RMI runtime keeps track of all live referenceswithin each Java virtual machine. When a live reference enters a Java virtual machine its reference count isincremented. The first reference to an object sends a "referenced" message to the server for the object. Aslive references are found to be unreferenced in the local virtual machine, their finalization decrements thecount. When the last reference has been discarded an unreferenced message is sent to the server. Manysubtleties exist in the protocol, most related to maintaining the ordering of referenced and unreferencedmessages to insure the object is not prematurely collected.


4 of 9 3/23/2014 8:20 AM

When a remote object is not referenced by any client, the RMI runtime refers to it using a weak reference.The weak reference allows the Java virtual machine's garbage collector to discard the object if no other localreferences to the object exist. The distributed garbage collection algorithm interacts with the local Java virtualmachine's garbage collector in the usual ways by holding normal or weak references to objects. As in thenormal object life-cycle finalize will be called after the garbage collector determines that no morereferences to the object exist.

As long as a local reference to a remote object exists, it cannot be garbage collected and it may be passed inremote calls or returned to clients. Passing a remote object adds the client or server to which it was passed tothe referenced set. A remote object needing unreferenced notification must implement thejava.rmi.server.Unreferenced interface. When those references no longer exist, unreferenced will beinvoked. unreferenced is called when the set of references is found to be empty so it may be called morethan once. Remote objects are only collected when no more references, either local or remote, still exist.

Note that if there exists a network partition between a client and remote server object, it is possible thatpremature collection of the remote object will occur (since the transport may think that the client crashed).Because of the possibility of premature collection, remote references cannot guarantee referential integrity; inother words, it is always possible that a remote reference may in fact not refer to an existing object. Anattempt to use such a reference will generate a RemoteException which must be handled by the application.

Warning: Loading classes from untrusted sources exposes clients or servers to a broadrange of malicious attacks. You should disable class loading unless you understand and

accept the potential risks.

The security of a process using RMI is protected by the existing security manager and class loader that arepart of the core Java system. The security manager regulates access to sensitive functions, and the classloader makes sure that loaded classes are subject to the security manager and adhere to the standard Javasafety guarantees.

However, the JDK 1.0 security manager does not regulate resource consumption, so the current RMI systemhas no mechanisms available to prevent classes loaded from abusing resources. In addition, it is possible thatmethods invoked by the system, for example the hashCode, equals, and toString methods, might containtrojan horses. As new security manager mechanisms are developed, RMI will use them.

In the applet environment, the AppletSecurityManager and AppletClassLoader are used exclusively.RMI uses only the established security manager and class loader. In this environment remote object stubs andparameter and return object classes can be loaded only from the applet host or its designated code base hosts.This requires that applet developers install the appropriate classes on the applet host.

In the server environment, where a Java process is being used to serve RMI requests, the server may need touse a security manager to isolate itself from stub misbehavior. The server functions will usually beimplemented by classes loaded from the local system and therefore not subject to the restrictions of the


5 of 9 3/23/2014 8:20 AM

security manager. If the remote object interfaces allow objects, either local or remote, to be passed to theserver, then those object classes must be accessible to the server. Usually those classes will be built-in classesor will be defined by the server. As long the classes are available locally there is no need for a specializedsecurity manager or stub loader. To support this case, if is no security manager is specified, stub loading fromnetwork sources is disabled.

When a server is passed a remote object for which it has no corresponding stub code, it may also be passedthe location from which the classes for that remote object may be loaded. Two properties control if and fromwhere the stub class can be loaded.

java.rmi.server.ClientClassDisable controls whether the URL's supplied by clients are used, ifset to true, URL's from clients are ignored and stub classes are loaded using the stub class base.java.rmi.server.StubClassBase defines the URL from which stub classes will be loaded. This is theURL that is passed along with remote object references so clients will know from where to load stubclasses.

RMI attempts to use the StubClassLoader to load the classes. If it succeeds those classes will be subject tothe current security manager and any classes the stub needs will be loaded and then regulated by that securitymanager. If the security manager disallows creating the class loader, the stub will be loaded using the defaultClass.forName mechanism. Thus, a server may define its own policies via the security manager and stubloader and the RMI system will operate within them.

In remote procedure call systems, client-side stub code must be generated and linked into a client before aremote procedure call can be done. This code may be either statically linked into the client or linked in atrun-time via dynamic linking with libraries available locally or over a network file system. In either the caseof static or dynamic linking, the specific code to handle an RPC must be available to the client machine incompiled form.

RMI generalizes this technique to load the exact stub code (in the Java language's architecture neutralbytecode format) at run-time to handle method invocations on a remote object. This mechanism, calleddynamic stub loading, exploits the Java mechanism for downloading code. Normally stubs can be dynamicallyloaded from the local file system, in which case there are no security manager restrictions. However, whenloaded from the network, those classes loaded must be restricted by the security manager.

Dynamic stub loading is used only when code for a needed stub is not already available. The argument andreturn types specified in the remote interfaces are made available using the same mechanism. Loadingarbitrary classes into clients or servers presents a potential security problem which is addressed below.

In this scheme, client-side stub code is generated from the remote interfaces of the implementation class andsupport the same set of remote interfaces. Such stub code resides on the server's host (or perhaps anotherlocation), and can be downloaded to the client on demand (if the correct stub code is not already available tothe client). Stub code for a remote implementation could be generated on-the-fly at the remote site andshipped to the client or could be generated on the client-side from the list of remote interfaces supported bythe remote implementation.

Dynamic stub loading employs three mechanisms: a Java class loader, a security manager and the objectserialization system. When a remote object reference is passed as a parameter or as the result of a methodcall, the marshal stream that transmits the reference includes information indicating where the stub class forthe remote object can be loaded from, if its URL is known.


6 of 9 3/23/2014 8:20 AM

A marshal stream is implemented by an underlying object serialization stream. These streams provide anopportunity to embed information for each class and object that is transmitted. When transmitting classinformation for a remote object being marshaled, a marshal stream embeds a URL that specifies where thestub code resides. Thus, when a reference to a remote object is unmarshaled at the destination site, themarshal stream can locate and load the stub code (via the class loader, checked by the security manager) sothat the correct stub is available to the client.

The Remote Method Invocation system can be used in several scenarios:

Applets can use RMI to invoke methods on objects supported on servers.Java applications can use RMI either in client-server mode or from peer to peer.

The differences in these scenarios come in two areas, security and loading of classes.

Applets are limited in many ways, though only the restrictions on network sockets and class loading affect theRMI system directly. In an Applet, any class that is needed must be loaded using the AppletClass loader. Theclasses needed are:

The RMI runtime.The classes of remote objects and their interfaces.The stub classes that serve as surrogates for the remote objects.Other classes used as parameters to or returns from remote interfaces.

Typically, the classes will be supplied by a Web server or by an FTP server as referenced in URL's embeddedin the HTML page containing the Applet. The RMI based service(s) used by the Applet must be on the sameserver because an Applet may only make network connections to the host from which it was loaded. Forexample, the normal Applet scenario uses a single host for:

The Web server providing the document.The Applet code.The RMI services.The bootstrap Registry.

In this scenario, all the RMI, stub, skeleton, and supporting classes are loaded from the Web server. All of theremote objects provided by the RMI service and passed to the Applet (which may pass them back to theserver) will be for classes that the RMI service already knows about. In this case, the RMI service is verysecure because it loads no classes from the network, and no security manager is needed.

In a related scenario, the Applet may create its own remote objects and pass them to the RMI service. If theclasses are all known to the service, there is no difference from the previous scenario. If, however, the appletuses classes unknown to the server to create new remote objects and passes them to the service, the servicewill need to load those classes. If the service is configured with a security manager, it may load the classesfrom the same location the Applet did.


7 of 9 3/23/2014 8:20 AM

Unlike Applets, applications written in the Java language using a client-server architecture can connect to anyhost, so more options are available for configuring the sources of classes and where RMI based services run.

Using the usual class loading mechanisms, classes can either be loaded from the local file system or from aWeb server.

Classes on the local file system can be found with the CLASSPATH environment variable. These classes arenot subject to the restrictions imposed by the security manager and are assumed to be trusted. Either or boththe applications and servers can load classes from the local file system.

Alternatively, a class loader can be used to load stubs from a Web server. The RMI Stub class loader is similarto the Applet class loader and is used to load classes from Web servers as needed by RMI. In the Stub classloader, classes will not be loaded from a Web server unless a security manager is present and when loaded theclasses are subject to the security manager restrictions. As with other class loaders, any stub class that refersto other classes will use the stub class loader and thus be subject to the security manager restrictions even ifthe referred-to classes are found on the local file system.

An application's need to dynamically load classes is always satisfied first from the local file system. If notfound locally, the RMI runtime needs to know where to find the class. Two mechanisms are used by the RMIruntime. As each remote object is passed to the application, the server, if configured to do so, may include theURL of the stub class. This URL is used to load the stubs. If not supplied, the RMI runtime uses a propertyconfigured by the application to load the stub. If this stub class base is not defined, the load will fail and themethod invocation will fail with an exception. So, either the server must tell the client where the stubs can befound, or the application itself must be configured to know. The application may disable the loading of stubsand force stubs to be loaded only from the locally defined stub class base.

For example, an application will usually load its initial classes locally, since (unlike Applets) there is nobuilt-in support for loading network classes. The remote objects used by the application will again come froma server. Unless the application is configured with a security manager, stubs will not be loaded even if theURL is supplied by the server. This keeps the application safe even from the server.

In another scenario, the application can use the RMI supplied security manager and stub loader to allowsstubs to be loaded from the URL supplied by the server. This allows more flexibility and extensibility.

Similar to the last Applet example, if the application creates and exports its own remote objects, then it willneed to supply the URL of those classes to the server(s). In many cases, those remote object classes will beloaded from a Web server and those URLs are passed on as needed. If however, the remote object classes arelocal to the application system, some provision will need to be made for those classes to be available via aWeb server and the stub class base to be configured so that the stubs of those remote objects can be loadedby servers. The easiest to manage is to put the classes on a Web server and have all the applications andservers load them from there.

For an RMI server to be able to pass on to clients the location of stub classes, the server must configure itsown stub code base with a URL that is used to retrieve needed classes, including both the RMI runtime, stub,parameter, and return classes. As in applications, classes are always loaded from the local file system if theyare available. When loaded by the core class loader, those classes are considered to be trusted and not subjectto the security manager. Once a class is loaded by a class loader, that same loader is used to resolve and loadall other classes it references even if they are loaded from the local file system.


8 of 9 3/23/2014 8:20 AM

The typical closed system scenario has the server configured to load no classes. The services it provides aredefined by remote interfaces that are all local to the server machine. The server needs no security managerand will not load classes even if clients send along the URL. If clients send remote objects for which theserver does not have stub classes, those method invocations will fail when the request is unmarshaled, and theclient will receive an exception.

The more open server system will define its stub class base so that stubs for the remote objects it exports canbe loaded by clients and so that the server can load stubs when needed for remote objects supplied by clients.The server will have both a security manager and stub class loader which protect the server.

A somewhat more cautious server can use the property java.rmi.server.ClientClassDisable to disablethe loading of classes from client supplied URLs. It can still load those classes from clients as well as the stubclasses need by its clients.

The JDK 1.0 security manager does not regulate resource consumption, so the current RMI system has nomechanisms available to prevent classes loaded from abusing resources. As new security managermechanisms are developed to control resource use, RMI will use them.

Applications using a peer-to-peer architecture are structured similarly to the client-server architecture. In thepeer-to-peer case, each Java application may support remote objects and needs to be configured with theURL that other applications will use to retrieve RMI runtime and remote object classes. Typically, a singleWeb server will be used to supply the remote classes, while the RMI based applications are distributed aroundthe network on servers or running on user's desktops. As in the other sceneries when classes are loaded intoan application a security manager must be present to protect the local environment from the loaded classes.Applications may define their own security manager or may use the restrictive stub security managerprovided with RMI.

[TOC] [Prev] [Next]

[email protected] 1996 Sun Microsystems, Inc. All rights reserved.


9 of 9 3/23/2014 8:20 AM

Documents

RMI System Architecture