SOA 快速指南 1 2 3（转IBM developerWorks 中国）

拓展 Tomcat 应用

级别: 初级

金戈, IBM软件部企业集成解决方案架构师, IBM 中国软件开发实验室 SOA设计中心
姚辉 (yaohui@cn.ibm.com), IBM 中国SOA 设计中心高级工程师, IBM 中国软件开发实验室
赵勇 (zhaoyong@cn.ibm.com), IBM 中国SOA 设计中心工程师, IBM 中国软件开发实验室
谭佳, IBM 中国SOA 设计中心工程师, IBM 中国软件开发实验室

2006 年 12 月 26 日

《SOA 采纳步骤和价值分析》是本系列文章的第一部分。本文前半部分首先概览了实施 SOA 的简单步骤，然后介绍了贯穿本系列文章的示例场景。在文章的后半部分着重介绍了IBM SOA 成熟度模型和SOA评估框架，并分析了示例场景中采纳 SOA 的步骤和价值。

以服务为中心的业务活动管理与监控是最近出现的一种热门的IT技术，它的目的在于帮助企业管理人员实时获悉企业运营状况，了解企业的战略实施进展。《SOA 快速指南 1 2 3》系列文章是笔者近年来在 SOA 项目实施中的经验结晶。该系列文章结合一个汽车贷款流程，介绍了在 SOA 的环境下如何基于 IBM 的现有产品构造业务活动管理解决方案，详细阐述了每个实施步骤中使用的 IBM 的方法学、技术和产品。希望通过本文的介绍，能够帮助读者理清业务流程管理所包含的基本概念，并了解构建解决方案所需要的基本步骤。

回页首

1. SOA 实施步骤总结

SOA 快速指南 1 2 3

本系列是 IBM 中国软件开发实验室 SOA 设计中心近年来在 SOA 项目实施中的经验结晶。

SOA是一个既简单又复杂的技术。简单地说，SOA就是一组设计原则，这些设计原则既有SOA特有的，如服务是第一概念[CBDI]，业务和IT对齐，为灵活而构建；也有被早已被业界广泛接受和使用的，如松散耦合、隔离关注、模块化、可重用性等。复杂地说，SOA是由这些设计原则衍生出的各种技术，如SOA成熟度模型、服务建模方法学、SOA编程模型、企业服务总线、服务注册库等。

同样，对SOA的采纳（Adoption）形式也具有从简单到复杂各种形式。一个分布式企业IT系统全面向SOA转型固然是SOA，而像HousingMap.com这样将Google Map提供的Web服务和Craiglist提供的Web服务集成起来提供全新的业务模式也不能不算SOA。笔者作为主要的技术人员主导或参加了若干SOA的实施案例，这里面有短暂的SOA试点项目，也有大跨度的SOA实施。从实践的角度而言，笔者认为一般的SOA的实施项目应该包含如下步骤：

0. SOA采纳步骤和价值分析：由于客户现有IT环境和业务环境的不同，采纳SOA的价值和采纳的步骤也会相应不同。对任何一个企业或者是应用提供商，在采纳SOA之前最好深刻理解SOA的内涵和外延，并客观分析采纳SOA的好处以及带来的风险，并实际情况规划SOA实施的步骤。

1. SOA监管：和传统技术不同的是，SOA是一个横向的技术，它不仅影响IT系统的设计者和开发者，它更需要改变业务部门对IT系统的看法，也需要运营部门改变系统运营的方式。几乎所有的相关人的活动都会围绕着服务模型和服务元数据。因此服务模型和服务元数据质量直接决定着企业向SOA转型的效果。简单的说，SOA监管通过建立适当组织和流程保证服务模型和服务元数据在创建时和运行时的质量。可以预见的是，一个企业采纳了SOA后，SOA监管会成为企业IT部门的重要任务之一。

2. 服务建模：如何根据服务建模方法学创建符合SOA设计原则的服务模型是实施SOA中及其重要的一步。发现服务候选、决定服务暴露和进行服务规约是这一步的重要内容。

3. 服务实现和架构设计：根据确定的服务模型，结合现有IT环境确定服务和服务组件的实现策略，并设计用于实现服务的基础架构(如ESB、流程服务引擎、人工服务容器等)是也是实施SOA过程中及其重要的一步。服务组件划分、服务实现决策和服务基础设施设计是这一步的重要内容。

4. 以服务为中心的开发和集成：在SOA的实施项目中，开发和集成的模式都会发生相应的变化，服务会成为开发阶段的中心概念。服务模型映射到编程模型，逐步实现服务，并在服务层次上进行持续的集成是这一阶段的主要内容。

5. 服务管理：以上的步骤主要侧重在功能层次上如何一步步实现SOA，而服务管理则侧重于在SOA实施中如何实现非功能性需求，这包括服务性能、服务安全等。

本系列文章将围绕SOA的实施步骤组织，但是SOA监管和服务管理不在本系列文章的范围内。

回页首

2. 示例场景介绍

本系列文章所涉及的场景是一个汽车贷款审批业务流程，从申请人提交申请到汽车销售商接受贷款并发货（或者申请人接收拒绝通知）。

从银行的业务角度，该业务流程的外部参与者包括最终用户（申请人、汽车销售商）和合作伙伴（保险公司），内部参与者包括业务执行人员（信贷员）以及风险管理人员(信贷经理)。从技术实现的角度，该业务流程既包含自动化的内部功能（查询存贷款记录）和外部功能（保险公司提供担保），也包括人工活动（信贷经理审批）。因此，该场景具备一般业务流程的典型性，基于该场景的SOA实施示例具备更大的借鉴意义。

图1：汽车贷款审批流程

图2：现有业务环境

从图2可以看出，信贷员是整个业务流程的枢纽，负责与客户、信贷经理、相关应用系统打交道。这种业务模式既增大了信贷员的工作强度，也增加了过程中的操作风险以及道德风险。

图3：现有 IT 环境

从图3可以看出，在业务流程中起到枢纽作用的信贷员，通过不同的方式访问不同的系统，获取申请人的相关信息，同时通过电子办公系统向信贷经理提交贷款审批申请。多样化的人机界面既增加了对信贷员的IT技能要求，也极大的降低了信贷员的工作效率。

回页首

3. SOA 评估框架和 SOA 成熟度模型简介

如上所述，SOA是由一些设计原则衍生出的一系列技术。和传统的方法不同的是，SOA的这些衍生技术遍布企业IT生命周期，以及企业IT系统的各个层次。为了评估一个企业的实施SOA的程度，我们需要一个覆盖全面的评估标准和一种对成熟度的划分。SOA评估框架就是这里说的评估标准，而SOA成熟度模型就是一种对SOA成熟度的划分。SOA的评估框架和SOA成熟度模型是了解企业IT和业务环境现状，分析企业采纳SOA的步骤和价值的重要工具。这里我们以IBM的SOA评估框架和SOA成熟度模型为例进行介绍。

IBM的SOA评估框架主要分析企业IT系统在如下四个方面的特性:

1. 组织和流程：企业是否有实施SOA的经验，实施SOA的范围多大，企业是否规划过需要实现的SOA的能力，业务部门是否理解SOA实施的价值和过程，特别是业务部门参与重要性，是否有系统的方法指导服务的发现和设计，业务部门在服务的发现和设计中参与的程度如何;

2. 应用：目前应用如何暴露可重用的逻辑？应用间连通的实时和异构特性如何？企业开始在多大构建复合应用？

3. 架构：目前企业应用集成现状？企业应用的组件化程度如何？是否存在服务模型？范围多大？

4. 基础架构：基础架构如何保持可扩展性和灵活性保证满足业务部门的需要？基础设施如何响应业务流程性能的变化？是否存在统一的安全架构和规范？

同时，IBM的SOA成熟度模型将SOA成熟度划分为7个层次：

L1. 孤立的：大多数为孤立应用，存在集成也基本上以数据集成为主；当需求发生变化时，需要大量的琐碎的架构调整；

L2. 集成的：应用间存在大量集成，但是以点到点的连接方式为主，应用程序的重构主要通过数据集成完成；

L3. 组件化的：将主要的或关键的应用从功能角度进行了组件划分，原有的J2EE/.Net等应用通过重构实现这些组件，组件间的集成通过组件接口和相互间的契约完成；

L4. 简单服务：存在业务部门内的服务模型和构建在服务上的业务流程集成；

L5. 组合服务：存在企业范围内和企业间的服务模型，已经在服务模型基础上完成价值链集成；

L6. 虚拟化服务：基础设施如服务器和存储已经完成虚拟化，服务运行在这些虚拟化的基础设施之上；基础设施、服务组件、服务、业务流程被极大解耦；通过对基础设施的监控和管理来保证服务质量；

L7. 动态配置服务：服务可以根据业务策略和IT策略进行动态组装；

回页首

4. 示例场景的 SOA 现有成熟度和目标成熟度

我们对示例场景中SOA现有成熟度分析总结如下：

1. 组织和流程：无论是在贷款业务部门，还是在其他业务部门，都没有进行过SOA的实施；业务人员普遍认为SOA是技术层面的事情，是IT部门的事情，业务部门在SOA实施中没有任何责任；

2. 应用：构建在主机上的核心银行系统业务逻辑体现为CICS的事务，业务逻辑划分清晰，但是逻辑和表示紧耦合，而且其业务逻辑划分和整体需求有一定差距，该银行已经构建EAI的基础设施，核心银行系统的业务逻辑可以通过EAI中的消息总线访问；房贷和车贷系统分布构建在J2EE和.Net平台之上，设计系统时对组件化考虑的很充分，主要的业务逻辑都构建在公共的组件基础之上，如果其他系统需要访问房贷和车贷系统，需要进行点到点的集成；保险公司担保网关是外部系统，已经服务化。

3. 架构：企业消息总线可以连通除房贷和车贷系统以外的大部分系统，但是消息总线中介能力不强，主要集中在消息转换，对重复业务逻辑的访问需要应用层处理；

4. 基础架构：服务器、存储和网络设施异构性很大，业务系统性能的调控相当刚性；已经具有统一的安全架构，如认证、授权和加密；

综合分析可见，对于整体企业而言其SOA成熟度，位于L2和L3之间；房贷和车贷系统SOA成熟度位于L3。

对于SOA的转型，该企业的近期目标是希望能够在现在的现有的房贷和车贷系统之上构建复合应用以支持汽车贷款审批流程；而该企业的长远目标是构建企业范围的服务模型，并逐步改造所有的应用为复合应用，并期望实现价值链集成。由此可见，对于围绕汽车贷款审批流程的房贷和车贷系统SOA改造的目标成熟度是L5；从企业范围而言，希望现在房贷和车贷构建SOA应用，而逐步扩展到整个企业，所以其目标成熟度先是L4，然后迁移到L5。

回页首

5. 示例场景的 SOA 采纳步骤和价值分析

结合示例场景的特点和SOA转型的需要，我们建议如下SOA采纳步骤：

第一步：以汽车贷款审批流程为中心进行SOA试点（ L2/3 -> L4 ）在这一步中，围绕汽车贷款审批流程进行服务建模分析，并在现有系统上构建企业服务总线。这一步的主要目标有四：第一）测量SOA可能带来的业务层面的价值，通过服务组装完成汽车贷款流程，来验证如何通过服务中介、服务替换和服务重新组装适应可能的业务变化，从而实现业务流程从建模‘自动化‘监控‘优化的全生命周期；第二）测量SOA可能带来的IT层面价值，通过将已有系统暴露为服务，并构建ESB实现虚拟化的服务，来验证将现有系统暴露为服务的技术可行性，验证ESB如何通过实现广泛连接性、验证如何通过服务中介完成重复逻辑合并和异构系统集成、验证如何SOA架构如何适应IT层面的变化如系统集中、系统合并和系统升级；第三）深化IT部门对实施SOA的技术理解，包括服务建模方法学、SOA架构设计、相关技术和产品的成熟度（安全，性能，…）；第四）深化IT部门和业务部门对实施SOA的方法和价值理解，包括SOA背后的价值驱动，如何建立SOA组织和流程进行SOA监管等；
第二步：重构贷款系统以实现贷款部门的服务模型，并将业务流程实现为复合应用 ( L2/3 -> L4 ) 在这一步中，围绕贷款部门的业务流程进行服务建模（这不仅包括贷款业务部门内部的服务，还包括可能访问到的核心银行系统的服务），并将主要业务流程迁移为复合应用。这一步的主要目标有三：第一）继续深化IT部门对实施SOA的技术理解，并培养SOA实施的各层次的技能；为企业范围内的SOA实施做技术准备，如各种SOA实施技术规范－SOA参考架构，服务模型规范，企业服务总线规范等；第二）继续深化IT部门和业务部门对实施SOA方法和价值理解，初步建立业务部门内的SOA监管组织、流程和基础设施（如服务注册库）等；第三）验证现有SOA技术和产品在大规模应用时的成熟度；
第三步：以消息总线的改造为中心，构建SOA监管组织和流程，并创建企业服务模型和企业范围内SOA的基础架构；( L4 -> L5) 这一步选择以消息总线为中心的原因在于，1）消息总线涉及主要的业务逻辑和业务流程，而且该企业在构建消息总线时已经对核心的业务进行了必要的调查和分析，这是服务建模的良好基础；2）消息总线是主要的应用集成设施，这是企业服务总线构建的良好基础。通过这一步骤，企业范围的SOA基础架构基本形成，这包括SOA监管组织和流程、企业范围内服务模型、企业服务总线和SOA参考架构；
第四步：逐步迁移主要业务流程为复合应用，并完善SOA监管和服务模型；(L4->L5) 这一步主要是在前一步的建立的SOA基础架构之上逐步将应用迁移到复合应用。实际上第三步和第四步应该是融和在一起的；
第五步：围绕价值链整合实现快速响应IT系统; (L5) 当完成SOA基础设施建设和复合应用迁移后，企业已经具备条件进行流程优化和价值链整合。这种条件下，无论是IT层面的调整，还是业务层面的调整，都可以通过服务模型和企业服务总线隔离变化，从而使用尽量小的代价完成对变化的适应，也即达到快速响应的IT。

本系列文章的后续部分将围绕SOA采纳的第一步 -- 以汽车贷款审批流程为中心进行SOA试点为背景介绍SOA实施的其他步骤

SOA 快速指南 1 2 3，第 2 部分: 服务建模

文档选项

拓展 Tomcat 应用

级别: 初级

2006 年 12 月 26 日

《服务建模》是本系列文章的第二部分。本系列的第一部分概览了实施 SOA 的简要步骤，并针对示例场景分析了采纳 SOA 的步骤和价值。本文首先介绍了服务建模的方法学；对示例场景进行流程建模，为服务建模做准备；在第一部分文章对现有业务和 IT 环境分析的基础上，结合价值分析和流程建模的结果，设计了目标的业务和 IT 场景；基于业务组件模型、流程模型以及业务目标进行服务建模的前两个步骤——服务发现和服务规约。

回页首

1. 服务建模方法论介绍

SOA 快速指南 1 2 3

本系列是 IBM 中国软件开发实验室 SOA 设计中心近年来在 SOA 项目实施中的经验结晶。

众所周知，面向对象的应用构建在类和对象之上。

随后发展起来的建模技术将相关的对象按照业务功能进行分组，就形成了组件的概念；对于跨组件的功能调用，则采用接口的形式暴露出来。

进一步的将接口的定义与接口的具体实现进行解耦，就催生了SOA。而作为业务和IT之间的契约的服务，是SOA最重要的概念。

因此面向对象、基于组件、面向服务是三个递进的抽象层次。

现在我们有OOAD（Object Oriented Analysis Design）和CBD（Component Based Development）来进行面向对象和基于组件的建模与开发。但是没有一个好的方法来进行SOA的分析、设计和开发。SOMA（Service Oriented Modeling Architecture）就是在这个背景下诞生的，其主要目的就是填补OOAD和CBD在建模领域留下的空白，为SOA实施提供一个方法学的指导。

需要特别指出的是，SOMA的出现并不是要替代OOAD或者CBD，正如CBD需要借助OOAD一样，SOMA也要借助OOAD和CBD进行实现层面的建模。

与OOAD和CBD相比较而言，SOMA贯穿整个IT建设的生命周期，在项目规划、设计、实施、运行中都起到重要的作用。本文就不展开阐述了，相关信息可见参考资料。

SOMA另外一个显著的特点就是将IT与业务对齐。在具体的实施过程中，SOMA将业务特性，如：业务目标、关键业务指标等，延伸到IT的分析和架构决策过程，从而缩小业务与IT之间的差距。具体来看，业务组件模型（或者类似业务分析方法论的结果）、端到端的业务流程以及关键业务指目标是SOMA的三项主要输入，SOA的实现则是SOA的输出，从这也可以看出SOMA的定位是在业务和IT之间。

图1：SOMA方法论

按照实施的阶段，SOMA分为服务发现、服务规约以及服务实现三个阶段。

1）服务发现：采用自上而下、自下而上和中间对齐的方式，得到服务的候选者。

自上而下（业务领域分解）方式从业务着手进行分析，我们将业务进行领域分解、流程分解，以及进行变化分析。

业务组件模型是业务领域分解的输入。根据业务组件模型的详细描述，我们可以将业务领域按照业务职责细分为业务范围，并直接其映射到IT范畴的子系统，实现业务与IT的无缝连接。

顶级的业务流程是流程分解的输入。将业务流程分解成子流程或者业务活动，逐级进行，直到每个业务活动都是具备业务含义的最小单元。流程分解得到的业务活动树上的每一个节点，都是服务的候选者，构成了服务候选者组合。在大部分情况下，服务候选者组合都是一个很长的列表，加上自下而上和中间对齐方式还有可能发现新的服务，因此将服务候选者按照某种方式进行分类是一件非常必要的事情。业务领域分解的结果——业务范围是一个业务概念，同时可以无缝映射到IT范畴，因此它是一个好的分类原则。根据业务范围，服务候选者组合可以被划分服务候选者目录。

变化分析的目的是将业务领域中易变的部分和稳定的部分区分开来，通过将易变的业务逻辑及相关的业务规则剥离出来，保证未来的变化不会破坏现有设计，从而提升架构应对变化的能力。变化分析可能会从对未来需求的分析中发现一些新的服务候选者，这些服务候选者需要加入到服务候选者目录中。

自下而上（已有资产分析）方式的目的是利用已有资产来实现服务，已有资产包括：已有系统、套装或定制应用、行业规范或业务模型等。

通过对已有资产的业务功能、技术平台、架构以及实现方式的分析，除了能够验证服务候选者或者发现新的服务候选者，还能够通过分析已有系统、套装或定制应用的技术局限性尽早验证服务实现决策的可行性，为服务实现决策提供重要的依据。

中间对齐（业务目标建模）方式的目的是帮助发现与业务对齐的服务，并确保关键的服务在流程分解和已有资产分析的过程中没有被遗漏。

业务目标建模将业务目标分解成子目标，然后分析哪些服务是用来实现这些子目标的。在这个过程中，为了可以度量这些服务的执行情况并进而评估业务目标，我们会发现关键业务指标、度量值和相关的业务事件。

结合这三种方式的分析，我们发现服务候选者组合，并按照业务范围划分为服务目录。同时为服务规约做好其他准备，如：通过对已有资产分析进行的技术可行性评估、通过业务目标建模发现的业务事件等等。

2）服务规约：定义实现服务的服务组件的细节，包括，数据、规则、服务、可配置概要、可能的变更，同时还会涉及到消息、事件的定义和管理。

经过服务发现的阶段，我们得到了候选服务目录，接下来就需要决定暴露哪些服务。理论上所有的服务候选者都可以暴露为服务，但是一旦暴露为服务，该服务候选者就必须满足附加的安全性、性能等方面的要求，企业还必须为服务的规划、设计、开发、维护、监管支付额外的开支，因此我们会根据一定的规则来决定将哪些服务候选者暴露为服务。

这些规则包含以下几个方面：

业务对齐：该服务候选者可以支持相关的业务流程和业务目标。
可组装：该服务候选者满足技术中立、自包含以及无状态等特点，同时还满足复合应用的相关非功能性需求。
可重用：该服务候选者可以在不同的应用、流程中重用，从而减少重复的功能实现，降低开发和维护的成本。

基于企业应用开发的经验，我们还可以有其他一些方面的考虑。

在决定暴露特定的服务候选者为服务以后，服务规约还需要定义服务的消息、非功能性需求以及服务之间的依赖关系、组合关系。

3）服务实现：

根据对业务领域的理解和现有IT系统的分析，将服务的实现分配到相应的服务组件，并决定服务的实现方式。具体的实现方式，可以由已有系统暴露相关功能为服务，或者重新开发相关功能提供服务，也可以由合作伙伴来提供服务。无论采用哪种方式，都需要对于关键点进行技术可行性的分析。

回页首

2. 流程建模

定义和建模业务流程是提升业绩的关键因素。业务流程是一种可变的交互模式，当某个组织在实现特定的业务目标时，在该组织的组件及其环境之间发生了这些交互。业务流程通常很复杂，因为在应对独特而瞬息万变的环境时，人们会不断进行大量的更改。没有正式的流程文档和流程管理系统的话，这些流程复杂性就会使组织遇到不必要的障碍和瓶颈。一个良好构建的业务流程模型可以帮助您定位和排除那些隐藏的低效、高成本以及带来延迟的业务活动。

IBM? WebSphere? Business Modeler 是一个业务过程建模工具，该工具使您能够建模、设计、分析与生成业务过程报告、集成新的和修订的工作流，以及定义您的组织、资源和业务项。

本文的主题是服务建模，因此有必要阐述流程建模与服务建模的关系。

首先，进行着两项活动的角色有明显的不同，流程建模一般由业务人员或者业务咨询专家进行，而服务建模由SOA架构师在业务专员的支持下进行。

其次，两项活动看待研究对象的角度不同。流程建模从组织结构、业务流程及相关资源的角度来看待业务，流程建模关注业务活动之间的流动；服务建模则利用服务——业务与IT的契约来分析业务，服务建模关注业务活动之间的层次化和组合关系。

除了上面两点不同以外，这两项活动还是相互依赖，迭代进行的。粗粒度的流程模型是服务建模的重要输入之一，帮助SOA架构师了解业务需求。服务建模的过程发现并规约了服务，产生的结果——服务列表以及服务的主要业务属性帮助业务人员准确的定义流程模型中的业务活动和业务项。但是服务建模中IT的成分如安全性、可靠性，流程建模并不关注；

而流程建模中的模拟运行和优化又和服务建模没有直接的关系。

根据对当前业务流程的分析，我们可以进行业务流程建模。图2展示了目标业务流程模型。

图2：基于角色的目标业务流程模型

点击查看大图

回页首

3. 目标业务及IT环境分析

通过对现有业务环境的分析，新的业务流程必须将信贷员从繁复的人工操作中解放出来，通过自动化的方式降低信贷员的工作强度；同时通过业务规则的约束，控制过程中的操作风险和道德风险。图3就是我们设计的目标业务环境，信贷员只是整个流程中的参与者之一，由自动化的汽车贷款审批业务流程来担当承担业务流程的枢纽。

图3：目标业务环境

IT环境的目的是解释应用或流程在执行的过程中会与哪些相关的业务系统交互（包括交互的方式），此外，还解释相关业务人员与流程的交互方式。通过对IT环境的分析，我们可以了解已有系统的功能和相关技术指标，为后面的服务实现和架构设计提供重要的信息。根据业务模型的转型，相应的IT环境如图4所示。汽车贷款审批业务流程能够通过计算机技术自动与相关系统互联互通，同时申请人、信贷员以及信贷经理作为人工任务的执行者参与到业务流程中。

图4：目标IT环境

回页首

4. 服务发现

服务建模按照服务发现、服务规约和服务实现这三个步骤进行，本文会涉及前面两个步骤。服务实现与架构设计是本系列文章的下一篇文章的主题。

自上而下方式

通过对业务流程的分解，我们可以得到服务的候选者。如图5所示，每一个业务活动的单元都是服务的候选者。

图5：业务流程分解

点击查看大图

中间对齐方式

通过与业务分析人员或业务咨询顾问的协作，我们可以获取服务建模的输入——业务目标。在本示例中，业务指标为"降低成本"和"降低欺诈风险"，并且通过销售成本、自服务比例和坏账率这三个关键业务指标来度量业务目标的实施情况。部分服务候选者可以与关键业务指标联系起来，例如：评估信用等级以及审批等服务候选者可以降低坏账率。

自下而上方式

通过对现有IT环境的分析，我们可以掌握现有系统的基本信息。了解到核心系统可以提供获取存、贷款记录的功能。

根据与业务目标的联系、与现有系统功能的映射，可以验证我们自上而下分析方法的结果，或者发现自上而下分析方法的遗漏。结合业务领域的分析，我们可以得到服务候选者列表。

由于服务候选者比较多，可以采用领域分解的结果来将服务候选者进行分类。领域分解的工作通常由资深的业务专家来进行，在本示例中，基于示范的目的，我们认为目标业务流程所涉及的业务范围包括客户服务和风险控制，并将它们作为分类的依据，得到服务候选者目录。

回页首

5. 服务规约

有了服务候选者目录，最重要的步骤就是服务暴露的决策，根据业务对齐、可重用性、业务可组装性等准则，我们决定暴露以下服务：

表格1

服务	业务对齐	可组装	可重用
1 汽车贷款流程	Y	Y
1.1 确认购车价格	Y	Y
1.2 评估信用等级	Y	Y	Y
1.2.1 查询存款记录	Y	Y	Y
1.2.2 查询贷款记录	Y	Y	Y
1.2.3 计算信用等级	Y	Y	Y
1.4 审批	Y	Y	Y
1.6 担保	Y	Y	Y
1.7 发放贷款	Y	Y	Y

在决定暴露的服务以后，就需要对这些服务进行消息的定义和非功能性需求，同时需要定义相关的业务事件、规则。

表格2

服务	输入	输出	业务事件	业务规则	非功能性需求
1 汽车贷款流程	1 汽车贷款流程	Application	applyResult
1.1 确认购车价格	carModel	carPrice
1.2 评估信用等级	Applicant	creditResult	信用等级报警	基于存款、贷款记录的信用评估业务规则
1.2.1 查询存款记录	Applicant	depositHistory			性能（略）
1.2.2 查询贷款记录	Applicant	loanHistory			性能（略）
1.2.3 计算信用等级	applicant, depositHistory,loanHistory	creditResult			性能（略）
1.4 审批	Application	approveResult	审批结果通知	授权额度业务规则
1.6 担保	Application	assureResult			可用性（略）
1.7 发放贷款	loanRequest	loanResult	贷款发放通知		事务（略）

实际项目中，服务规约会比较复杂，既包括具体的服务的操作、输入消息、输出消息，也包括相关联的业务目标、业务规则、业务事件，此外，非功能性需求等方面也是需要在服务实现以前定义。上表仅仅列举几个方面做简单的示意。

除了对单个的服务本身进行规约，服务规约还包括服务之间关系的描述，例如服务之间的依赖关系和包含关系。

在本示例中，汽车贷款流程由其他服务组装而成，评估信用等级由查询存款记录、查询贷款记录和计算信用等级组装而成；执行审批以前，必须先完成评估信用等级，因此从业务的角度来看，审批服务依赖于评估信用等级

SOA快速指南 1 2 3，第 3 部分: 服务实现及架构设计

文档选项

拓展 Tomcat 应用

级别: 初级

姚辉 (yaohui@cn.ibm.com), IBM 中国SOA 设计中心高级工程师, IBM 中国软件开发实验室
金戈, IBM软件部企业集成解决方案架构师, IBM 中国软件开发实验室 SOA设计中心
赵勇 (zhaoyong@cn.ibm.com), IBM 中国SOA 设计中心工程师, IBM 中国软件开发实验室

2007 年 1 月 31 日

《服务实现及架构设计》是本系列文章的第三部分。在第二部分，我们完成了服务建模的前两个步骤：服务发现和服务规约。本文的目的是进行服务建模的第三部分：服务实现，并完成架构设计的工作。第二部分已经整体的阐述了服务建模的概念和方法，本文就不再重复，因此首先介绍IBM的SOA的参考架构，作为架构设计的指导；然后结合场景的业务目标以及IT环境设计试点项目的架构，并重点突出关键点的架构决策。

回页首

1. SOA参考架构

SOA 快速指南 1 2 3

本系列是 IBM 中国软件开发实验室 SOA 设计中心近年来在 SOA 项目实施中的经验结晶。

SOA参考架构是一种组织SOA的构建元素--服务的方式，IBM希望通过这种参考架构为企业架构提供一种指导和参考，使得新的需求能够更快的得到响应。参考架构如图1所示。

图1：SOA参考架构

其中左侧的绿色部分表示建模和组装，中间的蓝色部分表示部署，右边的深蓝色部门表示管理。中枢部分是企业服务总线（Enterprise Service Bus），在服务之间提供连通性支持。

参考架构描述了企业范围内SOA方案所需要的关键能力。

工具是集成架构的基本组件，SOA参考架构则提供了开发服务和业务创新优化服务。开发服务用于实现新开发的组件以及重用基础架构的能力；业务创新优化服务用于从IT和业务两个层面来监控和管理运行情况。

企业服务总线是SOA参考架构的核心。它为整个架构范围内所有服务提供相互通讯的能力。其中传输服务、事件服务以及中介服务都是通过ESB来提供的。

交互服务将IT的功能和数据传递给最终用户，并满足用户特定的使用习惯。

流程服务提供服务控制能力，将多个服务串起来实现一个业务流程。

信息服务通过联合、复制和转换来解决基于不同实现方式的不同数据源之间的数据共享难题。

SOA解决方案中的很多服务都是有已有应用提供的，访问服务提供已有应用、打包应用程序与ESB之间的桥接能力，使得已有应用的功能以服务的形式对外暴露出来。

在业务流程需要与外部的合作伙伴、供应商交互的情况下，伙伴服务提供一组文档、协议以及伙伴管理的能力。

应用服务为新的应用组件提供运行时服务。

作为所有能力的基础，基础服务用于优化通过率、性能和可靠性。

IT服务管理服务包括对服务、应用和资源的管理和保护能力，如通过负载均衡来有效的分配系统计算资源。

SOA参考架构是一个完整的企业架构，可以覆盖整个企业范围内集成的需求。参考架构中的服务通过模块化的方式进行集成，因此SOA的实现可以从一个小的项目来启动，在新的项目实施的时候，新的功能能够轻松的加到架构中，通过渐进的方式在企业范围内扩大集成的范围。

回页首

2. 服务实现

无论怎样进行服务建模，服务最终都将由不同的服务组件来实现。因此服务实现是衔接服务建模和组件详细设计的关键步骤。正如我们在第二部分提到过，服务实现首先将服务分配到相应的服务组件，然后逐个分析服务实现方式并进行技术可行性的验证。

在服务发现的过程中，我们根据业务领域的分析结果将服务按照业务范围进行分类。在服务实现的过程中，将业务范围直接映射到服务组件，从而实现业务与IT的一致性。

服务实现的方式如图2所示。"客户服务"业务组件将实现贷款流程、查询存贷款记录、发放贷款等服务。"风险管理"业务组件将实现评估信用等级、审批、担保等服务。

在我们的示例中，对于服务实现方式的选择，可以分为以下几类：

映射已有功能服务：如查询存款记录、查询贷款记录和担保。其好处非常明显，就是重用已有功能，保护企业的投资；避免重复功能的存在，降低维护成本。但是在选择的过程中，需要考虑传输协议、消息格式的差异，是否可以通过引入中介来弥合服务调用者和实现者之间的差距。需要特别提出的是担保服务，该服务由合作伙伴提供，通过中介将外部的服务进行映射（还需要重点考虑安全性相关的问题），在业务流程中就可以无缝的使用了。
新建流程服务：如汽车贷款流程、评估信用等级。前者是一个长流程（Long Running），由于有人工活动的参与，使得长流程的执行不能在可预期的短时间（如：几秒钟）内完成，需要相关人员在完成自己的任务以后，流程才能进入下一步，常常是几天甚至几个月才能完成整个流程；后者是一个短流程（Micro Flow）。在传统的方案中，业务流程通常采用硬编码的方式将多个功能组装起来；与之相对，我们推荐采用工作流（如BPEL）的方式将服务组装起来，从而达到灵活组装、灵活应对变化的目的。
新建人工服务：如审批。人工服务是相对于自动化服务而言。自动化服务通常由IT系统来提供，不用人为的干预；人工服务则是由企业的员工、合作伙伴员工或者最终用户来执行，但是它同样具备完整的服务描述。采用统一的服务描述来定义人工服务，可以将人工服务与自动化服务统一对待，除了可以在多个应用之间重用人工服务以外，还可以在服务实现从人工活动迁移到IT系统的过程中保持系统的柔性。
新建业务规则服务：如计算信用等级。由于这部分功能不稳定，会随着国民经济的发展、物价水平以及社会环境的变化而变化。将易于变化的这部分逻辑从稳定的架构中剥离出来，可以增强IT应对业务变化的能力。采用业务规则来实现相应的服务，可以相对灵活的进行修改来适应业务的变化，业务规则引擎已经在大量的行业得到广泛的应用。
新建功能服务：如确认购车价格。针对以前没有的功能，或者以前采用人工方式完成的功能，现在可以引入自动化服务来提高业务流程的运行效率。在这里实现了新建功能服务以后，也能在其他的应用中逐步引入，从而达到在企业范围内重用的目的。

图2：服务实现

回页首

3. 架构设计

完成了服务实现的决策，也就对系统的架构提出了明确的需求。不同方式实现的服务，需要系统架构提供不同的能力，例如流程引擎、人工服务引擎以及业务规则引擎等。参考IBM的SOA参考架构，我们设计一下系统架构，将各种不同的服务实现的元素部署到系统架构中，如图4所示。

图4：系统架构

架构关键点分析：

ESB实现机制：

选择一：WebSphere Enterprise Service Bus 优点：内置的转换、路由中介，并且可以通过客户化中介扩展；采用标准的编程模型（SCA, SDO）。

选择二：WebSphere Message Broker

优点：灵活的转换、路由能力；对负载均衡、高可用性上有很好的支持；支持基于MQ的可靠传输；支持多样化的连接方式。

结论：此场景主要是业务部门级别应用，涉及的应用大多数都采用标准化技术，如：XML、Web Service等，也没有特别的分布式应用的需求。因此采用选择一，并利用WebSphere Adapter for CICS将非标准化的CICS应用连接到WebSphere Enterprise Service Bus。在随着企业向SOA全面转型的以后，建议引入Message Broker作为企业服务总线的骨干，当前方案中的WebSphere Enterprise Bus作为一个业务部门级别的节点接入骨干，形成整个企业的服务总线。

应用服务的集成：

选择一：Web Service

优点：支持分布式调用；跨平台；支持开放性标准。

选择二：EJB

优点：支持分布式调用；支持不同的J2EE中间件平台。

结论：企业服务总线是基于J2EE的实现，采用EJB的方式暴露应用服务，具备更好的性能。因此选择方案二。即使将来希望采用Web Service方式，在WebSphere Application Server上也能够很方便的将EJB（Session Bean）暴露为Web Service。

贷款系统的集成：

选择一：通过Web Service访问贷款系统。

优点：支持开放性标准。

选择二：直接通过JDBC访问贷款系统数据库。

优点：支持分布式调用；性能较高。

结论：通过Web Service 访问贷款系统，应用层访问的方式，保证业务的完整性，隔离具体的业务实现。同时避免直接访问数据库带来的安全策略等问题。因此采用选择一。

最终，方案的架构涉及以下IBM的产品。

IBM WebSphere Process Server提供的流程引擎、人工任务引擎和业务规则引擎为流程服务、人工服务以及基于业务规则的服务提供运行环境。

IBM WebSphere Enterprise Service Bus提供的连通性能力以及转换、路由中介能力为企业服务总线提供运行环境。

IBM WebSphere Business Adapter 的连通性能力帮助我们将基于CICS的核心系统功能暴露为功能服务。

IBM WebSphere Application Server提供的J2EE容器为新开发的功能服务提供运行环境。

为了验证架构的可扩展性，可以引入一些变化的场景来分析。

保险公司的多样化支持

由于各家保险公司的IT建设水平参差不齐，因此架构需要能够支持不同形式的接入。

对于能够独立提供服务网关的保险公司，采用Web Service或者socket的方式通过ESB接入。

对于不能提供服务网关的保险公司，可以实现一个人工服务，该人工服务遵循与合作伙伴服务同样的服务规约。可以让保险公司的人员访问该人工服务，或者由银行职员通过传真、电话确认信息，然后访问人工服务。

上面这两种形式的担保服务，对于业务流程是透明的，ESB会根据用户选择的保险公司，将请求路由到保险公司的服务网关或者人工服务。在保险公司建立或者升级自己的服务网关的时候，系统只需要配置或者修改ESB就可以满足业务的需求。

评估信用等级的变化

现阶段，国内还没有统一的信用评估方案，随着相应的业务环境变化导致对信用评估带来的变化，是可以预计到的。

短期的变化可能是信用评估的规则发生变化。由于每年各地的平均收入水平变化，信用评估的规则可能相应的调整。基于业务规则实现的计算信用等级服务，可以灵活的进行规则的修改。

长期的变化可能是引入统一的信用评估平台。由国家或者第三方机构提供一个全国范围内统一的信用评估平台。只需要将现有的评估信用等级业务子流程替换为外部的统一信用评估平台提供的合作伙伴服务，通过ESB来弥合传输协议和消息格式的不同，整个业务流程依然保持不变。

通过对上述变化场景的简单分析，我们验证了架构的可扩展性。当然这种可扩展性只能是在一定的程度上满足业务的变化，也只有通过对业务变化的前瞻性分析，对系统架构进行修正，才能更好的保证架构的可扩展性。这整个过程是一个迭代进行的过程

SOA快速指南 1 2 3，第 4 部分: 快速实现服务集成模型

文档选项

拓展 Tomcat 应用

级别: 初级

2007 年 2 月 01 日

《快速实现服务集成模型》是本系列文章的第四部分。本文承接前面系列文章的分析和建模的结果，主要进行SOA实施的层面上的探讨，首先介绍SOA项目实施的准备工作，然后介绍在实施过程中怎样利用分析建模的结果定义服务并将服务分配到模块中，根据模块的分析得到服务的集成模型，从中总结出一些有价值的指导原则和实施细则，希望对SOA项目方面的开发测试人员有所帮助。本文假定读者能够使用WID进行基本的SCA开发和相关的操作。

回页首

1. 项目实施的准备工作

SOA 快速指南 1 2 3

本系列是 IBM 中国软件开发实验室 SOA 设计中心近年来在 SOA 项目实施中的经验结晶。

在本系列的前面3篇文章中，我们已经了解到，通过业务价值分析和服务建模，经过服务架构的分析和设计，我们能够确定需要实现的服务接口和消息规约，以及服务之间的调用关系。现在我们的任务就是如何实现和构建这样一个以服务为中心的应用系统。

实现服务集成模型是本文的主要内容，我们将讨论如何独立实现相应的集成模块，由架构组在整体层面上把握路线，建立集成模型。本系列文章的第五篇将进一步讨论如何逐步实现服务和持续集成服务。

首先简单分析一下我们的目标，我们的工作此时能得到的输入就是本系列文章的前3篇文章中的输出（服务规约、服务实现决策以及系统架构），我们的目标就是获得相应的输出：一个以服务为中心的应用系统。

我们将会采取如下的基本步骤来实现我们的目标：

1 项目准备:准备相关的软件：硬件环境和组件开发团队。

2 在开发环境中定义服务：使用WID工具定义服务的基本元素。

3 决定服务之间的物理关系和服务集成模型：主要是得到服务集成的顺序和路径。

4 逐步实现服务：使用模拟服务的方法快速实现服务和快速测试。

5 持续集成服务：根据服务模型的顺序持续的集成服务，构建完整的应用系统。

在开发过程中会包括迭代的开发和持续测试。

首先我们回顾前文的工作成果，我们确认系统将要提供以下服务：

服务编号	服务名称
S0	汽车贷款流程服务
S1	确认购车价格
S2	查询存款记录
S3	查询贷款记录
S4	发放贷款
S5	评估信用等级
S6	计算信用等级
S7	审批
S8	担保

因此我们将开始实现层面的探讨，我们将讨论服务组件的划分和实现过程，服务的组成和聚合关系。模拟服务的实现和测试，UI和后台系统的准备。

在本文中，我们主要根据既定的系统架构，实现每个服务的基本框架和SCA模块的基本内容，用于验证概念，与客户交流，安排开发计划和进度。在实际的项目中，最主要的通过本文的工作内容，得到项目结构的全景，通过评审、项目组会议和演示等手段，使得全组对整个系统的实现架构和组成，每个组员的工作，系统的开发和部署单元等都要有全面的了解。

1.1 开发环境

目前供选择的支持SCA编程模型和面向服务的体系架构的开发的工具还不是很多。IBM公司于2005年10月发布的WID6.0是目前比较好的能够支持SCA的开发工具。实际上IBM公司提供了整条产品线能够实现基于SOA的应用从建模，开发，部署，监控等一系列阶段的支持，请参见图1。

图1：IBM支持SOA的产品线。

为了更好的说明SOA的生命周期和IBM产品的对应关系，这里我们提供一个简单的产品表格（以最新的WebSphere 6系列版本为例），参见表1：

表1：SOA的生命周期和IBM产品对应关系

1.2 团队环境

本系列文章前三篇探讨的内容都是由SOA项目小组的早期成员（架构组成员和项目负责人，客户代表，业务分析师，现存系统架构师等）一同完成的，从现在开始，项目小组的重心向开发的方向转变，工作开始产生新一轮的迭代，新的成员加入，原有成员或离开从事新的项目，或坚守岗位，成为项目开发的主要骨干。

我们认为，本系列文章的前三篇所探讨的话题，从时间的角度来讲，主要发生在项目的早期，视项目大小，其所用时间可能从10天到数月不等，参与人员可能从4、5人到十数人不等。除了客户人员外，项目组在早期可能只包括业务分析人员，SOA架构师和IT架构师。因此和传统的项目类似，在项目的早期，团队构成以分析人员，设计人员和架构师为主。

当SOA项目进行到实现阶段，架构设计已经比较明确，此时开发人员和测试人员就要加入，原小组成员需要一天到数天的时间进行知识共享，使得新加入的人员对项目背景，所实现系统的功能有明确的认识。然后根据项目情况和个人情况，组建开发小组。此时我们建议架构师转变角色为开发小组的TeamLeader，保证开发和项目设计的持续性。同时我们强调小组之间的交流和信息共享，以保证项目进度的透明性，使得开发人员对SOA的认识保持一致。

在我们的项目实例中，我们项目小组的组成如表2所示。

表2：示例项目中的项目小组组成。

通常项目团队的分组可能面临两种选择：

一种是水平分组：按照应用的水平层次进行分组，如UI相关，流程相关，中介相关，服务实现后台系统等。

一种是垂直分组：按业务功能划分，以业务流程为中心，功能相关的UI，流程，模块，后台系统为一组。

在以服务为中心的SOA项目中，我们推荐将项目以服务为中心分为2个大的Work Stream：

1 服务实现：

包括新的服务和对现有服务的包装，这样实现的服务将作为基本的服务组件分布在服务模块中，等待互相调用和被流程等方式进行编排。

2 服务集成

包括从UI到业务流程，或者SCA之间的装配。

这样考虑主要是因为服务的实现是可以独立的完成（我们强调SOA中的Service是粗粒度的业务服务），而服务的集成主要体现在流程以及服务模块之间的装配，这样的划分对于我们将来的持续集成有着非常重要的意义。

每个Work Stream之中，可能需要按业务或者技术侧重分成若干小组，同时Work Stream之中，根据人员技能的不同，每个开发人员的角色会有侧重。各Work Stream之间需要保持相应的交流，对于一些重要的技术人员或者领域专家，可以在Work Stream之间实现共享，例如在我们的例子中，有一名BPEL专家主要承担流程编排，并同时为各小组提供相关咨询。

在表3中我们列出SOA项目通常情况下开发人员角色（基于J2EE的SOA项目，以IBM产品为例），供读者参考。

表3：SOA项目开发人员角色和技能列表。

回页首

2. 定义服务的基本元素

在相关的准备工作完成以后，我们将逐步开始接触服务的实现，首先我们会定义服务的基本元素，包括服务的消息格式和服务接口的定义，以及服务的分组。

2.1 定义业务对象和服务接口

在前面的系列文章中，我们经过分析已经能够给出服务之间的规约，现在是时候要开始在开发环境中实现这些定义了。

在项目实施中，我们通常基于一些表格形式的规约进行开发，这些表格的定义基本上是以业务人员为主，是侧重于真实的业务数据的定义，可能会和以前的业务系统的实现有差别，但是请不要怀疑，毕竟，SOA系统并不是以前的业务系统的简单重构，而是需要我们从业务（Business）服务的角度，规划和设计企业的IT架构。

这里给出一些示例：表4和表5。

表4：服务消息规约示例

表5：服务接口规约示例
表5：服务接口规约示例

2.1.1 业务对象

业务对象（Business Object）简称BO，在某种程度上你可以认为BO就是SDO一种特例，关于BO的信息，请参考参考资料《深入了解WPS中的业务对象Business Object》。

示例中的一个业务对象在WID中的定义如图2下所示。

图2：Address业务对象。

在使用WID实施SOA解决方案时，我们推荐将所有的公用的业务对象和服务接口实现于一个Library项目中，供所有需要的模块引用。对于模块内部的私有业务对象和接口，则由模块自己管理。

BO之间的关系可能有如下几种，我们这里简单讨论处理这些关系的时候需要注意的要点：

1 引用

在WID中，虽然在业务集成视图提供了可视化的编辑BO的方式，但你仍然会不时的打开BO对应的XSD定义文件，进行一些手工的操作。

例如，如果你在业务对象A中引用业务对象B，后来又删除了该引用，你仍然需要手工删除业务对象A对应的XSD的import。在SOA迭代的开发过程中，BO之间的关系会经常的发生变化，开发人员必须保证开发工具的视图和定义BO的XSD之间的一致。

2 继承

请注意WID支持BO之间的继承关系，其实现是通过XSD的extension来实现的，WSDL中的消息也是通过XSD来定义的，因此也支持继承。在一个复杂的系统中，业务对象不可能都是一个独立的存在，因此在定义BO的时候，你可能需要考虑继承。并且，我们更关注模块之间共享的BO，这些BO作为消息线索，将串联起主要的业务流程，具有非常明显的业务含义。

例如：我们可能考虑一个抽象的汽车业务对象，派生出客车，货车等不同的业务对象，其对应的贷款规则可能会有变化，通过在流程中组件之间使用抽象的汽车类型，而某些组件内部使用具体类型，我们可以灵活处理，并且类型发生变化时并不影响主要的业务流程。

3 映射

在更为复杂的情况下，WID 支持BO之间的Mapping和Transformer ，从而支持接口之间的Mapping，当然，你也可以使用Mediation模块里面的XSLTTransform来实现消息的转换。

例如保险系统的查询接口，需要使用保险人的姓名，地区，和身份证证件号作为输入，我们可以定义一个保险人查询条件业务对象，使用贷款申请人到保险人的映射来自动完成转换。

实际项目中，在使用WID工具定义业务对象同时，应当尽量将所有的变更记录在案，并和设计文档保持同步。你可以采用自动化的方法，将注释保留在代码中，使用工具生成文档，这样自动保证设计文档和实现的同步。对于定义BO的注释，我们推荐在属性页的注释面板中添加适当的注释，对于在系统间流动的BO，会被不同的开发人员引用，适当的注释可以大量减少你的口舌。对于业务对象中属性，需要考虑到是不是数组，以及是不是必需等问题，我们应该合理的使用这些定义，可以在早期测试的时候发现很多问题。在项目实现过程中，一个微小属性的变化可能带来一系列的问题，因为BO中的属性是强类型的，并且通常会和WSDL接口和Java代码产生很紧密的关联，所以我们应当尽量的事先考虑周全。

2.1.2 服务接口

服务接口的定义在目前的WID中实际上支持两种定义方式，WSDL和Java接口，但一般情况下，模块之间的接口我们使用WSDL，因为WSDL扩展性和通用性都比较好。而模块内部，我们可能使用WSDL，也可能使用Java。如果你的一个Java服务组件不得不引用一个无状态的SessionBean，你就不得不使用该SessioBean的接口来定义这个组件的接口。在使用WSDL接口定义的时候，尽量不要过早的在Process中绑定接口，因为一旦接口的参数的数据组织格式发生变化，Process的调用接口和分配变量部分会发生很大的变化。

如果你希望暴露的接口和你的组件接口不尽相同，你可以使用接口映射，接口之间的映射就需要用到业务对象的映射，而且也可以使用Mediation来做，实际上完成的功能基本上是一样的。

在WID中定义的一个接口示例如图3所示。

图3：WID定义的服务接口示例。

2.1.3 业务对象的映射

SOA采用分层的方法来隔离关注，利用分层可以提高开发和运行时的灵活性，但是层次之间以及层次的对象之间，经常会需要互相映射，这是SOA项目实践中非常常见的一个问题，在定义业务对象的时候，同样需要考虑这样的问题。

SDO的目的是统一数据的格式，然而在遗留系统中难免会有不同的数据源（数据库， LDAP等）虽然SDO提供了访问不同数据源的方式，但是你仍然不能避免SDO和Java对象之间的转化。通常情况下，如果被集成的后台系统是EJB，我们可以使用Web Service来包装EJB，然后在SCA模块中导入该Web Service 可以实现自动调用，在导入WSDL的同时，WSDL中定义的消息会自动转化为BO的XML Schema定义。此时我们就可以通过使用Mapping或者XSLT Transformer来实现BO之间的映射，从而隐式的实现BO到Java的映射。如果你的Java对象的定义不含弱类型对象，或者不含特定的业务逻辑，只是简单的映射，你可以使用JAXB或者XMLBeans轻松的通过配置实现Java对象到XML的映射，通过XML快速生成SDO。

有2种情况你将不得不亲自面对Java对象和BO之间的互相映射（转化）：

1 在特定情况下，因为效率，事务等的需要，不得不在SCA中直接集成EJB，并且你无法使用WSDL轻易的实现映射，尤其是当数据种隐含若类型对象或者隐含特定的业务逻辑。对于常见的J2EE系统，我们会遇见诸如Vector，List，HashMap这样的参数类型，对于这些弱类型的Java对象，虽然WSDL提供了Any 类型，但是一般不太容易交互，所以对于这种情况，你不得不需要使用良定义的Java对象来包装参数，或者将包装后的方法暴露成Web Service，或者直接手工实现Java和SDO的转化。

2 对于UI的重用性，有时候也要涉及BO和Java对象之间的转化。

对于这些情况，我们推荐你使用自己编写的TransformerFactory来生成每个对象和SDO的转化类。我们实现的TransformerFactory实际上是一个Java代码生成器。

值得注意的是，在生成Transformer的同时，我们可以捎带生成测试数据生成器，使用该生成器，你可以在项目的早期生成满足需要的测试数据，以方便单元测试，集成测试，实现自动化的测试。

在我们的例子中，银行内部的房贷系统就是这样一个后台系统，它暴露出EJB的接口，并且设计上采用Command模式，其中包含大量的弱类型参数以保证扩展性，因此我们无法使用WSDL映射来实现自动调用，不得不采用Java代码手工转化。我们在生成转化类的同时也生成测试数据生成类，这也是我们使用TransformerFactory捎带带来的一个优点。

回页首

3. 按不同类型的服务划分服务模块

根据本系列前面的分析，我们已经定义了将实现的服务和接口，但是如何下手开始做服务的编码呢？在SOA的角度，应用程序无非是服务的装配形式，但是，如何组织这些服务呢？SCA 的组件天然的有2种组装模式，一种是模块组装，一种是系统组装，所谓模块组装，就是SCA定义了一种SCA的模块，模块内部会有一个或多个SCA的服务组件通过流程，调用，等方式组成一组功能的集合，该功能的集合（模块）具有显著的业务层面上的价值和意义，所谓系统组装主要就是BPEL，SCA调用等方式，将不同的模块组织，以完成业务流程和业务功能。

WID 为我们提供了很好的SCA开发环境，在WID的环境中进行SOA的开发一般涉及到 SCA模块，Mediation模块，Library等模块。而一个SCA或Mediation模块就会对应多个WID的Project（一个基本的项目，一个Ear项目，一个EJB项目，还有EJB客户端和Web项目等），如果每个服务对应一个模块，就会产生太多的部署单元，系统给人的感觉整体上会杂乱无章，因此我们推荐使用以下地方做法来给服务归类，使用不同的模块来组织这些服务。

1首先将所有的服务归为大类，对于每一类中的多个服务，按照流程相关，中介相关，现有系统相关，新建服务相关，其他相关等模式进行组织。

2 在这个基础上在按功能和业务逻辑上的相关性进行组合，还要考虑部署，开发等的问题，最终均衡各方面的决策，实现一个比较中肯的分类，要以有利于开发和部署为原则，还要和集成的步骤和层次相吻合。

对于每个服务，我们可能会使用一些简单的表格来分析，参见表6。

表6：服务分类分析表示例。

对于我们的实际例子，我们最终建立如下的几个SCA模块：

1 购车贷款审批流程模块

这个模块完全是一个流程模块，它实现贷款的流程，调用其他的SCA服务或者Java服务组件来完成功能。其中包括一个子流程：信用评估流程模块。

2 信用评估流程模块

将信用评估子流程独立出来是希望将来灵活的变化或者根据地区进行定制的时候使得影响面尽量的小。

3 中介模块

我们抽象出一个中介模块，暴露出后台系统的服务接口，对于不同的客户请求，可能需要路由到不同的后台系统进行不同形式的业务操作，该模块实现了一个中介组件。因为后台系统基于CICS，我们使用MQ CICS Adapter实现调用的服务组件。

4 贷款系统包装

对于无法直接集成的现有系统，需要单独实现SCA模块，这样便于测试，模拟，也便于集成时隔离和发现问题，同样有利于后台系统地方变更和迁移。视功能情况的分配可能需要分配多个这样的模块。因此我们有一个对贷款系统的包装模块和一个外部保险担保系统的包装模块。

5 保险担保系统包装

保险担保系统包装模块主要实现了对保险担保系统的包装，提供了担保信息查询的服务。

6 汽车价格查询模块

汽车价格查询模块是一个新建服务模块。新建服务的模块主要是针对我们服务建模的时候新发现的服务而言的。对于新的汽车报价查询模块，银行希望自己实现一个简单的数据库查询系统，从某服务提供商处获取数据，每周更新一次。

通过对模块组成和服务调用的分析，我们可以清晰了解到从服务的角度看，系统将要实现的物理结构。此时，关于各个模块的接口，实现方式，逻辑功能，以及一些规约等都要归档，作为下一步开发的基础。

根据以上的分析，我们会得出表7，将服务映射到SCA模块中实现。

表7：服务与模块映射关系。

该结果将作为进一步分析的依据，成为服务集成模型的重要元素。

回页首

4. 实现服务集成模型

SCA作为SOA的编程模型，可以给我们带来显著的价值，易于集成，实现高灵活性和高开发效率。到目前为止，我们完成了服务和消息的定义，我们将独立的实现服务模块，UI，和后台系统，所有的这一切都是为了集成，集成为我们最终的应用程序。我们的目标就是要以服务为中心，持续集成。

首先让我们关注服务集成的模型，我们所谓的服务集成的模型主要只服务之间关系建立的计划安排和实现步骤。

为什么需要一个服务集成模型？主要有以下两点的考虑：

1 降低风险

2 最大限度利用资源

使用自动化的测试和基于模拟服务的持续集成将是我们实现目标的主要手段。

请注意，我们设计的示例场景经过简化，结构已经比较简单。我们可以假想将示例放在一个更大范围的应用中来看，该应用集成了网上购车，汽车贷款申请，新车手续办理和车险办理的一条龙服务，极大的方便了用户。在这样一种环境下构建服务的集成模型，持续的进行服务集成将变得更为重要。控制好模块之间的关联，制定合理的集成模型可以有效的控制项目的风险。

4.1 模块内部的集成

一个SCA模块将一些相关的服务按一定的关系进行组装，这些关系我们可以分为：顺序，循环，调用，路由等。模块内部的集成也就是模块内的服务组件之间的集成，从Export直到Import之间的路线的完成，实际上也就是服务调用和服务之间的关系的确立，参见图4。在模块内部的服务进行实现的同时，或者还没有进行实现的时候，就应该开始模块内部的集成。尽早集成，可以在没有功能的情况下用模拟服务实现集成，以获得一个模块内部运行路线的全局观念。在开发的过程中不断的迭代，来实现真实的服务替代模拟服务，对于项目的正常推进是非常重要的。

图4：SCA模块内部的集成示意图。

我们建议如果模块不是足够复杂，模块的实现可以作为一个原子的活动，不用区分服务和模块内部的集成，但是如果模块的规模比较大，对于模块内部的服务实现上还是要有一些考虑。

一般来说我们总是会优先实现简单的服务，对于功能复杂的服务，我们会使用门面或者代理的设计模式，将复杂的业务逻辑分解为独立的实现，在简单服务中包装或者代理这些服务，这样也有利于随时修改调用代码或者硬编码实现模拟服务以供测试使用。

请注意在模块内部的集成时，你不一定需要为模块暴露出接口，也不一定要对任何import进行绑定，因为随着全局观念的清晰化和你对项目认识的深入，很多预先定义的接口形式和绑定方式会发生变化。虽然WID的开发工具使得我们对于项目开发过程中的变化的可以快速响应，无需付出巨大代价，但是我们仍然需要尽可能的将变更带来的风险降到最低。

4.2 模块之间的集成

集成（或组装）是SCA中非常重要的概念，你可以想象如果我们的应用程序是一辆汽车，我们的服务就是汽车零件，服务模块这是汽车中的大型部件，最终，我们需要通过组装来实现我们的SOA应用，并且由于组件之间的良定义的接口，我们的组件都是可以替换的。在 SCA的编程模型下，模块之间的集成主要依赖于SCA调用和BPEL。参见图5。

图5：模块之间的集成示意图。

在模块内的集成进行的同时，项目领导小组则开始进行服务模块之间的集成模型的定义。在我们的实例中，我们增加了2组UI模块，供2种场合的使用（个人上网，业务大厅办理）。

在WID提供的SOA开发模式下，我们认为一个SOA应用会主要由以下一些部分构成：UI、业务流程模块、SCA模块和后台系统。

不同的部分会含有多个模块，模块之间的集成，在我们的例子中，我们可以分为两个层次：

1 垂直层次：

UI->服务组合->服务实现->后台系统：主要可能分为与UI的集成，与流程的集成，与现有系统的集成。由于工作量的不均衡，其完成的时间和集成发生的时间点不可能一致。

2 水平层次：

同一类型的模块（如果我们把相关的UI也按模块的相关性分组），之间的进度也不是一致的。

因此，我们会有如下的集成关系分析表：

其中：UI1指大厅用户界面，UI2指网络用户； L1，核心系统；L2，贷款系统；L3，保险系统。

对改表格的横向和纵向的分析将表明我们的模块之间的关系和集成度。

为了保证团队工作量的一致，同时为了降低最终集成的风险，最优化资源，达到最大的效率，都需要我们持续的集成。我们仍然从一个以流程为中心的开发小组为例，首先要考虑模块之间的交叉依赖性，被调用的越多的模块要尽早集成，然后考虑越先完成的模块要越先集成。对于有的模块可能会被多个模块调用，因此有重用交叉的地方优先实现。对于决定系统架构的关键路径上的组件，同样考虑要优先实现，优先集成。

经过各种方面的考虑，我们最终会得出组件的实现顺序和集成顺序，均衡的安排工作量。对于集成的服务模块，首先我们就有实现模块所需时间的考虑，对于模块之间的每个集成都要分析其实现方式，工作量，技术风险等，最终会为每个业务流程得出一个按时间排列的实现和集成任务列表。

根据以上的工作和分析，开发组进本定义了系统的体系结构和一些基础的服务元素，并定义了完整的集成模型，和均衡的计划。下面就需要开发人员根据时间安排，按计划的实现服务，持续的集成服务。至于如何实现持续的集成，我们需要单独实现各服务组件和全面的单元测试，在下一篇文章中，我们将详细探讨。

SOA 快速指南 1 2 3，第 5 部分: 逐步实现服务和持续集成

文档选项

拓展 Tomcat 应用

级别: 初级

2007 年 2 月 06 日

《逐步实现服务和持续集成》是本系列文章的第 5 部分。本文承接上篇文章定义的服务模块和服务集成模型，首先简要介绍了服务模块的逐步实现，对各种服务模块进行分析；然后阐述了如何根据模拟服务进行迭代的开发和集成，其中涉及到服务组件的测试，模拟测试客户端，以及模拟服务的实现；最后强调了SOA实施中的持续集成和持续测试。我们希望通过本文使读者对 SOA 项目的开发和测试形成基础的认识，对于一些重要的方法和特殊的手段能够有所了解。

回页首

1. 服务和服务模块的逐步实现

SOA 快速指南 1 2 3

本系列是 IBM 中国软件开发实验室 SOA 设计中心近年来在 SOA 项目实施中的经验结晶。

在本系列文章的第4篇中，我们通过分析给出了模块和服务的划分，模块的集成模型。持续的集成需要经过确实可靠的测试。值得注意的是，在开发和集成的同时，我们一般只实现模块的部分功能，随后一边集成，一边迭代的实现服务组件的功能。在SOA的开发中，持续的测试和自动化的测试显得尤为重要，因为很多潜在的问题只能在Runtime的时候被测试出来，因此不能将风险留给最后的集成阶段，必须持续测试，并保留测试数据、测试代码和测试脚本。从而在项目后期构建完整的集成测试脚本，实现自动化测试，对系统的变更做最快的反应。

在上面的规划和设计完成后，我们的开发人员对系统的了解已经比较熟悉，因此我们可以根据文档，每个开发小组并发进行服务的独立实现。在这个部分，流程和中介等部分的工作依靠WID的强大功能，实现起来并不会很耗费时间。UI，新实现的服务，包装现有服务的工作量相对较大。我们并不要求这些服务在快速实现服务集成模型的阶段完全实现，出于测试和部分集成的需要，可以先实现有限的路径或者尝试一些模拟服务的实现，在模拟服务中我们根据业务逻辑，返回一些硬编码的数据，随着开发和集成的深入，模拟的部分越来越少，从而迭代的实现系统的功能。

在开发阶段开始后，各小组可以独立进行各自模块的开发，基本上每个小组会负责相关的一些模块。每个小组的成员，都会"OWN"一些模块，请注意，一定要很显式的确定小组成员和模块之间的关系，明确责任感和代码的所有人。每个人对于自己模块的实现都会有自己的方式，但是不能脱离统一的架构和服务的规约。

我们不建议模块之间的过早绑定，因此凡是与绑定相关的工作，除非必要，不然都不要先实现，每个模块应当聚焦于该模块自身的功能。延时绑定的可能会带来以下两点好处：

1 在开发过程中绑定方式等各种条件会随着认识的深入和项目的进展而变化，过早的绑定往往可能需要重新设置，当然使用WID工具，这样的变更往往不是很耗费时间，但是变更带来的单元测试和集成测试以及重新部署等工作，可能会消耗比较多的时间。

2 单元测试阶段可以隔离组件间的影响，专注于组件内部的测试，不需要过早的建立组件之间的联系，以免得到扩散的测试结果。

如我们的上文分析，不同的模块的进展可能不太一样，基本上按照集成的顺序，各模块时间上的需求是越来越大，因此我们可能在模块和人员的配置上做一些有预见性的调整，比如对于我们示例系统的6个模块，在当前阶段，我们可能需要6名开发人员，每人负责其中一个模块，很快随着项目的进展，2流程和1个中介模块就会快速完成。此时可以保留一名开发人员负责这3个模块，其他人员去帮助时间需求更大的模块。主要因为WID实现了很多自动化的方式，提高了BPEL和SCA的开发效率。

在我们的示例中，我们的SCA模块都被业务流程组装起来，如图1所示。

图1：业务流程模块。

本章节的以下部分将分别讨论不同模块的实现和相关的经验。

1.1 业务流程模块

在SOA的环境下，流程作为集成服务的主要手段，起着非常重要的作用，通常情况下，业务流程是最接近展现层，流程向下集成不同的SCA模块，向上提供了用户交互和服务调用的功能，主要被UI集成。WPS中的BPEL流程引擎提供了丰富和功能强大的API，很容易的可以被JSP，SWT等客户端工具集成。

关于具体的BPEL开发，这里不打算详细介绍。在WPS6和WID中，流程的实现更为简单，只需要简单的拖拽和设置，你就能完成一个业务流程的建模。当然IBM也提供了更为复杂和专业的WBM（WebSphere Business Modeler），用于完整的业务流程建模，使用WBM导出的模型文件，WID可以直接射程业务流程组件。

对流程中的每个活动，你都可以增加业务事件的监控，设定CEI的消息，以实现业务监控的相关功能。

在单独实现流程的时候，我们可能需要定义一些模拟的后台实现，使得开发人员专注于流程本身（分支，选择，子流程等），所有的Parnter的实现我们可以先使用Java 组件的方式，使用伪代码或者上文提到的测试数据生成器。

业务流程本身我们是要定义在一个SCA的模块中，尽量使得这个模块只包括流程的逻辑，这样从部署，测试，变更控制等角度来看，都具有很重要的意义。

当这部分工作完成后，看起来这个就是一个完整的流程，包含了"预定"的业务功能，我们部署在自己的测试环境中，使用BPC Explorer 可以进行测试，观察流程在测试数据的运行情况下是否符合我们的预期，人工活动的交互是否满足等。此时的测试还是比较简单的单元测试，主要测试流程的完整性,流程调用和一些简单的业务逻辑。

注：你可以在部署完流程模块后在浏览器中键入"http://localhost:9080/bpc/"来访问BPCExplorer，具体的用法使用请参考WID的联机帮助文档。

在示例应用中我们的业务流程定义如图2所示。

图2：业务流程示例。

业务流程模块中会包含人工服务，需要注意对于包含人工活动的流程，需要设定流程类型为longrunning，同时需要设置相关的事务属性和会话属性，详情请参考相关文档。这里不作详细介绍。

1.2 SCA 模块

这里我们并不打算详细的介绍SCA的基础知识，如欲了解更多SCA的信息，请参考相关的参考资料。

SCA的一个非常重要的特点就是隔离关注，SCA模块强制的将服务的接口和服务的绑定完全分离，服务就是业务的服务，而绑定则是服务的外在表现和通信协议，和服务本身的逻辑是没有交叉的，具体说来，一个模块可以暴露出同一个接口的多种绑定形式，这就可以被不同的业务环境集成。

相比导出的绑定形式（SCA，JMS，Web Service ），WID中SCA的导入绑定形式相比增加了无状态session bean的形式。之所以要增加这个绑定，是为了更好的集成现有的J2EE应用，但是导出则没有这种方式，则是为了向上提供一致性。前面我们也提到，一般的服务组件如果是Java实现，通常的接口是SDO作为数据交换的格式，而如果你的组件import了一个SessionBean，你会发现你的服务组件的接口返回的仍然是该SessionBean的Java对象，此时Java对象和SDO之间的转化就不可避免了，我们在上一篇文章中已经探讨过这个问题。

在SCA的世界里，所有的服务都是SCA的服务，但是只不过是绑定的形式不一样，这符合我们一般的思维模式，比如服务本身的逻辑我们可以类比于是MVC模式中的model，而多种不同形式的绑定就相当于View。

通常我们在WID中一般实现一个SCA模块的过程如下所示：

1 确定模块内的服务组件：定义服务组件；

2 确定模块的接口：定义组件的导出；

3 确定模块要引用的SCA服务：定义组件的导入；

4 确定内部服务组件的实现方式：采用流程、中介、业务规则或是Java实现组件的业务逻辑；

5 确定组件之间的关系：采用流程、连线或者Java代码编排服务。

组件的实现方式的选择，可能和具体的业务逻辑相关联，比如包含路由，分支，映射等更能的组件，就要实现成Mediation Component，如果作为集成的简单的客户端，那么Java Component则是不错的选择。如果你希望将业务规则，状态转化等逻辑从应用中剥离出来，你可以选择Business Rule或者状态机这样的实现方式。例如在我们的例子中，最终判断贷款结果的过程就可以使用业务规则来实现，WPS内建了业务规则引擎，而WID内置了规则编辑器使得你可以将规则作为服务组件的一种实现方式，采用一种可视化的方式，将业务逻辑中最容易变化的部分剥离出来，采用专门的服务组件实现，可以很灵活的配置业务规则。使用业务规则编辑器你可以很方便的创建业务规则集，并将规则和接口绑定，还可以实习很多灵活的配置，对于规则类型的业务逻辑，采用业务规则来实现可以提高效率。

在实现阶段服务还未完成时，根据SOA项目松耦合的特点，我们可以使用模拟服务暂时替代，保证测试过程的畅通和持续的集成测试，实现迭代的开发，下文会有详细论述。

1.3 ESB的实现

ESB的实现实际上就表现为采用中介模块虚拟化原有服务，利用路由实现连通性，利用Mediation实现服务的适配。它能够显著的增加业务逻辑的灵活性，隔离底层服务的区别，提供虚拟化的统一的业务服务视图。

WID很明显的将中介模块和普通的SCA模块区分开来，你只有在中介模块中才能使用中介组件，中介组件主要实现服务的路由，消息的转换等工作。在考虑一个服务中介组件的时候，你首先需要确定中介的类型，尽量将相关的中介逻辑都要放在一个mediation组件中。

一个中介模块中可能有多个中介消息流，在这些消息流之间流动的除了消息外，还有一些上下文，你可以在每个中介节点中读写上下文，实现局部的消息传递。

在我们的例子中，我们采用一个中介模块来实现业务流程到核心系统的路由和消息转换，将中介层从业务逻辑中剥离，可以极大的提高系统的灵活性，实现服务之间的松散耦合。

贷款审批中的中介模块的例子如图3所示。

图3：示例的中介模型。

请注意接口和Partner之间的连线，每个连线都是一个中介流，我们可以进行编辑，增加ESB的相关功能。所以在实现角度ESB包括2层意思，一是ESB服务器，也就是我们选择的WS－ESB Server，他提供运行时的中介和路由能力；二就是ESB的运行时模块，也就是我们的中介模块，上图中的多条连线以及连线内的中介流，他们利用运行时的能力，实现了服务的虚拟化。

1.4 新建服务和后台系统包装

1.4.1 新建服务模块

在SOA的项目实践中，对于新建服务，实现方式上我们有两种选择：

1 独立完成，如采用传统J2EE等方式，实现后采用SCA包装。这样的考虑主要是现有业务模式已经比较成熟，有很多可重用的设计模式和框架，类包的支持，使得新建的服务可以和容易的实现。因此，在实现新建的服务后，以Web Service或者JMS或者EJB的方式暴露出来，在SCA中集成他们，在流程中调用SCA，这是一种比较理想的实现方式。

2 直接在SCA模块中实现业务逻辑。适当情况下，业务逻辑可以存在于SCA的组件中，比较常见的是Java组件或者业务规则组件，状态机等。这样做可以减少在不同的层次之间的调用和映射，提高效率。

具体考虑服务的实现方式可能基于不同的应用会有不同的结果，我们推荐新建服务使用最适合的方式实现，然后使用SCA模块进行调用和集成，这样才能体现SCA的优点，一旦后台系统发生变化，SCA作为中间层会向上屏蔽这些区别。这样所有SCA服务所在的中间层也就是一个ESB。

1.4.2 后台系统包装

SOA将现有系统作为可重用的IT资产管理，重用的方式就需要将这些系统包装成为服务，被业务系统集成和使用。IBM的产品家族为集成现有系统提供了很多的途径，包括Adapter、EJB、Web Service、JMS等方式。

例如，在我们的例子中，我们的房贷系统使用的是基于Command模式的EJBFacad来实现，我们不得不使用Java组件包装在后台系统，首先实现Java对象到Java对象的Mapping，然后在实现包装系统的Java对象到SDO的映射。

使用以上技术，我们将现有系统映射成为SCA模块，现有系统的功能通过该SCA的导出，被暴露成可重用的标准化的服务接口，作为进一步集成的基础，通过重用实现了价值的最大化。

回页首

2. 服务模拟和集成测试

由于项目进度的不均匀性，以及服务实现和服务装配2个不同开发路线上的进度的不均衡，在实际的SAO项目中，经常会发生开发被阻塞或者成员处于等待集成的状态中，因此我们非常有必要实现一些模拟的服务来供我们进行单元测试和集成测试。

2.1 组件测试

对于Java组件，状态机，业务规则或者中介等组件，他们内建的业务逻辑应该首先经过组件级别的单元测试，才会被允许集成。对于组件的集成你可以使用ITC(Integration Test Client)来完成。ITC提供了Emulator 的方式测试流程的运行和连贯性，全部采用人工活动来模拟输入。

同样如果你的逻辑被封装在Java代码中，以服务组件作为门面的话，你可以采用传统的方法如JUnit对你的代码进行测试。注意，此时的测试因为

1 缺乏Runtime 的上下文环境；

2 缺乏真实的业务环境。

所以此时的测试不见得能够说明问题，但是作为单元测试，能够保证组件在测试条件下正常工作，就算为集成和集成测试打了一个好基础。

在使用ITC的时候，所有的服务调用都是模拟实现的，你需要手工的输入服务的返回值，这样主要是为了专门测试集成。为了能够在单元测试的时候测试一些业务逻辑，这里有个小窍门，你可以在配置页面钟中删除那些Emulator以实现自动调用。

2.2 模拟客户端

在UI的工作没有完全完工之前，我们需要一个模拟的客户端，来和流程交互，测试流程的功能。当流程和后面的模块集成后，就可以一直测试到后台系统，同样对于SCA的模块在单元测试的时候，我们也需要的一个模拟的客户端。

使用ITC 首先我们可以使用WID的Integration Test Client，从右键菜单"Test Component"进入该测试界面，ITC会自动生成界面供你选择希望测试的接口的方法，并可以输入参数，开始测试。ITC会将测试结果和测试过程中捕获的异常以可视化的方式展现出来。ITC适用于所有的SCA模块，包括流程模块。在ITC中如果你不希望每次都要输入测试参数，你可以选择将测试参数保存进一个数据池，并将该次测试保存为配置文件，就可以自动加载了。

使用BPC Explore 对于流程模块，如果已经和后台系统或者虚拟服务连接，我们可以使用BPC浏览器来测试流程模块。如前文所述，该方法简单快捷，但是你可能不太容易进行持续的，自动化的测试。值得注意的是，很显然在BPC浏览器的后台，服务器端的代码是在调用BPE的API进行流程的交互，因此你可以自己手工编写测试代码去调用BPE API与流程容器交互，写出专门的针对流程的自动测试代码。

手工编写测试代码

请注意，任何时候我们都推荐使用测试代码进行测试，虽然不是一劳永逸的事情，但的确可以为你带来以下优点：

1 灵活，你可以用各种方式测试你的组件，并通过代码记录下来，你可以灵活的修改它。

2 重用，固化在代码中的测试逻辑，其重用性显然具有重要的价值。

3 自动化，这个是我们认为最重要的地方，借助于自动化的工具（JUnit和ANT），我们可以实现完全自动化的测试。

4 全面，你可以增加数据验证等测试功能，全面的测试你的业务逻辑。

针对一个SCA模块的测试代码看起来像这个样子（示例）：

                        public ConfirmTaxAmount locateService_ConfirmTaxAmountPartner() {
                        return (ConfirmTaxAmount) ServiceManager.INSTANCE
                        .locateService("ConfirmTaxAmountPartner");
                        }
                        /**
                        * Method generated to support implemention of operation
                        "confirmTaxAmount" defined for WSDL port type
                        * named "interface.ConfirmTaxAmount".
                        *
                        * The presence of commonj.sdo.DataObject as the return type and/
                        or as a parameter
                        * type conveys that its a complex type. Please refer to the WSDL
                        Definition for more information
                        * on the type of input, output and fault(s).
                        */
                        public DataObject confirmTaxAmount(DataObject input1) {
                        //TODO Needs to be implemented.
                        return
                        locateService_ConfirmTaxAmountPartner().confirmTaxAmount(input1);
                        }

请注意要在你的测试代码运行时加载SCA runtime的类包，或者使用WID 环境变量。

如上所述，我们同样可以直接调用BPE API和业务流程的引擎进行交互，生成高质量的流程自动化测试代码，实现上则更为复杂，这里就不做详细介绍。

因此我们可以看到，使用一些自动的客户端有以下一些问题：

1 自动化程度低；

2 缺乏数据验证的有效方法；

3 不能应付复杂情况，比如数据复制，上下文关系等。

我们推荐你使用自己的测试代码以保证最好的效率和灵活性。另一个有趣的方法是：

如果你的测试非常的多，手写自己的测试代码可能是一个比较大的工作量，因此我们推荐你研究ITC的API，使用Ant，你可以通过自动化的调用ITC的后台API，加载多个测试文件，实现自动化的测试。关于这方面的话题，每一个展开都会有很多的内容，有兴趣的读者可以自己发挥，自行研究。

2.3 模拟服务和集成测试

仅有组件的有限功能的单元测试，显然是远远不够的。对于已经实现的服务组件，根据我们的集成计划，服务就可以开始适当的集成和集成测试了，此时需要考虑服务的模拟实现。

例如当我们已经完成了一个流程模块和一个中介模块，中介后面的现有服务包装模块还未实现，我们不可能让项目组处于等待状态，因此我们需要模拟一个服务包装模块的服务实现。也就是说我们的服务包装模块的服务组件会有2套实现，一套是用于测试，一套用于开发。

具体的做法比较简单，我们以一个流程模块调用一个SCA模块为例：

1 配置文件：

你可能需要实现一个简单的配置文件，可能就是一个简单的property文件：

testURL=localhost
                        isTest=yes

2 实现一个模拟的SCA模块，其中的服务组件完全是硬编码的模拟服务，该模块的导出应该和真实的SCA模块完全一致。

3 在流程和模块之间应该实现一个中介模块，其导出也是和测试模块一致。

4 在中介中根据isTest的值进行路由，如果是测试，就路由到测试的模拟服务中，否则就调用正常的服务模块。

这样在你的真实的服务没有完成前，你尽可以提供测试的服务实现。一旦服务完成，你只需要修改配置文件就可以轻松的切换测试状态，调用真实服务。这样做的意义不仅限于可以提前供服务编排的测试，保留这些测试代码和模拟服务可以提供2个优点：

1 回归测试，用于流程或者组件重构；

2 适当避免真实的调用，在测试阶段节约宝贵的时间。（在使用WID以及配套的重量级开发环境时进行测试时，频繁的启动和调用服务会花掉测试人员很多的时间，因此除非必要，尽量使用模拟的服务测试前台的功能。）

一旦你开始使用模拟服务，你的测试代码就可以派上用场，会被频繁的重用，或者加入自动构建的脚本中，我们多次强调，自动化测试在SOA这种继承性很强的项目中具有显著的意义。

对于模拟服务的实现程度，最开始你可能都不用考虑业务逻辑，直接返回一些硬编码的值（还记得我们的测试数据生成器吗？），随着测试和开发的深入，你可能需要模拟一些简单的业务逻辑，仅可能的保证测试的质量。你的模拟服务要尽量满足部分测试的目的，主要有以下一些测试目的：

1 测试业务对象和接口在运行时的状态；

2 测试中介和流程的行为是否符合预期；

3 测试被集成的模块之间的连通性；

4 测试错误输入的反应情况。

回页首

3. 持续集成和持续测试

持续集成的基础就在于服务模拟的演进，随着集成和测试的深入，模拟服务的表现会越来越接近真实的服务，在机会成熟的时候，我们会完全连接真实服务进行测试。从而最终实现完整的SOA应用。当我们的测试数据能够满足真实的业务情况的时候，我们的SOA应用就被建立起来了。

3.1 评审和重构

注意在以上各阶段的实现过程中，我们要持续进行评审和讨论，保证设计和实现按照既定的路线前进，所有的变更在计划控制范围内。

评审和讨论的目的有2个：

1 发现不合理的地方；

2 以一种契约的形式规定开发过程。

可能的评审和讨论内容如下：

1 业务对象(BO)和服务接口（WSDL）的定义，包括对象映射和接口映射。

此时的评审主要是要邀请客户的业务专家，客户的技术决策人员，对BO的定义，接口的约定，与后台系统的差距，实现的连通性，整体结构的合理性，进行探讨。

对于发现的不合理的地方，需要重构我们的BO和接口，当经过一定的返工，再讨论后，我们可以以某种契约形式固定这些接口和BO，作为进一步开发的基础。

在修改BO的时候，如果添加和删除BO中的属性，可能需要手工删除import的那个xsd。

添加和删除WSDL接口中的参数，可能会造成流程调用该服务时的参数格式的问题，你可能需要手工修改WSDL文件。

2服务的组装和服务的实现

服务的组装和实现包括流程，中介，组件的调用等，在开发过程中，可能会产生如下的变化：

1 人工服务的实现可能会被机器服务取代；

2 服务的绑定方式会发生变化；

3 由于接口的变化和BO的变化带来的影响；

4 服务实现的变化，例如：可能由Java实现转化为Business Rule实现。

对于这些或者不能避免，或者可以避免的变化，架构组的成员都要仔细讨论，评估变化带来的影响，做出决策，保证项目的顺利进行。

3.2 持续集成

通常情况下流程集成，我们的SOA应用和一般的应用从UI的角度看起来并没有太大的区别。因此在UI的实现上，常见的方式都能够适用，最终的装配可能有2种形式：

1 UI+BPEL；

2 UI+SCA 调用。

无论是那种情况，UI的model可能都是对应SDO，因此可能需要适当的方式做一些SDO的转化，你可以在JSF中直接使用SDO作为数据源进行展现，而且这也是一种比较合理的做法。

对于UI和BPEL流程的集成，我们可能会使用一些BPE的API，我们会在JSP或者Action中启动一个流程，并持续的和流程交互，UI的输入会被映射到流程的人工服务。

对于UI和SCA的集成也会用到WPS中的SCA API，具体可以参考相关的Sample我们推荐 UI、Process和SCA 各司其职，主要的业务功能仍然使用其最适合的方式，SCA和流程主要作为集成的手段，这样，对于开发部署，变更等，系统具有更大的灵活性。在流程模块中，尽量不包含流程以外的业务逻辑，业务功能应当在业务流程之后的SCA模块中实现。

3.3 持续测试

根据我们定义的集成模型，和我们持续的集成，迭代的开发，最终所有的集成会在预定的时间完成，此时我们需要进行完整的全面测试，测试路径将涵盖UI、流程、SCA模块和后台系统。

我们可以先测试一个流程中的一个功能，保证从UI到后台系统的连通性，验证体系结构的可行性。注意如果你对整个结构没有把握的话，这个过程可能提前。通常情况下，具备基础的SOA开发经验的工程师和架构师在设定的架构，都能够满足运行时候的需要，而不会产生全面集成时的大的架构变更。

业务功能测试是一项很巨大的工作，最好确保有一些自动测试代码和log分析工具来协助你进行测试，目前IBM公司也在开展一些SOA testing 方面的工作，希望将来会有整套的方法论和测试工具支持SOA测试。

部署也应该进行测试，以保证你的开发平台和最终的运行环境匹配，因此当你开发进行到一定的程度，应当进行部署方面的测试，部署的测试主要是进行部署和连通性测试，保证环境的问题尽早暴露。因此部署测试应该在至少全部的应用框架都能够运行，但是功能尚未全面完成的时候开始的。

一个具体的SOA项目可能会有数十个部署单元，构建自动部署的脚本是十分必要和明智的，可以帮你节约很多的人力和时间，尤其在项目的后期，进行持续的测试和改进的时候，你会频繁的部署和测试。一般我们使用基于ANT的自动化部署脚本，可以方便的解决问题。

使用Ant工具和jacl部署脚本以及我们在项目过程中积累的测试用例和测试代码，我们最终将完成从开发到部署到测试的自动化集成。

最终的测试脚本会首先从CVS上下代码，然后基于预先配置的类路径自动构建项目，然后实打包项目的EAR文件，然后是部署，最后是使用我们前面完成的测试代码，自动运行测试脚本，打印测试结果。这样项目的开发团队可以实现很高的开发效率。这里我们重复强调一点，因为采用很多动态的技术和弱类型的对象，SCA编程模型对运行时的要求变得更高，很多问题只能在运行时才会发现，因此，持续的测试和自动化的测试将会使得你的SOA开发达到事半功倍的效果。

回页首

4. 总结

回顾我们整个的开发过程，我们会有如下的关键体会：

1 借助新的SOA编程模型来保证设计和实现阶段服务模型的一致性。

服务模型包括服务的消息，接口，服务之间的关系等，我们认为服务模型的概念会一直延伸到SCA模块的层次。在我们的实现中我们借助工具，使用SCA编程模型保证了服务模型从消息定义到服务实现的一致性。

2 通过服务集成模型来降低SOA项目的实施风险：

服务集成的模型包括SCA内部的装配和SCA模块之间装配，以及这些装配的时间，进度，资源的安排。一旦项目的服务集成模型被定义，开发和测试的进度也就基本确定。

3 利用分层和映射来提高SOA开发和运行时的灵活性：

SOA采用分层的方法来隔离关注，层次之间以及层次的对象之间，服务之间，经常会需要映射，这是SOA项目实践中非常关键的一个问题。

4 利用持续的自动化的测试来提高SOA实施的质量和效率：

我们一直推荐采用测试代码的方法进行测试，除了灵活性的考虑，更多的是看重自动化测试带来的优点。对于SOA架构下的复杂应用，自动化的测试具有相当重大的意义。

SOA 快速指南 1 2 3，第 6 部分: 以服务为中心的业务活动管理与监控

文档选项

拓展 Tomcat 应用