Access EJB from JSP

Is it bad practise to access an EJB Entiy bean directly from a JSP? If at all possible?

For examle:

1. A user requests a list of Tasks in a form on a web page.

2. This form is then forwarded to a Controller servlet.

3. The Controller forwards the request to a stateless session bean ('Process').

4. The session bean locates the Task via an Entity bean.

5. The session bean then returns a HashTable containing references to the User Entities.

5. This HasTable is then associated with the JSP 'Request' by the 'Controller'.

6. The JSP then displays all the Tasks' information.

Alternatively, I could have created a normal beans and populate it with the Users' data. But, why duplicate?

Or I could have generated a XML 'Document' which contains the data? Seems complicated...

[862 byte] By [jaco@cyberseal.co.za] at [2007-9-26 4:50:47]
# 1

Whether it will qualify as bad, depends on how strict one wants to be with one's design.

Gnereally speaking, the stricter one (meaning one philosophy is followed throughout the system/application) is with partitioning the various application logics, the less headaches one has later during problem resultion and more so during maintenance, which is always goind to be there.

These days, a more frequently encountered question with respect to JSP is : whether to have any Java code in JSPs at all ? , especially considering the facilities such as custom tags that let you encapsulate dynamic content generation in reusable tag components. The JSP container maintains a pool of tags once they are instantiated.

In light of the design philosophy used at my place, exposing an entity bean or for that matter any type of EJB to the JSP would not be considered a good design.

In short, the options' set is not just (EJB aware JSP, normal bean aware JSP) but (EJB aware JSP, normal bean aware JSP, custom tag)

neville_sequeira at 2007-6-29 18:42:21 > top of Java-index,Other Topics,Patterns & OO Design...
# 2
We are trying to always use a controller for security purposes.In developement though I tend to get quick JSP's running with EJBs while the servlets are being developed, easier to trouble shoot the front/back end also...
tman191 at 2007-6-29 18:42:21 > top of Java-index,Other Topics,Patterns & OO Design...
# 3

My two cents in the discussion. I totally agree with neville_sequeira . Infact even for testing in development phase as we divide work across the tiers, personally I will write simple java classes to test and use some log kits like Log4J to write to some log files. That way you have log files to look back also.

Coming to main point, It is not a good idea to put any business related code in the web tier so calling entity beans from JSPs is not right thing to do. If you are talking about session beans, it should not matter that much if you are anyway outting some java code in the JSPs. But J2EE recommends not to put too much java code in the JSPs.

mad123 at 2007-6-29 18:42:21 > top of Java-index,Other Topics,Patterns & OO Design...
# 4

The issue is not the code in the JSP. The issue is how should I contain the data for the JSP in order to seperate content from logic.

Generally JavaBeans are used which are then called from the JSP with simple getValue operations (or indirectly via a custom tag).

My question is: Why should I convert the EJB data to another bean to store content -its duplication. I want to use the EJB directly to contain the data. And that don't necessarily mean more code in the JSP's. Because the right entity beans are located and referenced by trhe process, which is not in the JSP..

jaco@cyberseal.co.za at 2007-6-29 18:42:21 > top of Java-index,Other Topics,Patterns & OO Design...
# 5
After some research I'll try and explain it myself:The EJB and Web tiers might not reside on the same computer -scaling. Therefore, reading each value seperately from the EJB will take long and consume resources. Hence, we read once and wrap it in a JavaBean.
jaco@cyberseal.co.za at 2007-6-29 18:42:21 > top of Java-index,Other Topics,Patterns & OO Design...