TECHNOLOGY: INDUSTRY STANDARD
By Rich Schwerin
Use EJB 3.0 to streamline your application development and standardize persistence for Java.
Working vacation. Concise tax code. Bipartisan cooperation. Simplified Enterprise JavaBeans (EJB). Pop quiz: Which one isn't an oxymoron? If you chose EJB, you must be familiar with the goal of EJB 3.0—to simplify the development of Java applications and standardize the persistence application-programming interface for the Java platform. EJB 3.0 directly addresses the primary drawback developers have identified in EJB 2.x: complexity.
"Enterprise JavaBeans makes developers' lives easier, by providing a clear, standard way to build the business logic of applications without having to worry about complicated issues such as transaction support, security, and remote object access," says Debu Panda, Oracle's principal product manager for EJB. "However, EJB 2.x has been criticized by many developers for its complexity—something that EJB 3.0 addresses directly."
Building Distributed Applications in EJB 2.x
As a technology used to build server-side business components for applications using the Java platform, EJB enables developers to develop applications that are distributed and secure, using the Java programming language. For example, an online shopping cart built with EJB encapsulates business logic without requiring a lot of code to maintain the state of conversation, transactional guarantees, and security. Plus, as an open standard, EJB is portable across different application servers.
"EJB 2.x makes a lot of complex stuff easier for developers, but it still has room for improvement," explains Panda. "With EJB 2.x, if you build an EJB, you have to implement at least two different interfaces. You have to build a deployment descriptor, and you have to implement EJB-specific APIs—and this creates a lot of complexity."
Panda explains that EJB evolved as a kind of distributed component, which can be invoked by use of Java Remote Method Invocation (RMI) and used remotely. A lot of developers and applications don't require distributed components—they want components that can be used locally but that also include transactional, persistence, and security features.
Other shortcomings of EJB 2.x include testing costs and lifecycle-method overhead. "There are risks and costs associated with testing in EJB 2.x," says Panda. "With EJB 2.x, because you can't test outside the container, you've got to deploy on your application server. This is expensive, in the sense that when you make a little change in the code, you have to redeploy all over again."
"In EJB 2.x, developers must implement lifecycle methods— ejbActivate, ejbLoad, ejbStore , and so on—even if those methods aren't required by the application," says Panda. "The EJB 2.x specification requires all these different lifecycle methods for the EJB to be defined so that when a method is required, the container will call that particular method. In EJB 2.x you need to implement these methods even if they aren't required for your specific EJB."
EJB 3.0: Passing Over the Complexity
JavaBeans are often referred to as Plain Old Java Objects (POJOs), and interfaces are called Plain Old Java Interfaces (POJIs). In EJB 3.0, the EJB class and interface will now resemble POJOs and POJIs, respectively. And, as a consequence, the requirement of EJB 2.x artifacts such as the home interface and deployment descriptors are removed in EJB 3.0. (See the "More Versus Better" sidebar for a description of the component differences between EJB 2.x and EJB 3.0.)
"With EJB 3.0, many mundane tasks—such as creating deployment descriptors and implementing unnecessary callback methods—are now optional," says Panda.
Because EJB 3.0 now resembles regular Java classes, implementation of lifecycle methods is optional. Developers can now define lifecycle-callback methods either in the EJB bean class or as an external class; any arbitrary methods can be marked as callback methods with annotation. Interceptors, which offer control over method invocation, can be used on stateless Session Beans, stateful Session Beans, and Message-Driven Beans, explains Panda.
"In EJB 3.0, annotations replace deployment descriptors," he adds. "Each attribute in the deployment descriptor has default values, so you do not have to specify these attributes unless you want a value other than the default value, and these values can be specified with annotations in the bean class itself."
The EJB 3.0 specification also defines a set of metadata annotations such as bean type, type of interfaces, resource references, transaction attributes, and security; XML descriptors are optional.
Panda explains that using EJB 2.x is complex even if EJBs are colocated in the same application. If a developer wants to use an EJB 2.x from another EJB, for example, the developer must define the ejb-ref or ejb-local-ref in the deployment descriptor, look up the EJB, create an instance, and invoke a method. To use EJB 3.0, by contrast, developers can simply define the dependency on the bean, using an annotation; invoke the method; and use dependency injection to look up any type of environment and resource references, including DataSource, JMS, Web services, and more.
Enhanced Entity Beans
Entity beans get a major overhaul in EJB 3.0, which adopts a lightweight persistence model similar to Oracle TopLink. In EJB 3.0, entity beans are POJOs and no longer require component interfaces (home and remote). Enhancements to entity beans include inheritance and polymorphism support, simplified EntityManager API for Create Read Update Delete (CRUD) operations for entity beans, enhancements in query capabilities, and metadata for object-relational (O/R) mapping.
"The metadata for O/R mapping annotations allows users to 'decorate' their EJB 3.0 entity bean classes with O/R mapping metadata," explains Panda. "This metadata is then used to define the persistence and retrieval of their entity beans. So, you don't have to define the O/R mapping in a vendor-specific descriptor with EJB 3.0." If you prefer to use XML for O/R mapping, you can use it instead of employing annotations.
Oracle Application Server EJB 3.0 Preview
The EJB 3.0 specification greatly simplifies the programming model for EJB and standardizes the persistence model for the Java platform. The EJB 3.0 Preview for Oracle Application Server gives Java developers the opportunity to begin exploring the capabilities of EJB 3.0 by building and deploying applications.
"Oracle is proud to release the first and only such preview for developers by a commercial application server vendor, and with Oracle Application Server EJB 3.0 Preview, developers can start building EJB 3.0 applications today," says Panda. "For developers relying on the EJB 2.1 spec, testing is a nightmare. Thankfully, Oracle Application Server EJB 3.0 Preview makes testing EJB 3.0 a reality developers can get started with today. The preview gives Java developers the opportunity to begin exploring the capabilities of EJB 3.0 by building and deploying applications, in readiness for the finalized EJB 3.0 specification."
Rich Schwerin (email@example.com) is a senior editor for Oracle Publishing and a frequent contributor to Oracle Magazine, Profit, Oracle Technology Network, and Oracle.com.