C H A P T E R 1 - Overview and Architecture

C H A P T E R 1

Overview and Architecture

This chapter provides an overview of the Web Application Framework architecture, and attention to how the various parts are combined to write a Web Application Framework application.

The name of the technology underlying the Web Application Framework is JATO. There are occasional references to JATO throughout this document, especially in class and other programmatic names. Consider the names Web Application Framework and JATO to be equal to one another.

Overview

What is the Web Application Framework?

The Web Application Framework is a mature, powerful, standards-based J2EE Web application framework geared toward enterprise Web application development. The Web Application Framework unites familiar concepts such as display fields, application events, component hierarchies, and a page-centric development approach, with a state-of-the-art design based on the Model-View-Controller and Service-to-Workers patterns.

Who Should Be Interested in the Web Application Framework?

The Web Application Framework is primarily intended to address the needs of J2EE developers building medium, large, and massive-scale Web applications. Although the Web Application Framework can be, and has been used for small Web applications, its primary advantages are not as readily apparent at that scale. The Web Application Framework especially shines when applications will be maintained for a long period, undergo many changes, and grow in their scope. In short, the Web Application Framework excels at helping develop enterprise applications.

Because the Web Application Framework provides core facilities for reusable components, it is well-suited to third party developers who want to provide off-the-shelf components that can be easily integrated into Web applications. These same features make the Web Application Framework suitable as a platform for building vertical Web offerings, particularly because these extension capabilities provide a well-defined way for both end users and original developers to extend and leverage existing vertical features.

What Does the Web Application Framework Do?

The Web Application Framework helps developers build enterprise Web applications using state-of-the-art J2EE design patterns. It provides a design-pattern-based skeleton upon which enterprise architects can hang other portions of their architectures. Web application developers find an easy development approach, and enterprise architects find a clearly delineated design that integrates in a well-defined way with other enterprise tiers and components.

The Web Application Framework helps developers build reusable components by providing both low- and high-level infrastructure and design patterns. Developer-defined components are first-class objects that interact with the Web Application Framework runtime as if they were native components. Components can be arbitrarily combined and reused throughout an application, across applications, and across projects and companies.

The Web Application Framework helps introduce new J2EE developers to Web application development, and empowers advanced J2EE developers by providing them a powerful toolkit with which to develop advanced features not possible with other frameworks.

What Doesn't the Web Application Framework Do?

The Web Application Framework is not an enterprise tier framework, meaning that it does not directly assist developers in creating EJBs, Web services, or other types of enterprise resources. Although the Web Application Framework is geared toward enterprise application development, it is properly a client of these enterprise tier resources, and thus provides a formal, first-class mechanism to access these resources.

Note - For a broader introduction to the Web Application Framework, see the Web Application Framework Overview.

The Three Tiers of the Web Application Framework Architecture

The Web Application Framework uses the time-tested Model-View-Controller, or MVC, pattern as one of its key architectural foundations. The original MVC pattern was developed to help developers write stateful client-side applications in Smalltalk. This pattern has been adapted for use in the J2EE Web tier, in a largely stateless manner. The Web Application Framework's MVC pattern is full-fledged and complete. This makes the Web Application Framework significantly different from other Web tier frameworks that advertise MVC compliance, but which actually use only parts of that pattern in significant ways.

The following points briefly explain the three parts of the MVC architecture, referred to in this document as tiers, and how they fit into the Web Application Framework:

Model Tier

In MVC terms, a Model is a presentation-neutral arbiter of data. This data can be tailored to support a given presentation, or tailored to represent application-specific data structures.

In the Web Application Framework, the bias is toward making Models that represent application data, with minimal dependence on the way the data is presented. Instead, Views are chosen that best match the format of the data.

Types of Models

There are a number of Model types in the Web Application Framework:

Model Type	Description
Model	The most general type of Model. All Model components ultimately must implement this minimal interface. This interface specifies the most fundamental Model behavior, which is the ability to get and set field values.
ContextualModel	A type of model that can hold data in named contexts. The definition of a context is Model-specific.
DatasetModel	A type of Model that contains distinct rows of data. DatasetModels can be positioned to a particular row via iterator-like methods.
MultiDatasetModel	A specialization of DatasetModel and similar to ContextualModel, this type allows access to named datasets.
ExecutingModel	A type of Model that can be executed to retrieve or update data in a backing store.
RetrievingModel	A sub-type of ExecutingModel that specifically supports a data retrieval operation. (Although this type might appear related to SQL, it is not SQL-specific.)
InsertingModel	A sub-type of ExecutingModel that specifically supports a data insertion operation. (Although this type might appear related to SQL, it is not SQL-specific.)
UpdatingModel	A sub-type of ExecutingModel that specifically supports a data updating operation. (Although this type might appear related to SQL, it is not SQL-specific.)
DeletingModel	A sub-type of ExecutingModel that specifically supports a data deletion operation. (Although this type might appear related to SQL, it is not SQL-specific.)
TreeModel	A Model that stores data in a generalized hierarchical structure rather than a Cartesian structure. Provides iteration over this data structure.
BeanAdapterModel	A Model that uses one or more JavaBeans as a backing data store.
ObjectAdapterModel	A Model that uses any Java object graph as a backing data store.
QueryModel	A JDBC -based Model that uses an RDBMS as a backing data store using SQL statements.
StoredProcModel	A JDBC-based Model that uses RDBMS stored procedures to get and set data.
WebServiceModel	A specialization of ObjectAdapterModel that uses a Web service via JAX-RPC to get and set data.
CustomModel	An abstract Model type that allows developers to implement their own data storage mechanism.
CustomTreeModel	An abstract Model type that allows developers to implement custom storage for hierarchical data.
SimpleCustomModel	A concrete Model that provides ready-to-use storage and dataset capability

View Tier

In MVC terms, a View is a presentation-specific way of displaying data from a Model. There is a relationship between a Model and View such that changes in a Model are automatically reflected in any Views attached to it, and changes in the View-presented data are automatically pushed back to associated Models.

The Web Application Framework uses the same basic definition of a View: a View presents Model data.

If you are familiar with writing a client-side application in Swing, Visual Basic, Delphi, or Powerbuilder, you will find Web Application Framework's notion of a View easy to understand. In these other environments, developers create frames, windows, and dialogs that contain child components. These child components are GUI widgets or containers for other GUI widgets, and they can be arbitrarily nested to any level.

Web Application Framework View components are almost exactly analogous. Just as you find various types of GUI widgets in a client-side application, such as display fields, panels, trees, and complex subcomponents, there are various types of Web Application Framework View components that fulfill these same roles. The Web Application Framework has specializations of Views that act as display fields, containers that can contain other Views, and a combination of these that can act as complex View components.

Types of Views

Objects that are Web Application Framework Views are actually objects that implement the com.iplanet.jato.view.View interface or one of its derived interfaces.

The following table shows the primary types of Views available in the Web Application Framework:

Name	Description
View	The most general type of View. All View components ultimately must implement this minimal interface. This interface specifies no specific View behavior. Therefore, you are unlikely to find useful instances of the View interface.
ContainerView	A type of View that can contain other Views. This interface adds methods specific to management of child View components.
TiledView	A special type of View that can present its child View components in a number of repeated tiles, or repeated regions. Examples of tiles might be rows or columns of a table, or tabs in a tabbed component. There is no assumption of tile layout made; simply the notion of repetition of tiles is encoded in this interface.
TreeView	A type of ContainerView that helps present information in a tree format.
ViewBean	A specialization of ContainerView that can serve as the top, or root, of a View component hierarchy.
DisplayField	A special type of View that has a value associated with it. The value of a display field can be presented on a page, and generally submitted back to the application by a user. There are a few special types of DisplayField, including BooleanDisplayField, ChoiceDisplayField, and CommandField.
CommandField	A special type of DisplayField that represents a user- or user-agent-activatable element in a rendered response. For example, in HTML, buttons and links would be represented in the server-side Web Application Framework application by CommandFields. When a CommandField is activated, a new request is sent to the server and a corresponding event or object is invoked on the server in response to that request.

Pages and ViewBeans

As explained above, the Web Application Framework embraces existing J2EE standards and technologies where possible and advantageous. One of the J2EE technologies useful to the Web Application Framework is Java Server Pages (JSP) technology. JSPs are natural for application developers to use, and are convenient to author and change quickly.

The Web Application Framework embraces JSPs as a primary way for application developers to create pages in their applications. However, there must be some glue between the existing JSP technology base and the Web Application Framework. ViewBeans fulfill this role, and are in some sense where JSP technology meets Web Application Framework technology.

The following sections explain the relationship of ViewBeans to JSPs and the Web Application Framework.

ViewBeans and Their Relationship to JSPs

If you have ever written a J2EE Web application using JSPs, you probably used what are commonly called helper beans to manage complexity in your JSP. Helper beans are commonly used with JSPs to keep Java code and complex data structures out of the JSP, where they are hard to maintain and debug. Instead, these complex features are put into the helper bean, and the bean is associated with and used by the JSP via a <jsp:useBean> tag.

Similarly, in a Web Application Framework application, developers want to avoid complexity in the JSP because of the inherent difficulties maintaining and debugging JSPs. Therefore, the Web Application Framework embraces the helper bean pattern and extends it to support the greater feature set required to make the framework functional and productive.

Specifically, the Web Application Framework uses ViewBeans to manage complexity in the JSP, and to provide a place for application developers to put application-oriented Java code. Like other helper beans, application developers can work with ViewBeans using traditional bean-oriented techniques, since ViewBeans are placed into JSP page scope and can be accessed just like any other helper bean. However, despite the name, ViewBeans are not exactly like helper beans.

The most significant difference is that (most) consumers of a ViewBean (for example, Web Application Framework JSP tags) do not use bean-like properties to access application data. Instead, Web Application Framework tags use the Web Application Framework-specific View API to interact with a hierarchy of View child components. In addition to the richer interactions made possible by this approach, it also represents a significant performance advantage, a clear advantage for enterprise applications that need to scale to massive levels.

ViewBeans and Their Relationship to Views

In addition to fulfilling a role similar to that of JSP helper beans, ViewBeans are special View components that function as root views in the Web Application Framework View component hierarchy. That is, they are top-level View components that contain other View components, and as such have no parent. In terms of Swing or other client-side development technologies, ViewBeans function like a window, frame, or dialog component.

The ViewBean interface extends from the ContainerView interface. This means that ViewBeans can contain other View components in a nested fashion, just like a root directory on a hard disk contains other directories. In addition to having all the behavior of a regular ContainerView, the ViewBean interface adds methods that are specific to its role as the root of a View component hierarchy.

Because of these attributes, ViewBeans can be thought of primarily as pages in your application. Just as your client-side application consists of a number of windows and dialogs, your Web-based application consists of a number of pages, and each of these pages has a ViewBean associated with it. When you count the number of Web Application Framework pages in your application, you will find the same number of ViewBean objects.

What makes a ViewBean special, as compared to a regular ContainerView?

ViewBeans are the only View components that can be directly associated with a JSP (via the <jato:useViewBean> tag).

Because ViewBeans are an abstraction of a single page in an application, they have logic and methods that manage page-specific functions, such as storage of page-specific application values.

ViewBeans expose methods that allow application developers to initiate rendering a response to a client (they can serve as controllers of the request).

ViewBeans are the only components in your application that are visible and can be accessed by application clients.

Pagelets and ContainerViews

As mentioned above, the View tier is generally comprised of an arbitrarily nested hierarchy of View components. Many of these components will be one of many types of ContainerViews, such as TiledViews or TreeViews, or other high-level components like data grids, input forms, headers and footers, and more. The general term for all these variations is pagelet, or a part of a page. Where ViewBeans are analogous to a page, ContainerViews are analogous to pagelets.

Pagelets might have their own JSP fragment associated with them, or might use their parent page (or pagelet) for rendering. When a pagelet uses a JSP fragment, instead of declaring a specific reliance on a type like a full JSP does, the association between a fragment and its pagelet peer is done by name. This allows a single pagelet to be rendered by several JSP fragments, dynamically, at the whim of the application. This allows for extremely flexible dynamic page generation.

Controller Tier

The Controller coordinates activity between Models and Views, and for the application as a whole. Whereas Model and View components can frequently be instances of off-the-shelf types, Controllers are typically custom written to an application.

In some J2EE architectures, the Controller role is fulfilled by a monolithic class, mapping, or other store of information using a highly centralized approach. Although this approach can be convenient for newcomers to visualize the application, it has serious drawbacks in terms of maintainability and the ability to compose an application from componentized pieces. Therefore, the Web Application Framework uses an inherently distributed approach in which the Controller role is further subdivided into Controller objects and logic units that are more closely related to a specific task or application component.

Unlike the View and Model tiers discussed above, there is no one single object or interface that corresponds to the Controller role in the MVC pattern in the Web Application Framework, at least not in a global sense. The reasons for this are generally described in the remainder of this document as various Web Application Framework features are discussed. However, suffice to say at this point that the Web Application Framework adopts a distributed approach to fulfilling the Controller role in the pattern, and with this come a number of advantages, including the ability to create reusable components and to aggregate an application from components over time.

How Web Application Framework MVC Differs From Traditional MVC

Traditional (stateful, client-side) MVC architectures generally use a publish-and-subscribe event model to relate objects to one another. However, this approach requires stateful objects, an approach which in the Web tier generally will not scale to large numbers of users. Because the lifecycle of a request in the J2EE Web tier is well described and predictable, and because scalability is a primary requirement, the Web Application Framework avoids stateful server-side objects. This approach requires moving away from event listeners as a way to relate MVC objects to one another. The Web Application Framework maintains relationships between the tiers in MVC, but these relationships are not traditional event listener relationships.