Getting Started with Enterprise Java Beans
In this article, you will discover, the diverse range of services provided to EJBs by the container and how access to EJBs is controlled.
You will see how the container configures beans using the concept of convention over configuration and how you as a developer can gain back control over bean configuration through meta-data specified in annotations.
You will learn the differences between @Stateless, @Stateful, @Singleton and @MessageDriven beans and the roles that they play in the business tier of a typical application.
What is an Enterprise Java Bean?
The Java EE programming model has been simplified substantially since J2EE. Annotations have replaced the XML description files, convention over configuration has replaced the tedious manual configuration and dependency injection hides the creation and lookup of resources.
All you need is a Plain Old Java Object and an annotation that specifies its services and you have yourself an EJB. It does not need to extend an interface or adopt a class hierarchy, unlike previous versions. EJB 3’s simplified programming model emphasizes convention over configuration allowing you to write the least amount of code required to make something work.
In previous articles (Introduction to CDI, What is JSF? and What are JAX-RS annotations?), I have been talking about the different layers of a typical enterprise application and I have talked about the presentation layer, but now I am going to talk about the business layer.
Encapsulates Business Logic
This is where EJB’s fit into our architecture. EJBs tend to encapsulate business logic so this is where you’ll find much of the heavyweight logic being executed.
EJBs execute in a container that provides a range of services such as thread-safety. In fact, all EJB’s are thread safe, and as each EJB instance runs in a single-threaded context you will never run into concurrency issues. Instances are pooled and access is throttled.
EJB’s are monitored. If you look at the container console you should find an interface showing data related to your EJBs that are running, their response times and much more very useful information.
Your EJB’s will always run within a transaction so whenever you call an EJB method it will execute safely in a transaction.
All of these services are provided out of the box and for free by the container.
Two Flavours of EJB
There are essentially two types of EJBs:
- Session beans and
- message driven beans.
These beans have supporting annotations. let’s take a look at session beans.
Sessions beans implement business logic, these are going to be either stateful, stateless or singletons and are defined using the annotations: @Stateless, @Stateful or @Singleton.
A session bean functions as an extension of the client in the sense that it holds specific client related data that is unique and distinct client state data.
It creates a one to one relationship between the client and the bean itself. So if there are 100 client connections there will be 100 instances of the stateful bean in memory.
So when designing a bean, you must ask yourself: is this bean an extension of the client? If so I need the bean to hold state, so it must be a stateful bean otherwise it should be a stateless bean.
If I want to reuse objects and have a single object accessed by multiple clients you should use either a singleton or stateless bean.
In the stateless world this many to one relationship is created through a pooling structure, so when a client makes a request it looks and feels like a many to one relationship but actually, one object is retrieved from the pool for each request.
There is only one type of workflow bean which is the message driven bean and we annotate it @MessageDriven. Message driven beans are the extension of the messaging system and represent the endpoint functionality.
They don’t need to worry about how the message is delivered or consumed only what to do with it when it is received, it’s just about message handling.
They look and feel similar to stateless session beans but cannot be directly accessed by a client. The only way to interact with a message bean is via messages. They are completely hidden from the client.
I have published more articles about Java EE. Here is a short list of topics that might interest you:
- Java EE: Past, Present, and Future
- Introduction to JavaServer Faces
- What are JAX-RS annotations?
- What is @Context annotation used for?
- JAX-RS @Consumes and @Produces annotations
- Bean validation failure management
If you want to learn more about Java EE try my Lynda.com video training courses. They cover a selection of Java EE technologies: