Next Generation Internet: The "Fourth Tier" Is Born.

Solving the problem of disparate content types

Web content began as static HTML p ages and evolved to include client-side scripting, proprietary content technologies, and application programming interfaces. HTML has remained the basis of all Web content-until now. We are about to witness the revolutionary move of content from HTML to XML (Extensible Markup Language).

XML is a set of rules for defining a document using tags in a self-described vendor- and platform-neutral manner. XML has numerous advantages over HTML. It is easily transformable and can describe any type of content.

HTML is a rendered presentation of data for a specific set of clients (namely HTML-based browsers), while XML can be data, its presentation, or a combination of both. Metaphorically speaking, HTML is a picture of a 3D object (Data, Presentation, and Flow Logic) while XML is the 3D object itself. Viewing an HTML object from a different perspective will produce a fuzzy picture at best because the object's entire data set is unavailable. Cell phones, PDAs, or embedded devices may have problems with HTML, which often has extraneous or missing data.

Content in XML can be transformed into a wide range of other content (like voice based content) and made available to a wider range of devices (like digital cell phones). XML content can be rendered in one way for cell phones (like WML for WAP) and in another way for PC-based browsers (like XHTML).

The Complexities Of Content

Content, more complex than ever before, is currently provided by a variety of servers. It exists in three distinct formats: data, audio (including voice), and visual (including video). Each content type requires different mechanisms and systems for storage, processing, and serving. Content combinations depend on user specifications, device capabilities, and available content. Configuring the combination correctly is a complex process and is not accounted for in the current development model. Today's systems solve only one problem: data. Audio and visual components must be integrated and content mixtures served to clients must be synchronized.

The variety of Internet clients has multiplied considerably. Five years ago, users only expected to access content from different PC browsers. Today users expect to tap into the same content from multiple devices with vastly different capabilities. These devices range from cell phones to PDAs to web browsers. Each client can process different amounts and combinations of each type of data. Web browsers, for example, typically have a keyboard/mouse/monitor interface while cell phones have a phonepad/voice interface. Hybrid devices combine the capabilities of devices: PDAs have cell phones integrated into them and cell phones possess many PDA capabilities.

When building today's systems, future requirements must be considered, including content form.

Most audio and video systems have switched from analog to digital. Most digital, visual, and aural based content is served in proprietary formats. There has been no equivalent to non-proprietary HTTP until recently, with the development of XML.

Audio, data, and video content can be described by metadata in XML. Clients can easily process data if video or audio streams are wrapped inside XML with some meta data about the stream. VoiceXML, for example, allows voice-based content to be described by XML, encapsulating the data concerning the content. This data can then be used to "introduce" the content to any client wanting to use it. Content can be customized at run-time using an XML description of the client, user settings, and content structure.

Approaching content in this way gives birth to a new software layer separating the user interface and the application server (the middle-tier). This layer enables us to author content once using the new presentation layer: then the formats and logical flows required for various clients can be created. This new system will separate the data, presentation, and logic of the user interface.

The Move From Three-Tier To Four-Tier Architecture

Three-tier architecture has been the prevailing design for Internet systems during the past few years. In this design, as seen in Figure 1, there are three primary components: database, application server, and client.

Three-tier architecture was considered an evolutionary step over the client server model. It removed business logic from the client and the database and placed it into an application server. It became responsible for the processing work that implemented the business logic in the system. It enabled systems to scale larger and become more reliable by implementing various forms of fail-over at a lower cost. By clearly defining an API (Application Programming Interface) at each tier in the architecture, it allowed for a more sophisticated development cycle. System development could now be broken down and distributed among three groups: database engineers, software engineers, and user interface developers. New features could be added in a faster, more methodical way.

Four-tier architecture will solve the problem of disparate content types by abstracting and removing the data and presentation logic from both the client and the application server of the three-tier model. The new presentation server is responsible for gathering content, client-, and user- settings and preparing them to serve the client. Figure 2 shows the basic four-tier architecture.

Four-Tier Architecture

In the four-tier architecture model, the database server remains the data storage and retrieval mechanism and the application server continues to act as the container for implemented business logic. The presentation server becomes the contact point for the client. All requests and responses originate there. The client can insert a structured XML payload, consisting of commands, data, etc., into the presentation server request, allowing for structured payloads rather than a flat unstructured payload in name-value pairs.

The response sent by the presentation server to the client contains meta-data for the audio and video content. The actual audio and video is still served by systems specifically made to serve those content types, taking advantage of their particular performance tuning. The application server has access to the audio and video content servers to facilitate its interaction with the meta-data of those media types.

The presentation server can communicate with the application server using any combination of naming services and remote interfaces (like the RMI/JNDI/IIOP combination). This can also be done through a stateless protocol, using HTTP alone, or with a high layer protocol like SOAP, XML-RPC, etc.

The presentation server will perform one of two actions: a)retrieve cached content and return it to the server or b) send one or more requests to the application server and/or other content servers. If cached content is available and appropriate, it is returned. If cached content is not available, one or more requests are made to the application server, which performs the necessary business logic and returns a response to the presentation server. The presentation server formats the data received according to the presentation logic, the client device capabilities, its user settings, and content type. This is sent to the client, which retrieves the described content.

The presentation server abstracts all presentation logic from the client and the application server, and sends the appropriate data when it is requested. It performs all presentation formatting before the response is sent to the client.

The Development Cycle

In the three-tier model, presentation logic development is combined with the presentation itself. When using JSP, for example, web developers and software engineers have to work together on a single file where the "look and feel" is in HTML and the presentation logic is in Java, complicating development.

In the four-tier model, content is broken into a presentation server specific scripting language and a presentation layer in XSL. The actual content comes from the application server, which may be in actual or modified XML. This separates programming from formatting.

Software developers are freed to work on the scripting code and application server. Web developers are freed to work on the XSL, but will still need to create some canonical sets of XSL pages to match individual or families of devices. This process can also be streamlined. The fourth-tier model will drastically reduce the length of web development cycles and cleanly separate development efforts.

The Presentation Server

The presentation server is one or more applications running inside a server with the primary purpose of implementing all presentation logic. Though it is merely an application running in an environment similar to the application server, it should be viewed as a subsystem separate from the application server and the content management system.

The application server performs business logic related tasks such as manipulation of data, business computations, maintaining persistence, etc. The application and presentation servers are isolated leads. Each set of functionality will have different requirements for scaling, fail-over reliability, performance, and deployment.

It is important that the presentation server be kept as stateless as possible. The application server should handle all states, such as session information and transactions. The presentation of data, whether it is device dependent, user dependent, or content dependent, is stateless. There may be exceptions to this statelessness when implementing features such as caching and content synchronization.

The original client request to the presentation server is typically in HTTP with a possible payload of XML. The output of the presentation server to the client is the result of changes to the content coming from the application server, typically in XML format.

The presentation server requests and receives data from the application server, using a variety of techniques including stateful protocols such as RMI/JNDI/IIOP in Java, or stateless protocols such as HTTP, with or without some XML based protocol such as SOAP or XML-RPC.

This new method of architecting systems using four distinct components is an evolutionary step over today's three-tier system. The presentation server will solve the problems brought on by the proliferation of devices and content types. By dividing the work between software and user interface developers, four-tier architecture will cleanly separate development efforts and drastically streamline the development process.

Reza B'Far is a senior software engineer at eBuilt, Inc. (Irvine, CA).

Acknowledgements and contributions: Stephen Ditlinger and Paul Park, both senior software engineers at eBuilt; and Roger Richards, a project manager at eBuilt.