Using Different EJB Types with Struts

This section examines the four main types of available EJBs and how they might fit in with Struts. Although in any situation, as the old Perl adage goes, TIMTOWTDI ("There is more than one way to do it!"), it's possible to generalize. These recommendations might not exactly fit what you're doing, but they provide a starting point and give you a good idea of how EJB technology fits with Struts.

Entity Beans

Entity beans are primarily used as an interface to a database. They enable the developer to work with database data at a business-object level and not worry about low-level management of the database. The actual JDBC calls as well as the code are taken care of by the entity bean and the EJB container.

Because of their tight integration with the database, entity beans aren't intended to contain a great deal of business logic. In fact, the majority of entity bean implementations ( especially those using container-managed persistence [CMP]) have virtually no business logic in them; they exist only as an interface to the database.

Given these characteristics, the following general rules are appropriate for using entity beans in Struts:

• Entity beans should be very thin. That is, entity beans should provide minimal formatting or other logic in front of the database fields they provide access to. Any business logic that might cause different View components to be presented to the user should usually be moved into the Action class. Also, use value objects rather than setting/getting individual properties.

• An Action class should interact with no more than one or two entity beans. If more than one or two entity beans are required, consider using a stateless session bean as a facade in front of them. This has the advantages of both minimizing traffic between the Web and EJB containers and simplifying the Action class.

• Minimizing the number of entity beans your Action class deals with is easier if you make the entity beans represent business-level objects rather than just map them directly to tables in your database. This is sometimes called designing them to be coarse grained. For example, having a Customer entity bean that has the customer's personal and address information might be better than having a Customer entity bean that maps to the Customer table and an Address entity bean that maps to the Address table.

Stateless Session Beans

Stateless session beans are ideal for many uses in Struts applications. They have the advantage of being relatively lightweight objects in your EJB container as well as providing a lot of flexibility. Stateless session beans should be considered for use when

• Multiple entity bean or other database accesses can be hidden behind the facade of a single session bean.

• If two systems need to be updated as part of a single transaction, wrap them in a single stateless session bean. For example, if a stock purchase must be recorded in both a customer information system as well as sent through a purchase clearing system, have your Action class access a stateless session bean and have it coordinate the other transactions. That way you have the EJB container to manage transaction commit and rollback if needed.

The reality is that stateless session beans are the most versatile of all the EJB forms. You can do about anything with them.

It's the best practice to create the session bean just before you need to access it and then remove it immediately after you're done. This minimizes the load on the EJB server. You should never store a reference to a stateless session bean for reuse.

Stateful Session Beans

Stateful session beans are similar to stateless session beans except that they remain stateful with the user's session in the EJB server. That is, they aren't directly related to the session information in Struts (that information is stored in the session context of the Web container). Remember: Both the Web container and the EJB container maintain their own session information.

Stateful session beans can maintain the user's conversational state. For example, they can be used to hold items in a user's shopping cart between requests . However, this comes at a price. The price is that the EJB container has to dedicate resources to maintain the stateful session beans until the session on the EJB container ends. If you have many users, maintaining the pool of stateful session beans can take up a lot of resources. In addition, when clustering EJB servers, some implementations require all stateful beans to be replicated between servers in case a failover occurs.

When you consider that Struts and the Web container automatically maintain stateful information anyway, using stateful session beans seems like a bad idea unless you really need them. For this reason, we recommend against their use. If you can, use stateless session beans and store stateful information in the session context of the Web container.

One situation in which stateful session beans make sense is when a transaction in the back-end system requires multiple requests to complete. If this occurs and you need the EJB container to manage the transaction, use stateful session beans ”just keep them as small as possible and remove them as soon as you can.

Message-Driven Beans

The newest breed of EJBs (since the EJB 2.0 specification) is message-driven beans. Message-driven beans essentially wrap a JMS (Java Message Service) queue and allow the full power of JMS to be used, while enabling you to write code to interact with the JMS queue as if it were an EJB instead of having to learn to write JMS client code.

Message-driven beans are useful in the same places that JMS is useful. For example

• When you need to pass information to a back-end messaging system such as MQSeries.

• In a situation in which you're working asynchronously when there might be a lag between the time you send in a transaction and the time the response comes back. For example, you might send a customer address change into a back-end system where the change occurs overnight. Using a message-driven bean, you can originate the transaction and look for the response later (or some other process can look for responses).

Summary of the Rules for Using Struts with EJBs

In summary, EJBs fit in with Struts in the following ways:

• EJBs fit with Struts Model components. Generally, they should be called only from the Struts Action class.

• If you have more than one (or maybe two) EJB to access from your Action class, consider implementing a stateless session bean (or even a non-EJB helper class that's called from your Action class) to act as a facade and simplify your Action class.

• Entity beans should be coarse grained to minimize the number of beans created and to isolate the Action class from changes in the table structure of the underlying database.

• Use value objects and pass data to and from the EJB "one bean at a time" rather than "one property at a time."

• Avoid using stateful session beans. Use stateless session beans instead and maintain stateful information in Struts using the session context of the Web container.

• Use stateful session beans only if you have transactions that span more than one user request and you need the EJB container to manage committing or rolling back the transaction.

Future Directions for Struts and EJBs

EJB technology isn't standing still. The EJB 2.0 and 2.1 specifications added a great deal of capability to EJBs. In addition, many corporations have adopted a J2EE-compliant application server such as WebLogic, WebSphere, iPlanet, or JBoss as their corporate standard for new application development.

The widespread adoption of J2EE and EJB technologies has ensured that this technology will be around for a long time. So, what changes are coming?

The EJB 2.0 and 2.1 specifications are adding a great deal of capability. Message-driven beans were added in 2.0 and will be enhanced in 2.1. A timer service will be available for EJBs to have the container call their methods at specific time intervals. But the biggest changes to come center around making EJBs easier to use with Web services. Session beans will be used to publish JAX-RPC “style Web services and message-driven beans will be used to publish JAX-M “style Web services. This support will be a requirement in EJB 2.1.

What does this mean for Struts? Mainly this: You can safely build your Struts applications today to interact with EJBs and be confident that EJB support will be available through the life of the application.