Tapestry in Action: Implementing a Tapestry Application

Tapestry in Action: Implementing a Tapestry Application

This portion of a chapter is an excerpt from the book © Tapestry in Action and is posted with permission from Manning Publications Co.

This chapter covers

Dividing the application into layers Combining Tapestry with Enterprise JavaBeans Authenticating the user Adding security checks to pages Deploying an enterprise application

In the previous chapter, we described the Virtual Library, a demonstration application included with the Tapestry distribution. We covered quite a bit of functionality, some of which is specific to individual pages, while other functionality is distributed throughout the entire application. In this chapter, we’ll get down to the nuts and bolts of implementing the Virtual Library. Along the way, we’ll investigate how to best utilize the facilities of Java 2 Enterprise Edition (J2EE) to support the application, and how to best organize our code for robustness and maintainability.

The source code for the Virtual Library is part of the main Tapestry distribution; the code for the Enterprise JavaBeans (EJBs) is in the examples/VlibBeans directory; and the code for the Tapestry portion of the application is in examples/Vlib. Appendix B tells you how to obtain the Tapestry distribution.

10.1 Looking at the application layers

Because it’s a J2EE application, the Virtual Library is split into two distinct sections: a presentation layer and an application layer, as shown in figure 10.1. The presentation layer is the user-facing aspect of the application, and is the portion constructed using Tapestry. The application layer consists of the session and entity EJBs that, ultimately, interact with the database.

The application layer for the Virtual Library consists of six EJBs (listed in table 10.1): three entity beans using container-managed persistence, and three session beans. The presentation layer will only access two of those beans: Book-Query and Operations.

Figure 10.1 The presentation layer, the Tapestry portion of the application, is separate from the
application layer.

Table 10.1 EJBs used to manage interactions with the database

All database access, without exception, occurs in the application layer, as either direct Java Database Connectivity (JDBC) calls in the Operations, BookQuery, or KeyAllocator bean, or as container-managed persistence in the three entity beans. In a production environment, the presentation and application layers will be operating within the same Java Virtual Machine (JVM). Most application servers (including JBoss and WebLogic) will recognize this configuration and have the different objects communicate directly, without utilizing Remote Method Invocation (RMI). RMI is intended for communications between different processes often on different servers, so avoiding that overhead provides a great performance boost.

In a development environment, things are different. During development, the application layer changes far less often than the presentation layer. When was the last time you tweaked an EJB because it “didn’t look right”? Here’s where the enforced discipline of developing a J2EE application, with real separation between the layers, actually pays off: The application layer can run in one process, just as it would in a production environment, while the presentation layer runs in another process, executing within your IDE. Important advantages to structuring your development environment this way include the following:

Debugging the presentation layer is much faster and easier than debug¬ging the application server remotely, especially when using an IDE that supports “hot code replace” (changing methods while the application is still running), such as Eclipse. The presentation layer may be stopped and restarted in a manner of a few seconds. Even a lightweight application server such as JBoss can take at least a minute, often much longer, to shut down and restart. You can work on files directly within your development workspace, without constantly having to repackage and redeploy your web application. You will discover early any problems with object serialization (of any value objects that move between the two layers). Operating within a single JVM can mask these problems (since RMI will not be used).

 

Created: March 27, 2003
Revised: May 8, 2004

URL: https://webreference.com/programming/tapestry/1