本文共 6245 字,大约阅读时间需要 20 分钟。
(), 软件架构师, IBM 软件部
需求分析阶段是梳理项目中相关功能需求和非功能需求的重要步骤,它是整个项目成败的关键。在这个阶段我们将从企业业务需求出发,梳理端到端的跨系统业务流程;基于业务流程,依据科学的方法论进行服务鉴别;由服务列表出发,梳理服务的消费和提供关系;然后根据 SOA 的最佳实践,定义服务的接口,包括服务的 Schema 描述,字段的类型,编码的规则;依据服务的消费-提供关系,梳理 ESB 中的服务映射和转换规则和策略。
概括而言,我们需要从功能性和非功能性两个方面来进行 ESB 的需求分析。
针对 ESB 的功能性需求,我们要侧重了解以下方面的问题:
1. 梳理出要被集成的系统的名称,个数。
2. 针对每个系统而言,要了解:
针对 ESB 的非功能性需求,我们要确认:
1. ESB 平台的扩展性和高可用性需求,包括 HA 和集群等;
2. ESB 平台的性能需求,主要包括系统间数据交换的频率,要交换的数据的大小 ( 消息大小将直接对效率造成影响 );峰值时候对 ESB 数据吞吐量、响应时间的要求等;
3. 哪些交易要保证数据传输的高可靠性;
4. ESB 平台的可管理性需求,如服务的生命周期管理,ESB 平台的维护和管理;如果企业已经设立了 SOA 管控方面的规范,那么要遵从规范的制约,比如要考虑是否有规定的命名规则,企业是否有企业级的数据规范和底层通讯协议的规范等;
5. 安全性方面的要求:是否采用 SSL 传输加密,是否对消息进行加密/解密处理等;
6. 错误处理和日志以及平台本身的运行监控等方面的要求等。
|
方案设计的主要内容包括:
图 1 是一个采用 ESB 整合的高层架构设计举例:
如图 1 所示,ESB 架构设计时主要要考虑通讯协议接入和转换、数据接入和转换、数据处理流程以及服务的注册和管理等方面的内容。其中通讯协议接入和转换是指对各种被集成的应用系统的通讯协议的支持和转换能力,例如 HTTP、JMS、Socket、FTP 等;数据接入和转换是指对各种被集成的应用系统提供的数据格式的支持和转换能力,例如 XML、SOAP、自定义格式以及符合某些行业标准的专有格式(SWIFT、EDI、HL7 等);数据处理流程是指路由、格式转换、数据库读写等对数据的各种处理;统一服务注册存储管理是指对服务的注册、发布、查询,以及对运营时服务的管控,并且提供服务运营状态的统计分析数据。
图 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 消息的典型流程如下:
6. Web Service Handler 组件是处理基于 Web Service 的业务请求,与 Message Handler 组件功能类似,也包括消息解析、格式转换,服务鉴权与认证、服务路由、服务日志等功能。Web Service Handler 组件处理 Web Service 请求的典型流程如下:
7. Event Handler 组件实现对 Pub/Sub 的处理。
8. Service Locating 组件负责根据业务请求定位具体的服务提供者。Service Locating 通过对服务目录的查询选择适合的服务进行后续的调用,该查询工作可以通过实时的服务目录查询获得结果。
9. Service Logging 组件负责记录整个业务请求处理过程中的情况,该组件的实现可以通过文件或者数据库的方式。
10. Authentication 组件负责对业务请求者进行鉴权,判断该业务请求者是否可以访问平台服务,该鉴权的工作在企业服务总线的外部进行,Authentication 组件只是调用外部功能完成。
11. Authorization 组件判断业务请求者是否具备访问某特定服务的权限,该验证权限的工作在企业服务总线的外部进行,Authorization 组件只是调用外部功能完成。
以处理基于 MQ 消息输入为例,ESB 的组件交互图如图 3 所示:
根据我们以往项目设计和开发时的一些经验,我们建议进行 ESB 的方案设计时要遵循下述最佳实践:
对于 ESB 的安全性考虑,主要有两种方式,第一种方式是通过 ESB 内部的 Mediation 节点来进行服务请求者的认证 / 授权;另一种是调用一个外部服务进行服务请求者的认证 / 授权,如图 4 所示,图中给出了这两种方式的示意图,具体实施时可以进行选择。
当一个企业开始它的 SOA 之旅时,开始阶段通常会选取一个具体的项目进行 SOA 的尝试,然后便会逐步走向全企业采纳,这时,大多数企业都会面临一个问题,那就是服务越来越多,对这些服务目录的管理出现了很多问题,例如:所有与服务相关的信息是如何被管理的,包括存储、管理、维护、存取等?服务请求者如何决定使用哪个服务?服务请求者如何定位服务的 Endpoint?当服务信息发生改变时如何得到通知?
因此我们建议用户在尽可能早的情况下考虑服务注册中心的建设,所谓服务注册中心是一个企业范围内的服务信息的存储库,该存储库存储了企业中注册的服务和服务相关的信息,它的主要功能包括:
除了服务注册中心的考虑之外,我们还要考虑对服务的管理。服务不仅具有特定的功能,还应该满足一些诸如性能、可用性、安全性等 QoS 指标。服务响应的快慢、什么时间可用、可以被谁调用、在某个时间段里能被调用多少次、哪些事件要记录日志,这些都是服务管理要考虑的问题。通过服务注册中心和服务监控平台的有机配合,我们可以根据服务的响应时间、服务可用与否等策略来实现对服务的动态访问。让我们来看一个例子:
如图 5 和图 6 所示,我们可以利用服务监控平台对服务进行监控和统计分析,从而使 ESB 平台可以根据服务提供者的性能优劣来动态地绑定和调用高性能的服务,其过程如下:
|
在 ESB 开发和测试阶段要完成的工作主要包括:
进行基于 WebSphere Message Broker 平台进行 ESB 开发时,通常要考虑以下一些方面的最佳实践,例如:通用的错误 / 例外处理、通用的日志 / 管理机制、子流程设计、交易完整性和消息永久性、ESQL 的使用等。
|
本系列文章结合交通运输业和制造业企业的不同行业特点和需求,为大家介绍了两个真实环境下企业 ESB 的方案设计,并且结合多年的项目实施经验和方法论,与大家分享了在 ESB 项目实施过程中有关需求分析、方案设计等方面的一些经验,希望大家的 ESB 项目获得成功。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14789789/viewspace-610864/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-610864/