Sun ONE Application Framework (JATO)

Design FAQ

The following are answers to a number of questions people new to JATO often ask about its design and architecture.

Q: Who should be interested in JATO?

A: JATO is primarily intended to address the needs of J2EE developers building medium, large, and massive-scale enterprise-strength Web applications. JATO combines robust design patterns with equally robust implementations of those patterns to provide an enterprise Web application foundation. Because JATO provides core facilities for reusable, JavaBean-like components, it is also suited for 3rd 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 applications or offerings, in particular because its horizontal extension capabilities provide a well-defined way for both end users and original developers to extend or leverage existing vertical features.

Q: Why use JATO when we already have J2EE?

A: J2EE is a relatively young technology, and though it is very exciting, it doesn't 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 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 JATO steps in: easy to understand and close to the metal, yet providing unprecedented design flexibility and consistency. Best of all, it is based entirely on the pure, standards-compliant J2EE platform, so you don't sacrifice J2EE to use JATO; instead, you benefit from both.

Q: Isn't JATO just another proprietary Web application framework (JAPWAF)?

A: No. With proprietary Web application frameworks, you are tied not only to the framework API—for which you don't have the source code—but also the the vendor's underlying application server platform. If you want one and not the other, you're out of luck, and moving an application from one vendor's solution to another's means a rewrite of your application from scratch.

JATO is different. First, JATO is based entirely on the J2EE platform. There is no container-specific code in the core JATO classes, which means you can use JATO in your favorite J2EE container, without changes. We've tested JATO in containers like Apache Tomcat, Caucho Resin, Allaire JRun, iPlanet Application Server, iPlanet Web Server, and IBM WebSphere, and it works the same in all of them (barring container bugs which may necessitate slightly different usage). As far as we're concerned, J2EE has delivered, and we take full advantage of that fact, with you as the benficiary.

Second, you have the full JATO source code. This means that should you wish, you can investigate, change, fix, tweak, configure, or otherwise mess with every nook and cranny of the framework, including even the underlying design pattern, to make it suit your exact needs (although we hope this won't be necessary). We want you to see how JATO works, not only because it will help get bugs fixed more quickly and easily, but because we believe JATO can only benefit from detailed technical review and discussion.

Finally, JATO is fundamentally a design pattern, based entirely on interfaces and object contracts. We provide a default implementation of these interfaces, but if you don't like the way this implementation works, you can override the portions you don't like. Or, reimplement the interfaces yourself to create a new type of JATO object that integrates seamlessly into the rest of the framework. Your new JATO objects can interact with other types of JATO objects because they all obey the same contracts. Try that in your favorite proprietary Web application framework.

Q: How is JATO different from other J2EE frameworks?

A: In our survey of J2EE frameworks both before and after the inception of JATO, we've found that other J2EE frameworks typically don't 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 failing we've seen is the predominant focus on JSP rendering and tag libraries. Apache Struts is perhaps 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 wishes 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, both 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 we feel that these kinds of features may be a productivity benefit for small- to medium-sized applications that don't require significant maintenance or an extended lifespan, clearly such applications are not typical in the enterprise. 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. 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. In order 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. What we most commonly see 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 doesn't require future changes to its backend tier, this might be acceptable.

JATO, 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, JATO provides a full model-view-controller architecture, while most other frameworks, in effect, only provide a view-controller architecture.

Finally, it's 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 hard to maintain. This omission places a burden on the developer that, unfortunately, may 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're receiving on any given request invocation.

Worse yet, multiple application paths to the same component force the preparation of the data required by the target component into the callers. This leads to extreme unmaintainability due to prolieration 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 concern himself with the low-level details of running in a Web application container.

Instead, JATO incorporates this class of functionality into its core design pattern and implementation. This frees the developer completely from concerning himself 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, JATO addresses the full range of enterprise developer needs, and avoids focusing on only one technology or subset of those needs. Other frameworks tend to take a narrower approach that may address one or two aspects of enterprise development, but seldom all the key aspects that are necessary to build large-scale, real-world enterprise Web applications.

Q: JATO has the notion of a "display field". This isn't like the J2EE Blueprints or other J2EE architectures I've seen—why not just pull values directly from a helper bean?

A: The display field paradigm offers unique advantages over more primitive techniques. Before explaining these advantages, first understand that there is no reason one need use "display fields" in an application as we've envisioned them. 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 JATO, but we hope to convince you 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 that 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 JATO 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 we call data shuffling. Instead, you get this for free in JATO, 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, etc. inside each of the bean's accessors. In short, 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, say you want to skip the rendering of a field because the current user isn't 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 vs. display-related data. In other words, it's messy and less maintainable.

JATO gets around this limitation by providing the best of both worlds. For example, if a developer wants to conditionalize the display of a field, or customize the output of the field's HTML at the last minute, he can 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, say changing a text box into plain text. Or, he can call methods on the display field view that indicate the necessary action, and this action will automatically be 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 worse, 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 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, JATO 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 like he or she would in a "fat client" application, by implementing an event handler and taking action based on the request and its updated field values. Realize that 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 understand 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, etc., 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, JATO 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. First, it allows display fields to provide an easily mutable mapping between the facade presented by the view and the set of models backing that facade. As we include XML-based declarative features into JATO (work already in progress), display fields will allow declarative changes to this facade, greatly simplifying application development and drastically reducing development time.

Second, because this facade is so easily changeable, changes to backing models can be propagated to the view portion of the application with extreme ease, and with declarative support, without recompilation. Compare this to the traditional helper bean approach in which developers would need to add accessors and mutators to their helper bean and/or modify the code needed to obtain values from or send values to the backing model. Because of these fine-grained changes and the recompilation they require, development time, productivity, and object reuse suffer significantly.

Q: Do JATO applications require the use of EJBs?

A: No. Of course, like in any other J2EE application, you can simply obtain a reference to an EJB and use it directly from within a JATO application. But, 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. There are a large number of Web developers who 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. We felt it would be a disservice to customers for us to require their use.

However, this isn't to say that we don't support and facilitate the use of EJBs. JATO 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, one 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 JATO, and provides automatic data binding and other high-level features.

As an initial way to get started with EJBs, we include in JATO 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 it's 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 could also use this class to wrap access to local business objects as well—the adapter doesn't care whether the objects it encapsulates are remote or local.

Q: How are JATO applications structured?

A: JATO 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 may be added at any time.

Each JATO application defines what we call 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 JATO 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 may also contain supporting models and other non-JATO 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 JATO 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.

Q: How are the request flow and URL format implemented?
A: 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 we encourage developers to learn the details of this mechanism by reading the well-commented source.

Q: How does a view bean relate to a session or entity bean?
A: 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.

Q: With the JSP scope set to "request" to simplify threadsafe coding and force beans to be constructed and destroyed with each request, will there be negative performance impact?

A: In general, we believe that the overhead of supporting persistent application objects is typically greater than that present in the current approach. In our testing, we have found 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 we feel it justifies the benefits provided by this approach. However, this doesn't mean that we've ignored the implications of such an approach.

Specifically, 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. We have been careful to design our equivalent application objects with as little overhead as possible, which is, in most cases, equivalent to the useful, stateful information that must to be recreated on each request anyway. In addition, JATO supports optimized access to these objects so that they are only created when needed. Thus, JATO-based applications are generally more efficient than non-J2EE applications in both processing and memory consumption, in most cases significantly so.

Furthermore, it is not necessarily possible to design an infrastructure that could make use of persistent application objects in a useful way. Both the iPlanet 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 anyway, which is at least as much overhead, if not more, than simply creating the objects anew. 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.

Finally, we feel that adding the layer of functionality to JATO to support persistent application objects would significantly separate developers from the underlying container. This generally violates our design principles of keeping things as close to standard J2EE as possible.

Having made these objections, however, we may in the future still provide the ability to use persistent application objects if we find that the possible benefits outweigh the drawbacks. However, we expect that such functionality, if present, would be applicable to only a narrow range of applications and not helpful to the typical JATO application.