Catherine Tornabene
CHAIMS Project
README
RMI Wrappers 1.0 - How To Start
June 19, 1998


Please follow the following steps to start up the wrappers and the 
server that they wrap.  You need to do this for every wrapper server/
non-CHAIMS-compliant server pair.  In this description, I refer to
the TestServer as an example non-CHAIMS-compliant server.

Some of these steps, such as running rmic, are only necessary if
the stubs and skeletons haven't been created.

(1) Set the paths appropriately.  You must set the CLASSPATH and
LD_LIBRARY_PATH variables to point at the correct directories.
In the CHAIMS/Wrappers/RMI directory, you can cut and paste the
commands in the file 'paths' to do this.  

(2) Compile all the .java files for the wrapper server and the 
non-CHAIMS-compliant server.  For my example, you can use
the Makefile I've created.

(3) Run rmic on the implementation class to create the stubs for the
non-CHAIMS-compliant server.

[Bigeye]> rmic TestObjectImpl

(4) Run rmic on the implementation class of the wrapper.  This will 
always be as follows:

[Bigeye]> rmic ChaimsCompliantObjectImpl

(5) Start the RMI registry as follows:

[Bigeye]> rmiregistry &

Note that for the wrappers I have written, the rmiregistry and the
two servers *must* be located on bigeye.  This can be changed,
but you must change the code.  Do 'grep bigeye *.java' in the 
CHAIMS/Wrappers/RMI directory to see where you will need to 
put the new server name.

(6) Start the non-CHAIMS-compliant server.  Note that you must start
the non-CHAIMS-compliant server before starting the wrapper server,
or the wrapper server will throw an exception saying that it couldn't
find the other server.  In the test example, do the following:

[Bigeye]> java TestServer &

(7) Start the wrapper server as follows:


[Bigeye]> java WrapperServer &

Note that the name WrapperServer will vary.  For every server that
you wrap, you will need to create a new WrapperServer.  For the test
purposes, I use the name WrapperServer, but a better name would probably
be something like 'TestMegamoduleWrapperServer'.

For testing purposes, I often didn't background the process, so that
I could easily kill the server, but you will normally want to background
it.  Note that there are currently quite a few print statements in the
wrapper server.  These are to demonstrate the flow of control in the
wrapper server.  For a long running wrapper server, you will probably
want to take these out.  When you start both servers, be sure to wait
for the print message "WrapperServer{TestServer} is bound in registry".
This indicates that the servers are ready to take client requests.  If
you do not wait for this message, when you try to run the client you
will exit with an exception.

(8) Log into your client machine.  I used durgon.  For the test,
make sure you are in the same directory.  Of course, you can split
directories if you want, but make sure that you copy over the 
ChaimsCompliantObjectImpl_stub.class file to the new directory.
It's probably easier to test from the same directory

(9) Start the client:

[Durgon]> java WrapperClient

I didn't background this so I could see what was happening.  In our
model, the WrapperClient is generated by the CHAIMS program.  However,
I have modified the client so as to show a test of all the
methods of the wrappers.  You should be able to tell what is going 
on from the printed statements; every time I make a call, I print out
what that call is doing.

Note that the multithreading in Java means that you will not see
the same behavior from call to call.  This is to be expected.
I have tried to force some behavior by using sleeps, but that is not
always consistent.