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