Mario Jeckle
DaimlerChrysler Research and Technology
Research Information and Communication/Data & Process Management
DaimlerChrysler Research Center Ulm (Germany)
mario.jeckle@daimlerchrysler.com
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.
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.