Introduction to EJB (Part 1)
Introduction to EJB (Part 1)
In this series' introductory post, we get an introduction into the world of EJBs. For anyone new to the Java EE space, this is a great place to start.
Join the DZone community and get the full member experience.Join For Free
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 metadata-specified in annotations.
You will learn the differences between the @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. I have talked about the presentation layer, but now I am going to talk about the business layer.
Encapsulates Business Logic
This is where EJBs 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 EJBs 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.
EJBs 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 other very useful information.
Your EJBs 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 Flavors of EJB
There are essentially two types of EJBs:
- Session beans
- 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 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 you 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 — the message driven bean — and we annotate it with @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.
This is a two part series overviewing Enterprise Java Beans. Coming up in part two, I will introduce the idea of bean access and talk about the three modes of access.
I have published more articles about Java EE. Here is a short list of topics that might interest you:
Published at DZone with permission of Alex Theedom , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.