EJB

Java development is at a crossroads. The open standards have done lot of good for the Java platform and language, but they have brought in some problems too. Developers are often drenched in the complexities that surround Java development. Worse yet, these complexities are so overwhelming that the actual business problems take a back seat.

The J2EE specification provides a lot of APIs, standards, and open ends that allow architects, designers, and developers to build superior enterprise systems. Care must be taken to engage in the balancing act of choosing the right technology.

Technology development has created more confusion for the developers (unless developers are versatile) rather than helping them to resolve the issues. Often, architects and developers spend most of their time supporting their chosen framework instead of concentrating on the business problem in hand.

This article discusses the techniques involved in designing and developing superior J2EE applications using the Enterprise Java Beans (EJB) specification. While the article does not intend to show how to use EJB, I'll discuss the various pitfalls in EJB development and essentially focus on the real-world antipatterns that sneak into your development.

Learning things the hard way is nice, but due to the ever-shortening development cycles, it is smarter to learn from mistakes made by other people. Having a comprehensive understanding of where the dangers are will help one to take a proactive strategy, which is precisely the theme of this article. We will start with the EJB Context in J2EE applications and then discuss some potential dangers that exist in EJB development.

Effective EJB Decision
Software is an engineered art and the engineering is continuous. With each exciting technology such as the EJB specification, weary engineering minds tend to adopt the exciting new technology in hurry. This is one reason most EJB projects fail. Often they fail so badly that they finish at point of no return. It would be wiser to engineer the choice of EJB rather than to embrace it just because it's a hot, sexy, and promising technology.

With regard to component architecture for building distributed, transactional, and persistent business solutions, the decision to use EJB in software projects demands a careful analysis and proactive planning with sound engineering practices.

Choosing Unwisely (A Golden Hammer for a Fly)
"When you have a hammer in your hand, everything looks a nail." This phrase befits most EJB choices. EJB may not be the best suited for most projects simply because the following are true:

• You have already paid for the server and have an EJB container ready for use
• You are doing enterprise Java development (is your business really an enterprise?)
• You want a fully portable architecture (is EJB really portable?)
• You have a container and EJB allows you to delegate most of the jobs to the container (this would reduce the development cost/time and ensure fast time to market)

Solution (Choose Wisely)
Figure 1 shows the trade-off between project size and cost for a simple POJO (Plain Old Java Objects) solution and an EJB solution.

Choosing an EJB Solution

• Strive to achieve the break-even point quickly
• Choose EJB if your project is complex (as seen in the graph, EJB projects start complex and expensive, but ramp up more slowly with project size)
• Choose EJB if the services provided the EJB container are needed for the business; in other words, choose EJB if the answer is YES to the following questions:
  - Do your components need to be distributed?
  - Do you need to handle global transactions?
  - Do you have security requirements at the business-component level?
  - Do you need a persistence framework that rund inside a managed environment?
  - Does your application need high scalability?

Not Everything Is an EJB
The most often seen misinterpretation of EJB among junior- and intermediate-level users is that when you use EJB, every component is an EJB.

No. This is rarely true. A component or a subsystem may be a true EJB candidate while others can be just POJOs. This mixed-mode design is tough, but engineering the design decisions at each component/subsystem level makes life easier during the roll out.

Coarse-Grained and Fine-Grained Services
One key aspect of choosing EJB at the subsystem level is to understand the EJB services. EJB components come in two flavors: a set of work horse components called session beans and a set of persistence components called entity beans. Session beans are generally coarse-grained services that take advantage of a container's ability to provide distribution, transaction management, and security. For a non-EJB component, the implementation of these services is the developer's responsibility. Components that make heavy use of these services are often the right candidates for session EJBs.

The EJB specification mandates support for fine-grained persistence services through entity beans. Each entity bean can itself be again distributed, transaction aware, and secure and hence there is a complex mixture of fine-grained and coarse-grained services. Often, this mixture makes entity bean components very difficult to manage. If a component needs to be just persistent, there is seldom a need for the component to be an EJB. Other popular, lightweight persistence frameworks exist (e.g., JDO, Hibernate etc.) that are easier to maintain.

Effective EJB Interfaces
One of the key aspects of EJB design is creating interfaces. Interfaces are the lingua franca of the EJB components. They serve as a vehicle to expose the services provided by the EJB component to the external world. Poor interface design would lead to EJBs that are hard to maintain and change.

Considerations for Interface Design
What is the size of your network pipe? At the end of the day, EJB is RMI. It involves remote procedure calls. The location transparency will just add some more network complexity. The EJB calls involve significant marshalling and unmarshalling of parameters over the network. Care should be taken when designing the remote interfaces. If you have a big pipe and can stream large data quickly through it, then the interfaces can be coarse grained. On the other hand, if you have a smaller bandwidth, then you're probably better off having finer-grained interfaces and lightweight parameter marshalling.