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.