Introduction
We need to overhaul our current view of presentation technologies, because years of conditioning have caused many in the IT industry to view some very aberrant design patterns as normal and natural, which in turn creates significant impediments to building good distributed applications in the modern era. Our position in this paper is that the entire thin client paradigm characterized by web applications (as opposed to static web sites) is actually a "kludge" that needs to be repudiated. To understand why we say this, one needs to travel back in time to the mid-nineties, when the Web began.
History
Two mutually antagonistic developments occurred almost simultaneously as the Web exploded in popularity: (1) the overwhelming importance of the browser as a ubiquitous client-side "application platform" that made applications easy to deploy with a small footprint, and (2) the vendor-based fragmentation that robbed that same platform of much of its potential. By the latter, we're referring to the browser wars between Netscape and Microsoft, which resulted in two families of products that behaved very differently when rendering web pages and executing JavaScript code. It was infuriatingly common for web applications not to work on one or the other browser. Faced on the one hand with increased demand for the Web way of delivering applications to users, and on the other with unreliable platforms on which to deliver them, what could the industry do?
The most commonsensical approach was to rely on the browser for the barest minimum functionality - rendering simply-formatted web pages, following hyperlinks, submitting forms, etc., and moving all other presentation logic to the part of the system that the service provider could control - the Web Server. Many server-side web frameworks then began to emerge to help manage the complexity of combined business logic and presentation logic on a single platform. Struts was perhaps the earliest success among these frameworks. Today, there are literally more than 50 of them, each claiming some particular advantage over its predecessors.
However, let us be blunt about the impact of these frameworks. Although they bring order and rationality to server-side presentation logic, they only serve to perpetuate a kludge. There is low cohesion within the Presentation Tier, because presentation responsibilities have been split between browser and web server for extraneous reasons that have nothing to do with sound architecture. Simultaneously, there is tight coupling between presentation logic and business logic on the server side. Specifically, current web frameworks create the client on the server from several variants of server-side templates, configuration files, annotations and the like, which increases the complexity of building something that should have been straightforward. Today, not only are web frameworks no longer required, their acceptance as a natural component of every system hobbles us significantly in our effort to build applications better.
A tipping point has been reached
There have been at least three developments in the recent past that help us break with history.
- The new-found popularity of an age-old principle, or what is known as Service-Oriented Architecture (SOA), indirectly changes the outlook for the Presentation Tier as well. Define it as we may, SOA rationalizes the way business logic is organized and provides a uniform interface to it. Good architectures are based on discrete layers that encapsulate different aspects of an application, and SOA allows the User Interface (UI) to be architected more elegantly as a true presentation layer. This layer holds no business logic but is a consumer of business services.
- The browser fragmentation that characterized the first decade of web applications has largely healed. Virtually all modern browsers conform to industry standards. Our strategy need no longer be one of minimizing our dependence on a whimsical platform. We can now place all presentation logic on the browser platform where it belongs and be reasonably confident that it will work as expected regardless of vendor implementation.
- XML has become dominant as the lingua franca for data interchange between systems. From our viewpoint, at a practical level, SOA is mainly about the design of XML document interchange and secondarily about the plumbing required to achieve that interchange. There are better tools available to work with XML, and newer languages (especially scripting languages) have begun to treat XML as a native data type, making the use of XML far less painful. These modern tools make it more natural to build SOA-conforming systems.
All of these developments benefit from a common architectural model - SOFEA (Service-Oriented Front-End Architecture). Interestingly, the older rich client paradigm, which has been overshadowed by the thin client or web model, now points the way towards a better architecture for both.
The basic principle of the new model is the separation of presentation concerns from business logic concerns. The latter align neatly with SOA principles, so the presentation tier needs to be compatible with a service-oriented business tier, across a well-defined Service Interface. If we look at SOA as the exchange of well-designed, structured data between architecturally distinct domains (whether they be application domains like Marketing and Finance or technology domains like architectural "layers"), there is no reason why the presentation tier should be exempt from such principles.
One of the important aspects of such compatibility is respect for data integrity end-to-end across an application. This translates to being able to speak XML in the form of XML document payloads using either of today's popular service paradigms - SOAP/WS-* or REST.
Elements of the new paradigm
The diagram above shows the important physical components and logical processes in this architecture. The Application Container is a generic name for the platform on which the client-side application runs. It is important to note that this is never a server-side component. The Application refers to the code that runs on this platform. The Application is not part of the Application Container.
It is sourced from somewhere else and is loaded onto the Application Platform at some point in time before it actually runs. The Download Server is the term for the component that serves the Application up to the Client Platform so it can be locally installed before it is run. The Service Interface is the standardized interface to the Service Tier. It supports a well-understood mechanism to exchange XML-based documents between the presentation tier of an application and the business logic tier.
There are three basic processes that occur on the client side. Application Download refers to the process of getting an Application onto the Application Container before it can run. Usually, this takes place all at once, but it could also be done in lazy fashion, loading screens on demand from the Download Server when required. In this latter design though, the system does not behave like a conventional web application that uses a server-side web framework to drive the screen flow. A client application that loads screens (or pages) on demand still drives this flow. Presentation Flow refers to the logic by which screens (or other channel-specific artifacts) are presented to the user. Data Interchange refers to the exchange of (XML-formatted and Schema-conforming) data between the Presentation and Service tiers.
Underlying rationale
The core theme behind this model is the separation of orthogonal concerns. This has always been a requirement, but could never be met because of the client platform constraints we described earlier. Now at last, the situation is conductive to building applications the way they should be. The presentation tier becomes smaller, more cohesive, more understandable and more maintainable as business logic is stripped from it. The server side also benefits similarly as presentation logic is removed from it.
Implications of the paradigm
- A lean architectural model with seamless integration between presentation tier and business logic tier with no impedance mismatch
- Rationalization of the role of a "web server" (for the first time)
- Support for MVC as the most natural design pattern for the presentation tier
- Assurance of end-to-end data integrity in applications; unification of "thin client" and "rich client" models
- Support for both SOAP and REST based services
- The server is no longer burdened with presentation-related logic and can be lighter/thinner
- Multiple user interfaces for the same set of business services can be built with much less cost
- The pressure to reuse presentation tier artifacts reduces, if business tier design has been done well and sufficient reuse is obtained just by calling the right services from the presentation tier
Technology examples
Ajax frameworks (Dojo, jQuery, Ext, et.c.), GWT, TIBCO GI, XForms, Mozilla XUL, Microsoft Silverlight/XAML, Java WebStart, JavaFX Script, Adobe Flex, OpenLaszlo, etc.
Conclusion
The contribution of this model is not so much to introduce something new as to show that an old and entrenched compromise need no longer be made. We have tried to show how new technology makes it possible to design and build applications the way they should always have been built. This is a paradigm whose time has finally come.
