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，保险系统。

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

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

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

    根据以上的工作和分析，开发组进本定义了系统的体系结构和一些基础的服务元素，并定义了完整的集成模型，和均衡的计划。下面就需要开发人员根据时间安排，按计划的实现服务，持续的集成服务。