Marshalling
with Stubs
Stubs are very important to me. Reason being, my phone number spells
886-STUB. (Actually, that's just coincedence.)
- The class that handles marshalling and unmarshalling is called a Stub. This resides on the client.
- The stub used to have a counterpart, called a skeleton, which resided on the server. This is a throwback to the CORBA days, but has since been eliminated with the help of reflection and introspection.
- The stub's job is to:
- Marshall the parameters passed.
- Create an identifier of the remote object and method to be used.
- The program formerlly known as the skeleton has to then:
- Unmarshal all parameters.
- Find the object to be called.
- Call the method on that object.
- Marshall the return value or Exception generated.
- Send this marshalled data back to the client.
- On the client, we talk to the stub through its interface. When we get a reference to the stub, we must save it in a variable of the stub's interface type.
- When you make an RMI program, you have to use the RMI Compiler (rmic) to generate the stubs.