The previous architecture succeeds in hiding complexity from both the controllers and the JSPs. And it makes good use of the Business Delegate and Service Locator patterns.
The bad news:
When it’s time for the JSP to get data, there are two problems, both related to the fact that the bean the JSP is dealing with is actually a stub to a remote object.
1 - All those fine-grained network calls are likely to be a big performance hit. Think about it. Each EL expression triggers a remote method invocation. Not only is this a bandwidth/latency issue, but all those calls cause the server some problems too. Each call might lead to a separate transaction and database load (and possibly store!) on the server.
2 - The JSP is NOT a good place to be handling exceptions that might occur if the remote server crashes.
Why not have the JSP talk to a plain old bean instead of a stub?
Q: If you want the JSP to talk to a JavaBean, where will this bean come from?
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: How do you get a bean across the network?
A: Hey, as long as it’s serializable, RMI has no problem sending an object across the network.
Q: So what would this buy us again?
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: Wait a minute... I see ...