当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

所有提交的信息确保安全。

My developerWorks:

我的通知：

退出

选择语言：

W3C Multimodal Architecture，第 1 部分: 概览和挑战

有关分布式多通道应用程序新兴架构的必知信息

Gerald McCobb (mccobb@us.ibm.com), 顾问软件工程师, IBM

Gerald McCobb 在 IBM 工作有 15 个年了，他目前致力于从事 WebSphere Business Activity Monitor 的开发。他也是 IBM 在 W3C Multimodal Interaction Working Group 的代表。

简介： W3C Multimodal Interaction Working Group 自 2002 年以来就一直在不断完善其 Multimodal Architecture 的提案。在这个由三部分组成的系列文章的第 1 部分，来自 IBM 的 Gerald McCobb 大致介绍了该工作组的进展情况。通过他的介绍，您可以提前接触这种新兴架构，并了解 Web 开发人员在决定实现这种架构时应该考虑的一些问题和挑战。

标记本文！

发布日期： 2007 年 6 月 08 日
级别： 中级
访问情况： 1707 次浏览
评论：

面向个人计算机和微型设备的应用程序现在正在迅速演变以满足市场对多种键盘、键板和手写笔等备选交互方式的需求。备选的交互模式包括语音和数字笔，并可与其他模式混合使用。比方说，一个手机用户通过与其手机接收器交互，比如 “告诉我在 12 月 23 日从波士顿飞往纽约的航班”，就可以获得航班信息。相应地，应用程序会在手机的屏幕上显示这些航班的列表，而该用户就可以通过语音或手写笔来选择其中一个航班。

自 2002 年以来，W3C Multimodal Interaction (MMI) Working Group 就一直在规划开发这类应用程序所需的标准框架。最近，该工作组发布了其 Multimodal Architecture and Interfaces 工作草案的最新版本。虽然此文档还只是一个草案，但它很有希望会成为 W3C 的一个推荐标准，而且 MMI Working Group 也一直在不懈地向这个目标努力，并取得了巨大进展。

这个由三部分组成的系列文章的第 1 部分，提供了 MMI Working Group 当前版本的 Multimodal Architecture 的概览。既讨论了该架构的一些显著特性，也给出了它为 Web 开发人员带来的一些挑战。在随后的第 2 部分，我将详细讨论一组 XML 标记语言（其中既有 W3C 推荐，又有早期的工作草案），尤其侧重于介绍它们如何作为标记接口用于 Multimodal Architecture 实现。在第 3 部分，我将描述 Multimodal Architecture 的一种 Web 服务实现，解释该实现是如何克服之前所描述的种种挑战和困难的。

为何采用分布式架构？

虽然，向应用程序添加另一种通道接口可以使应用程序更易于使用，但其中所需要的处理和资源要求对于一个小型的客户端设备来说太过复杂。比方说，一个手机不可能拥有运行一个本地语音识别系统所需的资源，如果此应用程序还需要能包含加利福尼亚州洛杉矶市的每个市民的名字和地址的语法，就更不可能了。

出于这个原因，在小型的客户端设备上运行的额外的通道接口都必须是发布式的，即，它必须驻留在远端服务器上，并通过网络协议，比如 HTTP 或 SIP，与该设备通信。相应地，W3C Multimodal Architecture 提供对分布式通道组件的支持，并定义了组件生命周期 API 来进行通道组件和服务器端交互管理器间的远端消息传递。同时，在客户端运行通道组件的这类实现，虽然受 Multimodal Architecture 允许，却不适用于 Web 应用程序，本文会对此做进一步解释。

Multimodal Architecture

Multimodal Architecture 指定运行时框架以及一个或多个分布式通道组件，这些组件通过一个生命周期事件 API 与运行时框架通信。如图 1 所示，此架构包含如下部分：

运行时框架: 运行时框架控制组件间的通信，并提供对交互管理器、交付上下文和数据组件的运行时支持。
交付上下文: 静态和动态设备属性、环境条件和用户首选项均存储于交付上下文。这些属性可随后被查询和动态更新。W3C Device Independence Working Group 现正致力于面向此交付上下文的接口的标准化工作。
交互管理器: 交互管理器负责发送和接收运行时框架和通道组件间的所有消息，查询和更新所需的数据组件。由于它维护对话流、当前状态和公共数据，因此，它很自然地会包含多通道应用程序。MMI Working Group 现在也在力图使交互管理器语言标准化。该语言 SCXML，即 State Chart XML 是 David Harel 的 Statechart（参见参考资料）的一种 XML 实现。
数据组件: 数据组件包含用于多通道应用程序的公共数据模型。
通道组件: 通道组件执行诸如识别语言输入、显示图像和运行标记语言（比如 VoiceXML、XHTML 或 SVG）之类的任务。由于通道组件只与交互管理器直接通信并只能通过基于事件的 MMI 生命周期 API 共享数据，因此它们是 “松散耦合” 的。标记语言并不硬性要求用户交互，而且交互可以基于 Java、C#、C++ 或其他编程语言。

图 1. Multimodal Architecture
W3C Multimodal Architecture 的示意图

回页首

生命周期事件 API

在通道组件和运行时框架间发送的事件如下：

NewContextRequest: 此可选事件由通道组件向运行时框架发送来请求新的上下文。运行时框架用 NewContextResponse 事件加以响应。
Prepare: 此可选事件由运行时框架通道组件发送以便该组件可以在准备被 start 调用时预先加载资源。通道组件用 PrepareResponse 事件加以响应。
Start: 当运行时框架调用一个通道组件时，该组件用 StartResponse 事件加以响应。
Done: 当通道组件完成处理时，向运行时框架发送此事件。
Cancel: 当运行时框架取消对通道组件的处理时，该组件用 CancelResponse 事件加以响应。
Pause: 当运行时框架暂停对通道组件的处理时，该组件用 PauseResponse 事件加以响应。
Resume: 当运行时框架恢复对通道组件的处理时，该组件用 ResumeResponse 事件加以响应。
Data: 运行时框架或通道组件均可向对方发送数据。此事件是所有内模式式通信的接口，比如用交互管理器作为调节器来同步聚焦。
ClearContext: 运行时框架使用 ClearContext 事件清除与通道组件共享的上下文。
StatusRequest: 运行时框架或通道组件均可请求对方的当前状态。发送 StatusResponse 事件来响应此类请求。

由于响应必须以非常迅速的方式被接收，因此传递 MMI 生命周期事件的网络协议必须可靠和私有，必须保证传递的顺序正确，且具有验证了的端点。

回页首

该架构的起源

W3C Multimodal Architecture 最初源自 Galaxy Communicator 和 Model-View-Controller (MVC) 架构模式。Galaxy Communicator 是一个开源项目，由 US Defense Advanced Research Projects Agency (DARPA) 发起。它是一个分布式的集中星型（hub-and-spokes）架构，在这个架构中，进行文本到语音的处理、执行语音识别或管理对话的服务器都在分支端。服务器间发送的消息通过中心 hub 进行路由，中心 hub 管理所有的数据和通信。

MVC 设计模式则为人熟知，它将应用程序分为三个部分：模型、视图和控制器。总的来说，这种架构中的模型负责封装数据和数据访问方法；视图是用户界面；控制器 处理来自用户界面的事件。控制器对应事件更新模型，而视图则对应模型中的更改被更新。

W3C Multimodal Architecture 与 Galaxy Communicator 类似，Communicator 的 hub 可对应于 Multimodal Architecture 的运行时框架。类似的，Communicator 的服务器可对应于 Multimodal Architecture 的通道、交付上下文和数据组件。Multimodal Architecture 又与 MVC 模式也非常相似，其交互管理器就相当于是控制器；数据组件和交付上下文可组成模型；通道组件则可视为视图。

通信和事件处理

基于这两种架构，W3C Multimodal Architecture 的运行时框架既可以充当通信 hub，又可作为事件处理器。通道组件必须将所有事件和数据发送到框架以进行处理并及时准确地路由到其他组件。图 2 显示了交互管理器充当 MVC 架构中的处理器的情形。当用户单击了 Submit 按钮后，提交的数据就会发送到交互管理器 (1)。交互管理器将数据提交到 Web 浏览器 (2)。Web 服务器对交互管理器的响应被处理 (3)。数据模型被更新，更新后的数据被同时发送给 HTML 和语音通道组件 (4)。最后，语言组件发送音频数据到客户端设备并作为 TTS（text-to-speech）呈现出来 (5)。

图 2. 交互管理器处理全部的数据事务
交互管理器可视为是一个控制器和 hub

在 Multimodal Architecture 的任何实现中，与其他通道组件相关的事件和数据应该被直接发送到交互管理器，包括提交给 Web 服务器的表单。MMI Working Group 在 2006 年 12 月 11 日版本的 Multimodal Architecture and Interfaces 工作草案中作过如下解释：

一种很好的应用程序设计实践是将数据在逻辑上划分成两类：一类是私有数据，只影响给定的通道组件；一类是公共数据，可影响交互管理器或多个通道组件。若合适，私有数据可以由通道组件管理，但对公共数据的所有修改，包括到后端服务器的提交，都必须委托给交互管理器。

跨多个设备分布

Multimodal Architecture 的另一个有趣特性是它允许应用程序在多个设备间同时共享。此特性由多通道组件的 “Russian doll” 配置使然，该配置允许运行时框架与另一个运行时框架通信，就像后者是一个多通道组件一样。

应用程序要想覆盖多种设备，首先要让这些设备能启动此应用程序，然后再允许同样的公共数据能在所有数据模型间共享。也就是说，在一个设备上运行的应用程序必须能向所有其他的设备广播。这类应用程序的一个例子是共享日历程序，它可协助几个用户找到合适的日期和时间来安排一次会议。图 3 显示了根据 Russian doll 配置，一个应用程序该如何在两个设备间共享。

图 3. 多个设备可同时共享相同的应用程序

回页首

Multimodal Architecture 的欠缺

Multimodal Architecture 一个非常重要的方面是每个通道组件都运行其自身的标记语言文档。其结果是，当通道组件驻留于相同的客户机时，客户机必须要在应用程序的生命周期内一次或多次地下载和分发多个文档。如下的两个图显示了这种做法为何不实际。

图 4 所示的配置中，交互管理器和数据模型驻留在远端服务器，而 XHTML 和语音通道组件皆存在于客户机。在这个例子中，相同的 Web 服务器向其各自的组件提供 XHTML 以及 VoiceXML 文档。XHTML 组件获取应用程序的第一个页面 (1) 并向服务器发送 NewContextRequest (2) 以开启具有新的上下文的交互管理器的一个实例。交互管理器运行新的 SCXML 文档，并且若受 SCXML 指导，还会向语音组件发送 Start 事件 (3)。Start 事件可以包含要运行的 VoiceXML 文档；否则，语音组件必须单独获取文档 (4)。

图 4. 客户组件分别连接至服务器

因为所有到由每个通道组件运行的文档的访问均通过交互管理器，所以由单个通道组件接收到的所有数据，包括 cookies 和其他的头信息，都必须被路由至交互管理器和路由回此客户机。当两个通道组件都在相同的进程中运行时，这没有任何意义。获取缓存了的文档也必须通过网络进行协调。例如，每次当用户单击 Back 按钮时，客户机都必须向远端交互管理器发送请求以从每个通道组件获取之前的文档。

另一个性能瓶颈

图 5 所示的配置中，交互管理器、数据模型、XHTML 以及语音通道组件都存在于相同的设备。在这里，运行时框架全部包含在客户机上。在 XHTML 组件获取了多通道应用程序的第一个 XHTML 页时，它就会调用本地交互管理器的 NewContextRequest API (1)。运行时框架随后获取 SCXML 文档 (2) 并调用交互管理器。交互管理器然后运行文档，若受 SCXML 指导，还会调用语音组件的 Start 事件。Start 调用包含要运行的 VoiceXML 文档，否则，语音组件必须单独获取文档 (5)。

图 5. 通过 IM 连接至服务器的客户组件

这种配置仍然存在性能方面的问题。只有当 XHTML 组件已获取并解析了应用程序的第一页、SCXML 文档已被获取并正常运行、VoiceXML 文档已被获取并正常运行之后，文本到语音的提示才会被显示给用户。由于网络通常总会成为性能瓶颈，因此用户将会体会到存在于看到 XTML 页和听到文本变语音之间的明显的（因此不可接受的）延时。若 SCXML 可被嵌入到 XHTML 文档内，这种延时将会有所减轻。SCXML 然后会通过 NewContextRequest API 调用传递给交互管理器（注意，上述场景只为了举例说明之用：不管是 XHTML 还是语音组件，均不能检索首页）。

认识到上述问题，我希望 W3C 将会致力于标准化 XML 形式的不同通道能被合并到单一文档的方式。这对于将上述本地通道组件的配置变得具有实际意义十分必要。

回页首

MMI Working Group 所面临的其他问题

除了性能问题之外，W3C Multimodal Architecture 还面对其他一些挑战和问题，这些问题有的有可能会在 Multimodal Architecture and Interfaces 规范的未来版本中解决。接下来，我将总结一下 MMI Working Group 所面临的一些主要困难。

另一个 Web 重构？: 传统应用程序若要利用 Multimodal Architecture，所有的通信，包括到 Web 服务器的表单提交，都必须用到交互管理器的 Data 事件替代。提交可以从 Web 服务器转给交互管理器，但这样做岂不是使 Web 服务器变成了另一个通道组件？对于 Ajax (Asynchronous JavaScript and XML)，随之而来的问题是 XMLHTTPRequest 对象必须包含 Data 事件以便交互管理器能为所有通道组件获取动态 XML 数据。
多通道组件功能？: 如果应用程序需要语音组件能够理解法语（比如说），它如何能够查询组件的功能来确定它的确如此呢？如果信息存储在设备的上下文组件内，应用程序又如何访问这些信息呢？要解决这个问题，就需要到设备上下文的接口。
一般的数据？: 一般的 Data 事件是惟一一个可用来标记作者的接口；Multimodal Architecture　内的其他生命周期事件大都将通道组件的各种操作（例如开始、停止、暂停等）视为软件的组成部分。不幸的是，Data 事件不具有端到端的互操作性，除非作者随处可知数据接收后如何格式化以及数据又是如何格式化以便发送的。而且，任何一个组件都可以随时对数据格式进行任意更改！

对于客户机，接收到的 Data 事件的内容必须映射到在此客户机上实例化的事件和数据字段（例如针对 XHTML 客户机的 DOM，即 Document Object Model）。这需要一种脚本语言，例如 JavaScript，来检查和处理 Data 内容。
一般的黑盒？: 通道组件是一些黑盒，这样一来，其中包含的数据才能得以封装。然而，除了数据封装之外，还必须有一种 API 能够代表与私有数据相关的行为。这是因为所有行为只能通过 API 访问。不幸的是，Data 事件 API 代表的是一种中间行为；后续的 Data 调用可以更新一小部分数据或由组件维护的整个数据模型。

问题是 W3C Multimodal Working Group 只想支持多种多通道组件，其中的一些组件可能会没有 XML 语言接口或者 DOM。由于不能标准化何种数据可以由通道组件封装，此工作组也就不能指定相关的行为。其结果是应用程序开发人员将不得不自己处理数据格式问题。
多通道标记？: 在 XHTML 组件可以向交互管理器发送 NewContextRequest 事件之前，它必须先在 XHTML 页面简要说明。W3C Multimodal Interaction Working Group 可负责标准化 NewContextRequest 说明的方式以及 SCXML 标记将如何嵌入到 XHTML 内的方式。标记作者也需要知道如何向交互管理器发送事件，以及如何侦听和处理由交互管理器发来的消息。
多通道协议？: Multimodal Architecture 所预想的多通道生命周期事件可从 Web 浏览器通过 HTTP 或 Ajax XMLHttpRequest 对象发送，而且一些应用程序还能在 SIP 堆栈可用时，发送和接收事件。然而，现在的 Web 浏览器都不支持由交互管理器 “推出” 的异步消息的接收。为此，我们需要一种多通道协议，但这种协议现在还尚不存在，不过已经有几个候选方案被提交给了 IETF（参见参考资料）。

回页首

结束语

W3C Multimodal Architecture 是一种分布式架构，定义了运行时框架、生命周期 API 和许多松散耦合的多通道组件。本文展示了此架构主要用于服务器端的交互管理，其中，多通道组件跨多个客户机和服务器分布。本文还给出了 MMI Working Group 所面临的一些挑战并简要解释了这些挑战将如何影响开发人员在构建 Web 应用程序时对是否采用此架构的取舍。

在下一篇文章中，我将讨论可解决其中一些挑战和问题的 XML 标记语言。例如，其中一种规范（2003 年更新的 W3C 的一个工作草案）就提议将一组基于意图的事件添加到多通道生命周期 API。SCXML（有望成为一种 W3C 建议）则是 Multimodal Architecture 和下一代 VoiceXML（即 V3）的中心。它还有可能对服务器端的 Web 应用程序开发产生举足轻重的影响。在本系列的第 2 部分中，我将探讨包括这两种语言的潜在影响在内的诸多内容。

参考资料

学习