4. 实现服务集成模型

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

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

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

    1 降低风险

    2 最大限度利用资源

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

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

    4.1 模块内部的集成

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

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

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

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

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