3.5 A J2EE Perspective
It is not enough to download the J2EE platform components and start writing enterprise applications with just any tool. Choosing the right development environment and application server determines whether complexity will be shielded and managed, or be an ever-present struggle during the development process. Realizing the full potential of J2EE technologies requires more than just a toolit requires a pattern-based approach that engages tool-produced artifacts.
Many choices are available to the developer who wants to use J2EE technology. Some are free, others are vendor-supported. Obviously if you are reading this you are interested in the IBM WebSphere suite of products. The remaining chapters capture and describe the complete cycle from development to deployment utilizing the WebSphere Studio Application Developer product and its integrated tooling support. Besides providing a complete tutorial on how to utilize these tools and the application server, we will describe design approaches and patterns that can help make your development and deployment process, as well as the resulting software, flexible to better meet changing business needs.
As we discussed in Chapter 1, we see the idea of layered application architecture as being critical to J2EE, and to understanding the architecture of the WebSphere product family. Figure 3.4 illustrates how the different technologies we've just covered fit into that layered architecture.
Figure 3.4. Layered J2EE application architecture.
At the top of our architecture is the presentation layer. We'll discuss providing presentation layers based on HTML using Java servlets, JSP, and eXtensible Stylesheet Language Transformations (XSLT). XSLT, not a J2EE technology, is a mechanism for transforming XML documents into HTML (commonly used along with servlets and JSP). We will also consider Web services in this layer, even though they are considered to be a program-to-program communication mechanism. We'll also examine how to test servlet-based applications using the open-source HTTPUnit tool.
Next comes the controller/mediator layer, which captures the notion of application flow and adapts the domain model layer to the presentation layer. We'll examine several ways of implementing controller logic, including implementing it with servlets, using the Struts open-source application framework, and even using message-driven beans (which are EJBs called through JMS) as application controllers for asynchronous logic flows.
In the domain layer, we'll examine how to implement domain logic using Java Beans (or, more correctly, Plain Old Java Classes) and EJBs. We'll also show you how to test your domain logic using the open-source JUnit toolkit. To support the persistence of objects in the domain layer, we'll examine the mapping layer in depth, discovering how to use mapper objects, bean-managed persistence (BMP) and container-managed persistence (CMP) entity EJBs.
In addition to showing you how to test with JUnit, we'll show you how to use the WebSphere Studio Universal Test Client. Finally, we'll examine the two most common sources of data for J2EE programs, JMS and JDBC.
While the book will proceed roughly in the order we've outlined, it won't cover the layers in strict order because not every system uses every technology we've described. Instead, you can rely on the application architecture graphic (Figure 3.4), which will appear at the beginning of every chapter starting in Chapter 5, to help you understand where the technologies fit into the overall J2EE architecture.