IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Services and service-related functions > Access Enterprise JavaBeans (EJB) services

EJB 3.0 and EJB 2.1

EJB 3.0 has some significant differences with EJB 2.1.

You should be aware of these differences when developing applications with EJB bindings based on 3.0 or higher.

EJB 3.0 was a rethinking of Enterprise JavaBeans (EJBs) based on an analysis of growing difficulties that developers had experienced as they developed applications using EJBs. The challenges addressed by EJB 3.0, the differences between EJB 3.0 and its predecessor, EJB 2.1, and a change to the local interface in EJB 3.0 are discussed below.


Challenges addressed by EJB 3.0

The EJB architecture was designed for applications with distributed components. BeforeEJBs, Common Object Request Broker Architecture (CORBA) had become one well-known standard that handled distributed objects but CORBA became complex and synonymous with difficult to use. As the EJB standard evolved, it too began to pick up many features and acquired a reputation as being too complex to use for developers. The following list of complaints were associated with EJBs by the time of EJB 3.0:

The next sections are a high-level look at the differences between EJB 3.0 and EJB 2.1. They are a starting point to understanding EJB 3.0 in particular. However, if you want to learn EJB 3.0 in depth then you should read a book on the specification. Many EJB 3.0 books are available at most libraries. They provide code samples, recommendations and tips when building applications that use EJB 3.0. The following links also provide helpful information.


Differences between EJB 3.0 and EJB 2.1

For over a decade EJBs have been a key element of large-scale application development written in Java. Over this period EJBs evolved into a standard framework for the development, deployment and execution of distributed components used in multi-user environments. The framework included services for lifecycle monitoring, concurrency, pooling resources, transactions, security and persistence.

By the time of EJB 2.1, these standard features were available to developers working with EJBs: session beans for non-persistent data and entity beans for persistent data; an XML deployment descriptor; a local or home interface though only clients inside the Java 2 Platform Enterprise Edition container could access it; message-driven beans for asynchronous messages; and support for web services that exposed an endpoint so that an EJB could be invoked when needed. The result of these features though was that developers had to write a lot of code just to create an EJB.

For example, developers needed to code a home interface, a component interface, a bean class, and a deployment descriptor which for an entity bean could be itself complex. Developers were also required to code methods for lifecycle management even if they were not called.

EJB 3.0 introduced the following major changes, which have led to a simplified programming model:

EJB 3.0 is formally defined in JSR 220: Enterprise JavaBeans 3.0.. This JSR is over 800 pages and is divided into three sections: the Java Persistence API defines the persistence framework and discusses entities; the EJB Core Contracts and Requirements section covers message-driven and session beans; and the EJB Simplified API provides an overview of the EJB development model;


How an EJB with a local interface works

Based on the previous sections, EJB 3.0 led to a significant simplification of the EJB specification. This is especially true for an EJB with a local interface (that is, an EJB that will run in the same JVM as the client). How simple? The following lines of code create an EJB interface. 

package ejbeasy;

public interface EasyEJBClaim {
	public void stateClaim(String myName);}

These lines create the implementation in a stateless session bean. 

package ejbeasy;

import javax.ejb.Stateless;

@Stateless
public class EasyEJBClaimBean implements EasyEJBClaim {
	public void stateClaim(String myName){
		System.out.println(myName + "says What could be simpler?");
	} }

The interface is a POJO interface and the bean class is a POJO. The @Stateless annotation converts the POJO to a stateless EJB.

Access Enterprise JavaBeans (EJB) services


Related concepts:
JNDI names


Related tasks:
Create EJB imports using the external service wizard
Create EJB imports using the assembly editor