Web Services Experience Language

Web Services Experience Language

Angel Diaz（aldiaz@us.ibm.com），IBM Research

John Lucassen（lucassen@us.ibm.com），Emerging Technologies，Application and Integration Middleware Division

Charles F Wiecha（wiecha@us.ibm.com），IBM Research

2001 年 10 月

WSXL（Web Services Experience Language）是交互式 Web 应用程序的组件模型，它是以 Web 服务为中心的。WSXL 的设计是为了达到两个主要目标：使企业能通过多种获利渠道分发 Web 应用程序，并可以通过利用 Web 上现有的应用程序创建新的服务或应用程序。

为了达到这些目标，WSXL 组件可以用三个基本的 Web 数据、表示和控制类型构成，其中最后一个使用基于 XLink 和 XML Events 的声明式语言与其它的内容“交织起来”。WSXL 还引入了一种新的描述语言以使服务与新的分发渠道相适应。WSXL 建立在广泛接受的已确立的但却是新兴的开放式标准之上，其设计要达到独立于执行平台、浏览器和表示标记的目的。

可以通过多种部署渠道把使用 WSXL 开发的交互式 Web 应用程序发送给最终用户：直接发送到浏览器、通过门户网站间接发送或者通过把其嵌入第三方 Web 应用程序。可以通过无缝结合 WSXL 应用程序并使之适合于新用户来创建新的 Web 应用程序。WSXL 应用程序通过简单的声明方式易于修改、调整、聚集、协调、同步或集成以最终利用世界范围内的 WSXL 组件调色板。

1 介绍

1.1 商业环境

在当今商业环境下，公司面对的大量的无情的市场压力不断增加。要成功，他们需要将支持其业务过程的应用程序快速经济的上市。他们需要把他们的业务过程分解成为核心的功能，以便能够发布各种广泛的不断成熟的服务并改变这些服务以响应不断变化的市场情况。他们需要利用种类越来越多的在线分发模型 － 包括直接和多分发渠道以得到多样的顾客。

随着企业试图确保其因特网投资能导致收入增加，他们经常设法优化多个分发渠道范围内的投资。例如，在 Web 上销售“旅行支票”（Traveler Check）的公司通过使用多种业务伙伴分发渠道将会使其 Web 应用程序（因而也就是他们的产品）在一系列范围更广的潜在顾客面前更多的出现。这样做，应用程序供应商也许需要修改或放弃对，如果不是全部的话，一些分发者的品牌关系及导航控制。经济的建立这样的再分配关系并以一种可以灵活适应使用不同业务模型的多个业务伙伴的需要的方式来维护它，这是技术上的难题。

通过扩展分发渠道的多样性经济的增加销售的难题并不限于物质产品和服务的生产者：信息或虚拟产品和服务的生产者面临着许多同样的问题。例如，许多“独立软件供应商”（Independent Software Vendors（ISV））正通过利用使用费的 Web 服务方式设法增加其现有压缩薄膜包装的软件的销售。这样的方式要求包括 B2B 和 B2C 在内的许多不同的应用程序可以重用同一代码。

以金融可视化软件供应商为例。为了给多种新的收入机会提供支持，供应商可能需要支持来自客户的直接访问（B2C）、增值分销商的再分发以及业务伙伴的 OEM。如果单独考虑这些方式，它们每一种在目前显然是可行的。然而，供应商评估分发渠道扩展时主要权衡的关键因素就是上市时间与进入成本。对于软件分发者和供应商来说，允许以一种开发与支持要求最小化的通用格式来表达软件的技术是关键的商业启动因素。倘若该技术灵活并简单易用，则这样的技术既可以缩短上市时间又可以节约进入成本，从而 ISV 得到大量新机遇而分发者和最终顾客将大大节约成本并从上市时间上获得较大收益。

最后，正如我们在 WSXL 目标中所说，企业也希望能够通过创建新的应用程序资产经济的利用现有的本地与远程组件来创造新产品和服务收入流。这些新的应用程序给传统行业与网络时代的公司都带来了机遇。以考虑希望成为“旅行支票”的增值分销商的银行的情况为例。银行设法控制同客户之间的关系并希望为其客户群体提供独一无二的和专门的功能，同时使其能最大程度的发挥逐日浮动对货币资产的杠杆作用的能力。既然使用信用卡支付工具通常使“旅行支票”应用程序在 Web 上可用，那么如果银行可以修改服务，允许在成员帐户中借记支付又会怎样呢？在“旅行支票”供应商的角度看来，这会提供一种额外的分发渠道。在银行的角度看来，这样的解决方案将会为客户提供一站式服务的便利，还会允许银行增加延期交易的利息 － 比如，使用现有的机构支付工具，如 ACH。

1.21.2 动态 Web 应用程序需求

企业需要新的方式开发并交付应用程序以协助降低开发交互式 Web 应用程序、把它们交付给用户以及在应用程序生命周期内根据由新的业务模型施加的不断变化的需求对应用程序进行调整的成本。

这些新方式必须使企业能：

获得有效的用户体验，其特点是极具吸引力、高效、在每个交付渠道内正确的印上商标。

维护业务灵活性 — 尤其是能快速添加新的分发伙伴以及应用程序内容供应商及联合（和伙伴合作）和单独（即，不依赖于伙伴）更改与更新应用程序的灵活性。

利用现有的技巧和基础设施。

而且，新方式需支持：

方便更改：实现新而且快速发展的商业模型，如交叉销售、合作提供以及外包。

方便调整：通过新渠道传递应用程序，如门户网站或第三方 Web 站点。

方便聚集：把几个应用程序组成单个的用户体验，如门户网站。

方便集成：通过紧密集成几个 Web 应用程序的元素来创建新的表示。

1.3 WSXL 以及现有技术

目前，种种不同的产品概念、体系及技术可以处理前面一节所描述的企业问题。WSXL 可以作为桥梁把这些不同种类的应用程序开发与部署机制统一起来。尤其是把 WSXL 设计成能：

促进类似于门户网站的产品间的互操作。

促进辛迪加式应用程序之间的互操作性。

独立于标记，且主要是方便应用程序更改、调整、聚集以及集成。

1.3.1 基于直接 Web 服务的应用程序

直接 Web 应用程序把最终用户直接同 Web 经历供应商相连接的应用程序，而且在现在的 Web 中是最普遍的情形。迄今为止，已有许多组织利用一般的可用技术，如 Java Server Page 和 Servlet 创建了直接应用程序。WSXL 通过利用功能强大的设计模式，如 XFORMS，扩展这些熟悉的技术，并结合迅速出现的 Web 服务体系结构支持直接应用程序开发达到方便更改、调整和集成的目的。

1.3.2 门户网站中间件产品

门户网站中间件产品使交互式 Web 应用程序可以被聚集成单次用户体验，还可以提供诸如单次登录、个性化之类额外功能。门户中间件产品典型情况下支持“肩并肩”表示：屏幕上被聚集的每个应用程序都指定了自己的矩形区域。在用户的角度看来，许多任务要求使用不只一个应用程序。但多数门户网站聚集者通过把一些现有的用户体验的相关部分紧密的集成在一起，从而创建新的用户体验增值的能力非常有限。而且，每个门户网站都有自己的特别组件接口，这使应用程序同门户网站之间的互操作几乎不可能。WSXL 的设计要达到促进门户网站间的互操作，为门户网站提供增长路径的目的，为此，还设计了为从简单的“肩并肩”表示到“应用程序的紧密集成”与“层叠门户网站”范围内的不同聚集模型提供支持。

1.3.3 应用程序辛迪加产品

应用程序辛迪加产品使交互式 Web 应用程序能为通过不同的交付渠道部署而进行调整。 典型情况下，应用程序辛迪加产品支持应用程序的“外观及感觉”的调整以满足分发渠道的加商标的要求， 并把应用程序直接传递给浏览器。同门户网站中间件产品一样，典型情况下，应用程序辛迪加产品只对“肩并肩”表示提供支持。尽管该模式具有简洁的优点，但它却使供应商和聚集者无法充分利用由于组合它们的应用程序以及集成它们的业务模型而获得的潜在的共同作用。比如，聚集者的应用程序常不知道发送给用户的页面内容，而且典型情况下也不能改变这一内容或其行为。而且，为辛迪加打包的应用程序典型情况下同任何门户网站组件模型不可互操作，这使得必须对为辛迪加设计的应用程序进行不必要的再次开发，虽然有多种渠道。设计 WSXL 是为了促进辛迪加式应用程序同门户网站之间的互操作，从而降低创建新的业务关系的成本，以及使调整某一特定传送渠道的应用程序变得容易，从而使聚集者能使其分发的应用程序增值。

总结 － WSXL 旨在提供互操作性标准为门户网站、辛迪加及 Web 服务中间件创建和扩展新的商机。作为应用程序服务器的标准组件或现有的中间件产品的标准扩展，WSXL 运行时（WSXL Runtime）将协助启用应用程序组件和 Web 表示服务的新市场。

1.4 “Web 服务体验语言”示例

在随后的示例中，我们将演示如何把 WSXL 用于使 Web 应用程序辛迪加和重用变得容易。在企业的角度看来，这些方案着重于两个因 Web 应用程序标准组件模型才使其成为可能的新商机。

1.4.1 辛迪加式购买“旅行支票”

对于辛迪加的情况，WSXL 可以协助使供应商能够使用现有的软件资产扩展其分发渠道。如图 1 中所述，供应商可以描述包装现有的后端功能的 WSXL 应用程序。然后如果想的话，就可以对应用程序进行调整，并把其用于为直接客户访问服务或嵌在由业务伙伴重新分配的远程应用程序中。在后者的情况下，分发者能通过在需要的时候调整应用程序的外观、感觉、内容、流及功能，从而使其客户群体对应用程序建立起品牌为中心的观念。除为表示的目的用 WSXL 实现应用程序辛迪加之外，供应商的应用程序还可以直接控制由浏览器上的交互引发的事件。与目前可用的许多可选方式不同，本方案中使用 WSXL 使供应商能在进入成本同上市时间之间做出平衡的决定。对广泛采用的开放式规范的依赖将使供应商不会开发（或购买）以及维护那些其多样性比不上 WSXL 应用程序的用法模型的解决方案。

图 1：辛迪加式购买“旅行支票”

1.4.2 分布式可视化服务（远程门户）

同样地，金融图表实用程序服务的供应商利用我们在图 2 中所述方案启用这些服务的重新分配。在这种情况下，门户网站公司可以利用有商标的数据输入格式来增加实用程序服务。这一方式将能以较低的进入成本快速增长门户网站服务目录。

图 2：分布式可视化服务（远程门户）

1.4.3 分布式可视化服务（本地门户）

建立在前面的方案的基础之上，图 3 演示门户网站供应商也可以 OEM 他们的门户产品，该产品含对金融图表工具的访问。在这种情况下，应用程序供应链中的两级分发者可以从同一软件服务端点中获得收益。首先我们有门户网站产品供应商，他也可以是增值销售中介公司安装的产品的分销商。这种供应商在其产品功能目录中合并了访问金融图表工具的功能。通过同服务供应商达成收入分摊的协议，门户网站供应商可以获取对产品销售的收入，也可以对每次交易提成。相反的，中介公司也能从为那些不存在业务往来提供远程服务能力中受益。此外，对于任何 ASP 模型中介公司还可以向客户收取远程服务访问费。在任一情况下，中介公司和门户网站供应商都能针对市场需要把现有的远程服务访问重新分配来处理时间。

图 3：分布式可视化服务（本地门户）

1.4.4 “旅行支票”增值分销

我们的最后一个方案在图 4 中说明，提出使用 WSXL 如何来创建新的收入生成应用。在这种情况下，应用程序域表示售出“旅行支票”。但是，由于银行通过新的支付工具，具体是记入借方，试图增加其业务伙伴（“旅行支票供应商”（Traveler Cheque Supplier））现有的应用资产，所以银行在这种情况下是增值的分销商。为了达到这一目标，银行得通过把其业务伙伴的远程应用同本地可用的一个处理银行会员帐户的借方交易的应用集成在一起创建一个含银行独有的表示层的新应用。通过利用用于 B2B 和 A2A 集成的 Web 服务（SOAP、WSDL），WSXL 提供了一种声明式语言，这种语言允许服务接口集合可被归组成可重用组件，这些组件生成工作的离散单元。现在，我们可以公正的假定要使这一方案确实起作用，“旅行支票供应商”将不得不提供考虑到支票购买是被带外（out of band）捕获并结算的新的服务操作。然而， WSXL 提供了一种使之成为可能的技术来以一种及时的和成本高效的方式来达到业务目标。

图 4：“旅行支票”增值分销

1.5 Web 应用标准创立

旨在给下一代的 Web 应用程序及相应的商业模型提供便利的标准倡议必须满足几个成员的需要：Web 应用程序运行时供应商、Web 应用程序开发人员、工具供应商、IT专业人土、商业专业人土以及终端用户。所有这些成员都要求 Web 应用程序模型能：

方便不同传递渠道间的互操作。特别的，应用程序一定不能利用特殊的运行时模型，但必须易于实现通过不同渠道传递的部署。

支持对 Web 应用程序的调整。基于 Web 应用程序的标准必须易于为辛迪加或其它的定制“加上商标”。

允许无需或最少量的编程把 Web 应用程序集成为更大的用户体验。

为 Web 应用程序之间紧密而又完全的可定制集成作准备从而得到无缝的用户体验。

易于更改或修改。例如，商业专业人士必须能迅速部署及测试新的商业模型。

自然，必须通过重用现有的事实工业标准达到这些目标。特别的，任一 Web 应用程序标准的基础都必须由基于 XML 的标准，如 XPath、XML Event、DOM、XForms 和 XLink 以及 Web Service 标准，如 SOAP、WSDL 和 WSFL 构成。我们认为基于 Web 服务的 Web 应用程序功能和声明规范的结合将确保广泛成员范围的广泛认可。

2 WSXL

WSXL 采用的为满足上述要求的这个方式是为了允许 Web 应用导出一个或多个组件接口，这些接口在允许应用发展的同时公开足够的信息以启用适应调整、聚集和集成。WSXL 还使开发者能利用独立的表示、数据与控制组件构建应用程序；这有助于开发者把那些如果混杂在更多的庞大对象中将会使集成以便在多个渠道内重新使用更加困难的设计问题分离出来。为了确保适合现有的基于 Web 的应用结构，WSXL 服务生成可以被传统浏览器和设备通过现有的格式和协议所使用的标记。把更广阔的用户、渠道和任务市场作为目标要求有比目前 Web 应用程序所支持的多得多的变异。WSXL 通过启用多种多样组件的应用集合从而降低产生同一应用程序多种变异的成本。这还允许应用程序及其组件简单的开始并以企业驱动的方式来优化。

2.1 WSXL 框架介绍

本节介绍 Web 应用程序的 WSXL 组件框架（基于众所周知的模型-视图-控制器体系）并把它同现有的标准，如 XFORMS 和 XLINK 相联系。我们还举一个如何重用数据、表示和控制组件以通过集成产生新的 Web 应用程序而无需从头开始编程的简单示例。下面几节描述数据、表示、控制及其容器提供的接口，并详细介绍如何实现上面的方案。

WSXL 应用程序由一个或多个数据及表示组件，以及一个把组件绑定在一起并指定其相互关联的行为的控制器组件构成。

WSXL 基本组件具有生命周期管理、事件处理及生成输出标记的接口。生命周期操作可用于显式创建与破坏 WSXL 基本组件的实例。WSXL 基本组件可以定义它可能引发的 XML 事件，也可以定义它可以响应的 XML 事件。WSXL 基本组件可以应请求以一种或多种目标 XML 语言生成输出标记。“调整描述”（Adaptation Description）可能会牵涉到 WSXL 基本组件，它描述如何根据新的渠道调整组件生成的标记。

WSXL 数据组件这一组件是对基本组件的扩展，封装了 DOM 可访问的实例数据以及任意有关的模型定义的表示。WSXL 数据组件基于 W3C XFORMS（请参阅 http://www.w3c.org/tr/xforms）的模型与实例功能。可以使用 WSXL 控制组件把数据组件绑定到表示组件。此外，还可以把数据组件连接到 WSXL 应用程序外部的数据源，但这是超出 WSXL 范围的实现细节。

WSXL 表示组件这一组件是对基本组件的扩展，封装 DOM 可访问的在用户界面“页面”内的元素的表示。虽然表示组件所用的元素的名称空间不是由 WSXL 规定的，但是通常有用的“小控件”的集合 是可用的，如 XFORMS UI 草案中所定义的。可以使用 WSXL 控制组件把 WSXL 表示组件绑定到数据组件，而且必须引发并响应由该组件定义以更新并复位相关数据值及更新表示的事件。

WSXL 控制组件是对基本组件的扩展，管理实例化数据与表示组件之间微控制以把它们绑定在一起。这决定了在对每个方向进行更新的过程中何时调用事件处理程序来解析并再次格式化数据值。WSXL 控制组件阅读以基于 XLINK 的可扩展控制语言规范撰写的声明来建立要求的 arc 并实现开始、排序和更新的处理模型来同步表示和数据状态。控制组件的另一功能是管理涉及在用户从头至尾使用应用程序时对全新数据和表示组件的实例化的宏控制。这方面的控制可以通过状态机标记法或使用可扩展的工作流语言接口的工作流语言来指定。

把 Web 应用分解成独立的数据、表示和控制组件的目的是为了给这些组件重新装配多个替代版本的组件提供便利以满足如上面的介绍要求一节中所扼要叙述的分离渠道、用户和任务的要求。因此，WSXL 将提供 Web 开发者利用由独立的供应者单独提供的数据、表示和控制来装配应用程序的能力支持。

把整体设计分解成一个基本组件和该基本组件的扩展的主要原因是要方便WSXL 与 Web 服务的其它中心表示组件模型之间的合并。

WSXL 接口可以使用“Web 服务描述语言”（Web Service Description Language（WSDL））来描述。WSDL 考虑到了组件接口内的类型、消息及操作的定义应不依赖于语言。WSDL 把这些接口特性（服务的 portType）同 portType 和特殊的传送机制的绑定分离开来。许多 Web 服务是使用 SOAP 消息通过网络远程访问的。在其它一些情况下，可以本地执行组件而且它使用性能更高级的“传送”，如直接方法调用。 我们旨在使对本文档中的 WSDL 定义的与是远程访问还是本地访问所描述的 WSXL 组件无关的被解释。

可以使用本文档中所描述的“调整描述语言”（Adaptation Description Language）来表达 WXSL“调整描述”。我们把“调整描述语言”从“Web 服务描述语言”中分离出来的目的是为了允许组件接口同某个“调整描述”选择关联。

2.2 组件描述

本节我们描述由 WSXL 基本组件提供的接口。接着，我们将展示三类特别组件（数据、表示及控制）是如何由基本组件接口派生而来的。在后面一节中，我们将讨论如何利用组件组来构建应用程序。WSXL 容器（Container）可用于管理一组组件。通过进一步实现组的 WSXL 组件（Component）接口，其变得可以作为一级组件本身重用。

2.2.1 基本组件

概要

WSXL 中的基本组件指定了对所有 WSXL 组件都通用的接口：生命周期管理、事件处理、输出标记的生成，还有描述如何根据新的渠道调整组件生成的标记的概念“调整描述”。包括数据、表示和控制在内的其它 WSXL 组件实现这些基接口以及其功能要求的特别接口。

基本组件接口

WSXL 基本组件（WSXL Base Component）特定的接口类别如图 5 中所示，其内容包括：

生命周期：组件的生命周期接口提供可以由实现其生命周期的容器调用的操作。虽然一般情况下，可能会要求有多个生命周期 — 以支持依容器管理的组件类型不同而提出的不同要求，但最初 WSXL 生命周期操作将包括那些创建及销毁组件实例的操作。

事件：WSXL 组件必须实现 DOM Level 2 EventTarget 接口。XML 事件规范将用于描述事件侦听器。

OutputMarkup：生成输出标记，典型情况下是在更新／刷新周期的结束。返回实例数据文档的 XML 表达。

图 5：WSXL 基本组件和接口

当然不要求公共接口中定义的数据、表示和控制结构同组件的实现在内部支持的数据、表示和控制结构相同。在许多情况下，如果现有的实现是由 WSXL 兼容组件包装的，组件开发者将采用非 DOM 的实现。

一般情况下，组件可能只对外公开一部分设计 — 通过使用接口规范，此接口规范反映旨在受控的扩展或集成而非全部底层的实现的受限的组件结构和行为。

2.2.2 数据组件

概要

除上述 WSXL 基本组件接口外，WSXL 数据组件还实现用于描述和维护 WSXL 应用程序中可由 DOM 访问的数据实例的接口。WSXL 数据组件基于 XFORMS 的数据功能并包括 XFORMS 模型与实例功能。

数据组件接口

WSXL 数据组件接口的其它类别如图 6 中所示，其内容包括：

访问（Access）：WSXL 数据组件用 DOM Level 2 接口的一个子集描述了它希望公开的结构。WSXL 要求 DOM Level 2 的特定操作还未确定。组件至少必须支持对其 DOM 的读写。

更新控制（UpdateControl）：用于标识更新组的开头与结尾。由容器决定是否使用该接口。缺省行为是同每一次更新同步引发更改通知事件。
确认（Validation）：用于触发对数据实例及其模型间的类型约束的评估。

再次计算（Recompute）：用于触发对数据在别处更新引起的副作用进行评估。结果是调用数据组件内部实现中的任何处理程序，也就是说，不会把其当作外部控制链接（参见下面的控制组件）的评估结果来进行评估的处理程序。

数据可用性（DataAvailability）：用于标志组件实例数据的可用性。虽然组件同外部数据的连接方式本身没有标准化，但与该数据连接有关的状态，比如断开连接，可以是请求数据、不完全数据和可用数据。

图 6：WSXL 数据组件与接口

注

WSXL 容器定义一个处理模型对受其管理的组件应用执行更新并管理刷新对容器中其它同 WSXL 控制组件绑定在一起的组件的更新所需步骤。使用控制组件定义实现容器内组件的更新的特定的事件处理程序。

我们如何实现与错误、输入、缺省以及有效这样的数据的关联呢？这如何同 XML 处理模型而不仅仅是 XFORMS 处理模型连接 — 这如何同 WSFL 连接？

同在同一 WSXL 容器内与之关联的数据组件分在一组的 WSXL 控制组件上或把数据直接链接到表示的控制组件上是否应有 XFORMS 元数据以及相关的和必须的属性，这是一个开放式的议题。我们宁可把独立的控制组件同数据链接，是因为如果我们给把表示同模型链接的 arc 添加模型约束，我们将不得不把这些约束复制到每个我们要把其同数据绑定的表示组件。

组件开端集 — Web 服务的简单包装器，允许声明创建 WSXL 数据组件；聚集数据组件的简单容器。工具会以可视编辑器中的拖动／放开隐喻公开。

2.2.3 表示组件

概要

除上述 WSXL 基本组件接口外，WSXL 表示组件还实现用于描述和维护 WSXL 应用程序中可由 DOM 访问的表示实例的接口。WSXL 表示组件基于 XFORMS 中的 UI 规范，且包括 XFORMS 表示实例及模板功能。

WSXL 表示不指定任何特殊的小控件集。WSXL 表示组件可以由任意名称空间中的元素组成，还可以生成以任何目标 XML 语言表示的类似的输出标记。WSXL 的一个目标是成为基本设施支持可能在业界出现的特殊的 XML 用户界面小控件集，包 括 XFORMS、XUL、UIML 等中的那些。

表示组件接口

除基本组件接口之外，WSXL 表示组件接口的额外分类如图 7 中所示，其内容包括：

访问（Access）：WSXL 表示组件用 DOM Level 2 接口的一个子集描述了它希望公开的结构。WSXL 要求 DOM Level 2 的特定操作还未确定。组件至少必须支持读写 DOM 上的属性。

交互（Interaction）：用于表明最终用户同表示组件中的元素交互的状态，如聚焦、选择、激活、执行、隐藏／公开。利用及扩展 DOM Level 2 事件模型中抽象的 UI 事件。物理事件，如鼠标，对于服务端组件重要性可能要差一点。 要求有键盘事件。

图 7：WSXL 表示组件与接口

2.2.4 控制组件

概要

如图 8 中所示，WSXL 控制组件是基于 WSXL 的组件，比如数据与表示组件的扩展。除基 WSXL 组件接口之外，WSXL 控制组件实现一些接口用于管理绑定数据组件到表示组件的 arc，解析并解释下面描述的基于 XLINK 的控制语言规范以及实现控制事件通知在数据和表示之间双向传播的处理模型。

图 8：WSXL 控制组件与接口

基本控制模型在图 9 中说明。或者对其 arc 管理接口调用作出响应，或者间接通过解析并解释控制语言规范，控制组件可以在数据与表示之间建立 arc。每个 arc 都包括一个对象，它是一个侦听器，侦听数据组件上的一个给定元素及表示组件上的另一个元素。数据和表示组件相互之间并不直接连接。控制组件建立 arc 并在运行时维护自身以管理每个方向上的事件通知的排序与定时。

图 9：绑定于 WSXL 数据和表示组件的 WSXL 控制组件

事件处理程序可以同 arc 相关联提供通过响应事件通知触发的控制逻辑。该中间组件，或“微观级”控制逻辑可以（1）修改数据和／或表示组件的值或结构；（2）调用外部服务；（3）同全局组件或“宏观级”控制交互以触发应用程序中后续步骤需要的对额外的 WSXL 组件的初始化。

注意到微观控制逻辑和宏观控制逻辑都是由在单一类别的 WSXL 控制组件建立并管理的 arc 上引发的事件触发，这是重要的。它们之间的区别恰恰类似于事件处理程序使 arc 产生的变化。事件处理程序在已经实例化并绑定的数据和表示组件内进行更改，它牵涉到的只有微控制逻辑。对新 WSXL 数据和表示组件进行实例化及绑定或销毁现有的 WSXL 数据和表示组件并返回到应用程序开始的步骤的那些事件处理程序牵涉到宏控制逻辑。我们期待宏逻辑在通常情况下可以通过使用由 WSXL 控制组件上的事件处理程序调用的流语言（如WSFL）规范来实现。

控制组件接口

除基本组件接口之外，WSXL 控制组件接口的额外类别如图 8 所示，其内容包括：

arc 定义与管理：用于通过提供源和目的服务实例、这些实例内的 XPATH 定位器以及与 arc 有关的事件处理程序来创建新的 arc。该接口支持对 arc 进行枚举、更改、删除与创建动作的操作。该接口可以被直接调用，或通过下面描述的控制规范语言。相关的 arc 的标准包括 XFORMS、XLINK 及 XML 事件。

控制规范解析：用于解析基于 XLINK 的控制规范文件和使用上面的接口创建 arc。该接口支持以声明方式定义控制组件行为，无需直接驱动底层编程接口。

更新处理模型：用于维护“脏”链接列表、排序更新与更新组列表、根据绑定语言设定的策略应用更新（sync，async）以及启动 arc 上的事件处理程序。

注

对多处理模型有哪些要求呢？portlet、XFORMS、批处理还是多态？一般情况下，应用程序作者是会定义新的处理模型呢？还是对此进行修正呢？也许为了实现又懒又贪的刷新？

XFORMS 的确指定了 sync 应当何时发生，还定义了允许的最长延迟时间。检查点。

更新组要求控制组件功能呢？还是用数据或表示组件就可以实现更新组呢？更新组确实更符合上面的 UpdateControl 概念。因此要求 Control 组件内有一个 API 以支持批更新。

控制规范可绑定到许多不同的操作语言：Java、Javascript、XML vocabulary like WSUI。

2.3 可扩展的微控制语言

控制组件支持一种声明方式把类型数据或表示组件绑定在一起。已经标准化的语法在其表达非常必要的概念的过程中得到了扩展，即：1）XLink 语法提供了一种方法，指定“locator”给存在于相同或不同的组件中的端点命名，而且指定“arc”来表达一对定位器之间的连接以及遍历 arc 的语义（尽管遍历语义需要扩展，超出导航的语义）；2）“XML 事件语法”（XML Event syntax）提供了一种方法指定操作、其类型、事件、事件源及应当在事件处理过程中哪一阶段触发该动作。下面的小示例演示上述内容是如何结合的：

假定 www.examples.com/presentation.html 内包括如下内容：

假定下面的内容是 www.examples.com/data.xml 里的根元素的一个子元素：

那么一个“微控制”绑定声明的示例可以是：

“微控制”绑定声明

http://www.w3.org/2001/xml-events"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:type="extended"
xlink:title="Example binder link specification">