O'Reilly logo

Head First EJB by Bert Bates, Kathy Sierra

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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?

image with no caption

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 ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required