| CONTENTS | PREV | NEXT | INDEX | Designing Enterprise Applications with the J2EETM Platform, Second Edition |
The following sections present a number of application scenarios, setting the stage for a detailed discussion of the sample application. The J2EE specifications encourage architectural diversity. The J2EE specifications and technologies make few assumptions about the details of API implementations. The application-level decisions and choices are ultimately a trade-off between functional richness and complexity.
The J2EE programming model is flexible enough for applications that support a variety of client types, with both the Web container and EJB container as optional. Figure 1.2 reflects a range of possible application configurations, including cases where clients interact solely with the Web container, where clients interact directly with the EJB container, and full-blown multitier applications with stand-alone clients, Web-tier components, middle-tier EJB components, and EIS-tier access to resources and data. While the J2EE platform has no implicit bias favoring one application scenario over another, a J2EE product should be able to support any and all of these scenarios.
The sample application is a multitier application that uses both a Web container and an EJB container. The following enterprise requirements heavily influenced the choices made in developing the sample application:
- The need to make rapid and frequent changes to the "look" of the application
- The need to partition the application along the lines of presentation and business logic so as to increase modularity
- The need to simplify the process of assigning suitably trained human resources to accomplish the development task such that work can proceed along relatively independent but cooperating tracks
- The need to have developers familiar with back-office applications unburdened from GUI and graphic design work, for which they may not be ideally qualified
- The need to have the necessary vocabulary to communicate the business logic to teams concerned with human factors and the aesthetics of the application
- The ability to assemble back-office applications using components from a variety of sources, including off-the-shelf business logic components
- The ability to deploy transactional components across multiple hardware and software platforms independently of the underlying database technology
- The ability to externalize internal data without having to make many assumptions about the consumer of the data and to accomplish this in a loosely coupled manner
Clearly, relaxing any or all of these requirements would influence some of the application-level decisions and choices that a designer would make. Although it is reasonable to speak of "throw-away" presentation logic (that is, applications with a look and feel that ages rapidly), there is still significant inertia associated with business logic. This is even more true in the case of database schemas and data in general. It is fair to say that as one moves further away from EIS resources, the volatility of the application code increases dramatically; that is, the code's "shelf-life" drops significantly.
In summary, the J2EE programming model promotes a model that anticipates growth, encourages component-oriented code reusability, and leverages the strengths of inter-tier communication. It is the tier integration that lies at the heart of the J2EE programming model.
Figure 1.3 illustrates an application scenario in which the Web container hosts Web components that are almost exclusively dedicated to handling a given application's presentation logic. JSP pages, supported by servlets, generate dynamic Web content for delivery to the client. The EJB container hosts application components that use EIS resources to service requests from Web-tier components. This architecture decouples data access from the application's user interface. The architecture is also implicitly scalable. Application back-office functionality is relatively isolated from the end-user look and feel.
It is worth noting that XML plays an integral role in this scenario. The ability to both produce and consume XML data messages in the Web container is an extremely flexible way to embrace a diverse set of client types. These platforms range from general purpose XML-enabled browsers to specialized XML rendering engines targeting vertical solutions. XML data messages typically use HTTP as their transport protocol. Java and XML are complementary technologies: The Java language offers portable code, XML provides portable data.
In the Web tier, the question of whether to use JSP pages or servlets comes up repeatedly. JSP technology is intended for application user interface components, while Java Servlets are preferred for request processing and application control logic. Servlets and JSP pages work together to provide dynamic content from the Web tier.
Figure 1.4 illustrates a stand-alone client scenario. 
The stand-alone client may be one of three types:
- EJB clients interacting directly with enterprise beans hosted in an EJB container within an EJB server, as shown in Figure 1.5. This scenario uses RMI-IIOP, and the EJB server accesses EIS resources using JDBC and the J2EE Connector architecture.
- Stand-alone clients, implemented in the Java language or another programming language, consuming dynamic Web content (usually XML data messages). In this scenario, the Web container essentially handles XML transformations and provides Web connectivity to clients. Presentation logic occurs in the client tier. The Web tier handles business logic and may directly access EIS resources. Ideally, business logic is implemented as enterprise beans to take advantage of the rich enterprise beans component model.
- Stand-alone Java application clients accessing enterprise information system resources directly using JDBC or Connectors. In this scenario, presentation and business logic are co-located on the client platform and may in fact be tightly integrated into a single application. This scenario is a classic two-tier client-server architecture, with its associated distribution, maintenance, and scalability issues.
Figure 1.6 illustrates a three-tier Web-centric application scenario.
There are a number of scenarios in which the use of enterprise beans in an application would be considered overkill: sort of like using a sledgehammer to crack a nut. The J2EE specification doesn't mandate a specific application configuration, nor could it realistically do so. The J2EE platform is flexible enough to support the application configuration most appropriate to a specific application design requirement.
As demonstrated in the book J2EE Technology In Practice, a three-tier Web-centric application scenario is widely used as the starting point for many J2EE applications. The Web container hosts both presentation and business logic, and it is assumed that JDBC and the J2EE Connector architecture are used to access EIS resources.
Figure 1.7 provides a closer look at the Web container in a Web application scenario.
Keep in mind that the term "Web container" has a precise meaning. It doesn't necessarily mean a distinct process running on a distinct piece of hardware. In many cases, J2EE platform providers may co-locate their Web and EJB containers, running them within the same Java Virtual Machine (JVM). J2EE applications deployed on such an implementation are still considered multitier applications, because of the division of responsibilities that the separate technologies imply.
Figure 1.8 illustrates a business-to-business scenario. This scenario focuses on peer-level interactions between both Web and EJB containers. The J2EE programming model promotes the use of XML data messaging over HTTP as the primary means of establishing loosely coupled communications between Web containers. This is a natural fit for the development and deployment of Web-based commerce solutions.
The peer-level communications between EJB containers is currently a more tightly coupled solution most suitable for intranet environments. With support for JMS and message-driven beans, the J2EE 1.3 platform makes developing loosely-coupled intranet solutions increasingly practical.
Future releases of the J2EE platform will provide additional functionality in the form of Java APIs for XML, which enable more complete support for loosely coupled applications through XML-based Web services.