内容


人性化的 Web 服务,第 2 部分

构建应用程序

人工利用可重用的组件、工作流和业务流程

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 人性化的 Web 服务,第 2 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:人性化的 Web 服务,第 2 部分

敬请期待该系列的后续内容。

引言

Web 服务体验语言(Web Services Experience Language,WSXL)为开发者提供了这样的灵活性 ― 当 Web 服务的组件发生更改时,可以重新配置和调整这个服务,就象您在 本系列第 1 部分中看到的那样。然而,用 WSXL 构建人性化的应用程序是一个很复杂的过程。为简化应用程序的构建工作,您应该以 WSXL 基本组件为基础开始构建工作。然后,您可以使用 WSXL 组件(component)集合(collection)在这个基础上构建应用程序,其中一个组件还可以是应用程序的聚集。(关于本系列中所用的许多术语的定义,请参阅 词汇表。)在这些组件中有一个是 控制组件(control component),它决定哪个集合应该充当显示聚集在一起的服务的浏览器窗口中的活动框架。

为确保组件集合和聚集的应用程序之间的交互流能正确进行,人性化的 Web 服务要依赖可重用的组件组和流控制机制,比如状态机、Web 服务流语言(Web Services Flow Language,WSFL)和业务流程执行语言(Business Processes Execution Language,BPEL)。虽然 WSXL 包含前两种机制,但 BPEL 这个关于业务流程的新兴标准仍是工作流标准的一个补充,它有助于使具有不同技术和不同业务需求的业务伙伴所采用的各业务流程的视图标准化。

可重用的组

在将可重用的组件组应用于 Web 服务的构建时,WSXL 起着很重要的作用。已经存在的 WSXL 组件可以与其他 WSXL 组件一起被重用,并被组织为一个集合内的可重用组。这种可重用性使您能够通过更改 WSXL 组件活动的执行顺序以及用其他方法调整 WSXL 来重新配置 Web 服务以改善 Web 服务的性能 ― 所有这些都不需要再另外大量编写新代码。

如果一个聚集的应用程序要充当集合中的一个 WSXL 组件,那么它就必须实现 WSXL 组件接口。WSXL 基本接口有四类,如 表 1 中所示。生命周期这一类特别重要;它被用于在应用程序或组件转移到下一个活动或重复当前活动之前检查活动的完成情况。对于表中的每种类别,我已经提供了简要的说明。

表 1. WSXL 基本组件接口

接口类别说明
查询允许客户机请求 WSDL 服务描述文档的基本查询操作
生命周期为客户机提供在随后的调用中间接地引用特定实例的手段
属性管理允许客户机在初始化以外的时间修改属性
输出输出服务的标记

如果一个集合包含在最终用户的页面视图中指明了的组件,那么这个集合就是一个 页面级集合。如果一个页面级集合实现了组件接口,那么就可以将它合并到一个更高级的集合中。这意味着几个页面级集合可以被看作是一个集合下几个可重用的组。

为使多个活动表示同步,您可以用 控制组件把多个表示组件归为一组。还有一种方法是可以把表示组件聚集起来以从中选择而不是同步它们的函数。例如,控制组件可用于确定一个组中哪个表示组是活动的框架。如果愿意的话,您可以指定另一个表示组件作为可以被控制组件识别出来的活动框架。

流控制

在构建应用程序时用一种反映交互流和业务流程规则的方法来控制组件间的流非常重要。我们来看一下 WSXL 所依赖的三种类型的控制机制:状态机、Web 服务流语言(WSFL)和业务流程执行语言(BPEL)。

状态机

根据 WSXL 规范,一个 状态机就是交互流的一个抽象可视化 ― 也即交互从一个点发生,再转到另一个点的顺序的抽象可视化。(同一个点还可以在流中按指定的次数重复。)一个简化版的示例如 图 1所示。

图 1. 状态机
状态机

图 1 中,状态机从节点 1 开始。在节点 1 处完成任务后,它移到应用程序的下一个状态 ― 节点 2 或节点 3(这取决于条件分支的逻辑)。如果机器到了节点 2 处,那么这个节点处的交互将一直重复自身,直到它完全满足预置条件才转到最后的节点,即节点 5 处来实现另一个交互流。如果机器选择通过另一条路到达节点 3,那么它必须决定交互流的下一个状态或下一条路径是什么:是节点 4 还是节点 6,这取决于分支条件的逻辑。不管产生的结果如何,机器最终都会进行到节点 6。然后,它一遍遍执行一个循环,直到满足某个条件才最终进行到流中的最后一个节点 ― 节点 5。另一方面,该机器可能想直接到达节点 4,然后移到交互流的最后一个节点和最终状态。

状态机的一个主要缺点是:它只对应用程序交互的宏观层次的可视化工作流有用。状态机并不太适用于描述宏观层次的业务流程;它是抽象的。集合内的一个应用程序可以拥有数百个业务流程(例如,从产品订购到产品交付)。每个流程都有一组不同的逻辑步骤,用于在一定条件下转到另一个进程、应用程序、集合或用户体验。流程和应用程序间的流用 WSFL 流引擎来处理更好,最好用 BPEL 来处理,尽量不要用状态图处理。

Web 服务流语言

WSXL 依赖 WSFL 流引擎来根据要求 Web 服务间进行相互交互的业务流程的规则来触发事件。集合可以允许自己发布自己的行为(例如,它在开发期间和运行时响应查询),这样将象 WSFL 流模型定义的那样描述活动如何从一个流转到另一个流。

在这个模型中,活动(组件)代表对 Web 服务的一个操作。由数据和控制链路连接在一起的活动包含业务流程。通过链接活动,这些链路定义了集合内每个组件的执行顺序。每个活动指定一组流程,它们的执行需要根据控制链路上条件表达式的条件分支的逻辑在进行到下一个活动前或者重复当前活动前进行。

组件、应用程序、交互和执行的控制流允许 WSFL 流引擎编排 Web 服务,并特别允许象 WSXL 指定的那样编排用户体验。每个 WSXL 组件都有一个 Web 服务描述语言(WSDL)生命周期接口。当活动组件正在执行时控制组件开始发挥作用,以确保事件处理程序被正确用来完成活动组件的任务。活动组件完成其运行后,流模型就确定应用程序是应该重复该活动还是应该转到流中的下一个活动。

除用于描述业务流程的流模型外,WSFL 还应用于全局模型以描述整个伙伴交互。但 WSXL 中并没有提供业务流程的这个全貌。这也是 BPEL 出现的原因,目的是填补这个空白。

业务流程执行语言

BPEL 为使用 WSXL 构建应用程序提供了更大的灵活性。它允许企业从标准的角度来指定既消费 Web 服务又提供 Web 服务的业务流程。它是用两个补充的规范 ― Web 服务协调(Web Services Coordination,WS-Coordination)和 Web 服务事务(Web Services Transaction,WS-Transaction)― 定义的。WS-Coordination 通过按适当的执行顺序协调业务流程的活动把 Web 服务连接起来。WS-Transaction 提供了一种机制来监视 被协调活动的失败或成功,即便在一个长时间运行的事务期间(例如,等待某个人开始一个流程活动)仍是这样监视。

把一个系统具体化为 Web 服务需要三步;为演示这些步骤,我将使用一个旅行代理系统作为示例,这个系统接收航班、旅馆和汽车出租代理预定。BPEL 文档是可执行的脚本,可以使用业务流程引擎来解释它以实现所描述的流程。具体化一个系统的步骤如下所示:

  • 定义业务流程以及与业务伙伴的连接(例如,航班、旅馆和汽车出租代理)。
  • 提供一种机制来协调业务流程中涉及的所有活动,比如接收来自客户的预定行程,向航空公司发送客户的预定行程,向航空公司订票,接收航空公司送来的票。
  • 提供一种机制以逐个任务为基础控制每个活动的事务。这些任务可能包括填写将作为消息发送的预定行程表单以及把该消息放入一个输入容器,稍后航空公司将检索这个容器。

结束语

WSXL 指定了为门户网站上、远程或本地的人性化 Web 服务构建应用程序所需的组件。采用 WSXL 的好处要远大于因 WSXL 组件模型的复杂性而带来的弊端。WSXL 的其中一个主要优点是它提供了当它的组件发生更改时可以重新配置和调整 Web 服务这种灵活性。另一个好处是 WSXL 依赖可重用的组和 WSFL 来构建应用程序。

BPEL 非常适合用来构建为业务伙伴(这些业务伙伴有不同的技术和业务需求)具体化 Web 服务的应用程序。这反映了在根据业务流程的外部规则开发交互式、人性化应用程序时企业用户和伙伴被承认是重要的参与者。

在这个系列将来的文章中,我将讨论如何将这些应用程序转换为 Web Services for Remote Portals(WSRP)这个 WSXL 组件所指定的门户网站上的 Web 服务。在那之前,我希望本文已经使您明白了如何改进自己的人性化 Web 服务。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=21207
ArticleTitle=人性化的 Web 服务,第 2 部分: 构建应用程序
publish-date=10012002