CODEWITHSUNDEEP
jsfseamejb
AndresQ
AndresQ

Reputation: 803

Why can't I have a session bean as a JSF backing bean in Java EE 5

AFAIK, the whole purpose of JBoss Seam is to integrate EJB and JSF.

The book Seam in Action says that:

By design, EJB components cannot be bound directly to a JSF view. It’s great that EJB components are scalable, transactional, thread-safe, and secure, but it doesn’t do much good if they are completely isolated from the web tier, accessible only through a JSF backing bean acting as an intermediary.

But I couldn't find the reason/motive of such impossibility, why are they isolated from the web tier? Why can't I use an EJB as a backing bean? Care to enlighten me?

Upvotes: 4

Views: 1311

Answers (2)

Bozho
Bozho

Reputation: 597106

Seam is not aimed to do that. CDI (Weld) is, however. With CDI you can @Inject an EJB in a JSF bean. (As arjan noted - you can do this without CDI as well, and since CDI is JavaEE6, you can try using @EJB private RemoteInterface bean)

But this is not about JPA entities. Although JPA considered part of EJB, and its predecessors were "Entity beans", a special type of EJBs, it is best not to think of EJB and JPA as one think. JPA is an ORM standard. EJB is a service/component model.

@Entity objects are managed by an EntityManager. They are not managed by an ejb container, nor by seam, nor by CDI even. This is because they don't fit the component model these three employ. Entities are usually instantiated by the developer. With CDI/EJB/Seam it is the framework that instantiates the components, manages them and performs injection.

Upvotes: 0

Arjan Tijms
Arjan Tijms

Reputation: 38163

But I couldn't find the reason/motive of such impossibility, why are they isolated from the web tier?

Traditionally this was done to enforce the separation between business logic and view related code. Intermixing those is what most every beginner does and it always leads to systems that are hard to maintain in the long run.

By allowing EJBs to be directly used as backing beans, people are going to put FacesMessages in them, and formatters specific for one particular page, and rendering code and so on.

Strict isolation prevents these mistakes to be made. However, this also raises the bar for those very same beginners to get started with EJB and gave EJB the reputation of being somewhat difficult (although with EJB3 this is not really the case). In the latest Java EE 6 release, a lot of intermixing is made possible by allowing EJBs to be defined without interfaces in the web module. With CDI annotations they are directly useable as backing beans.

Depending on your view, this is a step forward (easier, less constraints, less required artifacts), but it could also be seen as a step backward (promotes mixing of view and business logic again, something which deprecating scriptlets on JSP tried to prevent).

Upvotes: 2

Related Questions