Sun ONE logo     Previous      Contents      Index      Next     
Sun ONE Application Framework Overview



Sun ONE Application Framework Design and Architecture FAQ

This document provides answers to a number of questions often asked by people new to the Sun™ ONE Application Framework about its design and architecture.

The questions included in this document are as follows:

Who should be interested in the Sun ONE Application Framework?

The Sun ONE Application Framework is primarily intended to address the needs of J2EE developers who build medium, large, and massive-scale enterprise-strength Web applications. The Sun ONE Application Framework combines robust design patterns with equally robust implementations of those patterns to provide an enterprise Web application foundation. Because the Sun ONE 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 Sun ONE 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.

Why use the Sun ONE Application Framework when we already have J2EE?

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 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 Sun ONE 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 don't sacrifice J2EE to use the Sun ONE Application Framework; instead, you benefit from both.

Isn't the Sun ONE Application Framework just another proprietary Web application framework (JAPWAF)?

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 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 that of another means a rewrite of your application from scratch.

The Sun ONE Application Framework is different. First, the Sun ONE Application Framework is based entirely on the J2EE platform. There is no container-specific code in the core Sun ONE Application Framework classes, which means you can use the Sun ONE Application Framework in your favorite J2EE container, without changes. We've tested the Sun ONE Application Framework in containers such as Apache Tomcat, Caucho Resin, Allaire JRun, the Sun ONE Application Server, the Sun ONE 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 beneficiary.

Second, you have the full Sun ONE Application Framework 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 the Sun ONE Application Framework works, not only because it will help get bugs fixed more quickly and easily, but because we believe that the Sun ONE Application Framework can only benefit from detailed technical review and discussion.

Finally, the Sun ONE Application Framework 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 Sun ONE Application Framework object that integrates seamlessly into the rest of the framework. Your new Sun ONE Application Framework objects can interact with other types of Sun ONE Application Framework objects because they all obey the same contracts. Try that in your favorite proprietary Web application framework.

How is the Sun ONE Application Framework different from other J2EE frameworks?

In our survey of J2EE frameworks, both before and after the inception of the Sun ONE Application Framework, 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, 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, the Sun ONE 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. 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.

The Sun ONE 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 Sun ONE Application Framework 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 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 concern himself with the low-level details of running in a Web application container.

Instead, the Sun ONE Application Framework 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, the Sun ONE 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 Sun ONE Application Framework 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?

The display field paradigm offers unique advantages over more primitive techniques. Before explaining these advantages, first understand that there is no reason to 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 the Sun ONE Application Framework, 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 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 Sun ONE 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 we call data shuffling. Instead, you get this for free in the Sun ONE 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 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, you may 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.

The Sun ONE Application Framework 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 (for example, 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 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 Sun ONE 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 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, 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 Sun ONE 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. 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 the Sun ONE Application Framework (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.

Do the Sun ONE Application Framework applications require the use of EJBs?

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 Sun ONE Application Framework 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. The Sun ONE 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, 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 the Sun ONE Application Framework, and provides automatic data binding and other high-level features.

As an initial way to get started with EJBs, we include in the Sun ONE Application Framework 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 does not care whether the objects it encapsulates are remote or local.

How are the Sun ONE Application Framework applications structured?

The Sun ONE 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 may be added at any time.

Each Sun ONE Application Framework 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 Sun ONE 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 may also contain supporting models and other non-Sun ONE 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 Sun ONE 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.

How are the request flow and URL format implemented?

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.

How does a view bean relate to a session or entity bean?

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.

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?

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 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 be recreated on each request anyway. In addition, the Sun ONE Application Framework supports optimized access to these objects so that they are only created when needed. Thus, the Sun ONE Application Framework-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 Sun ONE 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 the Sun ONE Application Framework 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 Sun ONE Application Framework application.

Previous      Contents      Index      Next     
Copyright 2002 Sun Microsystems, Inc. All rights reserved.

Last Updated September 26, 2002