EJB 3 Introduction

An EJB platform is for building portable, reusable and scalable business applications using the Java programming language. EJB is a component or framework that lets you build enterprise Java applications without having to revent services such as transactions, security, automated persistence which allows you to to spend more time on the business logic than the infrastructure code.

EJB 3 is simpler and lighter than its previous versions, EJB 3 components are now more like Plain Old Java Objects (POJO) with special powers. There are three types of EJB components

Both session and message-driven beans implement business logic, where as entities are used for persistence.

EJB components execute in a specialized runtime environment called the EJB Container, an example of this would JBoss but there are many others. The EJB Container can provide business logic, managing application state, storing and retrieving information from a relational database, managing transactions, implementing security, performing asynchronous processing, etc.

Since Java 5 metadata annotations can be used to preconfigure the EJBs by specifying the type of service to add when the container deploys the EJBs. Metadata annotations dramatically simplify development and testing of applications without having to depend on external XML configuration file, you can declaratively add services to EJB components as and when they are need, you can also be used to specify other EJB components.

EJB allows you to build applications using two different layered architectures

The traditional four-tier architecture is pretty popular, you have the presentation layer which the client uses, the business logic layer which is the heart of the application, the persistence layer which provides a high-level object-oriented (OO) abstraction over the database layer and finally the database layer which consists of a RDBMS like Oracle, DB2, MySQL, etc. EJB fits into the business logic layer (session and message-drive beans) and the persistence layers (entities).

The Domain-Driven Design is a new concept, it emphasizes that domain objects should contain business logic and should not be just dumb replica of database records. Domain objects are known as entities in EJB 3 and these may contain business logic, which means entities defined by EJB 3 Java Persistence API (JPA) supports OO features, such as inheritance and polymorphism.

There are a number of reasons that you would choose EJB 3 over other products like Spring, that's not to say you cannot implement both

EJB Types

As I mentioned above there are three types of beans

Each bean serves a purpose and can use a specific subset of EJB services, the Container manages session and message-drive beans and the persistence provider manages entities

Session beans are invoked by a client to perform a specific business task (check bank balance), a session bean is available for a "unit of work" and thus will not survive a server crash or shutdown. There are two types of session bean

Message-Driven beans (MDBs) process business logic, they are different in that clients never invoke MDBs directly. They are trigger by messages sent to a messaging server, which enables sending asynchronous messages between system components. There a number of messaging servers like IBMs WebSphere, Oracles Advanced Queuing, etc. MDBs are used for robust system integration or asynchronous processing.

Before we discuss entities we need to discuss the Java Persistence API (JPA), persistence is the ability to have data contained in Java objects automatically stored in a relational database like Oracle, this is managed by the JPA. It uses a technique called Object-Relational Mapping (ORM) which essentially maps's data held in Java objects to the database tables using configuration, so you do not have to write low-level JDBC code. Since JPA standardizes ORM frameworks for the Java Platform you can plugin ORM products like JBoss Hibernate, Oracle TopLink, etc. The JPA defines a standard for

Entities are Java objects that are persisted into the database, they model the lower-level application concepts that high-level business processes manipulate, basically they are the OO representation of the application data stored in the database, thus they will survive crashes and shutdowns. JPA entities support the following

The EntityManager interface manages entities in terms of actually providing persistence services, the JPA provider tells entities how to map to the database, the entityManager performs the actual persistence operations. The following is a summary of what each can do

JPA provides a specialized SQL-like query language called the Java Persistence Query Language (JPQL) to search for entities saved into the database. It also supports native database specific SQL should you ever need it.

Inside EJBs

Session and message-driven beans require a EJB container to run and entities require a persistence provider. A Java EE Container is an application server solution that supports EJB 3, a web container and other Java EE APIs and services. There are a number of Java EE containers that you can use

The container is an extension of the basic idea of a JVM, but manages the memory on your behalf and provides services such as transactions, security management, remoting, web services. The EJB 3 part will provide services applicable to session beans and MDBs only, and putting a EJB 3 component inside a container is called deployment, once deployed it can be accessed via a client. To provide persistence you will require a JPA which can be plugged into the container, this means that you are freely to choice what JPA you want to use, JBoss Hibernate and Oracle TopLink are popular and you can mix and match containers with persistence providers.

There are a number of EJB 3 component services

Applies To
What's offered
Session beans, MDBs
Helps glue components together, in EJB 3 you use dependency injection (DI) as well as lookup
Stateless session beans and MDBs
The EJB platform creates a pool of component instances that are shared by clients. All instances are returned to the pool when the client has finished with them.
Session beans, MDBs
EJB makes all components thread-safe and highly performant in ways that are completely invisible, however complex the application.
State Management
Stateful session beans
The EJB container manages state transparently.
You can write messaging aware components with out to much detail of the JMS service
Session beans, MDBs
EJB supports declarative transaction management using simple configuration instead of code, the container can handle the commit and rollback of transactions.
Session beans
Integration of JAAS API, means that it is easy to implement security with simple configuration instead of code.
Session beans, MDBs
EJB 3 introduces AOP in a very lightweight, accessible manner using interceptors. This allows you to separate out crossing cutting concerns such as logging, auditing and so on in a configurable way.
Remote Access
Session beans
EJB 3 can make components remotely accessible without writing code. It allows clients to access components as if they were local using DI
Web Services
Stateless session beans
EJB 3 can transparently turn business components into robust web services with minimal code change.
Automated persistence as an alternative to verbose and error-prone JDBC/SQL code.
Caching and Performance
JPA provides a number of services geared toward data caching, performance optimization and application tuning, especially in large environments.

Unit Testing

The last thing to discuss is that because EJB 3 components are POJO (Plain Old Java Object), they can be easily executed outside the container. This means that it is possible to unit-test all components business logic using testing frameworks as JUnit. I hope to have a complete topic on JUnit testing in the near future.