Implementing a Solution Using EJB 2
- The EJB Runtime Environment
- Installing an Application Server and Deploying EJBs into It
- Divide and Conquer
- The Rest of the Story: Deploying EJBs
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
In this chapter
-
The EJB Runtime Environment
-
Installing an Application Server and Deploying EJBs into It
-
Divide and Conquer
-
The Rest of the Story: Deploying EJBs
Now that you have documented the basic design tenets of the BookEaz system in the logical model, it is time to enter coding mode: The days of implementation have arrived. Although some of the Java code you'll see looks like normal J2SE code, much of it does not; EJB 2.0 radically and irrevocably alters the fundamental look and feel of Java code.
The most pronounced change is in the quantity of Java code needed to implement a Java class. When transformed into EJB 2.0 components, J2SE-based classes containing hundreds of lines of code become EJBs containing only dozens of code lines. This dramatic reduction in source lines of code (SLOC) is caused by EJB 2.0 assuming many of the responsibilities formerly thrust on implementers. Under the old J2SE regime, for example, "business classes" (those residing in an architecture's business domain–specific upper layers) contained code for addressing transaction, security, and life-cycle issues. These issues are now factored out of classes in the upper layers and are handled instead by the EJB infrastructure occupying the architecture's lower levels. Merely by recasting vanilla Java implementations into EJB 2.0, an implementer's coding tasks are suddenly much less burdensome because the amount of code to be written is suddenly much smaller.
Alas, coding seems to adhere to Newton's Law: For every action, there is an equal and opposite reaction. EJB implementations contain far fewer lines of Java code then their non-EJB corollaries, but this reduction in SLOC is accompanied by a dramatic increase in implementation information expressed outside Java's purview. An Extensible Markup Language (XML)–based text file—the deployment descriptor—accompanies every EJB component's Java implementation. It uses small declarative statements to describe many aspects of EJB components' behavior, which is hard-coded into non-EJB Java components. So, although a traditional Java component might contain several hundred SLOC for mapping the component to a database through JDBC, an EJB version of the same component would use a few dozen lines in its deployment descriptor to describe the same database mapping information. The advantage of relying on declarative statements instead of Java code is that there is far less room for error with the number of SLOC reduced so drastically. The disadvantage of relying on deployment descriptors is that many Java programmers aren't yet familiar with XML. By the time you have completed this chapter, however, you will find that understanding the deployment descriptor's contents is not overly complex; it is certainly much less difficult than the intricacies of the Java packages.
Implementing EJB components, therefore, is at once familiar and completely new territory. Much of the work that lies ahead is familiar Java, with some of the more mundane and error-prone aspects removed. These aspects are replaced by the completely new world of deployment descriptors. The rest of this chapter introduces this new way of implementing code as a series of tutorials in which each EJB component discovered during the design phase is realized via a combination of Java code and a deployment descriptor.
NOTE
This chapter makes heavy use of the J2EE Reference Server, a free (yet charmingly full-featured) EJB container. Please follow the steps outlined in Appendix B, "Installing and Configuring the J2EE Reference Server," before proceeding with the code examples in this chapter.
The EJB Runtime Environment
The previous chapters have bandied about references to EJB containers and application servers without ever defining those terms. To developers, the two terms are almost synonymous; they both refer to the runtime software environment in which EJBs are implemented. The two terms are not completely equivalent, however, and at times you might need to distinguish between the two. The following section is a quick overview of EJB containers and application servers.
EJB Containers and Application Servers
A container is a runtime environment that supports and houses components, such as EJBs, servlets, and JSPs. There are different types of containers, and each supports a particular kind of component. EJB containers support EJB-based components. When BookEaz's EJBs are deployed, for example, they are deployed into an EJB container.
An application server is a conglomeration of software services that provide a runtime environment for any number of containers, as shown in Figure 3.1. A typical J2EE application server, such as WebLogic, WebSphere, JBoss, and Sun's J2EE Reference Server, houses a multitude of containers. WebLogic, for example, supports an EJB container and a servlet container.
Figure 3.1 Application servers house EJB containers, which in turn house EJBs.){kind=link}
The EJB container provides basic services, including transactions, life-cycle management, and security, to the EJBs deployed into it. By shouldering much of this burdensome lower-level functionality, the EJB container significantly reduces the responsibilities of the EJBs deployed into it. Because EJBs no longer contain code to provide these fundamental behaviors, EJB developers are free to concentrate on writing code that solves business problems instead of computer science problems.