Head First EJB

Passing a Remote object through a remote method call

It does not make sense to send a Remote object in a remote method call. After all, the whole point of a Remote object is to stay remote. To be accessed by clients who live... somewhere else. In another heap.

But what if you want to pass a remote client a reference to another Remote object? What if, rather than handing your client a full-blown copy of a Customer, you send him a stub to a Remote Customer?

When you pass a Remote object to or from a remote method, Java actually sends the Remote object’s stub.

In other words, at runtime, the Remote object stays right where it is, and its stub is sent over the wire instead.

Think about it. Before you read the next page.

Brain Power

What are the implications of passing a stub to a Remote Customer object as opposed to passing a non-remote Customer object?

What are the benefits of passing a stub instead of the real Customer object?

What are the drawbacks?

A remote reference is a stub to a remote object. If the client has a remote reference, he has a local reference to a stub, and the stub can talk to the Remote object.

(Note: whether to pass serialized objects or stubs to remote objects is a crucial design decision. We’ll explore this when we look at performance and patterns.)

When the return value is a Remote object...

1. The client invokes getCustomer() on Remote object A (using stub A).

2. Remote object ...