Deciding whether EJB is appropriate

Motivation

A recent Gartner Group report cited companies overspent $1 billion on EJB last year, when they could have just gotten by with Servlets/JSPs. This motivates our next discussion: once you've decided whether server-side Java is the way to go, you then need to make the all-important decision: are you actually going to use EJB on this project? Or is EJB overkill?

Example

As a motivational example, consider an E-commerce site that has involved business processes. When you buy something on an E-Commerce site, the site needs to:

• Validate your credit card
  
  
• Debit your credit card
  
  
• Perhaps run some anti-fraud checking algorithms
  
  
• Check inventory
  
  
• Send a confirmation email
  
  
• Submit the order
  
  
• Fulfill the order
  
  
• Track the order afterwards
  
  
• Handle returns

You can still achieve all of this by using vanilla Servlets and JSPs. For example, you could have the Servlets and JSPs call Java classes. Those Java classes perform your business logic. In fact, there are three scenarios that we can consider when it's possible to use Java classes rather than EJB components:

In a browser client web-based system with Servlets and JSPs, you could use Java classes rather than EJB components.

In a web services system where business partners call your Servlets and JSPs using XML/HTTP, you can also use Java classes rather than EJB components (see for a whitepaper on how to build web services using J2EE).

In a 2-tier client/server system such as a Java applet or Java application connecting to a server, you could again use Servlets and JSPs on the server. The thick client could communicate with the server via HTTP, which easily navigates through firewalls (compared to IIOP, which doesn't). Behind the Servlets and JSPs could be Java classes instead of EJB components.

NOTE: A Servlet/JSP HTTP layer is only important if the users of your system are going to be behind firewalls, such as anonymous Internet clients, business partners, or other departments within your organization. It's also important if your thick client is located across the Internet, because HTTP is a lightweight protocol that travels across the Internet easily. If there is no firewall issue, or if your users are not located across the Internet (but rather are on your local area network) you could get rid of your HTTP layer and connect the client to EJB components directly. In this case, the EJB value proposition is very strong, because EJB allows the client to call the server using intuitive method names, removes the need to perform XML marshaling, and gives you automatic remotability and load-balancing.

The Fear, Uncertainty, and Doubt

So how do you decide which is the right paradigm? Let's start out with the reasons that most people think are important for deciding between EJB and Java classes, but are actually not important at all.

EJB server cost. The major J2EE server vendors, such as IBM, BEA, and Oracle, do not sell their EJB layer separately from their Servlet/JSP layer. They sell a single "J2EE server" which bundles both layers. So if you go with a market leader, then you're probably going to buy an EJB server whether you like it or not. The only way to avoid this cost is to purchase an open-source or inexpensive Servlet/JSP implementation. This is a viable option, this is not recommended for major deployments. Why? Because the cost of the J2EE server is often a drop in the bucket compared to the total cost of the project. If the server doesn't work out, consider all the retraining you'll need to pay for, and the code you may need to rewrite if the servers use different versions of the J2EE specifications. Consider the difficulty in hiring skilled professionals if you don't go with a market leader, the cost of re-learning how to tune your new server, and the cost of learning how to administer that new server. The cost of the application server should not be an issue for most serious deployments--most major vendors are charging very reasonable fees, far less than the $50,000 per processor that was charged back in the day. Rather, you should consider whether an EJB layer or a Java class layer is appropriate for your project. The professional services fees--we call it geek time--tends to dwarf the application server cost.

Resource pooling. Some people think that only EJB can give you resource pooling. Not true. Almost all the major J2EE server vendors allow you to get connection pooling and thread pooling whether you use Servlets/JSPs or EJB components.

Clean separation of business logic and presentation logic. EJB is nice because it enforces a separation of presentation logic (Servlets and JSPs) from business logic (EJB components). We like this because in the future we can support different types of presentation logic, such as a WAP enabled phone, or an XML data stream client from a business partner. But you can achieve the same results with Java classes instead of EJB components as well. You just need to enforce some coding best-practices in your organization about the proper usage of Java classes as a business layer facade.

Deciding the right way

Now that we've blown away the FUD (Fear, Uncertainty, and Doubt), here are the real reasons to use EJB over Java classes:

Your system is built faster and more reliably. EJB components benefit from declarative middleware, such as instance pooling, transactions, security, container-managed persistence, container-managed relationships, and data caching. If you used regular Java classes, you'd need to write this middleware yourself over time. Eventually you might find that you have your own middleware framework. That 'framework' is a fancy word for building your own home-grown application server. The framework needs to be tested, debugged, features need to be added. This is a non-trivial task indeed. Can you honestly state that your staff is capable of building a better application server than the market leaders who specialize in middleware?

It is easier to hire new employees. If you build your own custom framework using Java classes, then newhires need to be trained on this framework. If your framework is complex, then you can no longer look for "EJB" on a resume when hiring a developer and expect them to be productive on your system.

You benefit from the best practices the world is building around EJB. You can figure out how to optimize your system by reading articles on the Internet, or picking up a book on EJB best practices, such as Floyd Marinescu's "EJB Design Patterns" book. This global knowledge base is not at your disposal with a proprietary Java class framework.

You can have different user interfaces. You can reuse the same EJB component layer for a thick client as well as a Servlet/JSP client. With Java classes, you cannot achieve this because Java classes are not remotely accessible. If you wrapped those Java classes in RMI objects, you'd need to invent your own load-balancing, instance pooling, and fail-over.

You can work with industry-standard tools to rapidly develop your system. While in the short run you may think that Java classes are going to make it faster to develop than writing all those files that comprise an EJB component, in reality there are many tools around that help streamline the EJB development process. There are command-line tools that generate the files you need, there are IDEs that help you build EJB components, and there are UML editors that help you generate EJB components from UML diagrams. See for more.

You can separate your web tier and application server. If you require your business logic to be protected by a firewall, then you can deploy the web server and application server on separate machines and stick a firewall in the middle.

And here are the real reasons not to use EJB:

You can't deal with the limitations of EJB. Examples include threading, static variables, and native code. Most companies can deal with this, because there are good reasons why the restrictions exist. But if (for example) you need to have a multi-threaded engine, and you can't deal with the EJB paradigm of load-balancing across single-threaded instances, then EJB is not a good fit for you. EJB is a square peg--don't try to stick it into a round hole.

Your have existing skillsets or investments in a working technology. For example, if your developers are proficient in CORBA, then great--why not stick with it? As an anecdote, The Middleware Company consulted with one of our clients who wrote a CORBA application that assisted with mapping the human genome. It worked well with CORBA, and they had no major complaints, and so we recommended they stick with CORBA and avoid the EJB hype.

Your application is a big GUI to a database. If you are just a big GUI to a database--heavy on data logic but no business logic--you could achieve a deployment easily using JSPs with tag libraries connecting to a database via JDBC.

Your application is simple. If you are prototyping, building a simple system, or developing a one-off application that will not evolve over time, EJB may be overkill.

Summary

In summary, it is a perfectly valid strategy to use EJB, or to use Java classes. Just make sure you know why you're making the decision, and that you do it for the right reasons.

PRINTER FRIENDLY VERSION