When to use EJB?

The definition of EJB states that it is a distributed, transactional, persistent software component written in Java Programming Language. From this definition, it can be derived that EJBs are required in the following scenarios.

i. When the application is distributed: When the resources and data are distributed across multiple sites, then it is ideal to go for an application that is based on EJBs. Choose EJB when you know your application will need to scale beyond initial low usage levels and support multiple, concurrent users.

ii. When the application is performance-centric, use of EJBs and the application server provide high performance and very good scalability.

iii. Declaratively manage transactions. When transaction management is required to ensure data integrity, EJBs may be used. In EJB, you merely specify whether a bean’s methods require, disallow, or can be used in the context of a transaction. The EJB container will manage your transaction boundaries appropriately. In a purely servlet architecture, you’ll have to write code to manage the transaction, which is difficult if a logical transaction must access multiple DataSources.

iv. Declaratively manage security. The EJB model allows you to indicate a security role that the user must be assigned to in order to invoke a method on a bean.

v. Separation of Business Logic. The most significant difference between a web application using only servlets and one using servlets with EJBs is that the EJB model mandates a separation between display and business logic. This can be achieved using Servlets and DAO also

Hope it helps.

Spring Vs EJB ( A feature comparison)

In quite a few design brainstorming sessions, the debate between Spring and EJB results in a deadlock. There are developers who are damn passionate about Spring and hate EJBs. Let’s have a look at the main important differences between the two in terms of features they support.

Feature	EJB	Spring
Transaction management	Must use a JTA transaction manager. Supports transactions that span remote method calls.	Supports multiple transaction environments through its PlatformTransactionManager interface, including JTA, Hibernate, JDO, and JDBC. Does not natively support distributed transactions—it must be used with a JTA transaction manager.
Declarative transaction support	Can define transactions declaratively through the deployment descriptor. Can define transaction behavior per method or per class by using the wildcard character *. Cannot declaratively define rollback behavior—this must be done programmatically.	Can define transactions declaratively through the Spring configuration file or through class metadata. Can define which methods to apply transaction behavior explicitly or by using regular expressions. Can declaratively define rollback behavior per method and per exception type.
Persistence	Supports programmatic bean-managed persistence and declarative container managed persistence.	Provides a framework for integrating with several persistence technologies, including JDBC, Hibernate, JDO, and iBATIS.
Declarative security	Supports declarative security through users and roles. The management and implementation of users and roles is container specific. Declarative security is configured in the deployment descriptor.	No security implementation out-of-the box. Acegi, an open source security framework built on top of Spring, provides declarative security through the Spring configuration file or class metadata.
Distributed computing	Provides container-managed remote method calls.	Provides proxying for remote calls via RMI, JAX-RPC, and web services.

Advantages of EJB

EJB provide developers architectural independence

EJB insulates developers from the underlying middleware, since the only environment an EJB developer sees is the Java environment.  It also helps the EJB server/container vendor to change and make improvements on the underlying middleware layer without affecting a user’s existing enterprise applications.

WORA for server side components

Since EJB is based on Java technology, both the developer and the user are guaranteed that their components are Write Once, Run Anywhere (WORA).  As long as an EJB Server faithfully conforms to the EJB specification, any EJB application should run within that server.

EJB establishes Roles for Application Development

The EJB specification assigns specific roles for project participants charged with enterprise application development utilizing EJB.

The server vendor can take care of providing support for complex system services and make available an organized framework for a Bean to execute in, without assistance from Bean developers.

EJB provides Distributed Transaction support

EJB provides transparency for distributed transactions.  This means that a client can begin a transaction and then invoke methods on Beans present within two different servers, running on different machines, platforms or JVM.

It helps create Portable and Scalable solutions

Beans conforming to the EJB API will install and run in a portable fashion on any EJB server.

It provides of vendor specific enhancements

Since the EJB specification provides a lot of flexibility for the vendors to create their own enhancements, the EJB environment may end being feature rich.