Server software allows for reengineered services

Server software allows for reengineered services
The Web revolves around browsers running on personal computers, rendering a content format known as HyperText Markup Language (HTML). But this dominance is about to end: Pervasive computing is gaining a strong foothold, letting a wide range of end-user devices access data and applications on servers. As the rendering capabilities of these devices expand with embedded computing power, the experience of the end user will match or exceed that which personal computers now deliver.

These new devices, including wireless phones, Web-enabled information appliances, and set-top boxes, are using a large number of diverse content formats, communication protocols, and user interfaces. They also differ from the conventional HTML-centric PC in their input and output capabilities and, more significantly, in the way they interact with the user.

The common feature among these devices is their browser-centric architecture. Content is transmitted from the server to the client device in the form of a marked-up document. All interaction between the users at the client device is orchestrated through a user interface that is generated and maintained by a browser program independent of the server and its application. The browser program resides permanently on the device.

Such applications have several advantages. First, no client-resident part needs to be maintained or managed. This means that the application can be upgraded easily by upgrading only the server. Second, the application's state and data can be easily regenerated from the server side. And third, the browser, through the markup language, provides the application programmer with a high level of abstraction from the hardware and software details of the end-user device.

On the down side, the user experience is dependent upon applications interacting between the client and the server. Depending on the latency of the network involved, this may prove slow or uneven. Local scripting capability, which is supported by most browsers and which enables some level of dynamic content generation on the client, can partly remedy the problem.

The work of enabling server-based applications to support a sea of devices is a complex endeavor. The variety of devices and browser infrastructures require dedicated gateways and application servers on all three levels of the application/communication stack: the "protocols" layer, which provides the communications primitives, the "application" layer, which uses such communications, and the "session" layer, which glues the two together.

As far as the protocols layer is concerned, communication is accomplished primarily using the TCP/IP suite of protocols, conveyed by standard bearer networks such as Ethernet in the wired world, CDMA (Code Division Multiple Access), and soon GPRS (General Packet Radio Service) in the mobile/wireless world.

On the application level, the browser and the PC environment — which is a client application execution environment — differ both in syntax and semantics. In syntax, the Internet is currently centered on HTML. By contrast, The Wireless Markup Language was specified for the Wireless Application Protocol (WAP) and is based on an Extensible Markup Language document-type definition.

In the omnipresent world of future rendering devices, it often makes sense to separate the data content from the presentation facilities. Instead of storing data in the format in which it will be rendered, structured data isn't formatted until its time to deliver it to the device and actually show it to the user.

How can application service back ends be reengineered to allow their services to be accessed from a variety of different browser-based end-user devices? The requirements for this application "rehosting" seem daunting.

The application server has to identify the type and version of the receiving device. Then the output generated in the "front end" has to be adapted to the class of device — that is, a different markup language must be chosen depending on the device browser. The exact content of each page must be adjusted depending on the device model because screen size and display capabilities vary among different models of the same device class. The application flow must be modified to suit the overall device characteristics and usage models. Finally, individual features of the application may be exposed or hidden, depending on the browser's ability to handle them , for example, push functions.

Meeting these objectives requires significant modifications to the server and back-end infrastructure to account for the lack of clear architectural distinctions among the application logic, the data and the front-end user interface.

A framework has been developed at IBM's Zurich Research Laboratory to meet these challenges as part of a project to adopt airline customer-service applications to WAP-based devices, although the scope of the project soon expanded beyond wireless receiving devices. The effort provides an execution environment for applications that can correctly interact syntactically and semantically, with a large set of browser-based receiving devices

The system server enforces a clean separation between the device-independent application logic and device-dependent front ends. The system can be viewed as a bridge between the user's receiving device on the one side and an application server's back-end data sources on the other.

If the back-end data sources are transaction engines, the system may simply provide a suitable access window into those transactions, allowing the user to select among the offered transactions, enter the relevant parameters, trigger those transactions and retrieve the resulting data sets. If the back ends are plain data sources (such as databases, data warehouses, news feeds), the system also serves as the hosting platform for the application logic. In both configurations the system provides a single communications platform to the set of receiving devices.

This communications platform is provided using the HTTP protocol layer as a common abstraction. As pointed out above, HTTP is already widely used in many Web-based client/server systems. When HTTP derivatives are used (as in WAP, which uses WSP, a binary version of HTTP), there is a clear mapping to HTTP primitives, except for features, such as "push," that have no clear counterpart in HTTP. Here, the common solution is to overload HTTP directives and add header field information.

The Java server page (JSP) mechanism has been selected to drive the overall application architecture. A primary advantage of JSP pages over the style sheet approach is their ability to poll the application logic from within the output template. If appropriately used, only application logic that is relevant to a specific device-dependent markup is executed.

A second advantage is that JSP pages can be authored easily using existing authoring tools and provide an intuitive framework to encode the application's user interface by virtue of specifying the menu structure through which the application's logic is made accessible. The standard JSP mechanisms do not fit the bill entirely for two reasons. First, they are tied to specific URLs — different JSP pages for two different device types will have two different URL addresses. Second, the JSP syntax requires a comparatively tight coupling to the application logic components, the beans.

This requires that JSP templates be "touched" whenever the configuration of the application logic changes and vice versa. The system aims to provide enough separation to update and modify the application logic without requiring additional changes to the JSP pages and, equally, to update the JSP repository (for example, to add support for a new device), without having to modify the application logic.

Consequently, JavaBeans or Enterprise JavaBeans are used for the logic aspects of the application. Those beans either improve application logic directly or act as wrappers and accessor methods to databases or transaction systems in the back end of the application service provider. In addition to providing effective tool support for the generation of JavaBeans, the system adds a framework invoker and the MetaBean to bolster standard JSP mechanisms.

The framework invoker is the component that is presented with incoming URL requests and has to fan those requests out to the servlet runner, the JSP compiler, the style sheet interpreter or any other execution environment. The framework invoker provides an application-independent framework within which to select the correct JSP to process a user request. It allows for a single URL entry point across a range of devices, and also allows the application providers to differentiate to an arbitrary level their responses to those requests, depending on the device class and type.

The MetaBean, which is unique to the IBM system, provides the desired separation of the JSP pages from JavaBeans. It operates as a dispatcher of property set and get calls from the JSP pages to the actual bean instances. The standard JSP mechanism provides the "use bean" directive, which couples a JSP to one or more JavaBeans. These beans can then be queried by embedding the appropriate set and get calls to the bean's properties. This coupling is comparatively tight because it implies that any change to the beans' structures also requires changes to the JSP templates that use those beans. The system inserts a "meta-bean" layer between the JSP pages and the beans in order to alleviate this tight coupling and allows application providers to maintain and upgrade separately either JSP pages or JavaBeans. Conceptually, the MetaBean is a singular bean that exhibits the union of all properties exposed by the set of beans that exist in the logic part of the application.

Celine Steenkeste, IT professional in the Business Innovation Services Branch of IBM Global Services (Paris), also contributed to this article.

See related chart