| Web Application Framework Overview |    
|
| Web Application Framework Overview |
|
| C H A P T E R 1 |
|
Web Application Framework Overview |
This chapter provides an overview of the Web Application Framework and includes the following sections:
J2EE
, and in particular its Web-tier components (Servlets and JSPs), has been successful because it addresses the core frustrations of first-generation Web developers. In the pre-J2EE world, these developers had to contend with vastly different programming models, APIs, and server eccentricities just to build simple applications. Enterprise scale applications were all the more difficult because so many factors had to be considered just to select a technology that might support an application's requirements. Actually building an application was an additional problem, complicated by platform immaturity, API mismatches, cross-platform integration issues, and lack of highly-scalable development and maintenance models.
Although server vendors solved many of the programming and development scalability issues by providing powerful, high-level application frameworks, these frameworks shared only few basic assumptions, and no common contracts or infrastructure. These frameworks were generally tied to the server vendor's proprietary server infrastructure, and while they made it possible to build highly functional, robust enterprise applications, it was not possible to change vendors or easily take advantage of technology provided by other vendors. Moving from one vendor's platform to another was essentially impossible without rewriting the application.
Enterprise architects adopted several strategies to avoid vendor lock-in, the most widespread of which was adding heavy doses of abstraction into the architecture. Although this strategy solved some of the problems--enterprise business objects and processes could be decoupled from Web-container details--it created others. These abstractions added significant, sometimes massive, complexity to the application, and introduced both development and deployment penalties. Debugging this complex infrastructure became exponentially more difficult as architects tried to distance themselves further and further from proprietary APIs. Web developer skills became less and less reusable, as each new project introduced new architectures and constraints that were incompatible with those they had previously encountered.
Each application was a world unto itself, and there was very little consistency, especially when the foundation application framework did not provide a strong direction for developers and architects alike. And while some constraints were helpful in focusing application development efforts, some frameworks became so high-level that developers had to work around features to accomplish advanced, or in some cases routine, tasks.
The advent of J2EE solved many of the problems endemic to first-generation Web application development. For the first time, developers could depend upon standard contracts between the container and their application components, and all J2EE-compliant containers were guaranteed to provide the same well-designed API. Architects and developers were liberated from the chaotic mix of proprietary frameworks, APIs, and containers.
However, with freedom came responsibility. Although J2EE is a solid foundation for an application framework, it is not one itself. The J2EE specification avoids recommendations in the application development space. J2EE leaves architects and developers the significant task of designing (or adopting) an application infrastructure that suits their application development needs. J2EE alone cannot suffice.
To develop real-world applications, especially large-scale enterprise Web applications, developers inevitably find that they must create some kind of framework. The underlying Web-specific platform is already provided by J2EE, but the delta required for actual application development must come from somewhere, and developing a framework internally can be both time-consuming and error-prone.
Thus, an abundance of reusable (and not so reusable) Web application frameworks built on J2EE have appeared, each of which tries to address some range of developer needs. For example, some frameworks focus exclusively on the rendering of data to the client, while others focus on validation of input data. Still others attempt to unify fat client and thin client GUI development.
Because J2EE abolished the de facto architectures used during first-generation Web application development, each J2EE project must now evaluate and choose an application architecture best suited to its requirements. Common concepts and terminology have evolved to assist discussions of these architectures, including such examples as Type I and Type II servlet architectures, Service to Workers delegation, and MVC-based UIs. However, while these concepts are fundamental and important, they are very broad, and applicable to the entire range of applications, from the very small to the very large. Furthermore, none of them truly address the details of how to build a Web application in a repeatable, maintainable, and scalable way.
To underscore this last point, nearly all contemporary application frameworks claim to use a Type II, Service-to-Workers, and MVC-based architecture, yet these frameworks are strikingly different in implementation, extensibility, and the constraints they place on developers. Knowing the underlying architecture only helps introduce the framework to developers. It has a surprisingly small ongoing role in helping the developer learn the framework, or even compare it to other frameworks, especially when these frameworks target different application scales.
Contemporary frameworks go beyond the space in which there is sufficient terminology to effectively describe their features. Thus, a much more detailed analysis is necessary to truly understand what one framework offers over another, and in particular, what a framework offers in regard to enterprise application development. Simply working from a checklist of features is grossly insufficient.
Reliance on tested and proven architectures is extraordinarily important when building Web applications, more so than in other application development domains. For example, fat client applications are quite forgiving in their response to sub-optimal architectural or technological choices. Even the most heavily abstracted client-side application architecture will run with sufficient performance when it has a modern workstation all to itself.
The same is not at all true when that same application has to be run over a loosely coupled network, on shared hardware which is supporting hundreds or thousands of simultaneous users. In this domain, the wrong choice of architecture or technology can make the difference between an application that responds in a timely manner to requests, and one that does not respond at all, or one that scales well in both development and production, versus one that might only do one or the other, but not both.
Failings in some of these factors can be forgivable in the small-to-medium application development space, where a handful of developers work closely on an application. In such cases, architectures can be much more fluid because the scope of future changes and contact with other teams is limited, and team members can easily coordinate to tweak issues as they arise. Coding standards and best practices are easily shared ad hoc, and retrofitting older portions of the application is a matter of a few hours of work. Teams tend to have similar levels of expertise, remain stable, and stay together for an extended period. Performance is usually not a critical factor, as the user base for these applications is small or forgiving of slower response times.
Development of enterprise applications is the antithesis of the small-to-medium application development model. Team communication is unwieldy; application changes have massive ripple effects; best practices are seldom disseminated outside of sub-teams; retrofitting parts of the application becomes simply impossible; developer turnover is high; and developer expertise varies widely. Finally, performance is absolutely critical, since it might play a determining role in whether a user will continue to use the application or abandon it for a perhaps less convenient, but more responsive, alternative.
Any framework facilitating enterprise Web application development must then account for these constraints in both its design and implementation. More importantly, it must minimize--and in ideal cases, eliminate--the impact of these constraints on the application development effort.
Therefore, any enterprise framework must do the following:
Most importantly, the framework must be proven, mature, robust, and well-performing in an enterprise setting. The users of the framework must know what to expect, and be confident that the framework meets these requirements before beginning any development work.
The remainder of this chapter describes how the Web Application Framework, with its goal of being a truly enterprise-class Web application framework, addresses these issues and meets these criteria.
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.
The Web Application Framework is based upon the collective experience of industry-leading software engineers, consultants, Web application developers, and enterprise Web architects. It has been in development since January 2000, and available to customers since June 2000. Since that time, the Web Application Framework has been used in dozens of real-world enterprise Web applications, and is being used successfully in production sites supporting millions of users, and millions of dollars in financial transactions every day.
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 are 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 wishing to provide off-the-shelf components that can be easily integrated into Web applications. These same features make the Web Application Framework very 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.
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 on 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, as well as a full component model. Developer-defined components are first-class objects that interact with the Web Application Framework as if they were native components. Components can be arbitrarily combined and reused throughout an application, across applications, and across projects and companies.
Finally, 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.
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.
The Web Application Framework is based on industry accepted, state-of-the-art design patterns and techniques, and as a J2EE presentation tier framework, it implements and relies heavily upon the Core J2EE Patterns published by JavaSoft. The following table lists the Web Application Framework's use of the published J2EE design patterns.
|
Core J2EE Patterns (see http://java.sun.com/blueprints/corej2eepatterns/index.html) |
Java BluePrints Pattern Catalog (see http://java.sun.com/blueprints/patterns/catalog.html) * |
|||
|---|---|---|---|---|
* Note that the J2EE BluePrints sample applications (for example, Pet Store) implement many business and integration tier patterns, but effectively only as demonstrations of these patterns. Furthermore, many of these patterns are directed toward use of EJBs, which the J2EE BluePrints applications assume, but to which the Web Application Framework is agnostic. For a number of reasons, the Web Application Framework offers alternatives to EJB use in some specific cases, and these alternatives use some of the business and integration tier patterns, though from Web tier entities.
** The Web Application Framework minimally implements the J2EE presentation tier patterns, but, as should be expected from a presentation-tier-only framework, does not necessarily implement Business and Integration tier patterns. The bulk of these patterns are left as recommended best practice to enterprise and integration tier developers, and these patterns are completely compatible and can be integrated with the framework's presentation tier patterns.
In addition to the use of patterns listed above, the Web Application Framework is based on an N-tier JSP/servlet architecture, and has been designed entirely around interfaces and object contracts that reflect these patterns--it is an integrated set of cooperating design patterns first, and an implementation of those patterns second.
Primary among Web Application Framework's patterns is the Model-View-Controller (MVC) pattern. Where other frameworks claim to be MVC frameworks, the reality is that they usually focus on one, or perhaps two of the pattern's components, but seldom on all three. Furthermore, other frameworks often claim that JSPs, perhaps with a custom tag library, comprise a full and proper View tier. They many times also claim that application-specific business objects comprise a full and proper Model tier.
The Web Application Framework addresses all three components of the MVC pattern fully. It defines formal View and Model entities with concrete relationships, and provides an advanced logical Controller role that allows applications to scope controller logic in appropriate ways. The Web Application Framework's View tier incorporates JSP technology, but is not synonymous with it. In the same way, the Web Application Framework's Model tier incorporates other J2EE technologies, but is not synonymous with any of them. For these and other reasons explained below, the Web Application Framework provides unprecedented extensibility for developers that other frameworks simply cannot match.
There are three logical groupings of the Web Application Framework functionality.
The Web Application Framework core is what is usually referred to as simply The Web Application Framework. It defines fundamental interfaces, object contracts, and primitives, as well as the minimal infrastructure required for the Web Application Framework applications. The Web Application Framework core does not provide a component library, but provides the enabling technology for component authors. Included in the Web Application Framework core are View-based primitives like ContainerViews, TiledViews, and TreeViews, as well as Model-based primitives like DatasetModels, QueryModels, and TreeModels. The Web Application Framework core also provides primitives for request dispatching and reusable Command objects. Using these primitives, developers can easily create application-specific or reusable components that can be shared within or across projects. The Web Application Framework core also includes high-level features that allow developers to immediately begin building highly functional applications. These features are covered in more detail in the sections below.
The Web Application Framework components leverage the Web Application Framework core infrastructure to provide high-level, reusable components for application development. These components can come in a variety of flavors intended for different usage scopes. For example, horizontal Web Application Framework components tend to be the most generic components available, with their strength being flexibility and customizability. These types of components are usable by many different Web Application Framework user populations, across projects and companies, and are generally not biased toward any particular look and feel. Vertical Web Application Framework components are tailored to a particular usage scenario, allowing them to provide high-level features and high ease-of-use. These types of components are less broadly usable, but because their scope is better defined, they can keep parameterization to a minimum and use a particular look and feel. All Web Application Framework components can use all of the facilities provided by the Web Application Framework core, and build upon its high-level features like WebActions, SQL-based Model implementations, and TreeViews.
Finally, the Web Application Framework extensions provide access to non-J2EE facilities in a Web Application Framework-compatible way. In many cases, the Web Application Framework extensions allow container-specific features to be used from the Web Application Framework applications seamlessly. Extensions differ from the Web Application Framework components in that they focus on technology integration rather than application development.
The Web Application Framework, or more properly the Web Application Framework core, is pure Java, and comes packaged as an industry-standard JAR file.
The Web Application Framework defines several top-level packages as follows:
com.iplanet.jato--Request handling infrastructure
com.iplanet.jato.command--Command-related interfaces and implementations
com.iplanet.jato.taglib--Custom JSP tag library
com.iplanet.jato.model--General Model-related interfaces and implementations
com.iplanet.jato.view--General View-related interfaces and implementations
Each of these packages contain subpackages of more specific derivations, such as HTML-specific View implementations, and SQL-specific Model implementations. There are no formal packages or classes for the Web Application Framework components or the Web Application Framework extensions, which are purely logical classifications.
In writing a Web Application Framework application, developers derive application-specific subclasses from existing Web Application Framework classes, or implement certain Web Application Framework interfaces in an application-specific way. In most cases, developers will use the existing Web Application Framework core implementations as superclasses, thus inheriting a great deal of useful behavior. (Component developers might be more likely to implement a set of Web Application Framework interfaces directly.)
Application objects are organized around the central concept of a page. Each page consists of a rendering specification--normally a JSP containing static content and markup plus custom Web Application Framework tag--and one class comprising the root of the page's View hierarchy. Each request to the server returns a page as the result. The page flow through an application is determined by the control logic written by the developer. There is no fixed relationship between one page and another other than that provided by the developer.
In the HTML world, each rendered page generally contains one or more links or buttons which the user can activate. Each activation of a link or button sends data back to the server, and results in invocation of a Command object specific to that activation. This Command object can take action itself, or delegate handling of the request to developer-defined event methods. Ultimately, the request is forwarded to a resource that is responsible for rendering a response to the client.
In most cases, this resource is an HTML-based JSP page which uses the Web Application Framework tag library to render dynamic content. The tag library uses the Web Application Framework View components to obtain the data it renders. These View objects are associated with one or more Model objects, and draw data from them as needed. Thus, the Web Application Framework Views act as a hierarchical facade to any number of Models. These Views can be reused across multiple pages and with different Models. Models can generally be used by any number of Views since they have no display or View dependencies.
After receiving a response in the form of a page, the user activates a link or button and a request is sent back to the Web Application Framework application. The request is sent back to the same objects that rendered the page. This allows the Web Application Framework infrastructure to map the submitted data back into the same Views (and thus Models) from which it originated, providing virtual persistence of this data. The developer interacts with the application objects and the submitted data as if there had never been an intervening response-request cycle. Once the data has been mapped back into the originating objects, the Command object specific to that link or button press is activated, and the cycle begins again.
The following sections outline some major differences between the Web Application Framework and other contemporary Web application frameworks.
Many frameworks adopt servlets as a viable technology while eschewing JSP, or vice versa. Still others say they adopt these standards, but in reality, they are merely proprietary containers that can be run in a J2EE container using rudimentary servlet-level integration.
The Web Application Framework embraces J2EE standards like servlets and JSPs directly, while still allowing developers to freely use the features J2EE provides. The Web Application Framework is not a container within a container, nor is it a layer meant to abstract the developer from J2EE. Instead, it adds to J2EE features that facilitate enterprise Web application development, while still letting developers interact with as much as or as little J2EE/Web Application Framework as they prefer.
The Web Application Framework provides display fields, application events, component hierarchies, and a page-centric development approach, all of which are time-tested and very comfortable to developers familiar with client-side application development using Swing, Delphi, Visual Basic, or PowerBuilder. While there are differences due to the Web paradigm, these familiar constructs lend a natural feel to the Web Application Framework for these developers, and significantly speed application development. They also mean that the Web Application Framework is particularly well-suited to integration with application builders, such as Forte for Java or JBuilder (for more information on the topic of application builder integration, see the Tool-ready section).
Many contemporary Web application frameworks are extremely flexible, and in some cases, this is the fundamental intent of the design. They consciously strive to be non-prescriptive about certain aspects of an application, like its Model tier. Instead, they focus on one or two areas of application design, most commonly the Controller and View portions of an MVC architecture, and leave the rest to the developer.
Some architects and developers might argue that flexibility is never a drawback, but when considering enterprise development, it certainly can be. While it might initially sound strange to characterize flexibility as a drawback, there is an inverse relationship between flexibility and application consistency. A framework that is maximally flexible, like the J2EE API itself, leads to applications that vary widely in the way in which they are developed.
Unlimited flexibility, or an ill-defined development direction, leave inexperienced architects and developers to discover some technique--any technique--that seems to accomplish the task at hand, even if this technique is ultimately flawed. When a framework fails to provide at least one clear path to follow throughout the full range of development tasks, developers are as likely as not to use a technique that sabotages or offsets the advantages that the framework provides. Furthermore, each isolated team will likely find a different technique to use, so that even within the same application, one group cannot easily understand or maintain the work of another group. In the worst case, a flawed technique in one portion of the application will undermine the rest of the application to such a degree that the application suffers performance or scalability issues. This situation easily arises when an inexperienced architect or lead developer chooses a poor global direction for the application. Such a choice might result in intractable architectural issues throughout the application, in the worst case rendering the application ultimately unworkable.
Unfortunately for Web application developers, it turns out that most frameworks are flexible in ways that can easily be counterproductive, in both development and production. As noted above, a good enterprise framework should guide naïve developers in a positive direction without getting in the way of advanced developers. Although many frameworks achieve the latter, they only do so because they are non-prescriptive about certain aspects of the architecture or application development, either because of design philosophy or due to a design flaw. This leaves the developer to make many choices when starting a project, including many which present significant danger to the overall project if improperly selected.
The Web Application Framework, by contrast, provides an implicit, proven direction for both Web application architecture and application development, without precluding the use of other approaches. It does this by providing well-defined points of interaction with an application, as well as clearly defined ways in which to extend, augment, or override existing behavior. The difference between using the Web Application Framework and another framework to develop a Web application, is that someone new to the Web Application Framework need not make a (potentially bad) choice in order to get started. That user can see from the outset a general approach, and after becoming more advanced and fluent in the Web Application Framework and J2EE, other approaches and techniques become apparent. Furthermore, whatever work the developer has done up to that point is still consistent with more advanced techniques used later. As a result, applications written in the Web Application Framework resemble one another more so than applications written using other frameworks. They are more consistent, both in use of high-level and low-level features, and thus are more maintainable.
Many contemporary application frameworks evolved from custom tag libraries, a very well-received and popular technology. In some cases, they are little more than a custom tag library and perhaps one or two additional interfaces. As a result, these frameworks are myopic in that they are heavily biased toward the display of data to the user, but provide little assistance for handling data from the user.
These frameworks perhaps address one set of developer needs well, but at the expense of others. In a Type II architecture, rendering technologies like JSP have zero involvement during the submit (request) cycle. This means that if the View representation is defined only in a JSP, the submit-cycle logic cannot take advantage of it. This logic instead just receives a raw list of parameters as inputs. Developers are then left to use these values in their raw form, with little or no assistance. They have suddenly stepped off the deep end into the most basic servlet techniques.
Frequently, in these frameworks, clear relationships between application objects are unspecified and hard to maintain. Because these frameworks provide little or no structure for incoming data, invoked components are forced to work in the dark, not able to reliably know what data they are receiving on any given request invocation. This can place a burden on the project that might not be readily apparent when the project is started, but quickly becomes a major factor as the application grows.
The lack of symmetrical display and submit cycles commonly leads to a proliferation of inter-object dependencies. Generally, this proliferation of relationships is reflected in a proliferation of low-level controller logic necessary to do nothing more than manually shuffle input data to a target object or backend. This can lead to an asymmetric notion of a backend object or model being used to render a page, but not used directly when handling a request from a previously rendered page. This asymmetry places yet more burden on developers to micro-manage backend components and concern themselves with the low-level details of running in a Web application container.
Productivity and maintenance are the casualties of a display-centric architecture. By contrast, the Web Application Framework assists with both the display and submit cycles in a symmetrical fashion, by virtue of its formal View tier. Whereas other frameworks loosely define their View tier as a JSP or some other kind of content rendering technology, the Web Application Framework makes a distinction between rendering specification (JSP) and View components. Only together are these considered the full View tier. A Web Application Framework application defines primarily a hierarchy of View components, and then references these components from the rendering specification. The developer interacts with these View components in the same way during both display and submit cycles. The View components are the canonical View form.
As noted in the previous section, many frameworks focus heavily on technology to assist display of data to the user. The most common species of this type of framework are those that focus on XML and XPath. Although enticing to developers looking to use the latest cool technologies, these frameworks have little to offer the developer during the submit cycle of the application, and frequently require representation of application data in XML or some other display-oriented format. The coercion of application data to a framework-centric representation is burdensome at best, and in some cases, a fatal shortcoming.
Instead, the Web Application Framework perspective is that the application should be able to represent its data in a View-agnostic way, and provide a formal mechanism for obtaining that data without implying a particular data format. Therefore, the Web Application Framework provides a formal Model entity that defines a handful of standard methods that all Models must implement. Using an arbitrary, Model-specific key, Model consumers (including the Web Application Framework Views) can obtain Model data in a standard way, without any assumptions about how that Model internally represents its data.
For this reason, the Web Application Framework components can interact with any Model in the same way, allowing a different Model to be plugged into the same View. Models become interchangeable, and therefore, so does the data they represent. Marshaling of data to a particular format purely for display becomes unnecessary, and the View tier need not understand the specific type of data with which it interacts. Different types of Models can coexist within an application, without the View tier being cognizant of any difference between their native data formats. XML/XPath, JDBC, JDO, and other enterprise data all look the same to a Model consumer, and thus the Web Application Framework is able to subsume the development approach of any framework concentrating on one of these data formats.
Finally, the interposition of a Model structure on an enterprise-tier resource enforces a level of abstraction that not only makes the application design far more consistent, but significantly eases the burden of maintenance. In formally defining the data available from the enterprise tier, developers also define a formal yet loosely-coupled contract between tiers of the application. This contract allows the application to be easily modified in the future, and in a well-defined way. The incidence of regressions is lower, and regressions are more readily apparent if they occur.
The Web Application Framework provides developers with a number of events for application-related occurrences. There are three types of events: general request events, specific request events, and display events.
General request events include events like onBeforeRequest(), onSessionTimeout(), and onUncaughtException(). Developers can use these events to respond to general application and request lifecycle occurrences, as well as error conditions. By default, error-related events use a consistent, localized mechanism to report errors to users, and can be overridden by developers to take application-specific action.
Specific request events occur based on user action. When a user activates a link or button (also known as a CommandField in the Web Application Framework) on a page, the request results in the invocation of a Command object on the server corresponding to that activation. Although users can provide their own Command objects in response to such actions, the default Command implementation delegates handling of the request to a request handling event method of the form handle<name>Request(), where <name> is the name of the CommandField the user activated. This event is invoked on the parent container of the CommandField, and thus is scoped to the component that originally rendered the link or button. Within this event handler, developers can take any action they like, either handling the request as they wish, or delegating the handling of the request to another object.
The main difference between this Web Application Framework feature and similar request-handling features provided by other Web application frameworks is that the event is invoked on the component to which it pertains, and is fine-grained per link or button. Other frameworks generally provide only one coarse-grained event handler per HTML form, and the developer is left to make that code conditional based on the user's action. This is both messy and hard to maintain as the set of fields changes. That approach also makes use of modular, self-contained components difficult, because the single event handler must be changed each time a new link or button is added to or removed from the form, regardless of whether it is contained within a component (for more information on this drawback, see the Hierarchical Views and Component Scoping section).
Lastly, the Web Application Framework provides fine-grained, field-level display events. Display events are invoked during the rendering of a page, and give the developer hooks into the rendering process that simply would not otherwise be possible. From these events, developers can access the tag handlers as well as the JSP page context and output stream. Display events can be used to skip rendering of a field or abort the currently rendering page altogether. They can also be used to tweak the outgoing content rendered by the JSP, providing advanced content filtering capabilities. Furthermore, display events encapsulate display logic pertinent to a component inside that component, thus providing a high degree of reusability for components even if they use advanced rendering techniques.
Most importantly, display events keep Java code or program-like structures out of the JSP. Any kind of programmatic construct in the JSP is generally a maintenance problem, both because it exposes application functionality to the JSP author, and because parallel content must duplicate this functionality in potentially many places (for more information on parallel content, see the Support for Parallel Content section). Although these kinds of features might be a productivity benefit for small- to medium-sized applications requiring little or no significant maintenance, or having a limited lifespan, such applications are not typical in the enterprise. Many frameworks emphasize this kind of application development, and many of their features are targeted to filling out these capabilities with a full range of programmatic constructs that mimic a traditional programming language. By contrast, the Web Application Framework recognizes and leverages the advantages of JSPs without compromising maintainability or the ability of the application developer to finely control rendering of the JSP.
Most frameworks use a flat namespace for data field names in an HTML form. This flat namespace severely limits how View components can be combined. For example, two components using a field called name cannot be used on the same form. The only resort is to contrive unique names for all fields, globally, throughout all components and forms. Clearly, this workaround will not scale during development, and curtails the development of a global component market.
The situation is even worse for frameworks that rely on tightly-coupled form-object concordance. In this situation, an HTML form corresponds to a Java object, usually a JavaBean, with accessor and mutator methods for each form field. Simple form field names like name easily map to Java methods like getName() and setName(). But, as noted above, developers will seldom be able to use these simple names if they want to employ reusable components, and will instead need to use globally unique, contrived names. Mapping of complex, contrived field names like com.foo.componentA.name to Java method names is particularly inelegant. Such names must comply with Java method naming standards, so the only viable options would be getCom_foo_componentA_name() and setCom_foo_componentA_name(). Workable, perhaps, but less than elegant or maintainable.
Any framework that relies on a single object as a facade for form field names precludes the use of View components altogether--all data used on that page or form must be reflected by a single object interface, regardless of whether portions of that form are used on multiple pages. A developer could create an object, solely for use by a form, which then delegates to other more reusable objects, but this requires tedious and hard-to-maintain data-shuffling code and is not a true component architecture. Furthermore, it requires a compilation step to make changes in the form or page, a critical shortcoming of frameworks that want to work with application builders.
The Web Application Framework, by contrast, provides a hierarchical namespace for HTML form fields that is not based on tightly-coupled form-object concordance. Each display field View is created separately as a child of a parent container View, and uses a simple local name within that container. It thus implicitly inherits a qualified, unique global name. These qualified field names are guaranteed never to conflict with other field names, even if local names are identical in other containers. Therefore, independent View components can be arbitrarily combined and will never conflict with one another. The Web Application Framework automatically manages the mapping of form data associated with these qualified field names back into components during the submit cycle, so developers never have to think about how they combine components. They simply use them and the Web Application Framework takes care of the details.
Furthermore, developers do not use these qualified names during authoring of a JSP page. Instead, the Web Application Framework provides what are called context tags. These tags define nested container and component scopes. Developers use local names in the JSP within these scopes, and these names are automatically and transparently translated to qualified names at runtime using the current context. Not only can View components then be arbitrarily combined, but rendering specification fragments (JSP fragments & pagelets) can be arbitrarily combined in a parent page. The Web Application Framework developers have then two types of View component reuse at their disposal, and these types can be combined in several permutations. This is simply not possible in other frameworks.
Many frameworks focus heavily on object reuse within the application, with the intent of being more efficient and scalable because they avoid object allocation. Unfortunately, this approach is today wrongheaded, and has been debunked in several well-know forums. While it might not have been true in the JDK 1.0 timeframe, object allocation in modern JVMs is extremely cheap, especially when compared to process-wide synchronization points. For maximum scalability, a framework must avoid synchronization between concurrent threads as much as possible.
Frameworks that go to lengths to share objects are unknowingly limiting their scalability. Furthermore, they increase their complexity significantly, and require great care to avoid bugs related to multithreading. In many cases, these frameworks also impose multithreaded programming concerns on application developers, who are more often than not unequipped to undertake such tasks. Perhaps a greater concern is the fact that these bugs might not reveal themselves until the application built on the framework is in production and under heavy load.
For these reasons, the Web Application Framework takes a pragmatic approach. It reuses objects where it makes sense, but allows other objects to be allocated as needed. The common request handling infrastructure of the Web Application Framework relies on shared object instances managed by the container, but objects used by the developer during normal request handling are allocated lazily as needed. Not only does this approach reduce complexity and eliminate an entire class of potential bugs for the Web Application Framework itself, it does the same for application code. Developers need not worry about stomping on shared data, and debugging becomes much easier.
The Web Application Framework has proven that this approach is maximally effective in production deployments, in which hundreds of requests per second are handled without significant latency or memory effects due to object allocation.
Most contemporary frameworks provide internationalization support by giving developers access to Java resource bundles. JSP authors replace static content in the JSP with custom tags that instead obtain localized content at runtime from a resource bundle backed by a property file.
While this is a useful approach, it has significant drawbacks when used alone, among these being that the JSP page author cannot author a page in a natural way using a standard HTML editor, but must instead edit content in property files. Furthermore, this approach largely assumes that the markup surrounding the localized content is unchanged, when in reality it might be heavily influenced by the device or language being targeted. Therefore, certain types of internationalization are best addressed using an alternative approach called parallel content.
The Web Application Framework provides full support for parallel content, which is the use of parallel sets of JSPs, with each JSP in the set customized to a particular language, target device, output markup (for example, XML, HTML, or WML), or any combination of these. Each of these JSPs references the same View components, and thus contains only variations of content and markup. The application can then choose the most appropriate JSP to render at runtime based on user preference or any other desired criteria.
Parallel content works very well when trying to localize content for both Western and Asian languages, where page layout might be affected heavily, or when trying to render to different device types like a standard browser or an Internet-enabled cell phone. The advantage is that the business logic and View structure remain consistent across localized versions of the page, while allowing for (sometimes significant) rendering differences.
Some frameworks assume a static association between JSP and application component, or try to automate page flow using a declarative specification of the component-JSP relationship. While this latter approach has its advantages in certain limited cases (yet many more significant drawbacks), it does not allow the flexibility needed for use of parallel content. Other frameworks that emphasize programmatic constructs in the JSP make the use of parallel content extremely difficult. Developers using these frameworks must copy and maintain programmatic constructs across multiple parallel JSPs. Because the Web Application Framework provides display events to keep programmatic constructs out of the JSP, display logic never has to be replicated across parallel JSPs in a Web Application Framework application.
The Web Application Framework provides full support for parallel content, making it extremely easy for applications to select at runtime a JSP to render based on any developer-defined criteria. The lookup for parallel JSPs is also developer-defined, so parallel content can be organized in a way that makes sense to the application. Together with resource-bundle-based internationalization strategies, the parallel content feature of the Web Application Framework provides the most flexible internationalization support possible.
The Web Application Framework provides not only low-level infrastructure for use by applications and components, but also high-level features that developers can use to rapidly build highly functional applications.
Among these features are WebActions, which allow developers to perform common, high-level tasks with a minimum of code. For example, developers can invoke the Next and Previous WebActions to automatically paginate through rows of data in a DatasetModel, across requests. The dataset position is automatically managed across requests by the WebAction infrastructure, with no additional code necessary from the developer. Any model implementing the DatasetModel interface can be used with these WebActions.
Another high-level feature that the Web Application Framework provides is a set of SQL-based Model implementations that automatically manage Model-oriented access to JDBC resources. These implementations use SQL queries and stored procedures to retrieve and persist data in an RDBMS, all without the developer worrying about detailed JDBC use or the inconsistencies in JDBC driver usage. Of course, developers can use JDBC directly from within a Web Application Framework application if they wish, but the presence of these value-added implementations in the Web Application Framework core allows developers to very rapidly build functional enterprise applications out of the box.
Other frameworks simply do not provide this level of functionality, out of the box or otherwise. Although developers can use object-relational mapping tools with any framework, including the Web Application Framework, they minimally require a conscious decision to use complex business objects in the application architecture. By contrast, the Web Application Framework SQL-based Models allow developers to abstract these details away from the application domain and put them behind a standard Model interface.
The rest of the application is not directly dependent on JDBC or SQL, and thus becomes far more maintainable and consistent.
Finally, the Web Application Framework provides TreeView and TreeModel primitives that drastically simplify development of hierarchical data displays. These primitives are complemented by a set of look-and-feel-agnostic custom tags, which allow developers to structure a JSP document into portions that will be selectively rendered for a given tree node. Since these tags output no markup themselves, they can be used in JSP fragments and pagelets to provide a pluggable and customizable component look and feel. No other contemporary framework has anything rivaling these components.
Unlike other frameworks, the Web Application Framework was designed from the ground up to ultimately be used with GUI application builders to create Web applications. Almost all other contemporary frameworks lack the features that make highly functional application builder integration feasible. Because they define no formal fields, components, or Models, nor provide a page-centric development approach, there is only limited opportunity for manipulation in a GUI builder. Instead, such integration is likely limited to one-way code generation from templates, with nothing but simple manual code editing to follow.
While tool-readiness has been part of its fundamental design, the Web Application Framework does not yet provide this capability, for several reasons. Before ever focusing on GUI application development, the framework must be correct, robust, and amenable to API-based manipulation. Developers must be able to do everything they need, including using very advanced techniques, via a well-designed API. Frameworks that focus on tool support from the beginning are generally biased toward only that type of manipulation, and fail to provide a well-designed, easy to use, and flexible API underlying that infrastructure. This means that developers cannot go below the tool-oriented layer to do things like build reusable components, or manipulate application objects in advanced ways.
Furthermore, focus on tool support tends to lead designs in a direction that might incur performance penalties. Perhaps the most common implementation approach leading to performance issues is the use of shared objects. Shared runtime objects are common in application-builder-oriented designs, but because they require significant synchronization at runtime, they ultimately limit scalability. Projects should not need to give up production scalability for development scalability; instead, the two should both be achievable.
The Web Application Framework perspective is that if the framework is first designed around interfaces and object contracts, GUI builder support is easy to add at a later stage (and in fact, this work is being pursued today in the Web Application Framework). What results is a framework that provides both development productivity using application builders, but also supports advanced uses that truly make the framework ready for the enterprise. This also means that scalability and performance are not compromised by a tool-centric design early in the process, and that even if application builder support requires some performance penalty, developers have the ability to make a conscious choice of development versus production scalability.
Finally, application-builder focused frameworks are usually consumers of additional, sometimes nonstandard, technologies, meaning that they require additional libraries outside their scope that cannot be guaranteed to be the right version, or even available on a given platform. These other technologies must then be made available manually by the project team, sometimes with difficulty because of version clashes. The Web Application Framework perspective is that it is better to be lean in this regard rather than require additional libraries which might conflict with a project's deployment architecture.
Because the Web Application Framework has been optimized to eliminate all synchronization points, applications built on the Web Application Framework are as scalable as the J2EE container in which they run. The Web Application Framework introduces only a small, fixed amount of overhead to each application request, whereas other frameworks that do costly synchronization might exact exponentially more overhead or incur increasingly longer latencies as load increases.
The Web Application Framework provides features that have either no equivalent or no equal in other contemporary Web application frameworks. The vast majority of available frameworks focus on rendering of data, using various technologies like JSP and XML. Only a very few actually attempt to address a significant range of developer needs, and only the Web Application Framework attempts to address the broad range of enterprise application development requirements. The Web Application Framework has been designed through and through to complement enterprise development, and minimize the impact of the unique challenges enterprise development presents.
Thus, the Web Application Framework meets the criteria of an enterprise framework in the following ways:
The Web Application Framework is mature, robust, stable, and extremely well-performing. But most importantly, the Web Application Framework is proven. It is being used successfully in production enterprise applications supporting millions of users and millions of dollars in financial transactions every day, and has had ringing endorsements from enterprise developers, architects, and project managers alike. Above and beyond all the other reasons outlined here, the fact that the Web Application Framework has already been proven in the enterprise most of all assures those adopting the Web Application Framework that it meets all the criteria of an enterprise-class Web application framework.
| Web Application Framework Overview | 819-0726-10 |
|
Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.