Section 6.2. Should I Use EJB or Not?


6.2. Should I Use EJB or Not?

From their inception, EJBs have been used for the right and wrong reasons. We've seen EJB-based projects that have failed miserably and others that were highly successful. So what made the difference? Here are a couple of key success factors with EJBs:

  • Developer knowledge and maturity

  • Decision-making

EJB development and deployment is complex with EJB 2.1 and earlier, so even if you have a good reason for using EJBs, your project still could fail if your development team hasn't worked with them before. If you're in this situation, take the same approach with EJBs as you would with any other technology that's new to youlearn how to use it before you build your system. The best way to quickly get up to speed on EJB is to get some training and to augment your team with a few experienced developers who've used them to develop production-quality systems.

But taking classes, hiring experienced developers, and reading books aren't enough. You also should consider some guidelines to help you decide if EJBs are appropriate for your architecture. As we said earlier, there are both good and bad reasons for using EJBs (of all types).

Here are some reasons for not using EJBs:


Your application uses threads

The EJB specification forbids using threads because the threads your code creates are outside the container's control and could cause unexpected results.


Your application is read-only or read-mostly

If your application reads data from your database most or all of the time, then transactions aren't important to you. In this case, EJBs are overkill.

Here are some dubious or wrong reasons for developing with EJBs:


You want to use database connection pooling with JDBC DataSources

You don't need an EJB or an EJB container to use a DataSource. You can configure a standalone Tomcat container with a database connection pool and use a DataSource.


You want to use Entity Beans for persistence

Other third-party ORMs, such as Hibernate, provide more functionality and better performance.


You think you'll need them later, so you're adding them now

Don't over-architect. EJBs add complexity, so add them only when they help you solve a problem. Remember that you can always go back and refactor to an EJB solution when the need arises.


You want to group your related business logic together

You could group order-related functionality into an EJB, but you could also do this with a POJO. The need to group related logic together isn't a strong enough reason to use an EJB. But if your business processes require transactions or if you have external remote clients, you should consider using an EJBsee the good reasons below.


Web tier session caching

Caching frameworks like JBoss Cache or OSCache (by Open Symphony) provide a powerful, lightweight, and more efficient alternative to the overhead incurred by EJBs.

Here are some good reasons for using EJBs:


Distributed transactions

Your application may access different types of back-end systems such as databases, messaging systems, or mainframes. If one of these systems has a problem with its part of a transaction, then you want each of the other systems to roll back their unit of work. All parts of the transaction either succeed or fail together.


Asynchronous processing

Message-Driven Beans are designed for consuming JMS messages. It's easier to use an MDB than to create your own infrastructure. The next chapter will talk more about MDBs.


Declarative transactions

Rather than cluttering your code with low-level transaction management logic, you can push transaction settings into deployment descriptors. Container-Managed Transactions (CMT) is one of the most popular reasons for using EJBs. CMT uses the EJB container's transaction services and manages transaction boundaries on behalf of the developer.


Component security

Declarative security enables you to set security levels for EJBs and for individual EJB methods based on user roles. The Security chapter covers EJB security.


Remote access

You may have Java applications spread across multiple servers, or you could have a Swing user interface. In either case, EJBs are a good fit because they're designed to be distributed components. Remote EJB access uses RMI as its communications protocolRMI is part of the core Java platform and interoperates with CORBA.

If your application requirements match several of the good reasons to use EJBs, then you probably need EJBs. As a rule, if your application doesn't have requirements concerning transactions and/or asynchronous processing , then EJBs probably aren't worth the added complexity and overhead. But if your application has to deal with these issues, EJBs make sense and provide real value. Even if your application requires EJBs, you won't need them everywhere. Consider your needs on a case-by-case basis.

Real Life, Real Decisions

Tom comes from a distributed computing background where applications always ran on separate machines, so when he moved into the Java world, EJB technology was a natural fit. Here are a couple of real-world examples from projects where his clients had to decide if EJBs made sense for them.

  • A client asked our EJB enthusiast to evaluate their architecture. The client wanted to know how to build a J2EE system that followed good design principles. They were concerned that their web application running on Tomcat wouldn't scale as more users were added, and were considering buying a commercial EJB container because they thought it would make things "better." It turned out that the application was read-onlyit queried the database and showed the results on a JSP. So, there was no need to impose transactions because they weren't updating the database. In this case, using an EJB container and adding EJBs was overkill. The real issue wasn't EJBs at allthe client's real concern was that they only had a single connection to the database and that their web site would fail under heavy loads. Our author showed the client's developers how to use database connection pooling and DataSources with Tomcat because this was all that they needed. Their scalability issues were solved, and they avoided the commercial license fees for the EJB container and the cost of additional training.

  • On another project, the client had distributed applications that needed to communicate across the enterprise, and much of the business logic involved multiple database tables and back-end resources. Some business processes were synchronous and some were asynchronous. These requirements matched many of the criteria for using EJBs, so the company based its architecture on EJB technology. The project launch was a success because the technology used met the needs of the business, and the application performed well in a large-scale production environment. In this case, EJBs made sense and were the right tool for the job.


Presumably you've chosen JBoss as your application server because you've already done the analysis and your application truly requires a fully functional EJB container. Even so, the acronym You Ain't Gonna Need It (YAGNI) should never be too far from the forefront of your application design. We take an additive approach when building applications, much like the flow of this book. Don't avoid technologies that clearly solve a problem, but don't add them just because they might solve a problem at some point down the road.

Please don't misunderstand uswe don't hate EJBs and we continue to use them on real-world projects. But we encourage you to look at your system-level and business requirements before using EJBs. We use Stateless Session Beans for managing transactions and Message-Driven Beans for asynchronous processing. The next section covers transactions in greater detail.



JBoss at Work. A Practical Guide
JBoss at Work: A Practical Guide
ISBN: 0596007345
EAN: 2147483647
Year: 2004
Pages: 197

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net