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




























Class / Interface in Package java.rmi.activation


Functionality


JLCA 3.0 Coverage


Description


ActivateFailedException


ActivationException


UnknownGroupException


UnknownObjectException


Exceptions


Converted


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


Activatable


 


This class provides support for remote objects that require persistent access over time and that can be activated by the system.


Partially


Converted


 


Converted to System.MarshalByRefObject. All members inside Activatable are not converted as Activation is handled differently in .NET Framework. Activatable remote objects only differ in the registration process.


ActivationDesc


ActivationInstantiator


 


These provides necessary information to activate an object.


Not Converted


 


 


Activation is handled differently in .NET Framework.


Remote objects could be server-activated or client-activated.


Namespace System.Runtime.Remoting.Activation provides basic functionality for remote objects activation.


ActivationGroup


ActivationGroup_Stub


ActivationGroupDesc


ActivationGroupID


ActivationMonitor


ActivationSystem


These classes support the activatable objects in group.


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























Class / Interface in Package java.rmi.dgc


Functionality


JLCA 3.0 Coverage


Description


dgc.DGC


 


This interface is used for the server side of the distributed garbage collection algorithm.


Not


Converted


Namespace System.Runtime.Remoting.Lifetime manages the lifetime of remote objects.


dgc.VMID


This is an identifier that is unique across all Java virtual machines.


dgc.Lease


 


This Lease object is used to request and grant leases to remote object references.


Converted


 


Maps to System.Runtime.Remoting.Lifetime.ClientSponsor. It could work like a traditional distributed garbage collector.


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 (2)

  1. As I promised, I have posted the JLCA 3.0 cheat sheet for the users on my Blogs. The aim of this exercise…

  2. As I promised, I have posted the JLCA 3.0 cheat sheet for the users on my Blogs. The aim of this exercise…

Skip to main content