SOA快速指南 1 2 3，第 3 部分: 服务实现及架构设计

最新推荐文章于 2024-11-12 16:26:38 发布

dlwvvx1943

最新推荐文章于 2024-11-12 16:26:38 发布

阅读量170

点赞数

文章标签：系统架构数据库人工智能

原文链接：http://www.cnblogs.com/HeroBeast/archive/2009/04/07/1431247.html

版权

级别：初级

姚辉 (yaohui@cn.ibm.com), IBM 中国SOA 设计中心高级工程师, IBM 中国软件开发实验室
金戈, IBM软件部企业集成解决方案架构师, IBM 中国软件开发实验室 SOA设计中心
赵勇 (zhaoyong@cn.ibm.com), IBM 中国SOA 设计中心工程师, IBM 中国软件开发实验室

2007 年 1 月 31 日

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

引言

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

回页首

1. SOA参考架构

SOA 快速指南 1 2 3

本系列是 IBM 中国软件开发实验室 SOA 设计中心近年来在 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所示。

图4：系统架构

架构关键点分析：

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 访问贷款系统，应用层访问的方式，保证业务的完整性，隔离具体的业务实现。同时避免直接访问数据库带来的安全策略等问题。因此采用选择一。