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

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