style="font-size:15px;"> We make every effort to ensure that there are no errors in the text or in the code. However, no one is perfect, and mistakes do occur. If you find an error in one of our books, like a spelling mistake or faulty piece of code, we would be very grateful for your feedback. By sending in errata you may save another reader hours of frustration and at the same time you will be helping us provide even higher quality information.
To find the errata page for this book, go to http://www.wrox.com and locate the title using the Search box or one of the title lists. Then, on the book details page, click the Book Errata link. On this page you can view all errata that has been submitted for this book and posted by Wrox editors. A complete book list including links to each book's errata is also available at www.wrox.com/ misc-pages/booklist.shtml.
If you don't spot “your” error on the Book Errata page, go to www.wrox.com/contact/ techsupport.shtml and complete the form there to send us the error you have found. We'll check the information and, if appropriate, post a message to the book's errata page and fix the problem in subsequent editions of the book.
P2P.WROX.COM
For author and peer discussion, join the P2P forums at p2p.wrox.com. The forums are a web-based system for you to post messages relating to Wrox books and related technologies and interact with other readers and technology users. The forums offer a subscription feature to e-mail you topics of interest of your choosing when new posts are made to the forums. Wrox authors, editors, other industry experts, and your fellow readers are present on these forums.
At http://p2p.wrox.com you will find a number of different forums that will help you not only as you read this book, but also as you develop your own applications. To join the forums, just follow these steps:
1. Go to p2p.wrox.com and click the Register link.
2. Read the terms of use and click Agree.
3. Complete the required information to join as well as any optional information you wish to provide and click Submit.
4. You will receive an e-mail with information describing how to verify your account and complete the joining process.
NOTE You can read messages in the forums without joining P2P, but in order to post your own messages, you must join.
Once you join, you can post new messages and respond to messages other users post. You can read messages at any time on the web. If you would like to have new messages from a particular forum e-mailed to you, click the Subscribe to this Forum icon by the forum name in the forum listing.
For more information about how to use the Wrox P2P, be sure to read the P2P FAQs for answers to questions about how the forum software works as well as many common questions specific to P2P and Wrox books. To read the FAQs, click the FAQ link on any P2P page.
1
POJO Programming Model, Lightweight Containers, and Inversion of Control
• Problems of the old EJB programming model that triggered the birth of POJO movement
• Advantages of the POJO programming model
• What a container is and what services it provides to its deployed applications
• Lightweight containers and what makes a container lightweight
• What Inversion of Control (IoC) means and its importance for applications
• Relationship between IoC and dependency injection
• Dependency injection methods, setter and constructor injection
• Advantages and disadvantages of those different dependency injection methods
The Plain Old Java Object (POJO) movement started around the beginning of the 2000s and quickly became mainstream in the enterprise Java world. This quick popularity is certainly closely related with the open source movement during that time. Lots of projects appeared, and most of them helped the POJO programming model become mature over time. This chapter first closely examines how things were before the POJO programming model existed in the enterprise Java community and discusses the problems of the old Enterprise JavaBeans (EJB) programming model. It's important that you understand the characteristics of the POJO programming model and what it provides to developers.
The second half of the chapter focuses on containers and the inversion of control patterns that are at the heart of the lightweight containers we use today. You learn what a container is, what services it offers, and what makes a container lightweight. You also learn how the inversion of control pattern arises and its close relationship with dependency injection terms. The chapter concludes with an examination of two different dependency injection methods and their pros and cons.
POJO PROGRAMMING MODEL
POJO means Plain Old Java Objects. The name was first coined by Martin Fowler, Rebecca Parsons, and Josh MacKenzie to give regular Java objects an exciting-sounding name. It represents a programming trend that aims to simplify the coding, testing, and deployment phases of Java applications – especially enterprise Java applications.
You'll have a better understanding of what problems the POJO programming model solves if you first understand what problems the old EJB programming model had.
Problems of the Old EJB Programming Model
The Enterprise JavaBeans (EJB) technology was first announced around 1997. It offered a distributed business component model combined with a runtime platform that provided all the necessary middleware services those EJB components needed for their execution. It was a main specification under the J2EE specification umbrella at the time.
Many people were really excited by the promise of the EJB technology and J2EE platform. EJBs were offering a component model that would let developers focus only on the business side of the system while ignoring the middleware requirements, such as wiring of components, transaction management, persistence operations, security, resource pooling, threading, distribution, remoting, and so on. Developers were told that services for middleware requirements could be easily added into the system whenever there was any need of them. Everything seemed good and very promising on paper, but things didn't go well in practice.
The EJB 2.x specification required that the component interface and business logic implementation class extend interfaces from the EJB framework package. These requirements created a tight coupling between the developer-written code and the interface classes from the EJB framework package. It also required the implementation of several unnecessary callback methods, such as ejbCreate, ejbPassivate, and ejbActivate, which are not directly related to the main design goal of EJB.
To develop an EJB component, developers had to write at least three different classes – one for home, one for remote interfaces, and one for business objects, as shown here:
The preceding code snippet shows the minimum amount of code that needs to be written in order to create an EJB component with only one method using the EJB2 application
