One of the primary values of the Java platform has been the concept of "write once, run anywhere." A key factor in achieving this goal has been the fact that Java, as a platform, has focused on defining standardized API specifications, which can be implemented by multiple providers who can compete on features and performance. For the application developer, the key benefit is portability across these implementations, avoiding vendor lock-in - as long as the standardized APIs are of sufficient power and usability to allow developers to create applications based on the standards, without having to rely on vendor extensions.

The servlet API was the first "extension" API to be standardized. Its mission was to encapsulate the HTTP protocol in an object-oriented style accessible to Java developers, with added features that help maintain state across HTTP requests. The original design has proven to be remarkably resilient, with subsequent versions focusing on packaging (Web application archives), filters (chain of responsibility pattern), and event handling.

Servlets, however, are primarily attractive to developers who understand Java. In addition, Web applications built directly on top of the servlet API tended to intermix presentation logic - the generation of the HTML markup - with business logic, leading to applications that were difficult to maintain and enhance.

The first issue was addressed by the development of JavaServer Pages (JSP) technology. Instead of embedding HTML generation inside a Java servlet, JSP pages turn the servlet inside out - the source code for a JSP is primarily HTML markup, with special markup elements (in JSP, known as custom tag handlers) used to insert dynamic content. Dealing with the second issue, however, has led to a plethora of innovative approaches to the overall architecture of a Web application.

One particular design pattern - the Model-View-Controller (MVC) pattern adapted from rich-client architectures - has proven particularly useful. The most popular implementation has been the Apache Struts Framework, an open source Web application framework that implements this design. It enables a separation of concerns between presentation logic and business logic, while providing useful additional functionality. The result has been its adoption as a de facto standard by nearly every major tool that supports Java Web application development.

While Struts has become the epitome of the overall architecture for Web applications, it does not include sophisticated components for the development of sophisticated user interfaces. The recent release of version 1.0 of the JavaServer Faces specification has addressed the need for standardized fundamental APIs for components, which will lead to the development of robust tools and interoperable component libraries.

What happens to a de facto standard when a portion of its functionality is later standardized? It depends on whether the existing technology embraces or ignores the newcomer. In the case of Struts, we'll see an embracing of JavaServer Faces just as it embraced the JSP Standard Tag Library (JSTL) earlier. An integration library, already available as nightly builds, allows you to migrate an existing application, one page at a time, to use JavaServer Faces components in the presentation tier - without changing the business logic embedded in actions. In other words, the separation of concerns provided by the framework really works.

I have enjoyed my personal participation in the evolution of the Web tier APIs in Java. My initial participation was in an open source implementation of the servlet API, which became Tomcat. I was the initial creator of the Struts framework, and co-spec lead for version 1.0 of JavaServer Faces. In my current role (architect on the team building Sun Java Studio Creator), I can assure you that my contributions will continue to be felt.