Q:	Q: If you want the JSP to talk to a JavaBean, where will this bean come from?
A:	A: Well, it used to come from the local model/service object, so why not have it come from the remote model/service object?
Q:	Q: How do you get a bean across the network?
A:	A: Hey, as long as it’s serializable, RMI has no problem sending an object across the network.
Q:	Q: So what would this buy us again?
A:	A: First of all, we’d have one big network call instead of a lot of little ones. Second, since the JSP would be talking to a local object, there’d be no remote exceptions to worry about!
Q:	Q: Wait a minute... I see a little problem here. Or maybe a big problem—if you’re using a bean on the client side, doesn’t that bean’s data become stale the moment it’s sent?
A:	A: Yes, you’re right, and this IS a trade-off: performance vs. how current the data is. You have to decide which makes sense based on your requirements. If the data used by your view component must absolutely, positively, represent the current state of the database at all times, then you need a remote reference. For example, if you make three calls, say, getName(), getAddress(), and getPhone() on customer, you’ll probably decide that this information doesn’t change rapidly enough to make it worth going back to the database (via the remote object) just in case the customer’s phone number changed IN BETWEEN the call to getName() and getAddress(). On the other hand, you might decide that in a highly dynamic environment, where a customer is making transactions 24/7, you DO need to show the most up-to-date info. Sending a JavaBean back for the client means the View would have a snapshot of the database at the moment the bean was populated, but since the bean has no connection to the database, the data begins to go stale immediately.