WAS v8.5 > Develop applications > Develop EJB applications

Develop enterprise beans

One of two enterprise bean development scenarios is typically used with the product. The first is command-line using Ant, Make, Maven or similar tools. The second is an IDE-based development and build environment. The steps in this article focus on development without an IDE.

EJB 2.x beans only: Design a J2EE application and the enterprise beans that it needs.

• Before developing entity beans with container-managed persistence, read the topic Concurrency control.

EJB 3.x beans only: Design a Java EE application and the enterprise beans that it needs.

• Before developing entity beans with CMP, read the topic, Concurrency control. Keep in mind that EJB 3.x modules do not support entity beans. You must continue to place entity beans in custom EJB 2.x-level modules.

The two basic approaches to select tools for developing enterprise beans are as follows:

• We can use one of the available IDE tools that automatically generate significant parts of the enterprise bean code and contain integrated tools for packaging and testing enterprise beans. The Rational Application Developer product is the recommended IDE.

  Add install_root/dev/JavaEE/j2ee.jar to the IDE project build path to resolve compilation dependencies on the new EJB 3.x API classes. Code assist works when this JAR file is added to the project build path. If you define a server (see J2EE Perspective), point the server to the product installation directory. When creating a Java EE related project in Rational Application Developer, the project automatically adds install_root/dev/JavaEE/j2ee.jar. to the project build path.

• If we have decided to develop enterprise beans without an IDE, you need at least an ASCII text editor. We can also use a Java development tool that does not support enterprise bean development. We can then use tools available in the Java SDK and in this product to assemble, test, and deploy the beans.

  Like the assembly tool, a standard Java EE command-line build environment requires some change to use the EJB 3.x modules. As with previous Java EE application development patterns, you must include the j2ee.jar file located in the install_root/dev/JavaEE directory on the compiler class path. An example of a command-line build environment using Ant is located in the install_root/samples/src/TechSamp directory.

The following steps primarily support the second approach, development without an IDE.

1. If necessary, migrate any pre-existing code to the required version of the EJB specification.

   Applications written to the EJB specification versions 1.1, 2.0, and 2.1 can run unchanged in the EJB 3.x container. See the topic Migrating enterprise bean code to the supported specification.

2. Write and compile the components of the enterprise bean.
   • At a minimum, a session bean developed with the EJB 3.x specifications requires a bean class.
   • At a minimum, an EJB 1.1 session bean requires a bean class, a home interface, and a remote interface. An EJB 1.1 entity bean requires a bean class, a primary-key class, a home interface, and a remote interface.
   • At a minimum, an EJB 2.x session bean requires a bean class, a home or local home interface, and a remote or local interface. An EJB 2.x entity bean requires a bean class, a primary-key class, a remote home or local home interface, and a remote or local interface. The types of interfaces go together: If you implement a local interface, you must also define a local home interface.

     The primary-key class can be unknown. See the topic Unknown primary-key class for more information.

   • A message-driven bean requires only a bean class.

3. For each entity bean, complete work to handle persistence operations.

   For EJB 3.x modules, consider using the Java Persistence API (JPA) specification to develop plain old Java Object (POJO) persistent entities. Review the topic Java Persistence API for more information. If you choose to develop entity beans to earlier EJB specifications, follow these steps:

   • Create a database schema for the entity bean persistent data.

     • For entity beans with CMP, you must store the bean persistent data in one of the supported databases. The assembly tool automatically generates SQL code for creating database tables for CMP entity beans. If your CMP beans require complex database mappings, IBM recommends that we use Rational Application Developer to generate code for the database tables. For more information about using the assembly tools, see the assembly tool information center.

     • For entity beans with bean-managed persistence (BMP), we can create the database and database table using the database tools or use an existing database and database table.

     For more information about creating databases and database tables, review the database documentation.

   • (CMP entity beans for EJB 2.x only)

     Define finder queries with EJB Query Language (EJB QL).

     With EJB QL, you define finders in terms of CMP fields and container-managed relationships, as follows:

     • Public finders are visible in the bean home interface. Implemented in the bean class, they return only remote interfaces and collection types.
     • Private finders, expressed as SELECT statements, are used only within the bean class. They can return both local and remote interfaces, dependent values, other CMP field types, and collection types.

   • (CMP entity beans for EJB 1.1 only: an IBM extension) Create a finder helper interface for each CMP entity bean containing specialized finder methods (other than the findByPrimaryKey method).

     Logic other than the findByPrimaryKey method is required for each finder method contained in the home interface of an entity bean with CMP:

     • The logic must be defined in a public interface named NameBeanFinderHelper, where Name is the name of the enterprise bean, for example, AccountBeanFinderHelper.
     • The logic must be contained in a String constant named findMethodName WhereClause, where findMethodName is the name of the finder method. The String constant can contain zero or more question marks (?) that are replaced from left to right with the value of the finder method arguments when that method is called.

Example: Using a read-only entity bean

This usage scenario and example shows how to write an EJB application that uses a read-only entity bean.

Usage scenario

A customer has a database of catalog pricing and shipping rate information that is updated daily no later than 10:00 PM local time (22:00 in 24-hour format). They want to write an EJB application that has read-only access to this data. That is, this application never updates the pricing database. Updating is done through some other application.

Example

The customer's entity bean local interface might be:

 public interface ItemCatalogData extends EJBLocalObject {
  
   public int getItemPrice();
  
   public int getShippingCost(int destinationCode);
  
 }

The code in the stateless SessionBean method (assume it is a TxRequired) that invokes this EntityBean to figure out the total cost including shipping, would look like:

 .....
 // Some transactional steps occur prior to this point, such as removing the item from 
  // inventory, etc.
  // Now obtain the price of this item and start to calculate the total cost to the purchaser
 
  ItemCatalogData theItemData = 
     (ItemCatalogData) ItemCatalogDataHome.findByPrimaryKey(theCatalogNumber);
 
 int totalcost = theItemData.getItemPrice();
  
 // ...     some other processing, etc. in the interim
 // ...
 // ...
  
 // Add the shipping costs
 totalcost = totalcost + theItemData.getShippingCost(theDestinationPostalCode);

At application assembly time, the customer sets the EJB caching parameters for this bean as follows:

• ActivateAt = ONCE
• LoadAt = DAILY
• ReloadInterval = 2200

  Deprecated feature: The reloadInterval and reloadingEnabled attributes of the IBM deployment descriptor extensions, including both the WAR file extension (WEB-INF/ibm-web-ext.xmi) and the application extension (META-INF/ibm-application-ext.xmi) were deprecated.

On the first call to the getItemPrice() method after 22:00 each night, the EJB container reloads the pricing information from the database. If the clock strikes 22:00 between the call to getItemPrice() and getShippingCost(), the getShippingCost() method still returns the value it had before any changes to the database that might have occurred at 22:00, since the first method invocation in this transaction occurred before 22:00. Thus, the item price and shipping cost used remain in sync with each other.

Assemble the beans in one or more EJB modules. See the topic Assembling EJB modules, or Assembling EJB 3.x modules if you are using EJB 3.x beans.

Subtopics

• Develop message-driven beans
  We can develop a bean implementation class for a message-driven bean as introduced by the Enterprise JavaBeans specification. A message-driven bean (MDB) is a message consumer that implements business logic and runs on the server.
• Enterprise bean development best practices
  Use the following guidelines when designing and developing enterprise beans.
• WebSphere extensions to the Enterprise JavaBeans specification
  This topic outlines extensions to the Enterprise JavaBeans (EJB) specification provided with the product.
• Set the run time for batched commands with JVM arguments
  This article explains how to set the run time for batched commands with JVM arguments.
• Set the run time for deferred create with JVM arguments
  For Container Managed Persistence (CMP) to happen during the ejbCreate, the EJB container can create the representation of the entity in the database immediately, or defer it to a later time.
• Set persistence manager cache invalidation
  To set persistence manager cache invalidation, follow these steps.
• Set the system property to enable remote EJB clients to receive nested or root-cause exceptions
  You might want to code the application to perform a given action if a certain kind of exception is the root-cause of a failure and is nested within the exception that you receive. The default behavior in the product might mask a nested or root-cause exception in the application.
• Unknown primary-key class
  When writing an entity bean, the minimum requirements usually include a primary-key class. However, in some cases you might choose not to specify the primary-key class for an entity bean with container-managed persistence.

Related concepts:

Application exceptions
EJB 3.0 and EJB 3.1 application bindings overview
EJB 3.x module packaging overview
EJB 3.0 and EJB 3.1 deployment overview
Enterprise beans
Concurrency control
Lightweight local operational mode for entity beans

Related

Configure EJB bindings in SCA applications
Use EJB bindings in SCA applications in a cluster environment
Tasks: Storing and retrieving persistent data with the JPA API
Develop read-only entity beans
Migrating enterprise bean code to the supported specification
Develop applications that use JNDI
Set the run time for batched commands with JVM arguments
Set the run time for deferred create with JVM arguments
Set partial update for container-managed persistent beans
Set persistence manager cache invalidation
Set the system property to enable remote EJB clients to receive nested or root-cause exceptions
Configure a timer service
Create timers using the EJB timer service for enterprise beans
Define data sources for entity beans
Applying lightweight local mode to an entity bean
Assemble EJB 3.x modules
Assemble EJB modules
Use EJB query

Reference:

http://publib.boulder.ibm.com/infocenter/radhelp/v7r5mbeta/topic/com.ibm.jee5.doc/topics/cejb3.html
EJB 3.0 specification
EJB 3.x module considerations
EJB metadata annotations
EJB 3.x interceptors
Create stubs command
WebSphere extensions to the Enterprise JavaBeans specification
Enterprise bean development best practices
Unknown primary-key class

Related information:

Dali JPA Tools

+

Search Tips   |   Advanced Search