| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
The following sections present a number of application scenarios, setting the stage for a detailed discussion of the sample application. In reviewing the J2EE specifications, a large number of application scenarios could be considered. Indeed, the specifications tend to embrace and encourage diversity. The J2EE specifications and technologies, can by definition, make few assumptions about how precisely the APIs are going to be used to deliver application-level functionality. The application-level decisions and choices are ultimately a trade-off, between functional richness and complexity.
The J2EE programming model needs to embrace application scenarios that treat the Web container, and the EJB container as optional logical entities. Figure 1.2 reflects some key scenarios, including those where either the Web container or the EJB container, and potentially both, are bypassed.
The sample application reflects a multitier application model. This decision assumes the presence of both a Web container and an EJB container. The following enterprise requirements heavily influenced the choices made:
- 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. The J2EE programming model takes the approach that it is highly desirable to engineer a
3-tier application such that the migration to a future multitier architecture is simplified through component reusability. 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 the EIS resources the volatility of the application code increases dramatically; that is, the application "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.2 illustrates a number of application scenarios that a J2EE product should be capable of supporting. From a J2EE perspective, there is no implicit bias favoring one application scenario over another. However, a J2EE product should not preclude supporting any and all of these scenarios. It is worth considering the scenarios individually and elaborating on the technologies and protocols relevant to an application developer.
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. The delivery of dynamic Web content to the client is the responsibility of JSP pages (supported by servlets). The EJB container hosts application components that, on the one hand, respond to requests from the Web tier, and on the other hand, access the EIS resources. The ability to decouple the accessing of data from issues surrounding end-user interactions is a strength of this particular scenario. For one, the application is implicitly scalable. But more importantly, the application back-office functionality is relatively isolated from the end-user look and feel.
It is worth noting that XML is included as an integral part of this scenario. The role of XML data messaging will be expanded on in subsequent chapters, but the ability to both produce and consume XML data messages in the Web container is viewed as an extremely flexible way of embracing a diverse set of client platforms. These platforms may range from general purpose XML-enabled browsers to specialized XML rendering engines targeting vertical solutions. Irrespective of the specific application area, it is assumed that XML data messages will utilize HTTP as their communication transport. The term XML data messaging is being used to denote a programming model where XML is being used to exchange information as opposed to promoting an object model orthogonal to the Java object model. The relationship of XML to Java is therefore viewed as highly complementary.
At the Web tier, the question of whether to use JSP pages or servlets comes up repeatedly. The J2EE programming model promotes JSP technology as the preferred programming facility within the Web container. JSP pages rely on the servlet functionality but the J2EE programming model takes the position that JSP pages are a more natural fit for Web engineers. The Web container is therefore optimized for the creation of dynamic content destined for Web clients and that use of JSP technology should be viewed as the norm while the use of servlets will most likely be the exception.
Figure 1.4 illustrates a stand-alone client scenario.
From a J2EE programming model perspective, we need to consider three types of stand-alone clients:
- EJB clients interacting directly with an EJB server, that is enterprise beans hosted on an EJB container. Such a scenario is illustrated in Figure 1.5. It is assumed that RMI-IIOP will be used in this scenario and that the EJB server will access the EIS resources using JDBC (connectors in the future).
- Stand-alone Java application clients accessing enterprise information system resources directly using JDBC and potentially even connectors in the future. In this scenario, presentation and business logic are by definition co-located on the client platform and may in fact be tightly integrated into a single application. This scenario collapses the middle tier into the client platform, and is essentially a client-server application scenario with the associated application distribution, maintenance, and scalability issues.
- Visual Basic clients consuming dynamic Web content, most likely in the form of XML data messages. In this scenario, the Web container is essentially handling XML transformations and providing Web connectivity to clients. Presentation logic is assumed to be handled on the client tier. The Web tier can be designated to handle business logic and directly access the enterprise information system resources. Ideally, the business logic is pushed back onto the EJB server, where the rich component model can be fully leveraged.
Figure 1.6 illustrates a 3-tier Web-centric application scenario.
There are numerous examples that one could concoct where an EJB server (at least initially) could be deemed to be an overkill given the problem being tackled. This is the sledge-hammer-to-crack-a-nut problem. In essence, the J2EE specification does not mandate a 2, 3, or multitier application model, nor realistically could it do so. The point is that it is important to use appropriate tools for a given problem space.
The 3-tier Web-centric application scenario is currently in widespread use. The Web container is essentially hosting both presentation and business logic, and it is assumed that JDBC (and connectors in the future) will be used to access the EIS resources.
Figure 1.7 provides a closer look at the Web container in a Web application scenario.
It is important to keep in mind that the term Web container is being used here in a very precise way. For example, if a given J2EE product chooses to implement, a J2EE server, such that the Web container and the EJB container are co-located (this assumes that the inter-container communication is optimized in some fashion and that the implementation details are private), then the J2EE programming model treats the application deployed on such a platform as essentially a multitier scenario.
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 the imminent integration of JMS into the J2EE platform, the development of loosely- coupled intranet solutions will become increasingly practical.
A brief aside here regarding the subsequent discussions of application scenarios. Throughout the remainder of this book, the Model-View-Controller (MVC) application architecture is used to analyze features of distributed applications. This abstraction helps in the process of breaking an application up into logical components that can be architected more easily. This section explores the general features of MVC.
The MVC architecture is a way to divide functionality among objects involved in maintaining and presenting data so as to minimize the degree of coupling between the objects. The MVC architecture was originally developed to map the traditional input, processing, and output tasks to the graphical user interaction model. However, it is straightforward to map these concepts into the domain of multitier Web-based enterprise applications.
In the MVC architecture, the Model represents application data and the business rules that govern access and modification of this data. Often the model serves as a software approximation to a real world process and simple real world modeling techniques apply when defining the model.
The model notifies views when it changes and provides the ability for the view to query the model about its state. It also provides the ability for the controller to access application functionality encapsulated by the model.
A View renders the contents of a model. It accesses data from the model and specifies how that data should be presented. When the model changes, it is the view's responsibility to maintain consistency in its presentation. The view forwards user gestures to the controller.
A Controller defines application behavior; it interprets user gestures and maps them into actions to be performed by the model. In a stand-alone GUI client, these user gestures could be button clicks or menu selections. In a Web application, they appear as GET and POST HTTP requests to the Web tier. The actions performed by the model include activating business processes or changing the state of the model. Based on the user gesture and the outcome of the model commands, the controller selects a view to be rendered as part of the response to this user request.
There is usually one controller for each set of related functionality. For example, human resources applications typically have a controller for managing employee interactions and a controller for human resources personnel.
Figure 1.9 depicts the relationships between the model, view, and controller portions of an MVC application.