Device-Independent Web Applications Based on Web Services

DaimlerChrysler Research's Position on Device-Independent Authoring Techniques

Mario Jeckle
DaimlerChrysler Research and Technology
Research Information and Communication/Data & Process Management
DaimlerChrysler Research Center Ulm (Germany)

Problem Statement

With the advent of XML as a view of heterogeneous data which unifies the underlying sources syntactically, will Web services promise to bear the same potential for heterogeneous functionality? Due to their foundation on XML, Web services could be used to create a unified view of the specific functions (i.e. services) offered by the various systems without taking the specific internal implementations (such as programming languages, calling conventions, parameter passing, etc.) into account. Thus, XML and Web services tackle two different aspects of interaction with an IT system by the introduction of a new, well-defined abstraction layer.

Since neither Web Services nor plain XML offer any kind of interaction component, simply because they were both not developed to accommodate this feature, it now turns out that one of the most vital aspects of today's business systems is missing completely: the user interface.

Additionally, this drawback becomes even more aggravating when we consider that the results of a Web service execution are delivered not only to workstations but also to arbitrary devices including resource-constrained devices such as mobile phones. And in view of the extensions in the pipeline, at some point in the nearer future these services will need to be provided to small devices enabling ubiquitous computing. The main challenge thus becomes not just the support of all these devices and the ones potentially to come with some kind of content, but the creation of appropriate (i.e. consistent, usable, and easy to maintain) user interfaces. At the same time, content authors are increasingly being faced with the need to create interfaces which are geared for various user groups - in strong contrast to the technically focused adaptation to various display and interaction devices.

Relevance for DaimlerChrylser

The extremely wide variety of devices and user groups are the bane of the DaimlerChrysler Group. Since the organization has expanded more and more into a multinational alliance, the participants find themselves looking at a shift into an e-extended enterprise made up of not only the data-producing (i.e. car geometry engineering) partners but also their related suppliers. Device-independent access to internal data is therefore of two-fold interest to DaimlerChrysler.

First, within a business-to-business (B2B) environment, access to internal production-related data using a broader variety of devices would open up the possibility to provide up-to-date information to more people participating in the engineering and production processes than today. In particular, this data should preferably be derived from productive rather than form-redundant data sources introduced solely to satisfy these information needs. For example, consider the part numbers assigned to uniquely identify every part that goes into one of the Group's automobiles. These numbers, which are strings such as "A1100040109", are engraved into cast, forged, or even the blank metal parts requiring further post-processing, thus building the backbone of all engineering and manufacturing processes. Linked to the part number is various part-related information which acts as characterization of the part (e.g. color, weight, manufacturer). Consequently, numerous applications have to be granted access to part number-related information, whereas not all applications access all the data stored for a part number.
Access to this part number-elated information from various devices ranging from classical workstations also including Web applications to small handheld devices like PDAs or even mobile phones forms a key potential usage scenario. Preferably, all the necessary presentation layers consisting of a layout and an interaction model should be create in a comprehensible manner for the same source used to describe the characteristics of the data to be presented. It is not said the layout has to be realized in the form of a graphical user interface. Furthermore, it should be possible to create an interaction model which is reasonable for the corresponding device with respect to the data's visualization and interaction.

Second, within the business-to-customer (B2C) environment, prospective customers want to access data provided by the company concerning product-related information, generally preparatory to making a decision to buy. Ideally, the data underlying this information is identical to (or at least could be derived by restriction from) that stored within the productive systems.
In passing this data, the notion of the strict separation of in-car systems from the devices operating outside the automobile gradually becomes blurred. In a future scenario, various car-centric data such as fuel consumption or the need for repair will be available through in-car devices (such as Mercedes-Benz's COMMAND system) as well as via classical Web pages.

Both scenarios are underpinned by the same idea, which is to provide the user with the most appropriate user interface combined with reasonable interaction patterns for the device actually deployed.


The variety of devices will certainly soar in the future, especially since Web services promise to establish a further abstraction of the system's underlying functionality by considerably increasing the separation of coded control logic and the associated presentation layer.

There is no doubt that content authoring for various platforms should be eased over to the developer by reducing the necessity to take care of platform-specific controls (a.k.a. widgets) and interaction paradigms, e.g. keyboard-controlled input or strokes written on an input-sensitive display. It might also be useful to specify the actual characteristics of a device in a specific vocabulary, setting out a set of device-independent primitives that are transferred into a device-specific representation using an automated process.

The solution should be developed keeping in mind that further enhancements in the field of ubiquitous computing will certainly lead to demands for scaled access to various data sources deploying arbitrary devices. Therefore, a vocabulary allowing description of the device's characteristics and possible interaction patterns has to be made scalable and extensible to remain useful for devices as yet unknown.

Related to Web services, this results in a new layer within Web service's technology stack. Since XML acts as a foundation that enables the creation of such a specific vocabulary as WSDL, which describes the functional interfaces consumed and used by machines, the device-independent authoring vocabulary should be founded on the technical interfaces described by WSDL. Consequently, device independence is organized on top of the implementation independence granted by XML and WSDL. Hence, the device independence layer introduces a new degree of freedom separating the system from the outside world, which complements the independent view of internal data (enabled by XML) and the independent view of functionality (enabled by WSDL) with an independent view of presentation.