EJB changed rapidly over the past couple of years. Best practices for using EJBs “in the real world” are only now beginning to be documented, and there are already entire books on how to use EJBs. We cannot hope to cover everything in a single chapter. However, we can hit the important topics in designing EJBs for use in real-world business applications.
This chapter covers:
The questions you need to ask about your EJB container and database selections
beforeyou begin designing your EJBs.A step-by-step how-to for designing EJBs from functional requirements to completed EJB design, including the identification of potential base classes and EJB-helper classes.
Alternatives to EJB. There are places where Enterprise JavaBeans are not the best choice. The last section in this chapter helps you identify those places and introduces some alternatives.
Before you begin designing your application, it is essential that you consider the execution environment in which your code is run. The execution environment includes your:
| Hardware platform |
| Operating system |
| Java Virtual Machine (JVM) implementation |
| Application server (EJB container) |
| Database server |
Each of these elements has a direct effect on your application design’s success. We won’t talk about hardware and operating systems (about which you may have little choice, anyway), and we’ll stay away from arguments about who has a better JVM. We’ll focus on the last two issues; they have the greatest effect on EJB application architecture.
Which EJB container you choose has a significant effect on your application’s implementation and design. Regardless of your application’s functional requirements, spend some time familiarizing yourself with how your application server works. Ideally, you’d develop that familiarity before choosing your application server.
When learning your container’s capabilities, you are trying to find out how the application server’s vendor has implemented its key features. Here are the primary areas on which to focus:
- What version of the EJB specification does it implement?
A container that implements the latest (2.1) EJB specification will offer more features (non-JMS MDBs, for example). However, a container that implements the older (2.0) specification will be more mature.
- What vendor-specific functionality or extensions does it implement?
Almost all EJB containers introduce some vendor-specific features. If you choose to use vendor-specific features, your application will be tied to that vendor’s container. Switching to another vendor later may be costly. While this is often unavoidable (several popular development tools, for example, tie you closely to a vendor’s implementation), there are tools such as XDoclet[55] that help to alleviate some of the risk.
- How does the container’s design or implementation affect performance?
Because every vendor’s implementation of the EJB spec is unique, containers from different vendors will perform differently. If possible, research the performance of your various container options specifically for the functionality you need before choosing.
Most vendors do a good job of implementing the specification, and it’s relatively easy to move from one vendor to another. But don’t walk into the EJB arena with your eyes closed. Ask the same kinds of questions that you would ask for any other major software purchase, and you’ll be okay.
While we place a lot of emphasis on the EJB container, the database server is just as influential on the overall system. Although the EJB container isolates you from the database, the database is still there, and every data-related function depends on it.
The most critical function of a database is to ensure that data is available and consistent. Availability and consistency are qualities that depend on how your application uses transactions and how the database implements transactions.[56] When investigating how your database implements transactions, your primary concern should be the database’s locking, isolation levels, and other resource management. Here are some questions to ask:
- What transaction isolation levels does the database support?
While most databases support the four isolation levels discussed in Chapter 16 (read uncommitted, read committed, repeatable read, and serializable), there are some that do not. For example, PostgreSQL 7.3.x[57] offers only read committed and serializable.
- What are the lock types and lock scopes? What factors influence them?
Lock scope is the number of rows that are protected when a lock is enacted. Depending on the vendor, the database may lock only the rows used by the transaction, blocks of rows (pages) that contain the rows used, or the entire table. The more rows are protected, the more likely it is that another process won’t be able to access the data it needs. If such contention occurs, the other process will either fail or wait until the lock is released.
As for what factors influence lock types and lock scopes, the database may “promote” locks under certain situations, such as if a query cannot use an index. This could mean that a nonexclusive write lock becomes an exclusive write lock or that a row-specific lock becomes a table-wide lock, should an index on that table not be usable in the write.
- How are database resources handled within a transaction?
During a transaction, especially a multi-step transaction, the database has certain resources that it must manage; a good example is the number of open cursors involved in executing the transaction. Depending on how the database handles reclaiming those open cursors, a series of database operations that work fine outside a transaction may not work at all when included in a transaction because needed cursors are left committed until after the end of the last operation. In this case, large, multi-step, iterative processes (“batch” processes) can hit the maximum number of open cursors and fail. Knowing how your database manages resources like open cursors can help you plan your transaction structure to ensure success.
Obviously, there is more involved in the selection of a database server for your application/system than we’ve described here. However, these issues all have direct ramifications on your EJB application.
[55] XDoclet is an open source Java tool that allows for attribute-driven development. See http://xdoclet.sourceforge.net/ for more information.
[56] Transactions are discussed in Chapter 16.
[57] The most recent version of PostgreSQL at the time this was written.