Expert One-on-One™ J2EE™ Development without EJB™

Chapter 17. Conclusion

In this book we've attempted to describe architectures, principles, and coding practices that help to produce simple, high-quality, maintainable, performant, and scalable J2EE applications, on time and within budget.

We feel that the main problem with J2EE is the complexity that often surrounds its use. We've attempted to demonstrate simpler approaches to solving common problems in J2EE.

We've argued that EJB often adds to this complexity. While EJB promises to reduce complexity in areas such as transaction management and threading, this claim is highly debatable. There are simpler alternatives to solving most problems that EJB addresses.

We've focused on web applications, but the architectural principles we've discussed are by no means limited to web applications.

There are some applications—especially distributed applications—in which EJB still offers much value. Unlike advocates of EJB itself for most of the history of EJB, we don't claim to have the perfect solution for all middleware problems but merely a very good solution for the majority of problems we see in real applications.

Looking Back

The J2EE platform is a remarkable achievement, with immense buy-in from vendors, managers, and developers. However, we can't ignore the fact that, for many applications, J2EE has not been a shining success. Failures are probably commoner than glowing successes. J2EE projects are often poor value for money: Many projects are late; most go over budget. Many applications ...