《ESB 项目需求分析和方案设计浅谈》由会员分享，可在线阅读，更多相关《ESB 项目需求分析和方案设计浅谈（10页珍藏版）》请在金锄头文库上搜索。
1、.ESB 案例解析和项目实施经验分享，第 3 部分: ESB 项目需求分析和方案设计浅谈本文是一个由 3 部分内容组成的 系列 文章，在前 2 部分当中，介绍了两个企业 ESB 解决方案的设计案例，这两个案例分别来自于交通运输行业和制造行业，我们针对不同行业的业务和应用特点设计了不同的 ESB 解决方案。第 3 部分内容我们介绍了 ESB 项目实施的一些方法论和经验。前言如同其它 IT 项目一样，企业服务总线类项目的实施也要经历需求分析、方案设计、编码和测试、上线部署等阶段。在介绍了两个特定行业对应的 ESB 解决方案之后，在本系列文章的最后一部分，我们将针对 ESB 项目的设计和实施过程中各
2、个阶段要完成的主要工作内容和一些最佳实践跟大家作一些讨论，进而希望大家在企业 ESB 项目实施过程中借鉴科学的方法论的指导来保证其成功。ESB 的需求分析需求分析阶段是梳理项目中相关功能需求和非功能需求的重要步骤，它是整个项目成败的关键。在这个阶段我们将从企业业务需求出发，梳理端到端的跨系统业务流程；基于业务流程，依据科学的方法论进行服务鉴别；由服务列表出发，梳理服务的消费和提供关系；然后根据 SOA 的最佳实践，定义服务的接口，包括服务的 Schema 描述，字段的类型，编码的规则；依据服务的消费提供关系，梳理 ESB 中的服务映射和转换规则和策略。概括而言，我们需要从功能性和非功能性两个方
3、面来进行 ESB 的需求分析。针对 ESB 的功能性需求，我们要侧重了解以下方面的问题：1. 梳理出要被集成的系统的名称，个数。2. 针对每个系统而言，要了解： 该系统的对外接口是向外调用 (OutBound)，被别人调用 (Inbound)，还是二者都有； 接口的实时性要求，是实时的还是批量的，还是二者皆有？ 接口的调用方式，是同步的还是异步的，还是二者皆有？ 应用系统所运行的操作系统平台。 应用系统本身的编程语言？C/C+, Java. 这些系统现有接口的情况，是否已经可以提供对外接口，接口的方式是什么，包括接口的通讯协议是什么，HTTP/MQ/Socket/ 其它？接口的数据格式是什么，
4、XML/ 自定义格式 / 其他行业标准格式？接口的编程语言是什么，Java/C/C+？如果本身不能提供接口，那么要做接口开发时有什么要求或限制条件？ 这些应用后台数据库的情况，数据库能否直接访问？ 每个应用跟其他应用交换数据时，源数据格式和目的数据格式，比如从文本格式转换为 XML 格式？ 交易特征：哪些处理要采用两阶段提交；是否需要多个消息组成一个交易；是否要保证消息之间的处理顺序； 适配器的情况：对于一些特殊系统，是否已经具备现成的适配器；适配器是单向的还是双向的； 消息通信的模式：是 Send and Forget、Request/Reply 还是 Pub/Sub?针对 ESB 的非功能
5、性需求，我们要确认：1. ESB 平台的扩展性和高可用性需求，包括 HA 和集群等；2. ESB 平台的性能需求，主要包括系统间数据交换的频率，要交换的数据的大小 ( 消息大小将直接对效率造成影响 )；峰值时候对 ESB 数据吞吐量、响应时间的要求等；3. 哪些交易要保证数据传输的高可靠性；4. ESB 平台的可管理性需求，如服务的生命周期管理，ESB 平台的维护和管理；如果企业已经设立了 SOA 管控方面的规范，那么要遵从规范的制约，比如要考虑是否有规定的命名规则，企业是否有企业级的数据规范和底层通讯协议的规范等；5. 安全性方面的要求：是否采用 SSL 传输加密，是否对消息进行加密/解密处
6、理等；6. 错误处理和日志以及平台本身的运行监控等方面的要求等。ESB 的方案设计方案设计的主要内容包括： ESB 涉及 IT 应用环境分析，定义 ESB 与相关应用的接口模式； ESB 架构概要设计，并定义架构原则； ESB 相关产品选择，包括与外围系统的适配器选择和 ESB 产品选择； ESB 组件模型设计，分解 ESB 的相关模块，满足 SOA 的分离关注点等架构原则； ESB 运作模型设计，满足平台的非功能性需求； ESB 平台的服务流设计，涉及路由、转换和映射等； ESB 的同步、异步或者发布/订阅模式设计； ESB 平台的接入渠道和数据接口设计，包括 XML/JMS、SOAP/HT
7、TP、EDI/MQ 等； ESB 相关的适配器设计，包括技术适配器或者自开发的适配器； ESB 平台的容错和重试机制设计，包括日志等的统一管理等；图 1 是一个采用 ESB 整合的高层架构设计举例：图 1. ESB 参考架构如图 1 所示，ESB 架构设计时主要要考虑通讯协议接入和转换、数据接入和转换、数据处理流程以及服务的注册和管理等方面的内容。其中通讯协议接入和转换是指对各种被集成的应用系统的通讯协议的支持和转换能力，例如 HTTP、JMS、Socket、FTP 等；数据接入和转换是指对各种被集成的应用系统提供的数据格式的支持和转换能力，例如 XML、SOAP、自定义格式以及符合某些行业标
8、准的专有格式（SWIFT、EDI、HL7 等）；数据处理流程是指路由、格式转换、数据库读写等对数据的各种处理；统一服务注册存储管理是指对服务的注册、发布、查询，以及对运营时服务的管控，并且提供服务运营状态的统计分析数据。ESB 的组件模型图 2. ESB 组件模型图 2 给出了一个 ESB 组件模型的示例，其中包含的各主要组件及其功能如下：1. Message Broker Runtime 组件提供消息路由、格式转换、消息日志等操作的运行时环境。该运行环境由 IBM Message Broker 提供；2. Messaging Broker Instance 组件是处理基于 MQ 消息业务请求
9、的容器。它是作为一个 Broker 实例运行在 Message Broker Runtime 上的。该实例提供了 MQ 消息的业务请求处理器、服务日志、服务定位等功能的运行容器；3. Web Service Broker Instance 组件是处理基于 Web Service 的业务请求的容器，它是作为一个 Broker 实例运行在 Message Broker Runtime 上的。该实例提供了 Web Service 的业务请求处理、服务日志、以及服务定位等功能。4. Event Broker Instance 组件是平台内部处理 Pub/Sub 事件的容器。它是作为一个 Broker
10、实例运行在 Message Broker Runtime 上的。该容器提供了 Event Handler 组件的运行环境，将基于 MQ/JMS 的事件分发到不同平台组件的目标队列上。5. Message Handler 组件是处理基于 MQ 消息的业务请求，包括消息解析、格式转换，服务鉴权与认证、服务路由、服务日志等功能。Message Handler 组件处理 MQ 消息的典型流程如下： 首先对 MQ 消息进行解析，对解析后的业务请求进行分析，之后通过 Authentication 与 Authorization 组件判断该请求者的业务请求是否可以进行后续处理； 通过 Service Loc
11、ating 组件对该业务请求进行服务定位与路由； 将基于 MQ 的业务请求消息转换成 Web Service 的业务请求消息； 通过 Service Logging 组件对整个业务请求进行日志记录； 返回业务请求处理结果给业务发起者，如果失败，返回错误消息。6. Web Service Handler 组件是处理基于 Web Service 的业务请求，与 Message Handler 组件功能类似，也包括消息解析、格式转换，服务鉴权与认证、服务路由、服务日志等功能。Web Service Handler 组件处理 Web Service 请求的典型流程如下： 首先对 Web Service
12、 请求消息进行解析，对解析后的业务请求进行分析，之后通过 Authentication 与 Authorization 组件判断该请求者的业务请求是否可以进行后续处理； 通过 Service Locating 组件对该业务请求进行服务定位与路由； 通过 Service Logging 组件对整个业务请求进行日志记录； 返回业务请求处理结果给业务发起者，如果失败，返回错误消息。7. Event Handler 组件实现对 Pub/Sub 的处理。8. Service Locating 组件负责根据业务请求定位具体的服务提供者。Service Locating 通过对服务目录的查询选择适合的服务进
13、行后续的调用，该查询工作可以通过实时的服务目录查询获得结果。9. Service Logging 组件负责记录整个业务请求处理过程中的情况，该组件的实现可以通过文件或者数据库的方式。10. Authentication 组件负责对业务请求者进行鉴权，判断该业务请求者是否可以访问平台服务，该鉴权的工作在企业服务总线的外部进行，Authentication 组件只是调用外部功能完成。11. Authorization 组件判断业务请求者是否具备访问某特定服务的权限，该验证权限的工作在企业服务总线的外部进行，Authorization 组件只是调用外部功能完成。以处理基于 MQ 消息输入为例，ESB
14、 的组件交互图如图 3 所示：图 3. ESB 组件交互图ESB 方案设计时的最佳实践根据我们以往项目设计和开发时的一些经验，我们建议进行 ESB 的方案设计时要遵循下述最佳实践：1. 确定标准的使用：使用与否、使用到什么程度；2. 确定在 ESB 上实现的业务逻辑：ESB 是一个服务路由和转换中心，而不是一个应用服务器，因此它并不能取代应有服务器。复杂的消息解析和转换相比简单的路由操作所需消耗的成本要高的多，因此在 ESB 上应该主要考虑路由、格式转换、服务调用等问题，而对于数据本身的处理应该交给相应的应用来完成；3. 确定消息格式：从标准化的角度而言，XML 当然是首选，但是从解析 / 处
15、理性能、行业标准以及对现有应用的最大兼容性的角度而言，可能会采用某些特定格式，例如 EDI、SWITF、平文本或者自定义格式等；4. 区别消息头和消息体：把数据的 Meta-data，例如：安全相关的信息、日志的等级、请求端的标识等放在消息头中，而不要放在消息体中。这样可以很容易地改变其内容及其对其的处理逻辑。在 ESB 中只处理消息头，避免对消息体的解析；5. 设计时参考 ESB 相关的成熟 Patterns；6. 使用服务注册库：如需要服务 Endpoint 的查找：推荐从服务注册中心进行查找，这样的好处在于：服务提供者可以容易地发布新的服务，服务提供者和 ESB 之间的耦合度可以更低，通过关于服务本身的 Metadata 来进行服务的查找和路由；7. 注重性能和高可用性的考虑；8. 在必须的情况下考虑交易完整性；9. 适配器的采用：应用系统通过适配器实现与 ESB 的双向交互，适配器主要分为技术适配器、应用适配器两种，适配器的物理部署可以与 EIS 部署在一起、或者与 ESB 部署在一起，也可以单独部署，在适配器设计时要考虑通信协议和消息格式两个方面；10. 多 ESB 的设计：ESB 也是一个逻辑的组件，在一个企业里可能需要多个 ESB，例如：企业内部 ESB 连接企业内部各个系统，外部 ESB 实现企业与合作伙伴等的外部连接；再如：企业内部可能存在若干个部门级 ESB
