| Web Application Framework Overview |     |
| Web Application Framework Overview | |
| C H A P T E R 2 |
|
Web Application Framework Design and Architecture FAQ |
This chapter provides answers to a number of questions often asked by people new to the Web Application Framework about its design and architecture.
The questions included in this document are as follows:
The Web Application Framework is primarily intended to address the needs of J2EE developers who build medium, large, and massive-scale enterprise-strength Web applications. The Web Application Framework combines robust design patterns with equally robust implementations of those patterns to provide an enterprise Web application foundation. Because the Web Application Framework provides core facilities for reusable JavaBean-like components, it is also suited for third party developers wishing to provide off-the-shelf components that can easily be integrated into Web applications. These same features make the Web Application Framework very suitable as a platform for building vertical Web applications or offerings. This is because its horizontal extension capabilities provide a well-defined way for both end users and original developers to extend or leverage existing vertical features.
J2EE is a relatively young technology, and though it is very exciting, it does not yet provide the richness and rapid development model that some non-J2EE Web technologies have developed over time. This is not necessarily a bad thing--being free of non-standard application APIs is a huge benefit, and the freedom that J2EE provides can make many Web development tasks easier and quicker, and the result more maintainable.
However, because of the ongoing industry need to quickly build richly functional Web applications, and the only minimal level to which J2EE (rightly) specifies such tasks, there is still a need for additional application design patterns and added functionality beyond J2EE for nearly any real-world Web development project, especially enterprise Web applications. This is where the Web Application Framework steps in: easy to understand and close to the metal, yet it provides unprecedented design flexibility and consistency. Best of all, it is based entirely on the pure, standards-compliant J2EE platform, so you do not sacrifice J2EE to use the Web Application Framework. Instead, you benefit from both.
No. With proprietary Web application frameworks, you are tied not only to the framework API--for which you do not have the source code--but also to the vendor's underlying application server platform. If you want one and not the other, you are out of luck, and moving an application from one vendor's solution to that of another means a rewrite of your application from scratch.
The Web Application Framework is different.
In a survey of J2EE frameworks, both before and after the inception of the Web Application Framework, it was found that other J2EE frameworks typically do not address the full range of enterprise J2EE developers' needs. Instead, these frameworks only try to solve limited portions of the broad range of enterprise development needs, and thus come up lacking when used to build large, real-world enterprise Web applications.
Perhaps the most common observed failing is the predominant focus on JSP rendering and tag libraries. Apache Struts is possibly the most well-known example of such a framework. Although JSPs are an integral part of any J2EE Web application, and tag libraries are crucial to reduce JSP authoring costs, they cannot be the primary focus of a framework that attempts to minimize developer work while maximizing application maintainability, both of which are critical for real-world enterprise development. For example, any kind of programmatic construct in the JSP is a maintenance problem, because it exposes application functionality to the JSP author, and because parallel content must duplicate this functionality in potentially many places. Additionally, these constructs can seldom be as rich or powerful as Java code, leading to an even worse problem of needing to create scriptlets in the JSP to handle complex, but relatively common, situations. Apache Struts emphasizes this kind of application development, and many of its features are targeted to filling out such capabilities.
Although these types of features might be a productivity benefit for small- to medium-sized applications that do not require significant maintenance or an extended lifespan, clearly such applications are not typical in the enterprise. 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. It accomplishes these goals by separating the view tier into a rendering specification (the JSP) and rendering logic components (View components). The combination of these entities simultaneously keeps programmatic constructs out of the JSP, where they are mixed with content and are hard to maintain, while providing even greater control over rendering by using fine-grained, view-related events.
Another common failing of other frameworks is the lack of any formal notion of a model or a view tier interface to backend components. For developers to quickly build extensible Web applications, there must be a defined contract between the view components that present application data and those that generate it. Commonly seen in other frameworks is no specification of such a contract or interface, so that developers are either forced to provide data in a view-tier specific format (such as a concrete object instance), or write tedious code to marshall data from the backend to the view. Again, given a small project, or a project that does not require future changes to its backend tier, this might be acceptable.
The Web Application Framework, however, provides a formal contract between the view and the backend via its Model interface, so that view components can be fully independent from backend components. This ability also allows developers to seamlessly change the backend associated with a view without any changes to the view itself. This means that a view could render directly from a SQL query early in an application's life span, but later render data from an EJB as the application's enterprise tier matures, all without the view components knowing the difference. For this reason, the Web Application Framework provides a full model-view-controller architecture, while most other frameworks, in effect, only provide a view-controller architecture.
Finally, it is common for other frameworks to simply not consider the submit cycle of a Web application, so that interlinks and relationships between application components are unspecified and difficult to maintain. This omission places a burden on the developer that, unfortunately, might not be readily apparent when the project is started. For example, although many frameworks provide structure for outgoing data, they provide little or no structure for incoming data, so that invoked components are forced to work in the dark, not able to reliably know what data they are receiving on any given request invocation.
Additionally, multiple application paths to the same component force the preparation of the data required by the target component into the callers. This greatly hinders maintainability due to proliferation of inter-object dependencies. Commonly, 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 the target component or backend. This can lead to an asymmetric notion of a backend component or model being used to render a page, but not used to directly handle a request from a previously rendered page. This asymmetry places yet more burden on the developer to micro-manage backend components and be concerned with the low-level details of running in a Web application container.
Instead, the Web Application Framework incorporates this class of functionality into its core design pattern and implementation. This frees the developer completely from being concerned with the population of data to and from the rendered view and the backing models. The result is that from the developer's perspective, models remain stateful between requests without imposing the burden of actual statefulness on the application (which would not scale).
In summary, the Web Application Framework addresses the full range of enterprise developer needs, and avoids focusing on only one technology or a subset of those needs. Other frameworks tend to take a narrower approach that might address one or two aspects of enterprise development, but seldom all of the key aspects that are necessary to build large-scale, real-world enterprise Web applications.
The display field paradigm offers unique advantages over more primitive techniques. Before explaining these advantages, note that there is no reason to use display fields in an application as they have been envisioned. The container and child view mechanisms are based entirely on the notion of embeddable arbitrary view objects. A child view object could be as coarse grained as an entire shopping cart display or application menu, or as fine-grained as individual display fields. This flexibility allows application composition from modular pieces, as well as a more traditional display field oriented approach. In short, you can just pull values directly from a helper bean in the Web Application Framework, but hopefully you can be convinced that there is a better way.
Each top-level ViewBean instance (or root view) is an instance of ContainerView, and can contain any arbitrary set of sub-views, some of which can be display field views. TiledViews are also sub-views, and can be arbitrarily nested, in addition to containing child views themselves.
This hierarchy of views is somewhat more intricate than what the typical Web-tier developer might expect. For example, many such developers might simply create a helper bean which declares all of the methods necessary to obtain the values needed to render a companion JSP. The source of those values would be encapsulated inside the helper bean's methods. They would use the "*" notation in a <jsp:setProperty> tag that would automatically map submitted request parameters to bean fields. This is straightforward, but has some significant disadvantages for development and maintenance.
Although the Web Application Framework is similar, the use of sub-views becomes very important to maintain a strict model-view separation. For example, all display field views are bound to a model. They have no notion of a value contained within them. Furthermore, all display fields are now bound, though not all are data bound. In some cases, this model is an instance of DefaultModel, which is simply in-memory storage. In other cases, the bound model is a SQL query, a stored procedure, an EJB, a business object, an XML DOM, or a SOAP procedure. The display field views are completely separate from the storage and management of data and business behavior.
Display fields are also model-agnostic, in that they can be bound to any model and work without knowledge of the type of that bound model. This means that you need not write application code to move values from some value source to a value consumer--what is called data shuffling. Instead, you get this for free in the Web Application Framework, unlike in the plain helper bean scenario in which you would need to write (and maintain) target-specific code to get values from an EJB, a JDBC ResultSet, and so on, inside each of the bean's accessors. In summary, display fields provide the minimal indirection needed to allow seamless pluggability of arbitrary models. Also, because the interaction of display fields with their associated models occurs via the very general Model interface, the backend data can be represented in its native format without requiring expensive marshalling to or from a data format required only by the view tier.
In addition, display fields significantly improve the programming model from the typical helper bean/taglib approach. Not only do they allow for intuitive manipulation by the controlling logic, but they provide type-specific operations and an interface to the HTML rendering, none of which is possible with other approaches.
For example, one of the drawbacks to the typical taglib approach is that the helper bean has no real input to the HTML rendering process. If one needs to control this rendering, as is common, this failure frequently leads to a burdensome amount of application-related logic and properties in the JSP as scriptlets. For example, you might want to skip the rendering of a field because the current user is not authorized to see it. In the typical JSP, the developer would have to provide a scriptlet to circumvent the display, which puts Java code in the JSP. An alternative would be to enhance the tag handler to conditionalize its display based on some standard mechanism, like checking a condition variable. The problem with either approach is that there is either no consistency or no partitioning of application-related data versus display-related data. In other words, it lacks neatness and is less maintainable.
The Web Application Framework gets around this limitation by providing the best of both worlds. For example, a developer who wants to conditionalize the display of a field, or customize the output of the field's HTML can, at the last moment, implement a display event handler in the parent view, and that handler is automatically invoked during HTML rendering. The developer can then skip the display of that field, or manipulate the HTML output directly (for example, changing a text box into plain text). Or, the developer can call methods on the display field view that indicate the necessary action, and this action is automatically taken into account when the field is rendered by the HTML rendering subsystem (the JSP/taglib combination).
Thus, rather than placing display-related code in the JSP along with page content, or in controlling business logic or in the business-oriented model, developers can either augment the display field rendering process or easily direct it. This not only keeps Java code out of the JSP, but it is far more powerful than scriptlets or other approaches to controlling HTML rendering. Another benefit is that it is far more consistent.
Display fields also allow the developer to work with an HTML page as if it were a stateful server-side object. When the user clicks a button or HREF on the HTML page, the request is ultimately routed back to the view that rendered that button or HREF, and an event handler corresponding to that object is invoked. But, before invoking the event handler, the Web Application Framework repopulates all the display fields and views with the submitted request parameters. The effect is that from the developer's point of view, the page remains stateful and simply responds to commands from the user. The developer handles the event, for the most part, in the same manor as in a fat client application, by implementing an event handler and taking action based on the request and its updated field values. Because display fields are always bound to a model, any changes in the value of the field are automatically propagated to the model. This allows developers to choose the most productive compromise between traditional fat client-like and formal MVC-like programming styles.
It is important to note that the alternative approaches of using helper beans and using display fields both implement the facade design pattern, in that the interface to and from the HTML page is handled by these objects. The data values provided via this interface can come from a number of sources, including multiple backing EJBs, business objects, result sets, and so on, all of which can be referred to in abstract terms as models. However, whereas the traditional helper bean would manage these models via custom code, with little or no consistency or reusability, the Web Application Framework abstracts them to a formal definition of a Model, and specifies a clear contract between a model and a view bound to it.
This formal contract has several advantages.
No. As in any other J2EE application, you can obtain a reference to an EJB and use it directly from within a Web Application Framework application. However, while EJBs are a component of J2EE, they are not a mandatory component. Furthermore, they are a relatively complex addition to an application's architecture, and currently have some significant drawbacks. A large number of Web developers are not prepared to move to an EJB-based architecture, as it presents many unique challenges and requires a significant additional investment in many areas of application design and implementation. Therefore, requiring the use of EJBs would be a disservice.
However, the use of EJBs is supported and facilitated. The Web Application Framework provides valuable features based on a flexible and pluggable model-view architecture, which compliments both Web-oriented and EJB-oriented applications. As an alternative to using an EJB directly, for example, a developer could use a model that is either backed or directly implemented by an EJB. Integration of EJBs is as seamless as it is for any other kind of model in the Web Application Framework, and provides automatic data binding and other high-level features.
As an initial way to get started with EJBs, included in the Web Application Framework is a class called BeanAdapterModel that maps the standard Model interface onto arbitrary JavaBean properties. If you have a Customer EJB, you can wrap it in this adapter model so that display fields can access its properties/values directly without any additional code. Using this adapter, values are rendered from the Customer bean on display and are pushed back into the bean on submit automatically. You can also use this class to wrap access to local business objects as well--the adapter does not care whether the objects it encapsulates are remote or local.
The Web Application Framework applications are fully independent entities comprised of one or more modules. Each module is a functional slice or logical grouping of the overall application. At least one module is required in an application, but other modules are optional and can be added at any time.
Each Web Application Framework application defines what is called the application servlet, which is the base class from which all module-specific servlets are expected to derive. Only the module servlets are accessed by clients of the application. The application servlet serves only as a common base class for the module servlets, providing the opportunity to consolidate common application-level event handlers in a single class. Module servlets allow for module-only specialization of these events. Together, these servlets form the request handling infrastructure of each Web Application Framework application.
Each module corresponds to a sub-package of the application, and in addition to containing a minimal servlet infrastructure specific to that module, contains one or more logical pages. Each module might also contain supporting models and other non-Web Application Framework classes (of course, classes in a module can use classes outside the module as usual).
Each logical page in the module consists minimally of one JSP and one ViewBean. The ViewBean is the helper bean for the corresponding JSP, and in conjunction with the Web Application Framework tag library, provides the display/application event infrastructure. Each ViewBean contains an arbitrary hierarchy of reusable child view objects which can be assembled to create full-fledged, data-bound pages within minutes.
All requests are initially handled by a controller servlet (one per module, several per application), and the URL of this servlet is chosen by the developer. This servlet dispatches a request to a request-specific controller object (the ViewBean), which then ultimately forwards the request to another resource (a JSP, ViewBean, or other Web resource). The source code for the servlet and its dispatching mechanism is fully under developer control, and developers are encouraged to learn the details of this mechanism by reading the well-commented source.
There is no direct relation. A view bean is a JSP worker or helper bean (a usebean). Each view bean acts as the central support for its peer JSP. Session and entity beans can be accessed from within the view bean or any of its associated models or views if desired.
In general, the overhead of supporting persistent application objects is typically greater than that present in the current approach. Testing has shown that the overhead from the current approach is insignificant when compared to what proprietary, non-J2EE containers previously did, as well as the typical behavior associated with a Web application. In essence, allocation of objects in modern JVMs is a sufficiently cheap operation that justifies the benefits provided by this approach. However, this does not mean that the implications of such an approach has been ignored.
Although some non-J2EE containers provided persistent application objects for efficiency reasons, these objects were not stateful to any client. Thus, each client's stateful information had to be regenerated on each request. Equivalent application objects have been carefully designed with as little overhead as possible. In most cases this is equivalent to the useful, stateful information that must, in any case, be recreated on each request. In addition, the Web Application Framework supports optimized access to these objects so they are only created when needed. Therefore, the Web Application Framework-based applications are generally more efficient than non-J2EE applications in both processing and memory consumption and, in most cases, significantly so.
It is not necessarily possible to design an infrastructure that could make use of persistent application objects in a useful way. Both the Sun Java System Application Server and other highly scalable servlet containers make use of multiple JVMs, and a user's requests are not necessarily routed back to the same address space. This means that persistent application objects would have to be reinitialized for each request in any case. This is at least as much overhead, if not more, than simply creating the objects again. Additionally, placing application objects in the session is not a viable option, as it is an extremely expensive operation and minimally requires deserialization, which is more expensive than simple object allocation.
Adding the layer of functionality to the Web Application Framework to support persistent application objects significantly separates developers from the underlying container. This generally violates the design principles of keeping things as close to standard J2EE as possible.
Having made these objections, in the future, the ability to use persistent application objects might still be provided if the possible benefits outweigh the drawbacks. However, such functionality, if present, would be applicable to only a narrow range of applications, and would not be helpful to the typical Web Application Framework application.
| Web Application Framework Overview | 819-0726-10 | |
Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.