《esb提供事件驱动和文档导向的处理模式》由会员分享，可在线阅读，更多相关《esb提供事件驱动和文档导向的处理模式（14页珍藏版）》请在金锄头文库上搜索。
1、ESB 提供事件驱动和文档导向的处理模式，以及分布式的运行管理机制，支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。ESB 是中间件技术实现并且支持 SOA 的一组基础架构，支持异构环境中的服务、消息以及基于事件的交互，并且具有适当的服务级别和可管理性。ESB 是 SOA 中的消息框架，即消息相互交换和通信的方式，是业界标准与客户消息框架的整合。分布式部署和集中控制。ESB 服务器在物理上可能相隔很远，但是通过集中管理，这些服务器组成一个 ESB 网络，在逻辑上形成完整的企业服务总线。服务注册、发布和编排。在 Apusic ESB 的服务仓库中，任何符合标准的服
2、务都可以在其中注册，从而被其他服务调用。而消费服务也无需知道被调用服务的具体特征，只需要发送相应地请求即可找到相应的服务，并进。行绑定和数据的传输。同时为了满足具体的业务需求，不同的服务需要被组装在一起形成新的应用系统。Apusic ESB 引入了工作流流程的概念，引入自主实现且基于业界标准的，具有条件分支和合并并行流转功能的BPEL4WS 流程引擎，从而实现综合的、复杂的业务逻辑编排。这个流程引擎支持子流程、条件脚本、路由节点等功能。通过灵活的流程定义，按照即时的业务需求，将单个离散服务有机的组合起来，达到服务重组的目的，完成集成的业务需求。 此外，Apusic ESB 在引擎级别将 BPE
3、L 规范的细节进行了包装，对用户来说，只需要关心流程中的一个服务即可，无须再去关心 BPEL 的具体技术细节。 最后，所有的调用、转换都必须有一个良好的管理工具来帮助实施，并进行监控。Apusic ESB 则提供了一体化的管理工具，通过这些工具，您可以非常方便的对 ApusicESB 进行集中式管理、可视化的流程设计，以及运行期的实时监控等功能。SOA 项目不应从 ESB 开始,因为 ESB 只是技术手段，而 SOA 的目标则是业务价值。对技术手段的过分重视往往使人们忽略了 SOA 的最终目标，陷入在技术的泥潭当中不能自拔。 以 ESB 来启动一个 SOA 项目是有害的，它将陷入技术的怪圈中，
4、而无法产生最大的业务价值。业务才应该是 SOA 开始的起点和最终的目标。你首先要在业务上进行服务的分解，然后才把他们映射到技术实现中。 SOA 项目的实施必须从业务需求的分析开始，而不是从构建 ESB 来开始。SOA 框架体系下的软件开发，应该是从业务流程分析开始的，用一些组件化的业务建模方法，对实际的业务场景进行分析。在这个基础上建立业务用例，并根据这些业务用例构造业务流程模型。ESB 不过工具和技术而已，关键上集成业务如何做?业务逻辑如何编制?如何实施? ESB 项目需求分析和方案设计浅谈2010-1-6如同其它 IT 项目一样，企业服务总线类项目的实施也要经历需求分析、方案设计、编码和测
5、试、上线部署等阶段。下面我们将针对 ESB 项目的设计和实施过程中各个阶段要完成的主要工作内容和一些最佳实践跟大家作一些讨论，进而希望大家在企业 ESB 项目实施过程中借鉴科学的方法论的指导来保证其成功。TT SOA 编辑推荐： 企业服务总线 ESB（更新版）ESB 的需求分析需求分析阶段是梳理项目中相关功能需求和非功能需求的重要步骤，它是整个项目成败的关键。在这个阶段我们将从企业业务需求出发，梳理端到端的跨系统业务流程；基于业务流程，依据科学的方法论进行服务鉴别；由服务列表出发，梳理服务的消费和提供关系；然后根据 SOA 的最佳实践，定义服务的接口，包括服务的 Schema 描述，字段的类型
6、，编码的规则；依据服务的消费提供关系，梳理 ESB 中的服务映射和转换规则和策略。概括而言，我们需要从功能性和非功能性两个方面来进行 ESB 的需求分析。针对 ESB 的功能性需求，我们要侧重了解以下方面的问题：1. 梳理出要被集成的系统的名称，个数。2. 针对每个系统而言，要了解：该系统的对外接口是向外调用，被别人调用，还是二者都有； 接口的实时性要求，是实时的还是批量的，还是二者皆有？ 接口的调用方式，是同步的还是异步的，还是二者皆有？ 应用系统所运行的操作系统平台。 应用系统本身的编程语言？C/C+, Java. 这些系统现有接口的情况，是否已经可以提供对外接口，接口的方式是什么，包括接
7、口的通讯协议是什么，HTTP/MQ/Socket/ 其它？接口的数据格式是什么，XML/ 自定义格式 / 其他行业标准格式？接口的编程语言是什么，Java/C/C+？如果本身不能提供接口，那么要做接口开发时有什么要求或限制条件？ 这些应用后台数据库的情况，数据库能否直接访问？ 每个应用跟其他应用交换数据时，源数据格式和目的数据格式，比如从文本格式转换为 XML 格式？ 交易特征：哪些处理要采用两阶段提交；是否需要多个消息组成一个交易；是否要保证消息之间的处理顺序； 适配器的情况：对于一些特殊系统，是否已经具备现成的适配器；适配器是单向的还是双向的； 消息通信的模式：是 Send and For
8、get、Request/Reply 还是 Pub/Sub? 针对 ESB 的非功能性需求，我们要确认：1. ESB 平台的扩展性和高可用性需求，包括 HA 和集群等；2. ESB 平台的性能需求，主要包括系统间数据交换的频率，要交换的数据的大小 ( 消息大小将直接对效率造成影响 )；峰值时候对 ESB 数据吞吐量、响应时间的要求等；3. 哪些交易要保证数据传输的高可靠性；4. ESB 平台的可管理性需求，如服务的生命周期管理，ESB 平台的维护和管理；如果企业已经设立了 SOA 管控方面的规范，那么要遵从规范的制约，比如要考虑是否有规定的命名规则，企业是否有企业级的数据规范和底层通讯协议的规范
9、等；5. 安全性方面的要求：是否采用 SSL 传输加密，是否对消息进行加密/解密处理等；6. 错误处理和日志以及平台本身的运行监控等方面的要求等。ESB 的方案设计方案设计的主要内容包括：ESB 涉及 IT 应用环境分析，定义 ESB 与相关应用的接口模式； ESB 架构概要设计，并定义架构原则； ESB 相关产品选择，包括与外围系统的适配器选择和 ESB 产品选择； ESB 组件模型设计，分解 ESB 的相关模块，满足 SOA 的分离关注点等架构原则； ESB 运作模型设计，满足平台的非功能性需求； ESB 平台的服务流设计，涉及路由、转换和映射等； ESB 的同步、异步或者发布/订阅模式设
10、计； ESB 平台的接入渠道和数据接口设计，包括 XML/JMS、SOAP/HTTP、EDI/MQ 等； ESB 相关的适配器设计，包括技术适配器或者自开发的适配器； ESB 平台的容错和重试机制设计，包括日志等的统一管理等； 图 1 是一个采用 ESB 整合的高层架构设计举例：图 1. ESB 参考架构如图 1 所示，ESB 架构设计时主要要考虑通讯协议接入和转换、数据接入和转换、数据处理流程以及服务的注册和管理等方面的内容。其中通讯协议接入和转换是指对各种被集成的应用系统的通讯协议的支持和转换能力，例如HTTP、JMS、Socket、FTP 等；数据接入和转换是指对各种被集成的应用系统提供
11、的数据格式的支持和转换能力，例如 XML、SOAP、自定义格式以及符合某些行业标准的专有格式（SWIFT、EDI、HL7 等）；数据处理流程是指路由、格式转换、数据库读写等对数据的各种处理；统一服务注册存储管理是指对服务的注册、发布、查询，以及对运营时服务的管控，并且提供服务运营状态的统计分析数据。ESB 的组件模型图 2. ESB 组件模型图 2 给出了一个 ESB 组件模型的示例，其中包含的各主要组件及其功能如下：1. Message Broker Runtime 组件提供消息路由、格式转换、消息日志等操作的运行时环境。该运行环境由 IBM Message Broker 提供；2. Mes
12、saging Broker Instance 组件是处理基于 MQ 消息业务请求的容器。它是作为一个 Broker 实例运行在 Message Broker Runtime 上的。该实例提供了 MQ 消息的业务请求处理器、服务日志、服务定位等功能的运行容器；3. Web Service Broker Instance 组件是处理基于 Web Service 的业务请求的容器，它是作为一个 Broker 实例运行在 Message Broker Runtime 上的。该实例提供了 Web Service 的业务请求处理、服务日志、以及服务定位等功能。4. Event Broker Instanc
13、e 组件是平台内部处理 Pub/Sub 事件的容器。它是作为一个 Broker 实例运行在 Message Broker Runtime 上的。该容器提供了Event Handler 组件的运行环境，将基于 MQ/JMS 的事件分发到不同平台组件的目标队列上。5. Message Handler 组件是处理基于 MQ 消息的业务请求，包括消息解析、格式转换，服务鉴权与认证、服务路由、服务日志等功能。Message Handler组件处理 MQ 消息的典型流程如下：首先对 MQ 消息进行解析，对解析后的业务请求进行分析，之后通过Authentication 与 Authorization 组件判
14、断该请求者的业务请求是否可以进行后续处理； 通过 Service Locating 组件对该业务请求进行服务定位与路由；将基于 MQ 的业务请求消息转换成 Web Service 的业务请求消息； 通过 Service Logging 组件对整个业务请求进行日志记录； 返回业务请求处理结果给业务发起者，如果失败，返回错误消息。 6. Web Service Handler 组件是处理基于 Web Service 的业务请求，与Message Handler 组件功能类似，也包括消息解析、格式转换，服务鉴权与认证、服务路由、服务日志等功能。Web ServiceHandler 组件处理 Web
15、Service 请求的典型流程如下：首先对 Web Service 请求消息进行解析，对解析后的业务请求进行分析，之后通过 Authentication 与 Authorization 组件判断该请求者的业务请求是否可以进行后续处理； 通过 Service Locating 组件对该业务请求进行服务定位与路由； 通过 Service Logging 组件对整个业务请求进行日志记录； 返回业务请求处理结果给业务发起者，如果失败，返回错误消息。 7. Event Handler 组件实现对 Pub/Sub 的处理。8. Service Locating 组件负责根据业务请求定位具体的服务提供者。S
16、ervice Locating 通过对服务目录的查询选择适合的服务进行后续的调用，该查询工作可以通过实时的服务目录查询获得结果。9. Service Logging 组件负责记录整个业务请求处理过程中的情况，该组件的实现可以通过文件或者数据库的方式。10. Authentication 组件负责对业务请求者进行鉴权，判断该业务请求者是否可以访问平台服务，该鉴权的工作在企业服务总线的外部进行，Authentication 组件只是调用外部功能完成。11. Authorization 组件判断业务请求者是否具备访问某特定服务的权限，该验证权限的工作在企业服务总线的外部进行，Authorization 组件只是调用外部功能完成。以处理基于 MQ 消息输入为例，ESB 的组件交互图如图 3 所示：图 3. ESB 组件交互图ESB 方案设计时的最佳实践根据我们以往项目设计和开发时的一些经验，我们建议进行 ESB 的方案设计时要遵循下述最佳实践：确定标准的使用：使用与否、使用到什么程度； 确定在 ES
