《服务实现及架构设计》是本系列文章的第三部分。在第二部分，我们完成了服务建模的前两个步骤：服务发现和服务规约。本文的目的是进行服务建模的第三部分：服务实现，并完成架构设计的工作。第二部分已经整体的阐述了服务建模的概念和方法，本文就不再重复，因此首先介绍IBM的SOA的参考架构，作为架构设计的指导；然后结合场景的业务目标以及IT环境设计试点项目的架构，并重点突出关键点的架构决策。

　　引言

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

　　1. SOA参考架构

　　SOA参考架构是一种组织SOA的构建元素–服务的方式，IBM希望通过这种参考架构为企业架构提供一种指导和参考，使得新的需求能够更快的得到响应。参考架构如图1所示。

　　图1：SOA参考架构
 
　　其中左侧的绿色部分表示建模和组装，中间的蓝色部分表示部署，右边的深蓝色部门表示管理。中枢部分是企业服务总线（Enterprise Service Bus），在服务之间提供连通性支持。

　　参考架构描述了企业范围内SOA方案所需要的关键能力。

　　工具是集成架构的基本组件，SOA参考架构则提供了开发服务和业务创新优化服务。开发服务用于实现新开发的组件以及重用基础架构的能力；业务创新优化服务用于从IT和业务两个层面来监控和管理运行情况。

　　企业服务总线是SOA参考架构的核心。它为整个架构范围内所有服务提供相互通讯的能力。其中传输服务、事件服务以及中介服务都是通过ESB来提供的。

　　交互服务将IT的功能和数据传递给最终用户，并满足用户特定的使用习惯。

　　流程服务提供服务控制能力，将多个服务串起来实现一个业务流程。

　　信息服务通过联合、复制和转换来解决基于不同实现方式的不同数据源之间的数据共享难题。

　　SOA解决方案中的很多服务都是有已有应用提供的，访问服务提供已有应用、打包应用程序与ESB之间的桥接能力，使得已有应用的功能以服务的形式对外暴露出来。

　　在业务流程需要与外部的合作伙伴、供应商交互的情况下，伙伴服务提供一组文档、协议以及伙伴管理的能力。

　　应用服务为新的应用组件提供运行时服务。

　　作为所有能力的基础，基础服务用于优化通过率、性能和可靠性。

　　IT服务管理服务包括对服务、应用和资源的管理和保护能力，如通过负载均衡来有效的分配系统计算资源。

　　SOA参考架构是一个完整的企业架构，可以覆盖整个企业范围内集成的需求。参考架构中的服务通过模块化的方式进行集成，因此SOA的实现可以从一个小的项目来启动，在新的项目实施的时候，新的功能能够轻松的加到架构中，通过渐进的方式在企业范围内扩大集成的范围。

　　2. 服务实现

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

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

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

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

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

　　图2：服务实现
 
　　3. 架构设计

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

　　图3：系统架构
 
　　架构关键点分析：

　　ESB实现机制：

　　选择一：WebSphere Enterprise Service Bus优点：内置的转换、路由中介，并且可以通过客户化中介扩展；采用标准的编程模型（SCA, SDO）。

　　选择二：WebSphere Message Broker

　　优点：灵活的转换、路由能力；对负载均衡、高可用性上有很好的支持；支持基于MQ的可靠传输；支持多样化的连接方式。

　　结论：此场景主要是业务部门级别应用，涉及的应用大多数都采用标准化技术，如：XML、Web Service等，也没有特别的分布式应用的需求。因此采用选择一，并利用WebSphere Adapter for CICS将非标准化的CICS应用连接到WebSphere Enterprise Service Bus。在随着企业向SOA全面转型的以后，建议引入Message Broker作为企业服务总线的骨干，当前方案中的WebSphere Enterprise Bus作为一个业务部门级别的节点接入骨干，形成整个企业的服务总线。

　　应用服务的集成：

　　选择一：Web Service

　　优点：支持分布式调用；跨平台；支持开放性标准。

　　选择二：EJB

　　优点：支持分布式调用；支持不同的J2EE中间件平台。

　　结论：企业服务总线是基于J2EE的实现，采用EJB的方式暴露应用服务，具备更好的性能。因此选择方案二。即使将来希望采用Web Service方式，在WebSphere Application Server上也能够很方便的将EJB（Session Bean）暴露为Web Service。

　　贷款系统的集成：

　　选择一：通过Web Service访问贷款系统。

　　优点：支持开放性标准。

　　选择二：直接通过JDBC访问贷款系统数据库。

　　优点：支持分布式调用；性能较高。

　　结论：通过Web Service访问贷款系统，应用层访问的方式，保证业务的完整性，隔离具体的业务实现。同时避免直接访问数据库带来的安全策略等问题。因此采用选择一。

　　最终，方案的架构涉及以下IBM的产品。

　　IBM WebSphere Process Server提供的流程引擎、人工任务引擎和业务规则引擎为流程服务、人工服务以及基于业务规则的服务提供运行环境。

　　IBM WebSphere Enterprise Service Bus提供的连通性能力以及转换、路由中介能力为企业服务总线提供运行环境。

　　IBM WebSphere Business Adapter的连通性能力帮助我们将基于CICS的核心系统功能暴露为功能服务。

　　IBM WebSphere Application Server提供的J2EE容器为新开发的功能服务提供运行环境。

　　为了验证架构的可扩展性，可以引入一些变化的场景来分析。

　　保险公司的多样化支持

　　由于各家保险公司的IT建设水平参差不齐，因此架构需要能够支持不同形式的接入。

　　对于能够独立提供服务网关的保险公司，采用Web Service或者socket的方式通过ESB接入。

　　对于不能提供服务网关的保险公司，可以实现一个人工服务，该人工服务遵循与合作伙伴服务同样的服务规约。可以让保险公司的人员访问该人工服务，或者由银行职员通过传真、电话确认信息，然后访问人工服务。

　　上面这两种形式的担保服务，对于业务流程是透明的，ESB会根据用户选择的保险公司，将请求路由到保险公司的服务网关或者人工服务。在保险公司建立或者升级自己的服务网关的时候，系统只需要配置或者修改ESB就可以满足业务的需求。

　　评估信用等级的变化

　　现阶段，国内还没有统一的信用评估方案，随着相应的业务环境变化导致对信用评估带来的变化，是可以预计到的。

　　短期的变化可能是信用评估的规则发生变化。由于每年各地的平均收入水平变化，信用评估的规则可能相应的调整。基于业务规则实现的计算信用等级服务，可以灵活的进行规则的修改。

　　长期的变化可能是引入统一的信用评估平台。由国家或者第三方机构提供一个全国范围内统一的信用评估平台。只需要将现有的评估信用等级业务子流程替换为外部的统一信用评估平台提供的合作伙伴服务，通过ESB来弥合传输协议和消息格式的不同，整个业务流程依然保持不变。

　　通过对上述变化场景的简单分析，我们验证了架构的可扩展性。当然这种可扩展性只能是在一定的程度上满足业务的变化，也只有通过对业务变化的前瞻性分析，对系统架构进行修正，才能更好的保证架构的可扩展性。这整个过程是一个迭代进行的过程。