Previous    Next

Deciding When to Use EJB

One of the most important architectural decisions – with implications for deployment, testing, tool requirements and support – is whether to use EJB. In this section we'll examine some of the decisive considerations.

Using EJB to Implement a Distributed Architecture

Use of EJB may be dictated by the choice between a distributed and collocated architecture.

By using EJBs with remote interfaces we let the J2EE server handle the details of remote access. The alternative of writing our own RMI infrastructure is far inferior: nonstandard, unnecessarily hard to implement, and likely to prove hard to maintain.

Transaction Management

Even if we don't require EJB to implement a distributed architecture, there may still be reasons to use EJB. In , I noted that Container-Managed Transactions (CMT) were probably the most compelling reason for using EJB. Let's examine J2EE transaction management in general, and how using EJB can help to simplify transactional apps.

Transaction Management in J2EE apps

A J2EE server must provide the following transaction services:

• It must be able to coordinate transactions across EIS tier resources. The part of a J2EE server responsible for this is called a transaction manager.

• It must offer EJBs the option of declarative transaction management, doing away with the need to write code to handle transactions explicitly. The only choice a developer needs to make in this model is whether to roll back a transaction.
• It must make the standard J2EE Java Transaction API (JTA) and the UserTransaction interface available to objects that wish to manage transactions themselves. These may include both EJBs and objects running in a web container. JTA is a relatively simple transaction management API.

A J2EE server must be able to handle low-level transaction protocols such as X/Open XA that are understood by transactional resource managers used by J2EE apps. A resource manager is an EIS tier resource such as a database. Resource managers control persistent state, and are usually transactional. A J2EE server's transaction manager is responsible for transaction propagation between J2EE components, whether collocated or in separate JVMs, and from the J2EE server to transactional resource managers. For example, if a method on an EJB is invoked by a web tier object, any transaction context must be propagated. Transaction contexts are associated with threads within a JVM. A container must be able to use the transactional capabilities of IIOP to handle the transactional requirements of distributed apps by propagating transaction contexts between transaction managers. As IIOP is vendor-independent, this means that transaction propagation works across J2EE servers, even when they are supplied by different vendors. Part of the J2EE promise is that this low-level detail is completely hidden from developers. Developers can assume that any transactional resource supported by their app server will be managed appropriately if they use standard features of the J2EE platform: declarative transaction management (available in EJBs), or programmatic transaction management using JTA (available in all server-side J2EE components). This is an important boon, as the mechanics of ensuring transaction integrity across disparate resources is complex. For example, the server should support two-phase commit to achieve correct behavior for transactions involving multiple resource managers or multiple EJB containers. Two-phase commit ensures that even in a distributed scenario, all resources enlisted for a transaction either commit or roll back. This is achieved by handling a distributed transaction in two phases. The first issues a prepare request to all participating resource managers. Only when each resource manager has indicated that it is ready to commit its part of the combined operation, will a commit request be sent to all resource managers. Two-phase commit can fail in some scenarios. For example, if a resource manager indicates that it is ready to commit, but subsequently fails to commit on a commit request, integrity may be lost. However, two-phase commit is considered a very reliable strategy for distributed transactions. The J2EE specification does not currently require an app server to provide full two-phase commit support. However, it does hint at requiring this in future (refer to documentation supplied with app servers for the degree of two-phase commit support they provide). Any class running within a J2EE server, but outside the EJB container, can perform programmatic transaction management. This requires obtaining the UserTransaction interface from JNDI and using JTA directly. Any J2EE component may itself manage transactions on a transactional resource such as an RDBMS using an API specific to that resource – in the case of an RDBMS, the JDBC API, or perhaps the JDO API – rather than the integrated JTA. However, this is a poor choice unless J2EE does not offer transactional support for the resource in question. Such transactions are referred to as local transactions. They are "local" in being isolated from the integrated transaction management of the J2EE platform. The J2EE infrastructure, which does not know about local transactions, cannot automatically rollback local transactions if a component marks a J2EE transaction for rollback only. The developer would be left to rollback and commit in code, resulting in unduly complex code and failing to leverage a valuable service of the app server. Local transactions must be created, committed, and rolled back using resource-specific APIs, making apps inconsistent in their approach to transactions.

Transaction Management and EJB

EJBs are the J2EE components best equipped to manage transactions. EJBs benefit from both declarative and programmatic transaction management. In the declarative model, the developer does not need to write any JTA code, ensuring that business logic is not complicated by lower-level transaction management operations. Typically, session EJBs are used to manage transactions, with each method on a session bean delimiting one transaction. For beans choosing to use Container-Managed Transactions (CMT), the container declaratively sets transactional boundaries at method level, eliminating the need to write transaction management code in user apps. Since app developers decide what each method does, this neatly integrates transaction management into the Java language. With Bean-Managed Transactions (BMT), the developer writes code in the EJB itself to begin, commit or roll back transactions programmatically using JTA.

Bean-Managed Transactions

Only session beans and message-driven beans may use BMT. Entity beans must use CMT. Using BMT is an all or nothing choice. The choice of BMT or CMT is made at bean level, not at method level; so, if only one method of a bean has unusual transactional requirements that seem to require the use of BMT, all methods of the bean will be forced to manage their own transactions (refactoring the design to split the bean may be more appropriate). BMT has a different meaning for stateless and stateful session beans. In the case of stateless session beans, the container must detect the situation in which a stateless bean method has returned after starting a transaction, but without committing it or rolling it back. Since a stateless session bean cannot hold state for a particular client between method calls, each method call must complete a unit of work, so this is clearly a coding error. On detecting this situation, the container must react in the same way as to an uncaught throwable from an EJB method, rolling the transaction back and discarding the offending EJB instance. For similar reasons, the same rule applies to message-driven beans, which must conclude any open transaction before the onMessage() method returns. In the case of stateful session beans, however, the container is not entitled to view a method leaving a transaction open as a coding error. It is possible that several method calls of the stateless bean make up a transaction, and that further method calls are required to complete the unit of work. However, the danger of this scenario is obvious. The client might allow user wait time between calls to the methods in the single transaction. This will waste valuable transactional resources, and potentially lock out other users of resource managers such as relational databases. Worse still, the client might never call the method that ends the transaction. EJBs using BMT must not use the setRollbackOnly() method on the javax.ejb.EJBContext interface. This method is intended to allow easy transaction management for beans using CMT.

Container-Managed Transactions

Using CMT is much simpler than using BMT. We don't need to write any transaction management code in our EJBs. We merely need to:

• Define method responsibilities so that transaction delimitation at method boundaries is appropriate. EJB methods – especially on remote interfaces – often implement a complete use case, so this often occurs naturally.

• Specify the appropriate transaction attribute for each method in the relevant ejb-jar.xml deployment descriptor, from the six recognized by the EJB specification (we'll discuss EJB transaction attributes in detail in ).
• Call an EJB API method to mark a transaction for rollback if required by business logic.

EJBs with CMT can also normally also use declarative control of transaction isolation level, although the EJB specification does not mandate how this should be achieved. Transaction isolation refers to the level of separation between concurrent transactions. We'll discuss this in the next chapter. The J2EE specification doesn't mandate how transaction isolation levels are set. Typically, a container will use an additional proprietary deployment descriptor such as WebLogic's weblogic-ejb-jar.xml EJB deployment descriptor to provide this information.

Transaction Management in the Sample app

The sample app is partly transactional. Therefore, the use of an EJB with a local interface is appropriate for the tutorialing process. This will enable us to use CMT and avoid direct use of JTA.

EJB and Authorization

Most J2EE components have programmatic access to the user's security principal to establish which roles the user is in. In the web container, this can be obtained from the javax.servlet.http.HttpServletRequest.getUserPrincipal() method; in the EJB container, from the javax.ejb.EJBContext.getCallerPrincipal() method. The javax.ejb.EJBContext.isCallerInRole() method provides a convenient way to check whether a user is in a particular role. Only asynchronous invocations received via JMS are not associated with principal information. However, EJBs have the alternative of declarative restriction of user principals. We can use the EJB deployment descriptor (ejb-jar.xml) to specify which methods are accessible to which user roles without needing to write a line of code. It's also possible to modify these restrictions without changing app code by redeploying the EJB. The web container offers declarative restriction of app URLs, but this delivers less fine-grained control. It also only protects business objects from unauthorized access via the web interface. In a collocated web app architecture, this is probably all the protection that business objects need, but it's insufficient for distributed apps. Even if we use EJB authorization, we will also normally implement web tier authorization – we don't want to permit users to attempt operations for which they lack authorization.

Declarative authorization is a valuable service which can indicate the use of EJB. However, it's less critical in collocated web apps, in which there is no risk of unauthorized access to EJBs.

EJB and Multi-threading

EJBs are written as though they are single-threaded. The EJB container performs the necessary synchronization behind the scenes. Sometimes this can greatly simplify app code, but, as I observed in , it is probably overrated as an argument for using EJB. Often EJB won't solve all our threading problems. Even in large apps, there is no requirement to write really complex concurrent code. Not to mention that EJB is not the only good solution for multi-threading. The sample app illustrates this. We don't need to use EJB to simplify threading. Simply by avoiding instance data, we can ensure that servlets and other presentation tier classes are threadsafe. The same approach can easily be extended to our stateless business objects. Threading issues are likely to be encountered in this app only where data caching is concerned. EJB won't help us with this problem, due to the EJB coding restrictions (discussed later in the chapter) and because we really want to cache data in the web tier, not the EJB tier, to maximize performance. Thus we'll address any threading issues we may encounter using third-party, non-EJB libraries such as Doug Lea's util.concurrent. This means that we don't need to write our own threadsafe caches from scratch, but don't need to rely on EJB for concurrent access.

Of course, where we have already decided to use EJB (in the tutorialing process), we will also take advantage of EJB's concurrency control.

Declarative Configuration Management

Another potential reason to use EJB is the mechanism it offers to manage environment variables and app "wiring" through the standard ejb-jar.xml deployment descriptor, enabling EJBs to be reconfigured without the need to modify Java code.

Such externalization of configuration is good practice. However, it is available to all J2EE components to some degree (for example, in the specification of named DataSource objects) and there are simpler ways, such as using ordinary JavaBeans, to separate configuration from code throughout J2EE apps (EJB deployment descriptors are verbose and complex, and only allow XML-based definitions). Hence this is not a strong argument for using EJB.

The Downside of EJB

Before we commit to using EJB, we must consider its negatives as well as positives.

So Much Infrastructure

All EJBs except message-driven beans require at least three Java classes to be implemented by the developer:

• The local or remote home interface. This allows the client to create and locate instances of the bean. The EJB container must provide an implementation of this interface at deploy time.

• The local or remote interface. This defines the business methods supported by the bean, and is also called the component interface of the bean. The EJB container must provide an implementation of this interface at deployment time, based on the bean implementation class.
• The bean implementation class. This implements the relevant interface – javax.ejb.SessionBean or javax.ejb.EntityBean – defining the container callbacks, and provides implementations of the business methods supported by the bean. The bean class should not implement the bean's remote or local interface, although this is legal. However, it is required to implement methods matching the signature of each business method. We'll discuss the "Business Methods Interface" EJB technique, which can be used to formalize this relationship to avoid coding errors, in .

Each group of EJBs deployed in an EJB JAR deployment unit will need one or more XML deployment descriptors, which may be complex. At deployment time, the EJB container is responsible for generating the missing pieces of the EJB jigsaw: stubs and skeletons handling remote invocation, and the implementation of the local or remote home, and the local or remote interface. Code using EJBs is also more complex than code that uses ordinary Java objects. Callers must perform JNDI lookups to obtain references to EJB component interfaces and must deal with several types of exception. Why is all this necessary? To deliver services such as transparent transaction management, the container must have complete control over EJB instances at runtime. The use of container-generated classes enables the container to intercept calls to EJBs to manage instance lifecycles, threading, security, transaction demarcation and clustering. When EJB is used appropriately, this is a good tradeoff, enabling the container to take care of issues that would otherwise need to be addressed in user code. In such cases, "simple" non-EJB architectures may turn into a morass of DIY solutions to problems that have already been well addressed by EJB containers. However, if the payoff introduced by the EJB indirection isn't sufficient, we'll end up with a lot of infrastructure we don't really want. The orthodox J2EE view is that this doesn't matter: tools will synchronize all these classes. However, this is unrealistic. It's better to avoid complexity than to rely on tools to manage it.

I'll spare you the EJB lifecycle diagrams. However, it is important to understand them, and if you're unfamiliar with them, I suggest that you refer to the relevant sections of the EJB 2.0 specification (http://java.oracle.com/products/ejb/docs.html).

Programming Restrictions Applying to EJBs

In we discussed the practical problems that EJBs can produce: essentially, greater complexity in development, deployment, and testing. There's another important problem area that must be considered before using EJB. Hidden away in section 24.1.2 of the EJB 2.0 Specification (page 494) is a section describing "the coding restrictions that a Bean Provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB 2.0 Container". This section of the specification is essential reading for all developers working with EJB. Not only does awareness of the restrictions enable us to avoid violating them; it also helps towards understanding the EJB model. Here we discuss some of the most important parts of those restrictions and the rationale behind them. The individual restrictions can be attributed to three main purposes:

• Clustering
  EJBs must be able to run in a cluster, and the EJB container must be free to manage bean instances across a cluster. This means that we cannot rely on assumptions – such as the behavior of static fields, and the implications of synchronization – that hold true within one JVM.

• Thread management
  The EJB container must be able to manage threads, and EJBs must not be able to hijack such management by creating their own threads or affecting the execution of container-managed threads.
• Security
  The EJB container must be able to manage the security environment of EJBs. Declarative or programmatic security guarantees are worthless if an EJB behaves in an uncontrolled manner.

The following table summarises the most important restrictions and their implications for EJB developers:

Most of these restrictions aren't problematic in practice. Remember that we choose to use EJB if it helps to avoid the need to write low-level code, such as code that handles concurrent read-write access: it makes little sense to choose to use EJB and then battle against self-imposed restrictions. However, these restrictions do make some common problems hard to solve simply in the EJB tier. Let's consider some of the implications of these restrictions. How seriously should we take the EJB restriction on synchronization? The EJB specification is clear that EJBs shouldn't use synchronization in their own business methods, and (as we've seen) there is good reason for this. However, the specification doesn't make it clear whether it violates the specification if an EJB uses a helper class that uses synchronization. I think we need to be pragmatic here. Attempting business operations in EJBs that depend on synchronization (rather than EJB container thread management) reflects use of EJB where it simply doesn't fit, or a lack of understanding of EJB container services. However, some classes that we wish to use as helpers may perform some synchronization – or we may not even have the source code, and be unable to verify that they don't use synchronization. Logging packages and pre-Java 1.2 collection classes such as java.util.Vector and java.util.HashTable are common examples of packages that use synchronization. If we worry too much about this, we risk spending more time concerned with violating the EJB specification than implementing business logic.

We should satisfy ourselves that such classes don't use synchronization in a way that will break clustering and that their use of synchronization couldn't conflict with EJB container thread management (which might be the case if synchronization is used heavily).

The Singleton Problem in EJB

Developers often find that they want to use the Singleton design pattern – or a more object-oriented alternative that achieves the same ends, such as those we've discussed in – in the EJB tier. A common reason is to cache data, especially if it does not come directly from a persistent data store and entity beans are not appropriate. Unfortunately, singleton functionality is a poor fit with the EJB model. In this section, we consider some of the difficulties and potential workarounds.

Java Singletons

Ordinary Java singletons – in which the Singleton pattern is enforced by a private constructor and the singleton instance held in a static member variable – can be used in the EJB tier, but are subject to limitations that seriously restrict their use. Since the EJB specification prevents the use of read-write static variables and synchronization, it's impossible to use singletons in many typical ways. This is an instance of the use of synchronization that violates both the spirit and letter of the EJB specification, as it involves app business logic. It is possible to avoid violating the restriction on read-write static data by initializing the singleton instance in a static initializer, as in the following example, which makes the static member final:

public class MySingleton {
 static final MySingleton instance;
 static {
 instance = new MySingleton();
 }
 public static MySingleton getInstance() {
 return instance;
 }
 private MySingleton() {
 }
}

Initializing the singleton in a static block is good practice outside the EJB tier, too. The common practice of instantiating the instance only if it's null in the static getInstance() method is susceptible to race conditions. Note that the static initializer shouldn't attempt to use JNDI, as there's no guarantee when the EJB container will instantiate the class. In the above example, the singleton instance could have been created when the instance variable was declared. However, using a static initializer is the only option if instantiating the singleton can result in an exception. It allows us to catch any exception and rethrow it in the getInstance() method. However, we're still likely to encounter problems, depending on what the singleton does. The likeliest problem is a race condition. As we can't use synchronization in the singleton's business methods and all EJBs running in the container will share the same singleton instance, we have no way of limiting concurrent access. This restricts the use of singletons for data caches: only if race conditions are acceptable can we cache data in a singleton. This may limit caching to read-only data. Use ordinary Java singletons in the EJB container only under the following circumstances:

• The singleton instance can be initialized in a static block (or at the point of declaration) to avoid race conditions

• The singleton isn't prohibitively expensive to initialize
• The singleton doesn't require JNDI access to initialize
• The work of the singleton doesn't require synchronization

RMI Objects

Given these restrictions, it seems a good idea to get singletons out of the EJB sandbox. One commonly suggested way of doing this is to make the singletons remote objects, and to access them from EJB code via RMI. However, implementing and accessing singletons as RMI objects is complex and error prone, and I don't recommend it. The singleton isn't managed by the EJB container, and will become a single point of failure. If the RMI server fails, the EJB container will have no way of dealing with the ensuing problems. Remote method invocation between EJBs and RMI object may also limit performance. And we certainly won't want to introduce RMI for this reason if we're using only EJBs with local interfaces.

Stateless Session Bean Pseudo-cache

Sometimes when something is particularly difficult to implement, it's worth taking a step back to look at what we're trying to achieve. What we're trying to achieve with singletons may be achievable with a different implementation strategy. Stateless session beans are created and destroyed infrequently by an EJB container. Each instance will normally service many clients in its lifetime. Thus a helper object maintained in a stateless session bean can be used to provide some of the caching services of a singleton: data held in it (and built up as an app runs) will be available through ordinary Java method invocation. The advantages of this approach are that it doesn't violate the EJB coding restrictions and is easy to implement. The issue of synchronization won't arise, as each SLSB instance will behave as if it is single threaded. The disadvantage is that we will end up with one "singleton" instance per session bean instance. In the case of stateless session beans, there will be at most tens of instances, as the stateless session bean lifecycle is independent of any individual client. However, the object duplication will be a problem if it's vital that all session bean instances hold the same cached data (which may be the point of using the singleton pattern).

This approach is of little value when using stateful session beans and of no value to entity beans, as these objects may change identity frequently. However, I can think of few legitimate reasons that an entity bean would need to use a singleton.

"Read-only" Entity Beans

If your EJB container supports "read-only" entity beans, it may be possible to use them as singletons. However, this approach isn't portable, as the EJB specification doesn't currently define read-only entities. The performance implications may be unclear, as locking strategies for read-only entities vary. I don't recommend this approach.

JMX or Startup Class

Another approach is to bind the singleton in JNDI using either proprietary app server functionality (such as WebLogic's "startup classes") or JMX. JBoss provides a particularly elegant way of binding JMX MBeans to a bean's environment. EJBs can then look it up at runtime. However, these approaches arguably remove the singleton from the EJB sandbox in appearance rather than reality. Synchronization, for example, will still violate the EJB coding restrictions. The Singleton design pattern is a problematic area in EJB. We've considered a number of workarounds, none of which is perfect.

When using a distributed architecture with remote interfaces exposing core business logic, singleton functionality supporting this business logic will need to stay in the EJB container. In this case we will probably need to choose the lesser of the evils discussed above in the context of the current app.

Timer Functionality

Another piece of commonly required functionality that is problematic to implement in the EJB container is timer or scheduling functionality. Imagine that we want an object in the EJB tier to be prompted regularly to perform a certain operation. Outside the EJB tier, we could simply create a background thread to do this, or use the java.util.Timer convenience class introduced in J2SE 1.3. However, both these approaches violate the EJB specification's restrictions on creating threads. There is no satisfactory standard solution to this longstanding problem in EJB 2.0, although EJB 2.1 introduces one. We will usually need to resort to server-specific solutions. JBoss and other servers provide components that address this issue.

EJBs in the Sample app

The sample app's reservation and tutorialing (confirmation) process is transactional. So by using EJB with CMT we can simplify app code by removing the need to use JTA directly. We don't require EJB thread management services; although we will probably need to implement some multi-threaded code in the web tier (see Caching later in the chapter), there's no obvious requirement for really complex multithreaded code.

A choice of not using EJB here would be quite defensible, as the app does not need EJBs to support remote clients – the one service that can not rationally be delivered without using EJB. While using JTA directly might be more error-prone (although not unduly complex), using a framework that offers declarative transaction management without the overhead of EJB would be a reasonable implementation choice.

Previous    Next