JavaParty as high-performance RMI server in three tier architecture
- Quick Tour
- Mailing Lists
- Command Reference
- Object Model
- Transparent Threads
- Distributed Threads
- Remote Monitors
- Object Location
- Object Migration
- Remote Threads
- Replicated Objects
The concept of a JavaParty RMI server application is described in ticket:224. A proof of concept implementation is provided by the classes PartyWorker, PartyServer, and PartyClient in the package jp.example.rmiserver that is included in the JavaParty distribution from version 1.07i on.
The PartyWorker is a "regular" JavaParty transparent remote class. It is compiled with the JavaParty compiler. Its instances are created within the distributed JavaParty environment. The sum of all PartyWorker instances build up the compute tier of the tree tier application. An instance of PartyWorker offers a public method party(). The goal is to call the party() method of a PartyWorker object from an external RMI application, while the JavaParty environment internally communicates using wiki:KaRMI remote method calls.
The PartyServer builds the middle tier, moderating between the RMI clients and the JavaParty runtime environment. The PartyServer operates as front-end on a separate machine outside the compute cluster. The PartyServer itself is a RMI server application that can be contacted by clients using regular RMI. It offers the remote method gotoParty(), which implements a regular RMI remote interface PartyServer_intf. Upon startup, the PartyServer contacts a running JavaParty environment and forwards compute requests sent by client applications to cluster nodes. The PartyServer is compiled after the PartyWorker class using the regular javac compiler.
In the demo application, the PartyServer creates a new PartyWorker for each call to gotoParty() and calls the party() method on this remote worker object.
To use the JavaParty transparency layer in the PartyServer class, the JavaParty runtime is initialized specially, because the virtual machine running the PartyServer is not part of the distributed runtime environment. The same trick is used as in a virtual machine acting as front-end in a regular JavaParty application with a GUI (when using the "-frontend" switch for jpinvite). Even transparent remote object creation can be used in the front-end machine. This does not even require to compile the PartyServer class with the JavaParty compiler, because handle classes of transparent remote classes initiate the creation of their implementation object from their constructor. The actual implementation object is created in the cluster behind the scenes.
The PartyClient is a regular RMI client application. After startup, it looks up the PartyServer object and calls its gotoParty() method. This call is transfered through regular RMI to the PartyServer object, which "transforms" the call into a remote KaRMI call of party() on a newly created JavaParty-remote PartyWorker object.