There’s good news and bad news...
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:
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 ...
Get Head First Servlets and JSP, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
