What is an EJB, and what does it do?
Been trying to learn what EJB beans are, what does it mean their instances are managed in a pool, blah blah. Really can't get a good grip of them.
Can you explain me what they really are (practically for a Java Programmer)? What do they do? Which are their purposes? Why really use them? (Why not just stick to POJO?) Perhaps an example application?
Please refer only to updated information, that is EJB 3.1. Dated information about EJB can be misleading.
For EJB learning beginners please note:
EJB are based on distributed objects, this refer to software pieces running on multiple machines (virtual or physical) linked by a network.
Answer
Why really use them? (Why not just stick to POJO?)
IF you need a component that accesses the database, or accesses other connectivity/ directory resources, or is accessed from multiple clients, or is intended as a SOA service, EJBs today are usually "bigger, stronger, faster (or at least more scalable) and simpler" than POJOs. They are most valuable for servicing large numbers of users over the web or corporate network and somewhat less valuable for small apps within a department.
Reusing/Sharing Logic across multiple applications/clients with Loose Coupling.
EJBs can be packaged in their own jars, deployed, and invoked from lots of places. They are common components. True, POJOs can be (carefully!) designed as libraries and packaged as jars. But EJBs support both local and remote network access - including via local java interface, transparent RMI, JMS async message and SOAP/REST web service, saving from cut-and-paste jar dependencies with multiple (inconsistent?) deployments.
They are very useful for creating SOA services. When used for local access they are POJOs (with free container services added). The act of designing a separate EJB layer promotes extra care for maximizing encapsulation, loose coupling and cohesion, and promotes a clean interface (Facade), shielding callers from complex processing & data models.Scalability and Reliability If you apply a massive number of requests from various calling messages/processes /threads, they are distributed across the available EJB instances in the pool first and then queued. This means that if the number of incoming requests per second is greater than the server can handle, we degrade gracefully - there are always some requests being processed efficiently and the excess requests are made to wait. We don't reach server "meltdown" - where ALL requests experience terrible response time simultaneously, plus the server tries to access more resources than the hardware & OS can handle & hence crashes. EJBs can be deployed on separate tier that can be clustered - this gives reliability via failover from one server to another, plus hardware can be added to scale linearly.
Concurrency Management. The container ensures that EJB instances are automatically accessed safely (serially) by multiple clients. The container manages the EJB pool, the thread pool, the invocation queue, and automatically carries out method-level write locking (default) or read locking (through @Lock(READ)). This protects data from corruption through concurrent write-write clashes, and helps data to be read consistently by preventing read-write clashes.
This is mainly useful for @Singleton session beans, where the bean is manipulating and sharing common state across client callers. This can be easily over-ridden to manually configure or programmatically control advanced scenarios for concurrent code execution and data access.Automated transaction handling.
Do nothing at all and all your EJB methods are run in a JTA transaction. If you access a database using JPA or JDBC it is automatically enlisted in the transaction. Same for JMS and JCA invocations. Specify @TransactionAttribute(someTransactionMode) before a method to specify if/how that particular method partakes in the JTA transaction, overriding default mode: "Required".Very simple resource/dependency access via injection.
The container will lookup resources and set resource references as instance fields in the EJB: such as JNDI stored JDBC connections, JMS connections/topics/queues, other EJBs, JTA Transactions, JPA entity manager persistence contexts, JPA entity manager factory persistence units, and JCA adaptor resources. e.g. to setup a reference to another EJB & a JTA Transaction & a JPA entity Manager & a JMS connection factory and queue:@Stateless public class MyAccountsBean { @EJB SomeOtherBeanClass someOtherBean; @Resource UserTransaction jtaTx; @PersistenceContext(unitName="AccountsPU") EntityManager em; @Resource QueueConnectionFactory accountsJMSfactory; @Resource Queue accountPaymentDestinationQueue; public List<Account> processAccounts(DepartmentId id) { // Use all of above instance variables with no additional setup. // They automatically partake in a (server coordinated) JTA transaction } }A Servlet can call this bean locally, by simply declaring an instance variable:
@EJB MyAccountsBean accountsBean;and then just calling its' methods as desired.
Smart interaction with JPA. By default, the EntityManager injected as above uses a transaction-scoped persistence context. This is perfect for stateless session beans. When a (stateless) EJB method is called, a new persistence context is created within the new transaction, all entity object instances retrieved/written to the DB are visible only within that method call and are isolated from other methods. But if other stateless EJBs are called by the method, the container propagates and shares the same PC to them, so same entities are automatically shared in a consistent way through the PC in the same transaction.
If a @Stateful session bean is declared, equal smart affinity with JPA is achieved by declaring the entityManager to be an extended scope one: @PersistentContent(unitName="AccountsPU, type=EXTENDED). This exists for the life of the bean session, across multiple bean calls and transactions, caching in-memory copies of DB entities previously retrieved/written so they do not need to be re-retrieved.Life-Cycle Management. The lifecycle of EJBs is container managed. As required, it creates EJB instances, clears and initializes stateful session bean state, passivates & activates, and calls lifecycle callback methods, so EJB code can participate in lifecycle operations to acquire and release resources, or perform other initialization and shutdown behavior. It also captures all exceptions, logs them, rolls back transactions as required, and throws new EJB exceptions or @ApplicationExceptions as required.
Security Management. Role-based access control to EJBs can be configured via a simple annotation or XML setting. The server automatically passes the authenticated user details along with each call as security context (the calling principal and role). It ensures that all RBAC rules are automatically enforced so that methods cannot be illegally called by the wrong role. It allows EJBs to easily access user/role details for extra programmatic checking. It allows plugging in extra security processing (or even IAM tools) to the container in a standard way.
Standardization & Portability. EJB implementations conform to Java EE standards and coding conventions, promoting quality and ease of understanding and maintenance. It also promotes portability of code to new vendor app servers, by ensuring they all support the same standard features and behaviors, and by discouraging developers from accidentally adopting proprietary
non-portable vendor features.The Real Kicker: Simplicity. All of the above can be done with very streamlined code - either using default settings for EJBs within Java EE 6, or adding a few annotations. Coding enterprise/industrial strength features in your own POJOs would be way more volumous, complex and error-prone. Once you start coding with EJBs, they are rather easy to develop and give a great set of "free ride" benefits.
In the original EJB spec of 10 years ago, EJBs were a major productivity hassle. They were bloated, needed lots of code and configuration artifacts and provided about 2/3 of the benefits above. Most web projects did not actually use them. But this has changed significantly with 10 years of tweaking, overhauling, functional enhancement and development stream-lining. In Java EE 6 they provide maximum level industrial strength and simplicity of use.
What's not to like?? :-) :-)