Sun ONE Application Framework (JATO) Overview

by Todd Fast & Mike Frisino, JATO Architects , Sun Microsystems, Inc.

Table of Contents

Introduction: The Challenges of Building Web Applications

Building Web Applications: Pre-J2EE

Building Web Applications: Post-J2EE

The Rise of the J2EE Application Framework

The Criteria of an Enterprise Application Framework

What is JATO?

Overview

Who Should Be Interested in JATO?

What Does JATO Do?

What Doesn't JATO Do?

How JATO Works

Use of Design Patterns

Types of Functionality

Technical Overview

The JATO Difference

Based on J2EE Standards

A Familiar Paradigm

Application Consistency

Symmetrical display/submit handling

Formal Model Entity

Application Events

Hierarchical Views & Component Scoping

Efficient Object Management

Support for Parallel Content

Ready-to-Use, High-Level Features

Tool-ready

Enterprise-class Performance

Conclusion

Introduction: The Challenges of Building Web Applications

Building Web Applications: Pre-J2EE

J2EE, and in particular its Web-tier components (Servlets and JSPs), has been so 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. To make matters worse, 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.

Building Web Applications: Post-J2EE

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.

The Rise of the J2EE Application Framework

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 in the last 18 months, 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" & "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 really 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 surprisingly little 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 really 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.

The Criteria of an Enterprise Application Framework

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 doesn't respond at all, or one that scales well in both development and production, versus one that may only do one or the other, but not both.

Failings in some of these factors may 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 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 may 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 in these regards, and be confident that the framework meets these requirements before beginning any development work.

The remainder of this document describes how JATO, with its goal of being a truly enterprise-class Web application framework, addresses these issues and meets these criteria.

What is JATO?

Overview

JATO is a mature, powerful, standards-based J2EE Web application framework geared toward enterprise Web application development. JATO 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.

JATO 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, JATO 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.

Who Should Be Interested in JATO?

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

Because JATO 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 JATO 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.

What Does JATO Do?

JATO 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.

JATO 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 JATO as if they were native components. Components can be arbitrarily combined and reused throughout an application, across applications, and across projects and companies.

Finally, JATO 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 JATO Do?

JATO 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 JATO 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.

How JATO Works

Use of Design Patterns

JATO is based on state-of-the-art design patterns and techniques, like Model-View-Controller (MVC), Service-to-Workers, Hierarchical View, Command, Business Delegate, and others. Furthermore, JATO is based on an N-tier JSP/Servlet architecture. JATO 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 these 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 maybe two of the pattern tiers, 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. These claims are specious.

JATO addresses all three tiers of the MVC pattern. JATO 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. JATO's View tier incorporates JSP technology, but is not synonymous with it. In the same way, JATO's Model tier incorporates other J2EE technologies, but is not synonymous with any of them. For these and other reasons explained below, JATO provides unprecedented extensibility for developers that other frameworks simply cannot match.

Types of Functionality

There are three logical groupings of JATO functionality:

JATO core is what is usually referred to as simply "JATO". It defines fundamental interfaces, object contracts, and primitives, as well as the minimal infrastructure required for JATO applications. JATO core does not provide a component library, but provides the enabling technology for component authors. Included in JATO core are View-based primitives like ContainerViews, TiledViews, and TreeViews, as well as Model-based primitives like DatasetModels, QueryModels, and TreeModels. JATO 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. JATO 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.

JATO components leverage the JATO 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 JATO components will tend to be the most generic components available, with their strength being flexibility and customizability. These types of components will be usable by many different JATO user populations, across projects and companies, and generally will not be biased toward any particular look and feel. Vertical JATO components are tailored to a particular usage scenario, allowing them to provide high-level features and high ease-of-use. These types of components will be 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 JATO components can use all of the facilities provided by JATO core, and build upon its high-level features like WebActions, SQL-based Model implementations, and TreeViews.

Finally, JATO extensions provide access to non-J2EE facilities in a JATO-compatible way. In many cases, JATO extensions allow container-specific features to be used from JATO applications seamlessly. Extensions differ from JATO components in that they focus on technology integration rather than application development.

Technical Overview

JATO, or more properly JATO core, is pure Java, and comes packaged as an industry-standard JAR file.

JATO defines several top-level packages:

Each of these packages contains subpackages of more specific derivations, such as HTML-specific View implementations, and SQL-specific Model implementations. There are no formal packages or classes for JATO components or JATO extensions, which are purely logical classifications.

In writing a JATO application, developers derive application-specific subclasses from existing JATO classes, or implement certain JATO interfaces in an application-specific way. In most cases, developers will use the existing JATO core implementations as superclasses, thus inheriting a great deal of useful behavior. (Component developers may be more likely to implement a set of JATO 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 JATO tags—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 JATO tag library to render dynamic content. The tag library uses JATO 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, JATO 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.

Once the user receives a response in a form of a page, he or she activates a link or button and a request is sent back to the JATO application. The request is sent back to the same objects that rendered the page. This allows the JATO 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 his 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 JATO Difference

The following sections outline some major differences between JATO and other contemporary Web application frameworks.

Based on J2EE Standards

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.

JATO embraces J2EE standards like servlets and JSPs directly, while still allowing developers to freely use the features J2EE provides. JATO 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/JATO as they like.

A Familiar Paradigm

JATO 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 JATO for these developers, and significantly speed application development. They also mean that JATO is particularly well-suited to integration with application builders, such as Forte for Java or JBuilder (see more on the topic of application builder integration below).

Application Consistency

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 may 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 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 may 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 lead to counter productivities, in both development and production. As we 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.

JATO, 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, then, between using JATO and another framework to develop a Web application, is that someone new to JATO need not make a (potentially bad) choice in order to get started. He or she can see from the outset a general approach, and as he or she becomes more advanced and fluent in JATO and J2EE, other approaches and techniques become apparent. Furthermore, whatever work the developer has done up to that point will still be consistent with more advanced techniques used later. As a result, applications written in JATO will resemble one another more so than applications written using other frameworks. They will be more consistent, both in use of high-level and low-level features, and thus be more maintainable.

Symmetrical display/submit handling

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 may place a burden on the project that may 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, JATO 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, JATO makes a distinction between rendering specification (JSP) and View components. Only together are these considered the full View tier. A JATO 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.

Formal Model Entity

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 JATO 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, JATO 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 JATO Views) can obtain Model data in a standard way, without any assumptions about how that Model internally represents its data.

For this reason, JATO 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 by this virtue, 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 JATO 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.

Application Events

JATO 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 JATO) 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 JATO 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 conditionalize that code 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 (see the next topic for more information on this drawback).

Lastly, JATO 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 (see below for more information on parallel content). Although these kinds of features may 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, JATO recognizes and leverages the advantages of JSPs without compromising maintainability or the ability of the application developer to finely control rendering of the JSP.

Hierarchical Views & Component Scoping

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.

To make matters worse, 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.

JATO, 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. JATO 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 JATO takes care of the details.

Furthermore, developers do not use these qualified names during authoring of a JSP page. Instead, JATO 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. JATO 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.

Efficient Object Management

Many frameworks focus very 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 may 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 scariest is that these bugs may not reveal themselves until the application built on the framework is in production and under heavy load.

For these reasons, JATO 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 JATO 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 JATO itself, it does the same for application code. Developers need not worry about stomping on shared data, and debugging becomes much easier.

JATO 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.

Support for Parallel Content

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 may 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.

JATO 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 may 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 JATO provides display events to keep programmatic constructs out of the JSP, display logic never has to be replicated across parallel JSPs in a JATO application.

JATO 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, JATO's parallel content feature provides the most flexible internationalization support possible.

Ready-to-Use, High-Level Features

JATO 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 JATO 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 JATO application if they wish, but the presence of these value-added implementations in JATO 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 JATO, they minimally require a conscious decision to use complex business objects in the application architecture. By contrast, the JATO 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, JATO 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 pluggable and customizable component look and feel. No other contemporary framework has anything rivaling these components.

Tool-ready

Unlike other frameworks, JATO was designed from the ground up to be ultimately 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, JATO does not yet provide this capability, for several reasons. First, 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 may 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 JATO perspective is that if the framework is first designed around interfaces and object contracts, GUI builder support will be easy to add at a later stage (and in fact, this work is being pursued today in JATO). What will result will be 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 will not be compromised by a tool-centric design early in the process, and that even if application builder support requires some performance penalty, developers will 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 JATO 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.

Enterprise-class Performance

Because JATO has been optimized to eliminate all synchronization points, applications built on JATO are as scalable as the J2EE container in which they run. JATO introduces only a small, fixed amount of overhead to each application request, whereas other frameworks that do costly synchronization may exact exponentially more overhead or incur increasingly longer latencies as load increases.

Conclusion

JATO 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 JATO attempts to address the broad range of enterprise application development requirements. JATO has been designed through and through to complement enterprise development, and minimize the impact of the unique challenges enterprise development presents.

Thus, JATO meets the criteria of an enterprise framework in the following ways:

JATO is mature, robust, stable, and extremely well-performing. But most importantly, JATO 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 JATO has already been proven in the enterprise most of all assures those adopting JATO that it meets all the criteria of an enterprise-class Web application framework.