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

　　引言

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

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

　　在本系列文章的第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架构下的复杂应用，自动化的测试具有相当重大的意义。