DM Review Published in DM Direct in January 2003.
Printed from

Adaptive Content Rendering Strategies

by Arvind Prabhu

Summary: Adaptive content rendering is the process by which a single enterprise system delivers accurate, appropriate and relevant content to various devices connected through various media.

We?ve come a long way from the days when mainframe computing was the state of the art. Nowadays, everyone has at least one computer at home and is connected to the Internet in some fashion. In the recent past, technology has grown by leaps and bounds; and customers demanded online access to almost anything and everything. Enterprise systems came into existence and provided customers with instant access to information and services through a desktop browser. Several browsers were introduced into the market, and enterprise systems had to evolve to support the various types and versions of browsers. More and more customers are venturing into the wireless world and demanding wireless access to the same information and services.

This wireless revolution spawned a multitude of devices each with their own capabilities and oddities. Devices range from palmtops and PDAs to cell phones and pagers. The major differences between these various wireless devices lie in their communication protocol, screen size and type, and user input mechanism. Customers are sparing no expense to purchase the "right" device that fits their personality and attitude. And, not only do they want to have access to their information, but they also want relevant content delivered quickly and efficiently.

Many businesses have reacted to this market need quickly and have either retrofitted or enhanced their enterprise systems with wireless capability. Several techniques have been employed to achieve this functionality, each with their own pros and cons. Some are a simplistic, ad hoc extension of their existing systems and provide basic support; whereas, others are more sophisticated and provide adaptive content rendering.

Adaptive Content Rendering

Adaptive content rendering is the process by which a single enterprise system delivers accurate, appropriate and relevant content to various devices connected through various media. The first point to note here is that an enterprise application must advertise a single point of entry for all types of devices. Each device whether it be a browser, PDA, cell phone, etc. should be able to access the same enterprise system the same way, and the enterprise system must respond in a device specific manner.

The other conditions of accuracy, appropriateness and relevancy of delivered content must also be met in order for an enterprise system to be deemed capable of rendering content adaptively. Accuracy refers to the correctness of the response delivered to the target device. For example, when a customer accesses an enterprise application through a cell phone, a correct WML response must be rendered to the device. In addition, the enterprise system must handle the various incompatibilities that exist within a family of devices. Appropriateness refers to how well an enterprise system filters content sent to various devices. For example, when a customer accesses a weather site (a graphics-rich Web site) through a PDA or cell phone, the enterprise system must filter out the high-resolution satellite images from the response. (However, with the advent of high tech cell phones, maybe it does make sense to send images to cell phones!) Finally, relevance refers to how well an enterprise system filters the functionality available to various devices. For example, when a customer accesses a banking application through a cell phone, the enterprise system should block the functionality to open a new account.

In addition, the enterprise system has to also deal with the existing issues of internationalization and personalization in an orthogonal manner. These too are an integral part of adaptive content rendering.

In the remainder of the article, I compare and contrast some techniques that are currently being utilized to address the issue of adaptive content rendering. I describe the techniques and discuss their advantages and disadvantages. And finally, I explore and discuss possible new techniques and strategies for implementing adaptive content rendering in enterprise systems.

Trade-Off Criteria

There exist several criteria when comparing the various adaptive content rendering techniques. The following are some of the more important ones:

  • Development Time ? How long does it takes to implement the solution?
  • Content Quality ? How well is the content filtered between various devices and how well is the content relevancy handled?
  • Maintainability ? How easy is the system to maintain; is there a lot of duplicated code and content?
  • Extensibility ? How easy is it to restructure the content delivered to various device and how easy is it to add support for new devices introduced in the market?

An ideal solution would excel in all these areas; however, in reality it?s all about tradeoffs. In the end, the technique used depends on the nature of the particular enterprise application being enhanced and the customer needs. In the real world, it?s perfectly fine for different enterprise systems to implement different practical solutions. There are four adaptive content rendering techniques currently being employed in enterprise systems:

  1. Transcoding
  2. Ad Hoc
  3. Conventional
  4. Data Centric

Current Approaches

Transcoding. In this approach, a third-party software product sits in front of an enterprise system and acts as a proxy by redirecting requests and filtering responses. All devices access the enterprise system through a single entry point, which in most cases is the transcoding proxy. Upon receipt of a request, the transcoding proxy determines the type and properties of the target device and forwards the request to the enterprise system. Then, the enterprise system processes the request and renders a device-independent (usually HTML) response. At this point, the proxy deciphers the response and transforms it to the format recognizable by the target device. Depending on the software, various transformation options can be configured on the transcoding proxy.

Figure 1: Transcoding Architecture

Transcoding as seen in Figure 1 is one of the earliest techniques employed to satisfy the multidevice/multichannel environment. Since the changes to an enterprise system are minimal (if any), this technique seems very attractive; however, in practice, transcoding does not perform well. Although the time to market might be short for this solution, the other factors including accuracy, appropriateness and relevance of content are not well addressed. The level at which content can be filtered may not be as fine grained as the enterprise application developer needs. In addition, due to the nature of this technique, the developer does not have any real-time control over the content filter from within the enterprise application. However, these kinds of issues are expected when the adaptive content rendering component is independent and external to the enterprise system.

Ad Hoc. In this technique, an enterprise system tries to achieve adaptive content rendering by advertising a different entry point for each supported device. Each device must access the enterprise system through its dedicated entry point for an appropriate response to be rendered. Depending on the implementation, the enterprise system might consist of several vertical subsystems each dedicated to serve a single device/channel. Usually these vertical stovepipes are designed to be independent of each other, and this leads to a lot of duplicated code, both in the front the back end. (See Figure 2.)

Figure 2: Ad Hoc Architecture

Considering all the bad aspects of this technique, it can only be concluded that this approach came into existence through desperation. First of all, customers accessing an ad hoc-based enterprise system have to be aware of the multiple entry points. Customers must access the system through the appropriate entry point based on the device they are using. However, on a slightly better note, the delivered content can be perfectly custom tailored for the device since the enterprise system has independent vertical subsystems, each handling a different device. But this comes at a huge cost of maintainability. With large amounts of code and functionality duplicated in the enterprise system, bug tracking and change control will be a nightmare. Even minor changes to the code base can become very pervasive. And finally, there is no sense of extensibility in this system, because it consists of several independent verticals. By default, adding support for another device would mean creating another separate vertical implementation.

Conventional. Typically, in this approach, an enterprise system is built using a model-view-controller architecture and provides a single point of entry for all devices. The system consists of a device detection component that is used to determine the target device and to render appropriate content. Typically, the views are mapped to JSP files, where a single JSP is associated with a single device. Thus, as more devices are supported, more JSPs are added to the system. The content for a particular device can be controlled independently from the content of another device. A typical request/response cycle as seen in Figure 3 would consist of the following:

  1. A request is made by a device.
  2. The device detection component of the enterprise system detects the type of device.
  3. Appropriate business logic is performed.
  4. The respective view (JSP) is selected by the controller.
  5. Device characteristics obtained from device detection are used in the JSP to customize the content.
  6. A device specific response is rendered.

Figure 3: Conventional Architecture

Conventional architecture is probably one of the most popular and widely used techniques today. It provides a single point of entry for all the devices and, unlike transcoding, internally handles the device detection and content rendering. The time to market depends on whether the supporting MVC/device-detection framework is purchased or developed in house. These days, there are several vendors that provide such a framework, and it?s just a matter of deciding which framework is the most cost effective. The content quality is under the control of the enterprise developer; JSPs can be tweaked independently of one another to achieve optimal results. Maintainability is questionable since a lot of the content might be duplicated across several JSPs; thus, if a fundamental content change needs to be made, the enterprise developer will possibly need to touch several JSPs. And finally, the extensibility is largely dependent on the extensibility of the device detection component of the MVC framework.

Data Centric. The data- centric approach is similar in many ways to the previously discussed conventional approach. It consists of an MVC/device-detection framework that provides a single point of entry for all devices. The major difference lies in implementation of the views and how they are adaptively rendered. In this architecture, views are data centric and reside in XML files. In addition, the views are complemented by a library of XSL files; one per device supported. Rendering a view boils down to performing an XSL transformation on a specific XML file using the appropriate device-specific XSL file. Figure 4 shows a typical request/response cycle:

  1. A request is made by a device.
  2. The device detection component of the enterprise system detects the type of device.
  3. Appropriate business logic is performed.
  4. The proper view (XML file) and an appropriate transformation (XSL file) are selected by the controller.
  5. An XSL transformation is performed to render the device specific response.

Figure 4: Data- Centric Architecture

At first glance, this technique seems superior to the others. It boasts all the advantages of the conventional approach and seems to address some of its drawbacks as well. With regards to content quality, this approach provides a much better solution due to the cleaner separation between data and presentation logic. Enterprise developers can concentrate on the data (XML) while front-end experts tweak the presentation logic (XSL). These two activities can happen in parallel to reduce the overall development effort. Maintainability is slightly improved since there is no duplication of data in the views; however, depending on the design, there still might be considerable duplication of presentation logic in the XSL files. Extensibility is achieved easily by adding to the library of XSL files.

While there are some significant advantages, this technique does introduce some new issues. In terms of performance, there is an additional cost of an XSL transformation for every request/response cycle. Also, the enterprise developers, dealing solely with the data in the views, do not have real-time or fine-grained control over the transformation. In addition, the XSL files tend to become complicated and convoluted over time posing maintenance issues.

New Approaches

In the previous section I discussed some of the existing techniques for achieving adaptive content rendering in enterprise systems. Some techniques are mediocre at best while others seem promising; however, each technique has its share of advantages and disadvantages. In the quest to find the ideal solution, I explore possible new techniques in this section. It will become apparent that these new techniques mostly build on existing ones and try to overcome their deficiencies. However, it will also become apparent that these new techniques still have certain drawbacks, which are inevitable in practical solutions.

Adaptive. This technique is an extension of the conventional approach. The main difference lies in the way the views (JSP files) are managed. In this approach, each view corresponds to a single JSP file regardless of the target device or channel. Thus, the enterprise developer is responsible for placing appropriate content rendering code within the JSP. This "code" doesn?t necessarily have to equate to Java code within the JSP. Custom tags can be developed which examine the properties of the target device and provide switching and formatting logic. In addition, the device detection module can be enhanced to conform to the Composite Capabilities/Preferences Profile (CC/PP) standard for describing devices. For more information on CC/PP see Erich Izdepski?s article titled "Ultimate Device Support with CC/PP" in XML Journal?s July 2002 issue.

Figure 5: Adaptive Architecture

This technique shares all of the advantages of the conventional approach. In addition, it relieves some of the maintenance issues caused by duplicated content. Since a view maps to a single JSP regardless of the target device, any change to a view requires only a single change in a single JSP. A change made to a single view is instantly available to all the devices that use that view. Also, the CC/PP enhancement to the device detection module renders the solution compliant with this emerging standard; thus, making it easier to add support for new devices in the future. It is the hope of CC/PP pushers that, in the near future, device manufacturers will release respective CC/PP files along with their new devices. So, supporting new devices is as easy as updating the library of CC/PP files.

There are, however, some drawbacks to this solution. In an effort to achieve a high content quality, enterprise developers will have to place fairly sophisticated logic within the JSPs. This can make the JSPs hard to read and difficult to maintain. In addition, since all devices share a common view, device specific changes cannot be made independently of one another. This device interdependency within a view affects maintainability in both a positive and negative manner.

Practical Hybrid. This is a fairly simple extension of the adaptive approach. In fact, it is a hybrid strategy that combines some of the view management aspects of the conventional and adaptive approaches. In this technique, the mapping of the views (JSPs) to the devices is left to the discretion of the enterprise developer. The developer may choose to share a view between devices where there is a lot of overlapping functionality. On the other hand, the developer may choose to keep the views independent where the functionality greatly varies from device to device.

Empowering the enterprise developer with this view management flexibility alleviates some of the maintainability issues created by the adaptive approach. Also, due to its nature, this technique shares all of the advantages of the adaptive approach. However, depending on the view management strategy implemented, there still might be some issues concerning maintainability of content.

Technique Summary Matrix

The table in Figure 6 summarizes the previously mentioned criteria. Keep in mind that an ideal approach would consist of low development time, high content quality, high maintainability and high extensibility.

Figure 6: Technique Summary Matrix

The Future

The wireless revolution has begun and all those handheld devices are here to stay. At a minimum, the future is guaranteed to introduce new devices and new families of devices. For an enterprise system to be valuable it must stay up to date with the latest technology and, more importantly, closely track customer needs. We?ve addressed some of the pressing issues that all enterprise systems are currently facing. In addition, we?ve seen how choosing the right adaptive content rendering strategy positions enterprise systems for the future.

Enterprise architects must also be prepared for the Web services revolution that is faintly visible on the horizon. This revolution promises a world where all enterprise systems are registered and advertised as Web services. Enterprise systems will be accessed through a Web services interface and all systems integration will boil down to simple Web service invocations. How will this affect your choice of an adaptive content rendering strategy for your enterprise system?

Arvind Prabhu is a software engineer in the Professional Series division for Cysive, Inc. He has more than seven years of experience in the computer industry. He is a Sun Certified Java programmer and a Sun Certified Java developer. You may contact him at

Copyright 2004, Thomson Media and DM Review.