[Webinar] Streamline your web hosting managementRegister Today

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 198
  • Last Modified:

Why using a "adaptor" between JSP and EJB?


In many documents about JSP (by example, JAVA SERVER PAGES and SERVLET DESIGN by J.Akerley, A.Koutsoumbos, M.Hashim and A.Maffione) they suggests
that a JSP page better not using directly the EJBs (entities) but pass by a intermediary bean (a adaptor).

Reasons seems to be:
- To not link JSP code closely with business logic.

- Be sure that the view (JSP page) should not accessing all the code of the entities (EJB).

- Giving the possibility to Gui designers (rather then developers) to build JSP page via a simplify interface
(adaptors rather then entities).

So, my questions is: is there any other reasons to use adaptors in JSP pages rather then entities? Is it just a question of “clean design”?


      Jean-Marc Desbiens
1 Solution
Definitly clean design. Two other points:
1) Handling errors on the servlet side instead of when the JSP is called
2) U can stick your internationalisation code in the adaptor and maintain a clean division between business logic and locale specific code
The typical goal of JSP is to serve as the presentation layer. JSP is not meant to be a complex coding vehicle. If you have your JSP directly accessing your EJB, you a) have tight coupling between your JSP and your EJB and b) you likely have more code in your JSP than is desirable.

The goal of the J2EE spec isn't just about clean architectures but clean partitioning of responsibility. By keeping your JSP pages relatively simple and clean, they are more likely to be owned by web masters than heavy java developers. Typically, the JSP is light embedded code accessing simply defined beans as the intermediate layer. These beans and the EJBs behind the scene are more complex and developed by Java programmers.

These beans are also reusable and you may find that in the future you aren't tied strictly to JSP - it should only be your view. The beans can be ported to an alternate view in the future without having to rip all sorts of code out of your JSP. This leaves you with more architectural solutions - java applets, bean deployment on the middle-tier, JSP, etc.

Here are some good references to support this discussion:

http://java.sun.com/products/jsp/ - look all through this resource for recommendations
http://www.servletcentral.com/1998-12/jsp.dchtml (down right now, but a great site)
http://www-4.ibm.com/software/ebusiness/pm.html (IBM also has numerous other excellent discussions in their websphere area)


Featured Post

The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now