In-Depth
Must You Choose a Single Technology?
Will the trend of increasing power and ease of use in development tools continue? See why basing Web application architectures on Java technologies is a smart business decision.
Committing your application architecture to a particular framework is a potentially risky decision, because changing later is potentially expensive. At the same time, as the technologies at our disposal continue to evolve—and new technologies become available—we would like to be able to incorporate these technologies into our existing applications without having to throw away our entire previous investment. Therefore, one of the factors of choosing foundational technologies (such as a Web application framework architecture) is whether the chosen framework embraces new technologies when they become available.
The Struts framework illustrates the acceptance of new technologies' concepts in several different ways. Struts is agnostic about Model tier implementation strategies. Whatever Java technology you wish to use in this area will be comfortable. In the Controller tier area, recent innovations in the implementation of the Struts controller are focused on adapting current design practices for containers, particularly in decomposing complex operations into easily composable pieces, to allow for easy customization and specialization. At the same time, backwards compatibility is being maintained by standard compositions of operations. In the View tier area, Struts has historically provided an optional View tier based on custom tags, and was an early innovator in using scripting-like expressions to bind input and output fields to corresponding property values in the Model tier. As the technologies around JavaServer Pages (JSP) improved, Struts has embraced them.
The evolution of the JSP Standard Tag Library (JSTL) introduced a standard expression language syntax that is more powerful (and more concise) than the original Struts expression language. In response, Struts added a set of "work alike" tag libraries that provided familiar functionality, but allowed the use of expressions identical to those used in JSTL tags (and now, with the advent of JSP 2.0, available everywhere in a JSP page).
Pluggability
The standardization of JavaServer Faces (JSF) creates a desire (on the part of application architects) to be able to use JSF components in the JSP pages of an existing Struts-based application. This desire is being met through the development of the Struts-Faces Integration Library.
The design center for the Struts-Faces integration library is to leverage the pluggability interfaces in JSF and provide "work alike" JSF components where necessary, such that an existing application can be migrated to using JSF components in the View tier, one page at a time, with essentially zero changes to the Controller tier and Model tier portions of the application. (Thereby fulfilling one of the key values of the separation of concerns encouraged by an MVC architecture; minimizing the cost of implementing changes in one tier by isolating those changes to only that tier.) In most cases, the only change required is to the JSP pages themselves, and to the logical mappings in the configuration file.
When deployed together, JSF receives and processes each request (just as it does in an application based solely on JSF). If the request was sent to the server merely to change the state of a UI component (for example, scrolling the rows in a data table, or expanding a node in a tree component), JSF will manage changing the state of the component and redisplaying the current page, without bothering the Model tier at all—which is entirely appropriate for a View tier state change. On the other hand, if a request was triggered by activating a Submit button, the library's integration into the JSF request processing life cycle causes the standard Struts request processing life cycle to be invoked, including all the behavior described earlier.
The possibility to adopt this sort of new technology through an economically feasible migration (since no one has time to completely rewrite nontrivial applications based on a new framework) will clearly be attractive to developers and organizations that have existing applications based on Struts. However, it also supports the opportunity to leverage the strengths of Struts where there is no corresponding functionality provided by JSF (such as the support for client-side and server-side form validation).
When selecting an application architecture for your Web applications, examining the history of how that framework has adapted to changing technologies should be one of your selection criteria.
In the evolution of Web application architecture, we like to focus primarily on technical details: APIs, standards, and what the code would look like if you wrote it by hand. Indeed, it has become easier to write such applications by hand, for several reasons. View tier page authors need to know less (or nothing) about Java language syntax to incorporate dynamic content. The syntax required to bind dynamic content elements to Model tier data has become simpler and more powerful, and (with the advent of JSF) has eliminated the need to explicitly perform conversions between the Strings used in the user interface and native data types typically used in the model. Frameworks have become available to eliminate the need for an application to develop and maintain its own Controller tier. Adapter classes (such as Actions in Struts, or action methods in JSF) have become simpler to write, with fewer restrictions such as required base classes.
Going Visual
All of these trends are helpful at making existing developers using text editor-type tools more productive. However, there is a very substantial number of developers who would prefer to develop in an environment where the various components are manipulated visually, instead of needing to be manually coded. Such a tool will shield the developer from the mass of details normally required, including everything from knowing the syntax of HTML elements in a JSP page to knowing the syntax of XML in a configuration file.
In the years that the Struts framework has been available, many IDEs have added the ability to produce Struts-based applications. Typical value-added features include visual composition of JSP pages, visual management of the page-navigation hierarchy, and transparent generation and maintenance of configuration files. Such development tools have greatly expanded the population of potential developers that are able to produce high quality Web applications based on Struts.
Today, we are seeing the initial delivery of tools that provide the same sorts of capabilities around JSF components. In one sense, it is not very surprising to see this rapid availability of tools—JSF was designed to be friendly to tools developers (many of whom participated in the expert group that led to the creation of JSF), and the advent of a standard component API maximizes the opportunity for component providers to make their components available in more than one tool. However, we also see the beginnings of an exciting opportunity for the Java platform as a whole—a way to attract a new developer audience to Java.
In organizations of all sizes, around the world, professional software developers are normally employed (or contracted) to create the mission-critical software applications that support the core functions of that organization. Generally, though, applications for internal use (especially for small subsets of the overall employee population, such as a department) are the responsibility of an Information Technology (IT) department that is, in nearly every environment, long on responsibilities and short on staffing to create and maintain internal applications. Therefore, more and more employees in such departments and work groups have taken it upon themselves to learn enough about developing Web applications to create simple applications for internal use.
Traditionally, such developers have used simple tools and scripting languages, nearly always in a visual development environment of some sort. In many scenarios, the Java platform has been perceived as too difficult for such developers to understand or use, so they have tended not to adopt Java technology based solutions. However, the maturity of Web application frameworks and the advent of standardized Java APIs such as JSF, has created the opportunity to build Java-based tools that meet the needs of this audience.
Sun Java Studio Creator is a leading example of an IDE tool that is targeted at this audience. Java Studio Creator has particular features targeted at making these developers immediately productive: visual composition of JSP pages made up of JSF components; visual construction of page navigation rules; drag-and-drop binding of JSF components to back-end data sources, such as relational databases, Web services, and existing Model tier components that expose their information through JavaBean properties; automatic association of each visual (JSP) page with a corresponding Page bean containing component references and event handlers, plus convenience methods for easy access to the entire application infrastructure; and the ability to switch back and forth between editing a visual representation of the application and the corresponding source code. Changes made in one view are faithfully synchronized into the other.
Business Sense
The standardization process has created APIs that are progressively more powerful and easier to use. Now, best practice concepts for the overall structure of an application have been encapsulated in powerful frameworks, enabling developers to focus on the specific logic required in their applications rather than on internal plumbing.
A parallel growth in visual development tools, providing high-level abstractions to seemingly complex internal concepts, and enabling both faster creation of applications by those familiar with Java already, has provided the ability to create applications for a new audience of developers. This trend towards increasing power of the foundational technologies, coupled with increasing ease of use in development tools, will undoubtedly continue in the future. Deciding to base your Web application architectures on Java technologies, then, is and will continue to be a smart business decision, as well as a beneficial technical one.
This article is excerpted from "The Evolution of Java Technology Based Web Application Architectures."
Download the related code for this article here.