Remotor
From WIKI@COMJAT.NET
Contents |
Introduction
It's Java! Remotor is a Java web service system. It is a very easy to use and a very fast remote procedure call engine (RMI | RPC). No need to bother about Stubs & Skeletons and Naming-Services. It is 100% pure Java (JDK 1.4 and up) - adapt it to the J2ME! In the Remotor howto you'll find an example with source codes which guides you step-by-step on how to use the COMJAT.NET Remote procedure call mechanism.
Author
Siegfried Steiner User:steiner
Lightweight remote procedure calls
The Remotor provides means for remote communication to be used in your applicationsm - minium requirenment is the J2SE (Java 2 Standard Edition, Version 1.4 and up). Remote communication in this context means the communication of different instances of the JVM, even if located on different computer systems.
100% oure Java
The Remotor is a mechanism for remote communication based on objects. The main difference between the Remotor-System and other method invocation mechanisms is that the Remotor is written in 100% pure Java, does not need any Stubs and Skeletons to be created and needs no native naming service to be started in order to invoke remote methods. Its definition is protocol-independent; drivers may enable different means of communication. Currently implemented are drivers for direct communication inside one JVM and a TCP-IP driver using serialization. One could also use RMI, but this would weaken the strength of the Remotor-System, as the developer has to take care of more then only creating interface-definitions for the objects to be published.
Figure 1: The pinciple of the Remotor, providing and cosnuming webservices
Under the hood
The Remotor-System works as follows: Assuming that there are two Systems, one of which acts as a server, the other as a client:
Step 1
An application uses the server to publish objects. The objects may be of any kind ? because of the proxy-mechanism of the Java 2 platform it is important that the methods to be accessible by the client are implemented from an interface (a common Java interface definition). One has also to take into account that the arguments and the return value of the methods are to be serializable as they might be transferred from one JVM to another JVM residing on different computer systems. Some of the standard Java objects are not serializable ? the Remotor-System may convert these objects to objects being serializable at runtime if provided as method arguments to the method being invoked.
Step 2
The client connects to the server ? the client creates Proxy -Objects which implement exactly the same interfaces as the objects published by the server. Because these objects are Proxy-Objects, they are only facades of the published objects. Each time a new object is published by the server or an object is signed off, an Event-Object is fired by the Remotor-System of the client so that the client application can act according to the situation.
Step 3
Invoking a method on a Proxy-Object residing on the client?s JVM results in the execution of the method on the server?s JVM: The method call on the Proxy-Object is encapsulated in a descriptor; this descriptor is transferred to the server and executed there. Any return-value or exception thrown is returned to the client, which then continues execution as if the method call occurred on the same machine (even the exception is thrown as if it occurred in the same thread).
Step 4
Closing the connection between the client and the server results in a ?signoff? of all the objects being published. Any Proxy-Object still kept in reference by the client application is disposed ? a call to such Proxy-Objects results in an exception being thrown (Proxy-Objects automatically implement in addition to the published object?s interfaces one supplementary interface: the one and only method of this interface informs about the state of the Proxy-Object: is it disposed or not?).
Hassle-free webservices
Just very few preconditions have to be taken into account when using the Remotor. No sepearate code generation has to be triggered by a build process. No server side application framework such as J2EE needs to be used. A J2SE Java standard edition is all you need. You use standard Java features, you don't need to know anything about proxies, stubs or skeletons - you use interfaces and classes.
As the Remotor uses Serialization and Reflection you need at least the JDK 1.4. The Remotor is the communication system for other systems being developed by COMJAT.NET:
- The COMJAT.NET Interlink system enables both the server and the client to use each other's remote services - here we do not distinguish any more between client / server.
- The COMJAT.NET Transceiver is a complete abstract messaging service. Here you get the reply where you post it (in the same Thread), and you know when to expect the reply.
Further reading
The Remotor howto provides you with a step-by-step guide on how to use the COMJAT.NET Remotor in your own applications.
