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

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

文档选项 将此页作为电子邮件发送 拓展 Tomcat 应用 下载 IBM 开源 J2EE 应用服务器 WAS CE 新版本 V1.1 级别: 初级 金 戈, IBM软件部企业集成解决方案架构师, IBM 中国软件开发实验室 SOA设计中心 姚 辉 (yaohui@cn.ibm.com), IBM 中国SOA 设计中心高级工程师, IBM 中国软件开发实验室 赵 勇 (zhaoyong@cn.ibm.com), IBM 中国SOA 设计中心工程师, IBM 中国软件开发实验室 谭 佳, IBM 中国SOA 设计中心工程师, IBM 中国软件开发实验室 2007 年 2 月 06 日 《逐步实现服务和持续集成》是本系列文章的第 5 部分。本文承接上篇文章定义的服务模块和服务集成模型，首先简要介绍了服务模块的逐步实现，对各种服务模块进行分析；然后阐述了如何根据模拟服务进行迭代的开发和集成，其中涉及到服务组件的测试，模拟测试客户端，以及模拟服务的实现；最后强调了SOA实施中的持续集成和持续测试。我们希望通过本文使读者对 SOA 项目的开发和测试形成基础的认识，对于一些重要的方法和特殊的手段能够有所了解。 引言 以服务为中心的业务活动管理与监控是最近出现的一种热门的IT技术，它的目的在于帮助企业管理人员实时获悉企业运营状况，了解企业的战略实施进展。 《SOA 快速指南 1 2 3》系列文章是笔者近年来在 SOA 项目实施中的经验结晶。该系列文章结合一个汽车贷款流程， 介绍了在 SOA 的环境下如何基于 IBM 的现有产品构造业务活动管理解决方案，详细阐述了每个实施步骤中使用的 IBM 的方法学、技术和产品。希望通过本文的介绍，能够帮助读者理清业务流程管理所包含的基本概念，并了解构建解决方案所需要的基本步骤。 回页首 1. 服务和服务模块的逐步实现 SOA 快速指南 1 2 3 本系列是 IBM 中国软件开发实验室 SOA 设计中心近年来在 SOA 项目实施中的经验结晶。 项目概述 第 1 部分：SOA 采纳步骤和价值分析 第 2 部分：服务建模 第 3 部分：服务实现及架构设计 第 4 部分：快速实现服务集成模型 第 5 部分：逐步实现服务和持续集成 第 6 部分：以服务为中心的业务活动管理与监控 在本系列文章的第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 应用 下载 IBM 开源 J2EE 应用服务器 WAS CE 新版本 V1.1 级别: 初级 金 戈, IBM软件部企业集成解决方案架构师, IBM 中国软件开发实验室 SOA设计中心 姚 辉 (yaohui@cn.ibm.com), IBM 中国SOA 设计中心高级工程师, IBM 中国软件开发实验室 赵 勇 (zhaoyong@cn.ibm.com), IBM 中国SOA 设计中心工程师, IBM 中国软件开发实验室 谭 佳, IBM 中国SOA 设计中心工程师, IBM 中国软件开发实验室 2007 年 2 月 06 日 《以服务为中心的业务活动管理和监控》是本系列文章的最后一个部分，将结合本系列文章所使用的汽车贷款实例介绍如何实现构建企业的业务流程管理模型。本文的组织方式是：第 2 部分介绍业务活动监控的基本概念，即什么是业务监控，它与传统商业智能之间的关系是什么；第 3 部分描述创建业务流程管理模型的基本步骤，即从何入手建立一个完整的企业业务活动监控模型，第 4 部分则结合本系列的业务场景使用 IBM 最新推出的 WBI Modeler 6 来介绍如何构造一个业务活动监控模型，最后是总结。希望通过本文的介绍，能够帮助读者理清基本的概念脉络，了解构建业务活动监控模型主要的实施步骤，从而为在将来的项目中实现业务活动管理奠定良好的基础。 1 引言 以服务为中心的业务活动管理与监控是最近出现的一种热门的IT技术，它的目的在于帮助企业管理人员实时获悉企业运营状况，了解企业的战略实施进展。 《SOA 快速指南 1 2 3》系列文章是笔者近年来在 SOA 项目实施中的经验结晶。该系列文章结合一个汽车贷款流程， 介绍了在 SOA 的环境下如何基于 IBM 的现有产品构造业务活动管理解决方案，详细阐述了每个实施步骤中使用的 IBM 的方法学、技术和产品。希望通过本文的介绍，能够帮助读者理清业务流程管理所包含的基本概念，并了解构建解决方案所需要的基本步骤。 回页首 2 概念介绍 SOA 快速指南 1 2 3 本系列是 IBM 中国软件开发实验室 SOA 设计中心近年来在 SOA 项目实施中的经验结晶。 项目概述 第 1 部分：SOA 采纳步骤和价值分析 第 2 部分：服务建模 第 3 部分：服务实现及架构设计 第 4 部分：快速实现服务集成模型 第 5 部分：逐步实现服务和持续集成 第 6 部分：以服务为中心的业务活动管理与监控 在当前激烈竞争的市场环境下，企业管理人员面临着巨大的压力提高生产率和削减运营成本。从战术执行的角度来考虑，公司管理人员需要一种手段来帮助自身从纷繁复杂的表象中获取知识，实时获悉企业战略实施情况，及时了解企业运营过程中存在的风险，并做出及时地响应，从而将公司打造成为能够快速适应外界环境变化的有机实体。业务流程管理（Business Process Management, BPM）为实现这一目的提供了有针对性地解决手段。据InformationWeek统计，85%的企业CIO都认为业务流程管理将成为公司利润提升的主要手段。但是，从现有的企业IT环境来看，当前信息技术很难为构建灵活的业务流程解决方案提供直接地支持，这其中存在两个问题：首先是技术异构问题，从长期来看，企业出于保护投资或是选择项目实施合作伙伴的原因，企业信息系统建设通常采用了不同的技术。在经过多年的积累后，企业内部的每一个应用都形成了一个小的信息孤岛，IT本身就成为了一个大麻烦；其次是实时性和适应性的问题，当前市场上存在的商业智能软件能够以数据报表的形式为管理人员提供决策支持，但是传统的商业智能软件主要是对于企业运营历史数据的分析和处理，它能够为企业高层管理人员制定合理的战略提供量化的支持，但是无法反映企业战术层面的执行问题，无法快速响应业务流程执行的异常情况，也无法按照需求的快速变化调整公司运营策略，这种情况被David Luchham称为"IT Blindness"。 面向服务的业务流程管理为解决以上问题提供了可能性。从概念上来看，业务流程管理可以划分为三个层面的内容：业务流程建模、流程执行和流程指标监控。流程建模用于构建公司的业务运营流程模型，它从公司日常的生产经营活动入手，使用业务活动之间的序列关系描述企业的业务模型，帮助业务分析人员识别流程中的瓶颈，从而为流程优化奠定良好基础。业务流程建模是整个过程的第一步，也是最关键的一步，它不仅需要确定业务活动之间的序列关系，还需要确定业务模型中所包含的业务绩效指标信息。在分析人员确定企业的流程模型之后，软件架构师需要将流程模型转化为以服务为单元的体系结构模型，并由开发人员和集成人员加以实现。需要指出的是，业务流程的运行平台通常是企业服务总线，它体现形式可能是BPEL，也可能是MQ Flow，它们一个共同的特点是跨越了多个应用系统。最后是流程监控，流程监控是对于业务操作的记录，它一方面保存了业务运行的业务数据，如销售金额，另外一方面也保存了流程本身的信息，如时间信息和异常情况等。从运行的角度来看，流程监控软件会按照分析人员规约的流程监控模型收集系统业务事件，加以分析处理，进而将其转化为对于业务人员具有明确含义的关键业务指标，并以图形化的方式将分析结果展现在用户面前。流程建模、流程执行与流程监控构成了一个闭环的回馈系统，该系统使得企业能够根据自身业务流程特点，准确识别企业运行过程中存在的种种问题，并快速适应外界环境的变化。 2.1 基本概念 业务流程管理主要包含业务目标、关键业务绩效指标和业务度量等基本概念。业务目标是整个业务流程管理构建过程的起点，它描述了机构为达成良好增长所需要达到的条件，其描述方式通常是使用自然语言，如"本年度公司销售额增长率为10%"、"本季度公司利润增长率为5%"、"专利申请总数达到1000件"等。业务目标可以认为是公司高层管理人员按照公司的战略规划为整个组织所设定的里程碑，它不仅可以作为公司业绩的体现，也可以作为员工绩效考核的基础。业务目标具有如下几个特点：首先是可分解性，即整个公司拥有一个总体目标，其下属机构应该根据其自身环境确定每一个分部门的目标取值，每一个员工也会确定自己在本年度的个人绩效指标；其次是可实践性，业务目标必须建立在高层管理人员对于公司实际情况以及整个市场环境的精确判断上，它必须是可操作的；最后是风险性，业务目标只是一种预期，而市场环境瞬息万变，所以管理人员也必须意识到业务目标只是一种手段来帮助企业更好的成长。业务目标的确定不能仅仅局限于公司领导的经验，同时还需要行业咨询人员的帮助。在设计整个公司战略规划时，领导通常需要在业内资深咨询人员的帮助下构建企业总体执行战略，同时将业务目标作为一种战术手段推进执行的力度和激励员工的士气。 在确定公司的业务目标后，如何推进公司能够顺利地达成该目标成为执行的关键。业务流程管理认识到每一个公司所从事的业务活动都可以被划分为若干具有明确业务含义的业务流程，从流程出发度量整个公司的运营状况比单纯从数据出发更加容易，而且也拥有更加丰富的监控内容。所以，IT业界纷纷推出构建在SOA基础上的业务流程管理软件。为了从IT层面上支撑整个业务流程管理框架，业务流程管理还需要一组细化概念的帮助，其中最为重要的是关键业务绩效指标(Key Performance Indicator)和业务度量(Metric)。关键业务绩效指标是对于当前企业运营流程的度量，它通常是从高层描述了企业运营的某一个侧面，如贷款申请中的业务增长率和不良贷款变化率等。KPI是业务目标在特定流程层面上的细化，通常可以使用数值来度量，并且业务人员会为其设定变动的上限和下限范围。业务度量则是对于KPI的细化，它代表了一个可独立计算的数据项，但是可能在业务上并没有明确的含义，如贷款申请流程的启动时间和结束时间，而业务人员可能真正关心的是所有流程的平均处理时间。通常而言，每一个业务度量都代表了一次业务流程执行实例的特定侧面，而关键业务指标则是对于这些侧面的统计度量。所以，关键业务指标从IT层面上提供了一种可量化可操作的手段帮助公司高层管理人员实时获悉企业战略执行情况，了解运营过程中存在的风险，并为构建快速适应外界环境变化的机构奠定良好基础。 为了实现以上需求，从运行层面来看，面向服务的业务流程管理需要提供如下功能：首先，业务流程管理必须支持从各种数据源提取有意义的业务数据，并将它们组合成为具有明确业务含义的关键绩效指标(KPI)，这些数据源可能是关系型数据库，也可能是企业服务总线中的消息Hub；其次，业务流程管理需要针对流程运行的异常情况及时发送相关预警消息。业务人员在访问界面上设定某些关键绩效指标的阀值，当指标取值一旦超出预期范围，系统需要为业务人员发送预警消息，其手段可以采用邮件、即时消息或是短消息等；最后，业务活动监控需要以报表的形式对于历史数据做出相应的统计，系统按照特定的纬度对于数据做分类计算，如按照产品种类、时间范围或是空间范围等，这些统计数据以仪表盘（Dashboard）的方式为管理人员提供了直观的交互界面。 2.2 业务流程管理与商业智能 理清了业务流程管理所包含的基本概念内涵，接下来我们来看业务流程管理与商业智能(Business Intelligence, BI)之间的关系。商业智能为公司高层管理人员提供了一种量化的决策分析支持手段，它从公司历史业务数据入手，通过挖掘当前数据模式与预测未来趋势，BI为管理人员制定公司长期的经营战略奠定了良好基础。而业务流程管理则关注公司流程执行层面，它注重的是公司短期战术的执行，为公司运营提供了更加精细的监控手段。从本质来看，商业智能关注的是公司长期战略规划的问题，而业务流程管理解决的是公司短期战术执行的问题。业务流程管理与商业智能的区别在于：首先，从实施目的来看，业务流程管理更加着重于流程的管理与再造，通过使用流程建模工具将公司日常操作形式化，业务流程管理可以帮助管理人员更好的识别流程中的活动瓶颈，为流程优化奠定基础；而商业智能则着重于从现有数据集合众挖掘有意义的业务指标，为管理人员做出正确的长期战略决策提供帮助。其次，从建模内容来看，业务流程管理的内容包括流程建模、服务建模和业务对象建模等，而商业智能的基本实现步骤主要是基于现有数据库定义规约数据的挖掘维度，从中提取有明确业务含义的内容。再次，从操作对象来看，业务流程管理主要针对的是系统存在的服务和流程，而商业智能主要操作的对象则是数据库中当前存储的数据。最后，从实现手段来看，业务流程管理主要基于实时从业务流程中获取的业务事件，并将其转化成为有意义的业务数据，而商业智能则需要按照数据挖掘模型，从数据库中提取有意义的数据。另一方面，业务流程管理与商业智能之间又存在着紧密的联系，商业智能为业务流程管理的数据分析与聚合提供了良好的实现手段。在涉及到业务指标的多维计算与挖掘时，商业智能作为一种成熟的技术实现手段可以为业务流程管理提供良好的支持。 回页首 3 方案规划 在用户实施业务流程管理解决方案的过程中，第一步通常是明确企业的流程模型和服务模型。流程模型是具有明确业务含义的业务活动序列，它是对于企业日常操作的抽象，流程分解对于服务识别具有极其重要的意义。每一个服务都代表了系统中具有明确业务意义并且可复用的功能。本系列前述文章已经详细描述了如何从需求入手构造企业的流程模型和服务模型，本文不再赘述，下面本文将详细介绍如何基于已有流程模型构造企业的业务流程管理解决方案。 3.1 规划目标 WBI Modeler 6.0业务指标规约主要可以分为三个方面：业务指标规约、数据纬度分析和预警消息定义，这三个方面各有侧重，分别用于解决不同问题。 业务指标规约：业务指标定义最主要的目的是解决从问题域的业务目标描述到解域的业务指标规约的问题。在业务人员看来，业务目标通常是使用自然语言描述的业务陈述，如"本年度公司利润率预期增长10%"，"货物订单处理时间不超过三天"等。但是计算机通常无法识别以上陈述，其中的概念鸿沟就是通过业务指标定义来弥补。业务咨询人员或是业务分析员按照预先规约的业务流程与业务对象，建立形式化的业务指标规约模型，并将其与业务事件相互映射。在本阶段，相关人员使用WBI Modeler提供的关键绩效指标(KPI)、业务度量(Metric)、触发器(Trigger)、秒表(Stopwatch)和计数器(Counter)等基本概念来建模公司的业务度量指标。其中，关键绩效指标和业务度量是最核心的概念，而其它概念则是对于以上概念的延伸和扩展。 数据维度分析：实时数据维度分析是整个业务监控模型构建中重要的一环。业务指标规约解决了模型定义的问题，但是公司真正关心的是如何更好的从这些数据中挖掘出与绩效考核和流程优化相关的信息，这些系统通常是基于某些可比较的维度，所以为业务指标模型定义合适的数据分析维度非常重要。大致而言，数据分析维度的定义通常是基于一些分类信息，如产品类别、处理时间和销售地点等。业务流程管理基于这些分析类别，帮助公司管理人员按照区域或时间段实时展现和分析整个公司的运营情况，比如全国哪一个区域客户投诉率最低，哪一个区域取得了最大增长等，然后据此调整公司战术，为关键绩效指标的实现奠定良好的基础。 预警消息定义：预警消息是业务异常在流程执行层面的具体体现。当关键绩效指标未满足业务人员预先设定的区域变动阀值时，系统会自动提示业务操作人员，警告用户当前流程执行出现问题，需要人工干预加以解决。流程异常可能来自于多种原因，从流程实例运行的角度来看，可能是由于实例运行时间超过了最大服务时间，如贷款申请时间超过了银行预先申明的5个工作日等；从业务数据的角度来看，可能是由于业务数据统计数值未达到预先设定的目标，如某一个特定时间段银行的不良贷款率快速增长，超过了预先设定最大限额。所以，识别并定义这些预警消息是创建实时企业极其重要的一个环节。构建一个良好的预警消息模型依赖于两个方面的能力，首先业务人员需要清楚什么是真正的业务异常，什么样的异常需要用户及时的处理，另外一个方面则需要设定良好的变动阀值，阀值变动范围过窄会使得用户每天会收到大量的预警消息，从而降低用户处理业务异常的意愿和能力。 3.2 实施模型 业务目标、关键绩效指标和业务度量是整个业务流程管理框架的核心概念，它们覆盖了整个业务层面对于流程管理的需求。但是，从技术实现的角度来看，这些概念过于抽象，仍然无法保证实现一个良好的可操作的业务流程管理框架，这其中的问题主要是业务领域与IT域之间存在的差距。为了解决该问题，IBM WebSphere Modeler 6.0在以上三个概念的基础上构建了一个更加丰富的概念集合，如计数器、触发器和环境事件等，这些内容为开发人员实现基于流程的业务监控奠定了良好的基础。整个实施模型的概念框架如下图所示： 图1：IBM业务流程管理解决方案概念框架   关键业务绩效指标(KPI)：KPI是对于业务目标的量化规约，在WBI Modeler中每一个KPI都对应于一个业务流程类型，而不是业务流程实例。缺省情况下，KPI定义至少应该包含以下属性：名称、类型、计算函数、度量数据来源以及波动范围边界（通常包含上边界与下边界两种）等。 业务度量(Metric)：业务度量是对于流程实例运行过程中某一个侧面的记录，同时也是对于KPI的细化，它可能并不具有明确的业务含义，但是多个业务度量指标合起来可以计算一个业务绩效指标。比如，银行贷款流程实例的启动时间和终止时间对于业务人员是无意义的，但是该流程的平均处理时间对于业务人员而言则是有意义的。大致而言，WBI Modeler中的业务度量可以分为三类：业务数据度量、实例度量和聚合度量等。业务数据度量记录了流程执行过程中业务数据的属性变动，或是业务数据自身；实例度量则记录了流程执行的结果；聚合度量是对于其他度量数据的统计和计算，它用于发现以上度量集合中的最大值、最小值或是平均值。 秒表（Stopwatches）：秒表是一种特殊的业务度量类型，它记录了流程、活动或是活动集合执行所花费的时间。秒表具有两个特殊的属性：启动时间和终止时间，当接收到启动时间时秒表开始计时，接收到停止事件时终止计时，接收到重置时间则将计数值清零。所以，秒表可以接收多种触发事件。 计数器（Counters）：计数器也是一种特殊的业务度量类型，它记录了业务事件发生的次数。计数器的一个基本属性是计数值，它通常根据某一个预先设定的条件来确定是否将计数值加一、减一或是清零。 触发器（Triggers）：触发器提供了一种机制能够启动某些动作的执行，比如，开发人员能够通过触发器来执行业务度量数据更新的动作。大致而言，触发器有两种：外部触发与内部触发。外部触发是指当流程状态被改变或是接收到某一个活动的输入时，流程实例显式发出一条触发消息，推动整个业务流程管理的执行，而内部触发则是指模型内部的业务度量值被更新或是计数器发生变化并且满足某一条件后触发器被执行。触发器提供了一种机制使得开发人员能够灵活的定义整个监控模型的执行步骤，从模型整体来看，触发器会最终会构成一条执行链。 事件（Events）：事件可以分为两类：输入事件（Inbound Event）与环境事件（Situation Event）。输入事件是指流程监控引擎所接受到的外部事件，该事件一般会触发整个监控过程的执行，如流程开始运行，或是贷款被批准时，流程引擎都可能产生输入事件，从而启动触发某些外部触发器的执行。环境事件则是指由流程引擎主动发出的事件，如果关键业务指标或是业务度量满足特定的边界条件，则监控引擎会自动发出业务事件提醒业务人员，此时发出的事件就是我们之前讨论的预警消息。 回页首 4 实例分析 针对本文所使用汽车贷款流程，下面我们来介绍如何创建该银行的业务流程管理解决方案。从业务流程管理的整个生命周期来看，流程建模为运行时刻的流程监控提供了元模型，该模型会指导监控引擎从纷繁复杂的IT系统中抽取真正有意义的事件和数据，并最终汇集成为业务绩效指标数据。从汽车贷款流程来看，其基本的业务步骤包括：用户提交申请，信贷专员实行资信评估，信贷经理审批，最后知会申请人审批结果。我们现在的问题就是为这样一个简单的流程构造一个真正反应用户需求而且灵活易于扩展的业务监控解决方案。从实施步骤来看，整个过程可以被划分为如下步骤：识别业务目标、确定关键业务绩效指标、构建映射关系、建立预警规则和设计触发时间。 1) 识别业务目标：确定公司业务目标是整个方法中的第一步。分析人员通过与业务人员反复讨论，首先需要确定公司整体的业务目标规划。这一步骤中非常重要的一个原则就是分析人员需要与真正的业务人员紧密协作，需要由业务人员来确定什么是其公司的业务指标，而不能由分析人员越俎代庖。就汽车贷款流程而言，不良贷款比率与流程执行时间是两个比较重要的指标，其中不良贷款比率决定了公司的盈利状况，而贷款流程的执行时间则反映了贷款部门的工作效率，从而进一步影响了客户的满意度。本文将贷款流程执行时间的业务目标定义为5个工作日答复客户，不良贷款比率的业务目标设定为10%。公司整体业务目标规划的确定并不是本阶段的结束，开发人员还需要根据某些维度来细化业务目标，比如按照时间段、产品类别和公司机构等做进一步的细化分，确定每一个类别的业务目标。最后给出的结果是一份详细描述了客户需求的业务目标规约文档。 2) 确定关键业务绩效指标：在确定业务目标后，设计人员需要将业务目标转换为业务度量，即以量化的手段来描述业务目标。KPI可以是业务目标的量化体现，它从流程执行的层面定义了如何计算业务目标取值，以及该取值目标变动范围的大小。以汽车贷款流程为例，流程执行时间存在一个最大执行时间，一旦某一个申请案例处理时间超过该时间，需要及时通知相关的业务人员，并做出相应的决策以保证业务能够及时被完成。本文将贷款申请流程的关键绩效指标标准取值为4天，变动范围为-1~+1天。从运行的角度来看，KPI的标准取值与变动阀值通常是可配置的。 3) 构建映射关系：KPI定义了业务人员需要监测的内容，但是如何基于现有数据计算KPI还需要开发人员做进一步的映射。一般而言，KPI的计算公式是在业务度量数据上施加相关的聚合函数，如求最大值、最小值或平均值等。所以，第三步需要定义相关的业务度量模型，并在业务度量以及KPI之间建立相关映射。仍然以汽车贷款流程的平均处理时间为例，设计人员需要首先创建两个业务度量来保存贷款流程实例的启动时间和结束时间，然后创建一个实例度量来保存单个流程实例的处理时间，最后对于所有的实例度量求平均值，从而计算所需要的流程平均处理时间。 4) 建立预警规则：在确定KPI以及相关的映射关系后，开发人员还需要建立预警规则。预警规则通常是具有明确业务含义的提示信息，它用于在流程执行出现异常时向相关人员发送预警消息，如KPI取值超出其变动范围。在该步中，开发人员需要首先根据业务绩效指标，确定规则触发的条件，然后确定条件一旦被触发系统所需要采取的动作，可以采取的动作类型包括向业务人员发送电子邮件，发送手机短消息或是向应用特定的数据库中写入纪录等。以汽车贷款流程为例，预警规则可以定义为当汽车贷款申请流程执行时间超过5个正常工作日时会自动向相关业务人员发送警告消息。需要注意的是，预警消息不一定只能服务于关键绩效指标，开发人员同样可以为业务度量定义预警规则。 5) 选择触发事件：业务流程监控与传统商业智能的重要区别之一就在于其主动性，即能够实时响应外界环境变化，整个监控过程由触发事件来启动。触发事件来源有很多种，事件可能来自于流程运行所提供的状态事件，也可能是应用系统显式发出的异步消息。当触发事件发生时，系统启动业务绩效指标的计算，然后根据计算结果选择是否发出预警消息。从某种意义上来看，触发事件实际上是IT系统执行日志的体现。当某些动作发生时，IT系统显式的告诉业务活动监控构件，系统数据已经被改变，并且根据用户定义的监控模型需要采取某些行动。 下图是对于业务平均处理时间监控指标的建模。从图中我们可以看出，在流程启动即第一个活动开始运行时触发贷款申请启动触发器，该触发器直接启动了秒表计时。在流程运行结束时即最后一个活动完成时触发贷款申请结束触发器，该触发器结束秒表计时。所以，每一个流程实例都会拥有业务处理时间。KPI对于所有的业务处理时间执行平均值运算，获得的就是整个流程的平均业务处理时间，而且能够以图形化的方式显示给业务人员。 图2：银行汽车贷款流程平均处理时间建模实例   回页首 5 结束语 面向服务的业务流程监控是一种新型的IT技术，它以流程为基本监控单元，帮助业务管理人员实时获悉企业内部运营状况，分析未来趋势，挖掘业务运营风险，从而为创建快速响应的实时企业奠定良好基础。本文首先阐述了业务流程管理的基本概念，然后对于在SOA的环境下如何构造业务流程管理解决方案作了较为深入的说明，最后结合银行贷款流程场景的说明如何构造业务流程管理的解决方案。希望通过本文的介绍，能够帮助开发人员深入了解业务流程管理的基本概念，并为在将来的项目开发中正确使用相关技术做好准备。