JaVa
   

When to Use EJB

One of the most important design decisions when designing a J2EE app is whether to use EJB. EJB is often perceived to be the core of J2EE. This is a misconception; EJB is merely one of the choices J2EE offers. It's ideally suited to solving some problems, but adds little value in many apps. When requirements dictate a distributed architecture and RMI/IIOP is the natural remoting protocol, EJB gives us a standard implementation. We can code our business objects as EJBs with remote interfaces and can use the EJB container to manage their lifecycle and handle remote invocation. This is far superior to a custom solution using RMI, which requires us to manage the lifecycle of server-side objects. If requirements don't dictate a distributed architecture or if RMI/IIOP isn't the natural remoting protocol, the decision as to whether to use EJB is much tougher. EJB is the most complex technology in J2EE and is the biggest J2EE buzzword. This can lead to developers using EJBs for the wrong reasons: because EJB experience looks good on a resume; because there is a widespread belief that using EJB is a best practice; because EJB is perceived to be the only way to write scalable Java apps; or just because EJB exists. EJB is a high-end technology. It solves certain problems very well, but should not be used without good reason. In this section we'll take a dispassionate look at the implications of using EJB, and important considerations influencing the decision of whether to use EJB.

Implications of Using EJB

One of the key goals of the EJB specification is to simplify app code. The EJB 2.0 specification (§2.1) states that "The EJB architecture will make it easy to write apps: app developers will not have to understand low-level transaction and state management details, multi-threading, connection pooling, and other complex low-level APIs." In theory, by deferring all low-level issues to the EJB container, developers are free to devote all their effort to business logic. Unfortunately, experience shows that this is not often realized in practice. Using EJB often adds at least as much complexity to an app as it removes. Moreover, it may be dangerous for developers to "not have to understand" the enterprise software issues that their apps face. Introducing EJB technology has the following practical implications, which should be weighed carefully:

The pernicious effects of unnecessarily using EJBs with remote interfaces include:

These objections don't apply when we genuinely need distributed semantics. In this case, EJB isn't the cause of the problem but an excellent infrastructure for distributed apps. But if we don't need distributed semantics, using EJB has a purely harmful effect if it makes an app distributed. As we've discussed, distributed apps are much more complex than apps that run on a single server. EJB also adds some additional problems we may wish to avoid:

These are important considerations. Most tutorials ignore them, concentrating on theory rather than real-world experience.

Let's now review some of the arguments - good and bad - for using EJB in a J2EE app.

Questionable Arguments for Using EJB

Here are a few unconvincing arguments for using EJB:

Compelling Arguments for Using EJB

Here are a few arguments that strongly suggest EJB use:

Arguments for Using EJB to Consider on a Case-by-Case Basis

The following arguments for using EJB should be assessed on a case-by-case basis:

Important 

EJBs are a good solution to problems of distributed apps and complex transaction management. However, many apps don't encounter these problems. EJBs add unnecessary complexity in such apps. An EJB solution can be likened to a truck and a web app to a car. When we need to perform certain tasks, such as moving large objects, a truck will be far more effective than a car, but when a truck and a car can do the same job, the car will be faster, cheaper to run, more maneuverable and more fun to drive.

JaVa
   
Comments