lthough the EJB 3.0 specification has yet to be released, it is already generating much interest in the software development community by both proponents and opponents alike. All recognize the need to find more productive methods for developing software; the debate centers on whether, and to what extent, EJB 3.0 will play a role in this new landscape.
Debate notwithstanding, the release of the EJB 3.0 public draft and preliminary support in JBoss mean that now is a great time to explore this influential technology. In fact, reports of the use of EJB 3.0 in production systems are already emerging.
This article is the first in a three-part series exploring EJB 3.0 as defined in the public draft. Each article will introduce you to particular concepts from the specification and will walk you through the implementation of these techniques using JBoss. This first article will introduce EJB 3.0 and the basics of Enterprise Bean Components.
Introducing EJB 3.0
Enterprise applications are a class of software applications that perform business functions and typically involve large quantities of data concurrently accessed by many users. These applications rarely perform in isolation. Instead, each usually forms just one piece in the puzzle of a company's IT landscape and must interact with people and other systems. In short, developing enterprise applications is tough work. Issues such as performance, scalability, concurrency, and security must be addressed in almost all enterprise applications in order that they will successfully fulfill their role in the enterprise.
In answer to these challenges, the EJB specification was introduced in March of 1998 to make it easier to write distributed object-oriented business systems. The specification and the application servers implementing it have succeeded in this goal for the most part. But over the years the shortcomings of EJB, along with the advent of simpler alternatives, have caused many to question whether EJB offers the best solution for the productive development of enterprise applications.
Frequently cited shortcomings of EJB include the following:
- Components wanting to take advantage of provided enterprise services are coupled to the EJB API.
- It is an all-or-nothing proposition. Even if you want just one service of EJB, you have to accept all that comes with EJB.
- EJB components require a container and prove difficult to test.
- Each EJB requires several artifacts (interfaces, classes, and descriptors).
- Traditional EJB architectures are less object-oriented and introduce "fake objects" that have only state and no behavior.
Popular alternatives to EJB include the following:
- Aspect Oriented Programming
- Lightweight containers such as Spring, Pico Container, and Hivemind
- Object relational mapping (ORM) tools like Hibernate, JDO, and iBatis
- .NET Serviced Components
The public draft of the EJB 3.0 specification aims to ease development and to make it simpler to leverage enterprise services. These improvements are to some extent influenced by the success of the alternatives listed above. Some aspects of the above tools that have left their mark on EJB 3.0 include:
- A POJO (Plain Old Java Object) programming model
- A lightweight ORM persistence framework
- Dependency injection
- Metadata annotations
Other notable aspects of the EJB 3.0 specification include:
- Configuration by exception
- Elimination of component interfaces
- Elimination of home interfaces
- Reduction of the use of checked exceptions
This article assumes that you are already familiar with EJB 2.x and will focus on the changes introduced in the public draft of the 3.0 specification. The rest of this discussion will explore these improvements as you walk through the process of building an EJB 3.0 application using Maven and the JBoss application server.