Share via

JLCA 3.0 - Remote Method Invocation (RMI and RMI-IIOP)

  • Article

RMI provides an easy access to objects on remote machines. The server application registers objects on RMIregistry or a naming service and the client application gets the object’s references on a remote machine. RMI-IIOP architecture is a hybrid between RMI and CORBA and it works as simply as a RMI. It has the same flexibility as RMI with the powerful features of running over Internet Inter-ORB Protocol (IIOP). RMI and RMI-IIOP are primarily converted to .NET framework through System.Remoting, System.Security APIs and System.MarshalByRefObject class.

 

Mainly, JLCA 3.0 helps to convert the following features of RMI: Interfaces, Exceptions, Client and Server Sides, Registration, Security and System Properties. Moreover RMI-IIOP includes: Interfaces and their implementation and Client and Server Sides.

 

Table 15, Table 16,Table 17,Table 18,Table 19 and Table 20 contain relevant details for RMI conversion. In a summarized manner, they enunciate the RMI features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting applications using RMI.

 

Coverage Details

Table 15: RMI Conversion Coverage (1) – Package java.rmi.activation

Table 16: RMI Conversion Coverage (2) – Package java.rmi.dgc

Class / Interface in Package java.rmi.registry

Functionality

JLCA 3.0 Coverage

Description

LocateRegistry

LocateRegistry is used to create or get a remote object registry that accepts calls on a specific port.

Not

Converted

In .NET Framework, remote objects publishing/exposing is done using channels and not through a registry. Interaction between client and server works different.

Registry

Registry is a remote interface to a simple remote object registry that provides methods for storing and retrieving remote object references bound with arbitrary string names.

Converted

 

Converted to System.Runtime.Remoting.RemotingConfiguration.

Its use is limited to configure the remoting infrastructure; it could track registered remote objects. .NET Framework Remoting offers registering remote objects in a different way.

RegistryHandler

RegistryHandler is an interface used internally by the RMI runtime.

Not Converted

 

In .NET Framework, this is handled differently.

 

Table 17: RMI Conversion Coverage (3) – Package java.rmi.registry

Class / Interface in Package java.rmi.server

Functionality

JLCA 3.0 Coverage

Description

ExportException

ServerCloneException

ServerNotActiveException

SkeletonMismatchException

SkeletonNotFoundException

SocketSecurityException

Exceptions

Converted

These exceptions are converted to System.Runtime.Remoting.RemotingException.

LoaderHandler

RMIClassLoader

These provide methods to support dynamic class loading with RMI.

Not Converted

 

In .NET Framework Remoting has no availability to load classes and security contexts. This feature does not apply for .NET Framework.

LogStream

LogStream provides a mechanism for logging errors.

Not

Converted

In .NET Framework, extensions for error logging are not applicable.

ObjID

RemoteCall

UID

UID - identifier that is unique over time with respect to the host.

ObjID – identifier to remote object exported to an RMI runtime.

Not Converted

 

In .NET Framework, the representation of remote objects and remote calls is hidden and internally handled.

Operation

RemoteStub

RemoteStub is the common superclass to client implementations and provides the framework to support a wide range of remote reference semantics.

Not Converted

 

In .NET Framework, Remoting does not have to provide a description of a remote method using Stub files.

RemoteObject UnicastRemoteObject

RemoteObject class implements the java.lang.Object behavior for remote objects.

UnicastRemoteObject class defines a non-replicated remote object whose references are valid only while the server process is alive.

Converted

 

Converted to System.MarshalByRefObject.

It enables access to objects across application domain boundaries in applications that support remoting.

RemoteRef

Unreferenced

RemoteRef – handle for remote object.

Unreferenced – notify when there are no clients reference the remote object.

Not Converted

 

 

In .NET Framework, this is handled differently.

In .NET Framework, remote-objects don't receive incoming calls. Instead, a registered channel receives the client requests and handles it internally.

RemoteServer

RemoteServer is the common superclass to server implementations and provides the framework to support a wide range of remote reference semantics.

Not Converted

 

In .NET Framework,for safely exporting the remote-object, the user must register a channel to listen on a specific port. Then, expose the remote-object by using System.Runtime.Remoting.

RMIClientSocketFactory

RMIServerSocketFactory

RMISocketFactory

Used to obtain client and server sockets for RMI calls.

Converted

 

In .NET Framework, the user has no control over the internal creation of remoting sockets.

Classes System.Net.Sockets.TcpClient and System.Net.Sockets.TcpListener provide TCP services for connecting, sending, and receiving data over a network.

Class TcpListener listens for connections coming from TCP clients.

RMIFailureHandler

RMIFailureHandler handles the failure of RMI runtime unable to create a ServerSocket to listen for incoming calls.

Not Converted

 

 

In .NET Framework, the error handling of the channel-registering is not controlled by the user. Any error is automatically handled by class RemotingException.

ServerRef

Skeleton

ServerRef - server-side handle for a remote object implementation.

Skelton - server-side entity that dispatches calls to the actual remote object implementation.

Not Converted

 

In .NET Framework, proxy-like objects and filtering processes are natively supported when a client activates a remote-object and works with its representation and ensures forwarding any call to the concrete object.

Table 18: RMI Conversion Coverage (4) – Package java.rmi.server

Class / Interface in Package java.rmi

Functionality

JLCA 3.0 Coverage

Description

AccessException

AlreadyBoundException

ConnectException

ConnectIOException

MarshalException

NoSuchObjectException

RemoteException

RMISecurityException

Exceptions

Converted

These exceptions are converted to System.Runtime.Remoting.RemotingException.

MarshalledObject

A MarshalledObject contains a byte stream with the serialized representation of an object given to its constructor.

Not

Converted

 

Class System.MarshalByRefObject enables access to objects across application domain boundaries. Also, class System.Runtime.Remoting.ObjRef stores all relevant information required to generate a proxy to communicate with a remote-object.

Naming

Naming class provides methods for storing and obtaining references to remote objects in a remote object registry.

Converted

 

All the members are mapped to members of System.Runtime.Remoting.RemotingServices.

RMISecurityManager

Provides an example security manager for use by RMI applications that use downloaded code.

Partially Converted

 

Converted to System.Security.SecurityManager.

.NET Framework has static methods to interact with the security system.

ServerError

ServerException

These are thrown as a result of remote method invocation when an error or exception occurs.

Converted

Converted to System.Runtime.Remoting.ServerException.

Table 19: RMI Conversion Coverage (5) – Package java.rmi

Issues

Issue

Description

Custom Registry

Server applications using custom registries to publish remote objects (using related classes such as java.rmi.registry.LocateRegistry) are not converted.

A workaround could be required to create and use a listener channel on the original port used in the Java server.

Dynamic Class Loading

Although in .NET Framework, there are ways for loading dynamically external libraries/assemblies, there is no equivalent for RMI Dynamic Class Loading features (such as use java.rmi.server.RMIClassLoader).

A workaround could require re-designing the target application and deployment procedures in order to adapt client applications to use static class loading schema (compilation-time).

General Issues

RMI conversion requires user intervention. The Stub and Skeleton files could be ignored for target applications as they are not used in the target code. Also, RMI conversion creates a shared project: a class library named as “RMIInterface” (inside a folder “RMIInterface”). It contains all remote interfaces shared for both server and client applications.

If RMI server and clients are converted at the same time, the target project contains all the target code (except the remote interfaces which were moved to the class library project). The user has to split the target code in two separate projects for both server and client applications.

RMI conversion generates a Remoting Configuration File (.config) to include special behavior.

RMI Activation

Activatable remote objects are converted to non-activatable remote objects. RMI Activation features are not converted because .NET Framework manages the [de]activation on remote objects differently.

A workaround could be required to manage the activatables and activation groups using namespace System.Runtime.Remoting.Activation. Remote-object state persistence could be required to adapt the remote objects to manage files and reset states.

RMI Client Applications

RMI client conversion only covers the creation of the remote-object instances (before performed through java.rmi.Naming.lookup).

The user should create as many C# Projects as client applications exist. Each C# Project should contain all source needed to compile/run individually. The user must add the reference to the RMI Shared Class Library (RMIInterface).

Conversion of remote objects references lookup is done through method Activator.GetObject. The target invocations should be manually reviewed to adjust the URL (machine and port) corresponding to the remote objects server. The user could be required to fix the target type of remote objects (in castings too).

RMI Security

Although java.rmi.RMISecurityManager is converted, .NET Framework Remoting manages security differently. Issues related to setting up the security properties and policy files are not converted.

A workaround could be required to the use of namespace System.Security and configuration files specifying the credential on remote objects. Another approach could be to implement the interface System.Runtime.Remoting.Messaging.IMessageSink.

RMI Server Application

RMI conversion’s target project could be used as the base project for the server application.

The user must add the reference to the RMI Shared Class Library (RMIInterface). All files moved/contained in this shared project should be excluded because they are used through the added reference. The user should also exclude the code of client applications because it is contained in the user-created projects for client applications.

Moreover, the target invocations corresponding to remote-object publishing (before performed through java.rmi.Naming.bind) should be reviewed in order to adjust the target port for the remote objects available to clients (in calls ChannelServices.RegisterChannel). The user should take into account that same channel (port) can be registered only one time.

RMI Shared Project(RMI Interface)

The automatically generated project is intended to include the common (or shared) source code inherent in RMI applications (between RMI servers and clients). JLCA moves only the remote interfaces to this project. It renames their target namespace appending the prefix “IRemoting.”.

However, the user must move -to this library- all the source code which the remote interfaces are depending on. Also, the user should move the Compatibility Classes to it (SupportClass.cs). All code that is moved will be shared between server and client applications because they are shared in Java too.

Finally, the user must compile this class library in order to use and reference from the respective projects.

RMI System Properties

Use of RMI’s System properties to configure the RMI behavior is not converted. But some related functionality could be obtained in .NET.

A workaround could be required to set-in-code, the behavior through .NET Remoting API and using a Remoting Configuration File.

RMI-IIOP Issues

Conversion for an application using RMI-IIOP will be successful if both server and client applications are developed in Java. If not, it require a re-write or a wrap in the non-Java application in order to use Remoting services.

Table 20 : RMI Conversion Issues

Comments

  • Anonymous
    June 18, 2006
    The comment has been removed
  • Anonymous
    June 18, 2006
    The comment has been removed