Java Reference
In-Depth Information
reliability. If you're using the services that EJB offers for what they're really intended for,
then there really isn't any overhead.
By default, all session beans are transactional and completely thread-safe. In addition,
many containers pool stateless session beans for scalability (we'll discuss pooling in great-
er detail in
section 3.2
)
. So application components that these services are best applied to
should be session beans. Prime candidates are business logic/service-tier components that
directly or indirectly make use of back-end resources like database connections that require
transactions and thread safety (for a more detailed discussion on EJB thread safety, see the
sidebar “
Do EJBs need to be thread-safe?
”
). Session beans are also the de facto delivery
mechanisms for container services like security, scheduling, asynchronous processing, re-
moting, and web services. Components that might need these services should be session
beans (usually these services are applied at the business application API layer anyway).
Just as important as knowing where to use session beans is realizing when session beans
aren't appropriate. Making utility classes session beans isn't terribly useful. A utility meth-
od for formatting phone numbers or parsing tab-delimited input doesn't benefit from the
services being offered by an EJB container. A utility method doesn't use security, transac-
tions, or remoting. Making a utility class a session bean would add overhead without any
clear benefit. Although EJB provides dependency injection, lifecycle management, and in-
terceptors, plain CDI-managed beans can use these services too. A utility API should prob-
ably just use CDI and not EJB. The same is also true for DAO/repository classes. Although
these objects rely on thread safety and transactions, they don't need to be session beans
themselves because they'll likely be used through the EJB application service layer. As a
result, making DAOs session beans simply adds needless overhead.
As of Java EE 6, technically you can use EJBs directly as JSF-backing beans. Although this
is possible and might be useful for rapid prototyping, this is generally an approach we re-
commend that you avoid. Session beans shouldn't be used for page navigation or process-
ing the request parameters from a web form. These are tasks best suited for JSF-backing
beans or plain CDI-managed beans. Putting this logic in a session bean pushes the session
bean up into the UI layer. Mixing UI logic and business logic makes for messy code that's
hard to maintain in the long run.
Do EJBs need to be thread-safe?
