< Zurück | Inhalt | Weiter >

5.8.2 The rmic Tool

In order for a remote object to make itself available and in order for a client to be able to call such an object, each method needs a client and server-side stub to proxy the method call. Arguments to the method call are converted to streamable data (this process is called marshaling) by the client stub, and that data is sent over the network to the server stub, which must convert that stream into object instances on the server side (this is called unmarshaling). The server- side stub then calls the actual method implementation. When the method re- turns, any return values and changes to the state of the arguments must be marshaled by the server stub and sent back to the client stub where they are unmarshaled and stored in the correct locations on the client.

This was the traditionally painful part of writing multitier clients. What rmic does is automate the generation of these stubs, so writing a remote method is only slightly more difficult than writing any other method.

To generate RMI stubs for our application, run rmic19 against the class that implements the remote interface:

penfold$ rmic net.multitool.RMIDemo.SessionImpl

When you are writing “traditional” Java RMI, that is just about all you need to know about rmic. The program actually has a large number of options and switches, but most of these are to support alternate protocols and systems, such as CORBA IDL and IIOP. If you know what these are, and make use of these, you will find details on these options in Sun’s rmic tool documentation.20