<?xml version="1.0" standalone="yes"?>
<Paper uid="W03-0811">
  <Title>ing in Language Generation: An Abstract Reference</Title>
  <Section position="3" start_page="0" end_page="0" type="intro">
    <SectionTitle>
2 Anatomy of the Testbed
</SectionTitle>
    <Paragraph position="0"> The MULTIPLATFORM testbed in its diverse instantiations comprises the software infrastructure that is needed to integrate heterogeneous dialog components into a complete system. Built on top of open source software (Wu and Lin, 2001), the testbed SDK offers APIs as well as a large set of tools and utilities to support the whole development process, including installation and distribution.</Paragraph>
    <Paragraph position="1"> The following sections provide an overview of the testbed and describe the design principles that govern its realization. null</Paragraph>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.1 Architecture Framework
</SectionTitle>
      <Paragraph position="0"> A distributed system constitutes the natural choice to realize an open, flexible and scalable software architecture, able to integrate heterogeneous software modules implemented in diverse programming languages and running on different operating systems. In our project work, for example, we encountered modules for Sun Solaris, GNU Linux, and Microsoft Windows written in Prolog and Lisp, as classical AI languages, as well as in common conventional programming languages like C, C++, and Java.</Paragraph>
      <Paragraph position="1"> The testbed framework is based on a component architecture (Hopkins, 2000) and our approach assumes a modularization of the dialog system into distinct and independent software modules to allow maximum decoupling. These large-grained components--ranging from more basic modules that encapsulate access to specific hardware devices to complex components which may include entire application-specific subsystems--constitute self-contained applications which are executed as separate processes, or even process groups. The principle behind this view is to consider software architecture on a higher-level of abstraction as modularization is not concerned with decomposition on the level of component libraries in a specific programming language. Continuous evolution is one of the driving forces behind the development of novel dialog systems. The creation of a componentized system makes the integrated system easier to maintain. In a well-designed system, the changes will be localized, and such changes can be made with little or no effect on the remaining components. Component integration and deployment are independent of the component development life cycle, and there is no need to recompile or relink the entire application when updating with a new implementation of a component.</Paragraph>
      <Paragraph position="2"> The term middleware (Emmerich, 2000) denotes the specific software infrastructure that facilitates the interaction among distributed software modules, i.e. the software layer between the operating system--including the basic communication protocols--and the distributed components that interact via the network. The testbed as a component platform enables inter-process communication and provides means for configuring and deploying the individual parts of the complete dialog system.</Paragraph>
      <Paragraph position="3"> Our middleware solution does not exclude to connect additional components during system execution. So far, however, the testbed does not offer specific support for dynamic system re-configuration at runtime. In our experience, it is acceptable and even beneficial to assume a stable, i.e. a static but configurable, architecture of the user interface components within a specific system instantiation. It is obvious that ad hoc activation and invocation of services constitutes an important issue in many application scenarios, in particular Internet-based applications. We propose to hide such dynamic aspects within the application-specific parts of the complete system so that they do not affect the basic configuration of the dialog system itself.</Paragraph>
      <Paragraph position="4"> The details of the specific component architecture of different dialog systems vary significantly and an agreed-upon standard architecture which defines a definite modularization simply does not exist. Nevertheless, we found it helpful to use a well-defined naming scheme and distinguish the following categories of dialog system components when designing a concrete system architecture: Recognizer: Modality-specific components that process input data on the signal level. Examples include speech recognition, determination of prosodic information, or gesture recognition.</Paragraph>
      <Paragraph position="5"> Analyzer: Modules that further process recognized user input or intermediary results on a semantic level.</Paragraph>
      <Paragraph position="6"> Such components include in particular modality-specific analyzers and media fusion.</Paragraph>
      <Paragraph position="7"> Modeller: Active knowledge sources that provide explicit models of relevant aspects of the dialog system, like for example discourse memory, lexicon, or a suitable model of the underlying application functionality.</Paragraph>
      <Paragraph position="8"> Generator: Knowledge-based components which determine and control the reactions of the dialog system through the transformation of representation structures.</Paragraph>
      <Paragraph position="9"> This includes the planning of dialog contributions and application-centric activities as well as fission of multiple modalities and media-specific generators, e.g., for text and graphics.</Paragraph>
      <Paragraph position="10"> Synthesizer: Media-specific realization components that transform generated structures into perceivable output. A typical example is a speech synthesis component.</Paragraph>
      <Paragraph position="11"> Device: Connector modules that encapsulate access to a hardware component like, for example, microphone and sound card for audio input or a camera system that observes the user in order to identify facial expressions.</Paragraph>
      <Paragraph position="12"> Service: Connector components that provide a well-defined link to some application-specific functionality. Service modules depend on the specific application scenario and often encapsulate complete and complex application-specific subsystems.</Paragraph>
    </Section>
    <Section position="2" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.2 Inter-Process Communication
</SectionTitle>
      <Paragraph position="0"> Nowadays, a very broad spectrum of practical technologies exists to realize communication between distributed software modules. Techniques like remote procedure call and remote method invocation, which follow the client-server paradigm, have long been the predominant abstraction for distributed processing. In this programming model, each component has to specify and implement a specific API to make its encapsulated functionality transparently available for other system modules. Only recently, the need for scalability, flexibility, and decoupling in large-enterprise and Internet applications has resulted in a strong general trend toward asynchronous, message-based communication in middleware systems.</Paragraph>
      <Paragraph position="1"> In accordance with the long-standing distinction being made in AI between procedural vs. declarative representations, we favor message-oriented middleware as it enables more declarative interfaces between the components of a dialog system. As illustrated by a hybrid technology like SOAP, the simple object access protocol, where remote calls of object methods are encoded in XML messages, the borderline between a procedural and a declarative approach is rather difficult to draw in general. Our own data-oriented interface specifications will be discussed in more detail in section 3.</Paragraph>
      <Paragraph position="2"> For message-based communication, two main schemes can be distinguished: a0 Basic point-to-point messaging employs unicast routing and realizes the notion of a direct connection between message sender and a known receiver. This is the typical interaction style used within multi-agent systems (Weiss, 2000).</Paragraph>
      <Paragraph position="3"> a0 The more general publish/subscribe approach is based on multicast addressing. Instead of addressing one or several receivers directly, the sender publishes a notification on a named message queue, so that the message can be forwarded to a list of subscribers. This kind of distributed event notification makes the communication framework very flexible as it focuses on the data to be exchanged and it decouples data producers and data consumers. The well-known concept of a blackboard architecture, which has been developed in the field of AI (Erman et al., 1980), follows similar ideas.</Paragraph>
      <Paragraph position="4"> Compared with point-to-point messaging, publish/subscribe can help to reduce the number and complexity of interfaces significantly (Kl&amp;quot;uter et al., 2000).</Paragraph>
      <Paragraph position="5"> The MULTIPLATFORM testbed includes a message-oriented middleware. The implementation is based on PVM, which stands for parallel virtual machine (Geist et al., 1994). In order to provide publish/subscribe messaging on top of PVM, we have added another software layer called PCA (pool communication architecture). In the testbed context, the term data pool is used to refer to named message queues. Every single pool can be linked with a pool data format specification in order to define admissible message contents.</Paragraph>
      <Paragraph position="6"> In the different dialog systems we designed so far, typical architecture patterns can be identified since the pool structure reflects our classification into different categories of dialog components. The pool names together with the module names define the backbone for the over-all architecture of the dialog system.</Paragraph>
      <Paragraph position="7"> The messaging system is able to transfer arbitrary data contents and provides excellent performance characteristics. To give a practical example, it is possible to perform a telephone conversation within a multimodal dialog system. Message throughput on standard PCs with Intel Pentium III 500 MHz CPU is off-hand sufficient to establish a reliable bi-directional audio connection, where uncompressed audio data are being transferred as XML messages in real-time. A typical multimodal user interaction of about 10 minutes duration can easily result in a message log that contains far more than 100 Megabytes of data.</Paragraph>
      <Paragraph position="8"> The so-called module manager provides a thin API layer for module developers with language bindings for the programming languages that are used to implement specific dialog components. It includes the operations required to access the communication system and to realize an elementary component protocol needed for basic co-ordination of all participating distributed components.</Paragraph>
    </Section>
    <Section position="3" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.3 Testbed Modules and Offline Tools
</SectionTitle>
      <Paragraph position="0"> In addition to the functional components of the dialog system, the runtime environment includes also special testbed modules in support of system operation.</Paragraph>
      <Paragraph position="1"> The testbed manager component, or TBM for short, is responsible for system initialization and activates all distributed components pertaining to a given dialog system configuration. It forms the counterpart for functional modules to carry out the elementary component protocol, which is needed for proper system start-up, controlled termination of processes and restart of single components, or a complete soft reset of the entire dialog system.</Paragraph>
      <Paragraph position="2"> The freely configurable testbed GUI constitutes a separate component which provides a graphical user interface for the administration of a running system. In Figure 1 the specific testbed GUI of the SMARTKOM system (cf. Section 4.2) is shown as an example. The GUI basically provides means to monitor system activity, to interact with the testbed manager, and to manually modify configuration settings of individual components while testing the integrated system.</Paragraph>
      <Paragraph position="3"> A further logging component is being employed to save a complete protocol of all exchanged messages for later inspection. Flexible replay of selected pool data provides a simple, yet elegant and powerful mechanism for the simulation of small or complex parts of the dialog system in order to test and debug components during the development process.</Paragraph>
      <Paragraph position="4"> Another important development tool is a generic data viewer for the online and offline inspection of pool data.</Paragraph>
      <Paragraph position="5">  Currently active components are highlighted using a different background color. The data viewer windows provide a compact display of selected pool data.</Paragraph>
      <Paragraph position="6"> Further offline tools include a standardized build and installation procedure for components and utilities for the preparation of software distributions and incremental updates during system integration. Additional project-specific APIs and specifically adapted utilities are being developed and made avaliable as needed.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>