= JavaParty as high-performance RMI server in three tier architecture = 
[[TracNav]]

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.

== !PartyWorker ==

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.

== !PartyServer == 

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. 


== !PartyClient ==

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.