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.
Before you begin
Enterprise JavaBeans (EJB) 2.x beans only: Design
a J2EE application and the enterprise beans that it needs.
- Before developing entity beans with container-managed persistence
(CMP), 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 your EJB 2.x-level modules.
About this task
The two basic approaches to select tools
for developing enterprise beans are as follows:
- You 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 you create 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 you have decided to develop enterprise beans without an IDE,
you need at least an ASCII text editor. You can also use a Java development tool that does
not support enterprise bean development. You can then use tools available
in the Java Software Development
Kit (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.
Procedure
- 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.
- Write and compile the components of the enterprise bean.
- 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, it is recommended
that you 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), you can
create the database and database table by using the database tools
or use an existing database and database table.
For more information about creating
databases and database tables, review your 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 that contains specialized finder methods
(other than the findByPrimaryKey method).
Logic other than the findByPrimaryKey method is required for
each finder method that is 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
Enterprise JavaBeans (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.
depfeat
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.
What to do next
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.