Java Reference
In-Depth Information
Properly design remote interfaces
When using remote interfaces, make sure the methods that you include in the interface are
really supposed to be remotely exposed. You can have a local interface and a remote inter-
face that expose completely different methods.
Remote objects aren't passed by reference
Remote method parameters and return types must be serializable. Furthermore, objects are
exchanged by copying over the network. This means that you can't pass an object to a
remote stateless method and expect your local reference to mirror changes made by the
method. For example, if you pass a list of objects to a remote stateless session bean, you
won't see any changes made to the list unless it's returned by the remote method. Although
this may work for beans being accessed locally in the same application and Java Virtual
Machine (JVM), this obviously doesn't work for remote beans.
Avoid fine-grained remote calls
Remote calls are expensive—beans accessed locally can be finer grained, whereas remote
beans should naturally be very coarse-grained. On a remote service you want to avoid re-
peatedly contacting the server for different bits of information to fulfill a request because
each call exacts a charge that in aggregate might be unacceptable. For example, if the user
interface (UI) provided a UI that enabled multiple bids to be cancelled, it wouldn't make
sense to call the
BidService.cancel()
method in a loop—that would be horribly in-
efficient. Instead you should add an additional method that takes a list of bids to be can-
celled.
3.3. Stateful session beans
Recall that unlike stateless session beans, stateful session beans maintain their state over
multiple method invocations. Supporting a conversational state opens up new opportunit-
ies, such as long-running database transactions. Programmatically, stateful session beans
aren't that different from their stateless counterparts. The only real difference is in terms of
how the container manages its lifecycle. The container ensures that each method invocation
is on the same bean instance, whether it's local or remote. This is done behind the scenes.
Figure 3.6
shows this behavior graphically.
