2. 服务实现

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

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

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

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

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

    图2：服务实现

   
　
　  3. 架构设计

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

    图4：系统架构