周 志远 (zzyuan@cn.ibm.com), 软件工程师, IBM 中国开发试验室
郭 迎春 (guoyingc@cn.ibm.com), 软件工程师, IBM中国软件实验室
王 强 (wangq@cn.ibm.com), 高级软件工程师, IBM 中国软件开发实验室
2008 年 1 月 31 日 WebSphere Business Services Fabric (WBSF) 让用户能够根据服务策略动态的调用业务服务。本文将详细介绍 WBSF 动态服务选取的核心概念，工作原理，以及在 WBSF v6.02 中 SCA 编程模型对业务服务开发的支持。
引言
在面向服务的体系结构 (SOA) 中，业务服务（Business Service）代表了一组业务功能，其业务行为能够根据创建的策略和运行时上下文自适应调整，以更好地满足服务使用者的需求。
业务服务具有以下特点：
1. 从业务层面对业务功能进行设计
2. 通过业务策略和元数据来实现灵活，自适应的业务行为
3. 通过参照行业模型以简化各个系统之间的互操作
4. 基于 web service 和行业标准构建
因此，通过业务服务构建 IT 应用使得 IT 实现与业务需求吻合，非常好地体现了如下 SOA 理念：低成本，灵活自适应的的解决方案；最大化 IT 资产的可重用性；通过增量的解决方案降低了开发风险。
IBM WebSphere Business Services Fabric（WBSF）是对业务服务进行建模，组装，部署，管理和监控的软件平台。其产品包由三个部分组成：
-
IBM WebSphere Business Services Foundation Pack：基于 WebSphere Process Server 构建的业务服务管理和运行时环境。
-
IBM WebSphere Business Services Tool Pack：基于 WID(WebSphere Integration Developer) 的 Eclipse 插件，提供业务服务的设计和组装工具。
-
Industry Content Packs( 可选 )：一组基于行业标准和行业经验的 SOA 资产，例如行业模型，规则，通用服务等，可以加速行业 SOA 解决方案的开发。
具体来说，WBSF 能够根据服务的上下文 (Context) 信息动态地调用在其服务模型库 (Service Repository) 登记的业务服务，如图 1 所示 .。在运行时刻，WBSF 通过服务上下文信息对与之相关的策略 (Policy) 进行计算与检查，得到一组业务服务应该满足的断言 (Assertion)，以选择调用最佳的物理服务来满足业务服务请求。
图 1 WBSF 动态服务选取工作原理
在 6.02 版本中，WBSF 最重要的增强在于在业务服务的设计和组装中引入了 SCA 编程模型的支持。WBSF 引入了新的 SCA 组件用于对业务服务进行建模和组装。在 WID 中对业务服务进行组装时，可以通过 Dynamic Assembler(DA) 对业务服务进行组装；对于业务服务的动态组合，WBSF 提供了 5 种 SCA 扩展方便开发者对业务服务的调用进行定制。我们在后续部分介绍这 5 类 SCA 扩展。
什么是 Context
Context 即上下文信息，是运行时与服务相关的一组元数据。在 WBSF 中，服务的上下文信息主要包括如下内容：
-
Service Interface( 必需 )：服务接口名称的 URI，WBSF 将在运行时选择与此接口匹配的 endpoint 作为候选。
-
Subscription ID( 可选 )：用户对业务服务登记的 ID。该 ID 将用户与服务的一组上下文信息 ( 服务所属的 Application Suite，Application, Business Service, service Interface， Channel，Role，User 等 ) 关联起来。在 WBSF 中，应用程序套件 (Application Suite) 是最广泛的概念，包括一个或者多个应用程序 (Application)，应用程序包括一个或多个特定业务功能相关的业务服务 (Business Service), 业务服务代则是表示特定的业务功能，包括一组特定的服务。通道 (Channel) 是用户使用业务服务的通道，Role 和 User 则是通过特定通道使用业务服务的用户组和用户。WBSF 在运行时根据 Subscription ID 获与此调用者相对应的从上至下一组上下文信息。
-
Additional Properties( 可选 )：所有基于服务内容 (Content) 的属性，用于基于内容的断言 (Content based Assertion) 扩展。例如，在申请贷款的业务服务中，用户的信用值属于服务内容 ( 服务参数 )，同时也可以作为业务服务的上下文信息，用于选择不同级别的服务。
所有 Context 属性均以“名字 - 值”对的形式表示。
Context 属性有两种类型，一种是基于上下文的属性，主要包括 Service Interface, 以及与 Subscription ID 相关的一组与服务内容无关的非功能属性，可以为任何服务拥有。另一类为基于服务内容的属性，这种属性只为特定类型的服务拥有，一般与服务功能或者内容相关。例如，用户信用值属性是贷款申请相关类型的服务所特有的。
策略与断言
什么是策略？
策略是 Dynamic Assembler 用于选择服务 endpoint 的规则。
策略可以表示为：
IF LHS (left hand side) THEN RHS (right hand side)
其中，LHS 是一组服务上下文需要满足的条件，RHS 就是 Contract, 即对服务能力的要求，用断言 (Assertion) 来表示。
例如：IF( 请求来自 Portal Channel) Then ( MaxTransactionTime<200 ms) , 该策略表明，如果服务上下文中 Channel 属性为 Portal Channel，则选取的服务应该满足 MaxTransactionTime 小于 200 ms。
每个策略均有其作用目标 (target) 与有效时间区域，例如，有的 policy 作用范围针对一个业务服务，那么这个业务服务中所有的服务均在其作用范围之内；有的 policy 作用范围则只针对特定接口的服务。只有当请求的服务在作用目标之内，并且请求的时间在有效时间区域之内，WBSF 才会执行该策略。
什么是断言？
断言是 WBSF 中描述的服务能力特征，通常用表达式来表示，例如：MaxTransactionTime <200 ms。MaxTransactionTime 是断言的属性 ,ms 是属性单位，200 为属性值，”<”则是该断言使用的比较符号。
在 WBSF 中，断言有两个用途：
1. 在服务策略的 RHS 中，表明对策略对服务能力的要求。
2. 服务提供者将一组 assertion 与 endpoint 相关，标明该服务的能力。
WBSF 如何动态选取服务
当一个业务服务的请求发生时，WBSF 通过如下过程进行服务选取：
1. WBSF 根据与 Subscription 相关的上下文的属性，构建与此业务服务相关的 policy，得到一组断言的集合。若与 Subscription 相关的上下文属性在 policy 作用范围之内，则该 policy 被构建，并由此得到一组断言的集合。
2. 将 Context 中所有基于内容的断言属性对应的断言加入到断言集合中。
3. 对于所有实现此 interface 的服务 endpoint, 检查上面得到的断言集合。若多个 policy 产生发生冲突的断言，则采用作用范围最详细的 policy 产生的断言。例如，policy1 作用与应用程序范围，policy2 作用于通道范围，两者都产生 MaxTransactionTime 断言属性，则 policy2 产生的断言属性被采用。
4. 满足条件的最佳服务被选择进行调用。若多个 endpoint 符合条件，则选取代价做小的 endpoint；若仍然存在多个候选的 endpoint，则选取与断言要求最接近的 endpoint。若没有 endpoint 符合条件，则 WBSF 返回业务服务调用错误的消息。
WBSF 中的 SCA 编程模型
SCA 编程模型为 IT 服务提供了一个开放的、与技术无关的模型，它根据业务功能定义服务，使应用程序开发人员更易于访问中间件功能。您可以从参考资源中了解更多关于 SCA 编程模型的基础知识。
WBSF v6.02 最重要的新特性是提供了 SCA 编程模型支持以方便对业务服务的开发。具体来说，WBSF6.02 新增一种称为 Dynamic Assembler(DA) 的 SCA 组件，用于定制对业务服务的调用。DA 可以引用 5 种 WBSF 提供的 DA Extension 组件 , 对调用业务服务的各个阶段进行定制。
5 种 DA Extension 分别是实现了 WBSF 定义的 5 个 java 接口的 SCA 组件。这 5 个接口分别为：
1. Context Extractors
interface ContextExtractor {
Context extractContext(PendingRequest request)
throws UnexpectedContentException;
}
|
此扩展在 DA 构建 policy 之前被调用，我们可以从 PendingRequest 获取服务参数，并插入相应的基于服务内容的 Context 属性。例如，在贷款申请服务中，可以从 PendingRequest 获取到用户信用值这一服务参数作为断言属性，将其添加到 Context 中。
2. Policy Based Guards
interface PolicyBasedGuard {
GuardResponse inspect(PendingRequest request);
}
|
此扩展在 policy 构建之后，候选 endpoint 尚未获取之前被调用。我们可以从 PendingRequest 获取与请求相关的 policy 以及 Context 信息，用户可以在此根据特定的“语义”对自定义的断言进行处理，决定通过或者拒绝该请求。
3. Endpoint Filters
interface EndpointFilter {
CandidateList filterCandidates(CandidateList candidates)
}
|
此扩展在候选 endpoint 得到之后被调用。对于存在多个候选 endpoint 的情况，我们可以自定义算法，从中选择“最佳”endpoint
4. Response Listeners
interface ResponseListener {
OutboundResponse handleResponse(
InboundResponse inbound, OutboundResponse outbound);
}
|
此扩展在服务返回消息得到之后被调用。用户可以 InboundResponse 获取服务调用的相关数据，并对服务返回消息进行相应修改。
5. Event Listeners
interface AssemblyEventListener {
void handleEndpointNotFound(EndpointNotFoundEvent notFound);
void handleInvocation(InvocationEvent invocation);
}
|
此扩展类似于 Response Listener, 区别在于该扩展不能修改服务数据。例如，我们可以在此定制 DA 调用失败的处理函数，可以对特定类型 endpoint 的调用进行监控等等。
综合来说，DA 组件调用 SCA 扩展进行业务服务调用的流程如下：
1. 为请求创建 SUB-Context 结构
2. 调用所有其引用的 ContextExtractor 扩展组件对 Context 进行修改
3. 调用 Fabric Engine 的相应 EJB 执行 policy 构建
4. 调用所有其引用的 PolicyBasedGuard 扩展组件对请求是否继续进行判断
5. 调用 Fabric Engine 的相应 EJB 应用 policy 得到一组候选的 endpoint
6. 调用所有其引用的 EndpointFilter 组件对候选 endpoint 进行筛选
7. 获得调用选取 endpoint 的服务返回消息，调用所有其引用的 ResponseListener 组件对返回消息进行更新
8. 调用所有其引用的 AssemblyEventListener 组件进行特定的调用时间处理，例如，处理调用失败事件等等
9. 返回服务返回消息
结束语
在本文中，我们了解了 WBSF 根据服务策略进行动态服务选取的核心概念与选取原则，并且对 WBSFv6.02 中的 SCA 编程模型进行了介绍。在后续的文章中，我们将展示一个 WBSF v6.02 进行业务服务开发的实例，介绍 WBSF 开发的基本步骤，编程模型，并分析可能出现的错误的原因及其解决办法。
参考资料 学习
获得产品和技术
讨论
作者简介  | | | 周志远，工作在 IBM 中国软件开发实验室 - 中国新技术中心（China Emerging Technology Institute），从事 Incubator 及 SOA 相关项目的工作。他的邮件是zzyuan@cn.ibm.com。 |
| | | 郭迎春，IBM 中国软件实验室（CSDL BJ）的成员，有多年 Java 开发经验，目前主要研究方向为 SOA、CBS（Composite Business Service）。你可以通过 guoyingc@cn.ibm.com 联系她。 |
| | | 王强 IBM 软件工程师，工作在 IBM 中国软件开发实验室 - SOA Design Center，从事 Incubator 及 SOA、Grid 项目的工作，对 J2EE 架构、 SOA 架构、MDA/MDD 以及网格计算等技术有较深入的研究。联系方式：wangq@cn.ibm.com。 |
对本文的评价
| 
