There is a lot of research work pertaining to specific implementations of distributed object technologies. None of the researches sited thus far expose the inner workings of remote method invocation (RMI) from the perspective of a simulation model. Most publications are benchmark suits and implementation tests of the systems under study. This paper sites notable primitive object operations of RMI revealed by simulation study.
Keywords: Architecture, Distributed Object, Remote Method Invocation, Primitive Object Operations.
Ever since networking computers began to take hold it has become necessary to share resources and data in a cohesive manner. Therefore to facilitate sharing, computer applications use distributed objects in one form or another. The distributed applications range from large scale Enterprise Resource Planning applications that allow monitoring of all the diverse aspects of an average corporation, to file servers, web application servers, groupware servers, database servers and even print servers that enable several machines to share a single printer . Distributed Object Technologies have revolutionized distributed computing and is transforming businesses all over the world. Thus it is our belief that the advances in distributed object and component technologies need to be complemented by a clear understanding to guide developers in increasingly complex situations requiring the identification of an optimum (or very efficient) Distributed Object Architecture.
Computer architects have long relied on software simulation to study the functionality and performance of proposed software and hardware designs. This research uses computer modelling and simulation to reveal the inner working of java Remote Method Invocation (RMI), by Sun Microsystems, Inc. RMI allows the sharing of Java objects between Java Virtual Machines (JVM) across a network. An RMI application consists of a server that creates remote objects that conform to a specified interface, which are available for method invocation to client applications that obtain a remote reference to the object.
2. Remote Method Invocation (RMI)
For a client to locate a server object for the first time, RMI depends on a naming mechanism called an RMIRegistry that runs on the Server machine and holds information about available Server Objects . An RMI client acquires an object reference to an RMI server object by doing a lookup for a Server Object reference and invokes methods on the Server Object as if the RMI server object resided in the client's address space. RMI server objects are named using URLs and for a client to acquire a server object reference, it should specify the URL of the server object as you would with the URL to a HTML page. Since RMI relies on Java, it can be used on diverse operating system platforms from mainframes to UNIX boxes to Windows machines to handheld devices as long as there is a Java Virtual Machine (JVM) implementation for that platform . In addition to Javasoft and Microsoft, a lot of other companies have announced Java Virtual Machine ports. The following is the architecture of RMI:
Figure 1: RMI architecture 
The important parts of the RMI architecture are the stub class, the object serialization, and the server-side Run-time System. RMI technology architecture is based on one principle: the definition of behaviour and the implementation of this behaviour should be kept separate. RMI allows developers to separately store the behaviour description and its implementation code on several, separately working JVMs . This concept is ideal for distributed systems where the client needs to know only the definition of a service used and the server directly provides this service (its implementation). The architecture defines i) how objects are conducted, ii) how memory management works, in which place, iii) why exceptions exist and iv) which parameters (arguments) are sent into remote methods, and how they return.
The major objective is to make a performance comparison to identify the bottlenecks and implement optimization of RMI.
The minor objectives are
To make a computer simulation of RMI
To Experiment and present results from the experiments designed to investigate the inner workings of RMI
To discuss the primitive object operations of RMI.
A simulation project normally involves a sequence of steps, which can be used as Core Workflows in the Unified Process stages. The steps are:
Conceptual problem formulation and analysis
Data and information collection
Verification and validation
Experiment execution and results analysis
Refinement of experiment design
Final results analysis, and
Among these steps, data collection is the most time consuming and maybe the most important (to avoid: "garbage in - garbage out"). Validation is right next. One needs to make sure the model created corresponds to the real system in order to perform the experiments and propose changes.
In general, the development process of the simulation system includes six steps:
Step 1 Analysing the question of the objects according to the aim and the requirement;
Step 2 Building the concept model of the objects;
Step 3 Designing the system architecture;
Step 4 Modelling the system, sub-system, and components;
Step 5 Running the model and the simulation system to get the results;
Step 6 Verifying and correcting the model and simulation system according to the simulation results.
The core of the model and the simulation system is questionâ†’systemâ†’model and their decomposition and composition.
5. Technology Description
For the Simulation of the Architecture of RMI, the requirements are derived from the primitive operations of Client and Server Objects since the chief purpose of a Distributed Object Architecture implementation is mediating communication between clients and servers. The performance of the Architecture can therefore be expressed in a straightforward manner using metrics such as invocation time or communication throughput. To analyse the individual performance factors that influence the overall result of these metrics, we need to follow the invocation path of a typical broker from the Client Side to the Server Side.
5.1 Client Side
The invocation on the client side can use one of three available invocation mechanisms, namely the normal static invocation, the static invocation using the Asynchronous Method Invocation, and the dynamic invocation using the Dynamic Invocation Interface. All three mechanisms proceed by marshalling the arguments into a request.
5.2 Network Transport
This involves transporting the invocation data in a layout that is compliant with TCP/IP protocols. This phase of the invocation can include setting up or looking up the connection and processing the forwarding messages. This does not occur in continuous load scenarios, and it is difficult to isolate the effects on the observed performance.
5.3 Server Side
The invocation on the server side begins by dispatching the request to the proper object adapter and from there to the proper servant. After that, two invocation mechanisms are available, namely the synchronous static invocation and the synchronous dynamic invocation using the Dynamic Skeleton Interface. Both mechanisms proceed by unmarshaling the arguments from the request. The return phase of the invocation is similar as far as the performance factors influencing the overall result go.
The results of the simulation is described by the following primitive object operations
RMI - identifies classes by name and implementations by mappings to an URL in the RMI registry.
RMI - ObjIDs (faulting reference) in RMI, provides unique identification of server objects. Java/RMI object references normally denote abstract, long-lived objects. The references are immutable in that they reliably denote throughout that object's lifetime, regardless of the location or activation state of the object
Invocation of objects
RMI - Any Java object inherits the java.lang.Object, which holds the type information. Reflection and Introspection can be used to query the object type information. The Reflection API (in version 1.2 of the Java language specification) is however not integrated with Java/RMI4
The RMI technologies support parameters passing by either value of by reference. RMI - Java Interfaces must implement the java.rmi.Remote interface to be passed by reference, all other objects and parameters are passed by value. Parameters that are Java objects must implement the Serializable interface to be passed by value.
RMI - Java attempts to perform garbage collection of remote server objects. Java objects have a built-in reference counting where a separate process within the JVM, the garbage collector releases instances when no other object has references to the object.
RMI relies on a protocol called the Java Remote Method Protocol (JRMP). The current RMI defines very basic distributed object functions such as remote object connection, remote method call and object transfer. It relies heavily on Java Object Serialization, which allows objects to be marshaled (or transmitted) as a stream. Since Java Object Serialization is specific to Java, both the RMI server object and the client object have to be written in Java. Each RMI Server object defines an interface which can be used to access the server object outside of the current Java Virtual Machine (JVM) and on another machine's JVM. The interface exposes a set of methods which are indicative of the services offered by the server object.