ESB 在企业体系结构中的角色和价值
面向服务的体系结构（Service Oriented ArchitectureSOA）提供了灵活可扩展且可组合的方法来重用及扩展现有应用程序和构造新应用程序SOA 最为重要的特征是其灵活性其中将业务流程和底层 IT 基础设施作为安全的标准化服务对待可供重用和组装以处理不断变化的业务需求SOA 中的服务具有定义良好的接口此接口由消息接收和发送的一组消息定义而且接口的实现在部署之后将绑定到所记录的服务端口
企业服务总线（Enterprise Service BusESB）是一种体系结构模式支持通信各方间的服务交互的虚拟化和管理它充当 SOA 中服务提供者和请求者之间的连接服务的中间层它是一个灵活的连接框架可促进可靠而安全的系统集成并同时减少应用程序接口的数量大小和复杂度
其中的服务不直接交互而是通过服务连接框架 (ESB) 进行通信此框架提供实现和扩展 SOA 核心定义的虚拟化和管理功能ESB 模式提供以下方面的虚拟化
位置和标识ESB 标识消息并在交互服务之间路由这些消息这些服务不需要知道通信中的其他方的位置或标识例如请求方不需要知道多个提供者中是否有提供者可以处理请求您可以向正在工作的 ESB 添加其他服务提供者从而允许将消息路由到这些提供者而且不会对请求者造成干扰
通信协议ESB 允许消息在服务请求者和服务提供者之间来回传递的过程中跨不同的传输协议或交互样式中传递例如以 SOAP/HTTP 格式表示的请求可能送到仅接收 JMS 输入的提供者
接口服务的请求者和提供者不需要就单一接口达成一致ESB 可以对请求者发出的消息进行转换和充实来得到提供者预期的格式从而协调差异
您可以使用各种中间件产品（硬件和软件）编程模型和交互样式实现 ESB 模式ESB
标识消息并在应用程序和服务间路由这些消息
允许消息在服务请求者和服务提供者之间来回传递的过程中跨不同的传输协议传递
在请求者和服务之间转换消息格式
识别和区分不同源之间的业务事件
提供可靠而安全的通信
创建基于可插入组件的可扩展体系结构
提供智能路由和独立于位置的处理
通过元数据管理消息及其格式的描述和定义
集成所有类型的资产以满足您企业的需求
很多 ESB 实现都利用了服务连接性标准如 XML 和 Web 服务此类标准封装了行业对 ESB 定义的统一认识不过没有必要将 ESB 限制为仅使用这些标准可以对 ESB 体系结构模式进行扩展以支持现有 IT 投资此类投资包括大型机资产打包应用程序传感器和设备以及文件和不基于任何公用标准的自定义协议ESB 应该支持企业的所有连接性需求
ESB 应该支持不同类型的服务交互单向消息及请求/响应异步调用及同步调用和发布/订阅模型以及复杂事件处理（在其中可能会观察或使用一系列事件来产生一个事件将其作为系列事件中的关系的结果）
建立 ESB 是组织中建立 SOA 的过程中一项十分关键的基础投资组织可通过其实现以下目标
简化减少接口的数量大小和复杂度
减少风险和成本提高 IT 对业务需求变更的响应能力
促进重用提高数据和业务逻辑的可用性使应用程序更易于启用服务
支持动态实时事件驱动的 SOA替代了呆板无响应能力或采用批处理方式更新的 IT 系统
用户角色和任务
SOA 和任何 IT 活动一样都依赖于技术人员和流程ESB 采用过程中的一项关键的成功因素是ESB 技术必须能够在治理框架内进行管理以便为组织带来价值
很多组织发现SOA 卓越中心（SOA Center of ExcellenceCOE）价值很大能促进 SOA 技术的采用COE 必须涵盖整个组织内的团队以分享经验提供培训提出流程改进建议和确保 SOA 环境的成熟度COE 需要帮助 SOA 治理委员会处理 SOA 出现的问题如版本控制服务共享和安全性等SOA COE 是整个组织范围内的 IT 团队负责指导 SOA 远景和战略所确定的战略共享 IT 解决方案的 IT 投资涉及决策和实现COE 可帮助处理一系列问题如
治理
在组织内为 SOA 提供信息传播机制
在定义 SOA 治理和管理流程方面为 SOA 治理委员会提供支持
实现 SOA 治理和管理流程
充当思想领袖并进行远景规划充当 SOA 治理和管理流程的思想带头人
提供专业 SOA 技能和资源
演示资产收集过程中的知识管理
进行整个 IT 团队内及与组织的其他部门的沟通
下面以图形方式说明了 COE 所充当的很多角色
技术选择标准
交互样式
为了完全支持全面的 SOA 中所需的各种集成模式（如请求/响应发布/订阅和事件等）ESB 应该最好能在一个基础设施中支持三个主要企业集成样式
SOA其中应用程序通过具有定义良好的显式接口的可重用服务进行通信面向服务的交互将充分利用底层消息传递和事件通信模型
消息驱动的体系结构其中应用程序通过 ESB 发送消息以调用其他应用程序
事件驱动的体系结构其中应用程序以彼此独立的方式生成和使用消息
使用者可以采用不同的方式实现服务调用从使用者的角度而言差异在于
同步使用者使用单线程来调用服务线程发送请求会在服务运行时阻塞等待响应
异步使用者使用两个线程来调用服务一个线程发送请求然后另一个线程侦听并接收响应
发布/订阅服务将消息发布到特定的主题多个服务（订阅者）可以订阅此主题并接收发布的消息
对于单个服务ESB 可以提供这些调用模型的任意组合让使用者选择首选调用模型
交互样式可能影响 ESB 实现IBM® WebSphere® Message Broker 特别适合基本流范式为异步或伪异步方式的体系结构
有状态性
某些情况可能需要 ESB 在消息通过其中时维护状态从最后适用的消息的上下文信息中选择特定的服务端点就是这方面的简单示例而在更为复杂的示例中可以通过检测涉及上下文敏感的消息和事件组合（语义上下文时间上下文空间时间上下文）的复杂情况来扩展 ESB 范式在应用到来自多个事件源的输入处理时此功能极为强大从不同上下文中的业务应用程序或基础设施的角度而言均是如此例如此类场景可能涉及到服务水平协议 (Service Level Agreement) 警报和适用于安全财务银行和保险行业的遵从性检查
硬件 ESB 实现通常并不支持有状态交互这就使得有状态性成为了软件 ESB 实现的一个标准WebSphere Message Broker 以独特的方式在产品中直接实现了复杂的消息处理使其最适合需要此功能的用例
端点标准和协议
端点是通过 ESB 交互的使用者和服务
采用标准技术和协议（如 Web 服务）的端点在 ESB 技术选择方面提供了最大的灵活性不过将端点限制为存在大量遗留投资的标准的做法经常不实际或不经济高效类似地虽然可以使用专用 API 集成打包应用程序但将这个集成工作委托给中介供应商完成的做法通常很有用为了处理这些顾虑出现了能极大简化集成的适配器
适配器的使用会对 ESB 产品选择造成影响因为适配器需要软件运行时（在硬件 ESB 实现上并不支持适配器）而且各种适配器的先决条件各不相同
基于策略的交互管理和动态服务选择
在一项新兴的 ESB 技术中采用了动态端点选择其选择以服务器使用率和运行状况等基于代理的统计数据为基础在某些 IBM ESB 产品通过与 IBM Tivoli Composite Application Manager 的集成提供了对此的现成支持
消息量大小和类型
ESB 产品具有不同的可伸缩性特征通常基于硬件的实现可以很好地扩展而且具有很好的行业标准数据格式支持不过他们并不提供软件实现的通用性WebSphere Message Broker 性能优良提供了丰富的 ESB 功能而且可以使用自定义组件和适配器进行扩展WebSphere ESB 具有丰富的行业标准格式Java 和 Web Services 标准支持可以使用自定义组件和适配器进行扩展
可靠性可用性和可服务性（Reliability availability and serviceabilityRAS）
ESB 产品具有不同的操作特征它们通过不同的机制和体系结构规模（例如应用服务区集群和操作系统级别的集群）来实现可伸缩性和高可用性必须对此加以考虑而且所得到的解决方案体系结构必须在 RAS 考虑事项和现有预算组织内的技能以及操作复杂性方面求得平衡
所需的中介
ESB 产品在不采用自定义编程的情况下处理中介的能力方面存在差异最值得注意的是WebSphere Message Broker 提供了对各种标准数据格式（如 ACORDSWIFT 和 COBOL Copybook）的广泛支持如果数据格式是 XML 和 Web Services则最适合使用 Websphere DataPower® SOA Appliances此产品可提供非常高的性能
IBM ESB 产品
很多产品都可以用于创建企业服务总线（Enterprise Service BusESB）IBM 提供了创建 ESB 的多个选项这就允许客户根据其具体的需求选择 ESB 技术在很多大型组织中由于地理位置技术或其他原因可能会使用多项 ESB 技术来创建混合 ESB当两个大型部门各自以独立的方式开始 SOA 然后又发现需要彼此进行互操作时可能采用混合 ESB
IBM 的三个主要 ESB 产品是 WebSphere Message BrokerWebSphere ESB 和 WebSphere DataPower SOA Appliances
WebSphere Message Broker
WebSphere Message Broker 提供了很多客户用于创建其 ESB（或混合解决方案中的中央 ESB）的功能WebSphere Message Broker 源自 WebSphere MQ 消息传递领域特别适合 MQ 消息传递的环境该产品提供 WSDL 和其他消息格式的接口定义通过消息流提供中介功能并支持各种通信格式包括 WMQ 和 HTTPWebSphere Message Broker 还基于发布/订阅交互和托管主题空间提供内容
WebSphere Message Broker 支持各种服务交互端点的中介模式实现它支持各种行业标准消息集（当然只有其中一部分使用 XML 编码）支持添加对其他用户定义的消息格式的支持以下典型客户需求非常适合使用 WebSphere Message Broker 解决方案加以处理
事务
发布/订阅
ACORDSWIFT 或 COBOL Copybook 标准格式
采用 XML 格式的数据
符合 WS* 标准
WebSphere MQ 消息传递
复杂转换
复杂事件处理
WebSphere Message Broker 提供了多个 ESB 连接选项和任意格式间的数据转换通过这样遗留应用程序和不符合标准的应用程序就可以连接到 ESB
WebSphere ESB
WebSphere ESB 是 ESB 的 JEE 实例化成果WebSphere ESB 在 IBM WebSphere Application Server 内的 JEE 容器中运行该产品非常适合基于 JEE 和 WS* 标准的应用程序特别是只需要与其他应用服务器通信的应用程序另外该产品可作为进入 SOA 世界的敲门砖允许将基本 Web 服务作为进入更为可靠的 SOA 环境的垫脚石加以利用
WebSphere ESB 提供基于标准的 Web Services 连接性JMS 消息传递和面向服务的集成用于端到端和发布/订阅消息传递的 JMS 应用程序和面向 JAXRPC 服务的应用程序可以直接连接到 WebSphere ESB或者可以通过各种传输协议（包括 WMQSOAP/HTTP 和 SOAP/JMS）将消息交付到 WebSphere ESBWebSphere ESB 实现了 Web 服务网关此网关可以在基于 SOAP/HTTP 和 SOAP/JMS 的应用程序之间进行中介最后它还提供了统一描述发现和集成（Universal Description Discovery and IntegrationUDDI）的实现以下典型客户需求非常适合使用 WebSphere ESB 解决方案加以处理
JEE 实现
Web Services 接口
SOAP/HTTP
WebSphere DataPower SOA Appliance
WebSphere DataPower SOA Appliance 是同时包含硬件和软件的产品提供了大量的重要功能XML 加速安全措施执行和 ESB 功能DataPower 具有多个重要特征
经过优化的硬件固件和嵌入式操作系统
确保配置锁定的高级保证措施
减少安全漏洞
加密密钥的硬件存储和锁定的审核日志
没有硬盘CD ROM 或 USB 端口
篡改防护机箱在机箱打开的情况下机器将变为不可用状态
降低操作复杂性真正的 SOA 设备通过 DataPower能以最快的速度实现 SOA 入门而且同时还能提供增强的安全环境
以下典型客户需求非常适合使用 DataPower 解决方案加以处理
安全网关
XML 防火墙解析和验证
基本路由
基于内容的路由
协议桥接（HTTPWebSphere MQ 客户机FTPODBC 等）
辅助技术
除了上面讨论的 ESB 技术外以下补充产品还可以进一步加快或扩展 ESB 实现
WebSphere MQ 为多种不同平台提供可靠消息很多公司都使用 WebSphere MQ 作为消息传递中枢
WebSphere Service Registry and Repository 提供了集成的服务元数据存储库来治理服务和管理服务生命周期它可促进服务可见性一致性还将减少 SOA 中的服务冗余
WebSphere Transformation Extender 提供了通用转换功能非常适合满足极为复杂的需求或快速变化的需求如 EDI 等
WebSphere Adapters 是外接程序可帮助为打包应用程序或其他遗留资产启用服务以便参与到 SOA 中来其中提供的适配器允许将各种遗留信息系统和技术包含到 ESB 中来
WebSphere Process Server 提供流程工作流功能并包括 WebSphere ESB有些情况需要对来自很多个系统的服务调用和响应进行协调而此解决方案提供了在此情况下编排复杂 ESB 交互的功能
IBM Tivoli Composite Application Management for SOA 是专门针对 SOA 环境的 Tivoli 监视产品通过 IBM Tivoli Composite Application Manager for SOA可充分利用现有系统管理工具提供了 SOA 环境的全面操作视图
WebSphere Business Services Fabric 是用于进行组合业务服务的建模组装部署管理和治理的端到端 SOA 平台WebSphere Business Services Fabric 可帮助创建业务级别的服务以供组装为扩展的跨企业业务流程和解决方案而且可以基于服务请求的业务上下文对这些流程和解决方案进行动态个性化和交付
WebSphere Service Registry and Repository
WebSphere Service Registry and Repository 提供了基本 UDDI 服务目录所不提供的很多功能事实上很多组织发现由于 UDDI 规范尚不完全明确不同提供商实现该规范的方式也不一样WebSphere Service Registry and Repository 不仅提供了关于存在哪些服务的注册中心而且还提供了工具来向 ESB 提供这些服务和允许开发人员搜索现有服务供使用WebSphere Service Registry and Repository 包括
包含关于服务的信息（如服务接口其操作及参数）的服务注册中心
具有可靠框架和适合各种服务使用方法特征的可扩展性的元数据存储库
WebSphere Service Registry and Repository 几乎可以和 SOA 生命周期的所有部分进行交互
通过标准资产管理解决方案与服务开发生命周期交互
在进行服务的变更和发布管理流程的过程中跟蹤服务生命周期阶段
提供对运行时工具的优化访问
通过操作系统管理实用工具共享关于服务和服务元数据的信息
WebSphere Service Registry and Repository 提供关于何时何人对哪个服务进行了何种操作的信息此功能将在下面的案例研究中进行讨论
基本 ESB 模式
下面部分将介绍核心 ESB 中介功能的通用语言这些模式可以非常方便地帮助在上下文中说明 ESB可以用于表述与最佳实践和所得到的经验教训相符的可重复中介模式ESB 用例可以表示为这些核心模式的组装
协议切换
支持服务请求者使用各种交互协议或 API（如 SOAP/HTTPJMS 和 MQ Integrator (MQI)）来发送其消息
将请求转换为目标服务提供者的格式
可以在交互的请求者和/或提供者端或两者间的任何位置应用
此模式的中介通常在格式和彼此关系有明确定义的情况下自动创建
修饰符
在不更改上下文信息的情况下更新消息的有效负载转换子模式
消息有效负载从一个格式（模式）转换为另一个格式从而将请求者的消息定义与提供者的消息定义匹配
包括封装和取消封装即将采用一个网络格式的消息放入另一个网络传输所需的格式信封或对应的删除信封的过程
包括加密
充实子模式
通过添加来自外部数据源的信息（如中介的自定义参数或数据库查询）来更新消息有效负载
路由器 (Router)
更改消息的既定路由
在与中介关联的服务提供者之间进行选择
示例从金牌客户到备用的高级 SLA 提供者间
发现
查询 ESB 注册中心
以发现匹配请求者需求的一组服务提供者
选择其中一个
然后将消息路由到该提供者
路由模式的增强
可能的服务提供者集不是在中介预先配置的
提供者匹配请求者的消息格式所需的 QOS 或从中介到可能的提供者所支持的协议
示例数据中心故障转移场景在不更新每个中介的配置的情况下将数据中心上线注册服务将通信流量路由到对应服务
分发
将消息分发到一组相关方
通常由订阅者的兴趣概要驱动
监视
用于在消息通过 ESB 的规程中观察消息
不过不会以任何方式更改这些消息
示例
监视服务级别
提供用于进行问题确定的数据
退款测定
记录业务级别事件（超过特定收益值的交易）
记录消息供审核
相关（复杂事件处理）
从消息或事件流派生复杂事件
包含模式标识规则和响应模式发现规则
例如
通过生成从触发事件流的内容派生的复杂事件
可以对这些基本模式进行聚合以得到更为复杂的模式
规范适配器
所有各方使用的消息和业务对象集规范化为规范格式
规范适配器模式可以将端点的本机总线附加协议转换为标准协议
对有效负载进行规范化并在交付时进行反向转换
此模式是协议切换和转换模式聚合后得到的
转换记录路由
这是一个常见的 ESB 聚合模式
转换传入消息（转换）
对其进行记录（监视）并路由到相应的端点
代理或网关模式
路由或协议切换模式的变体
其中将对服务端点进行映射
并可能提供安全功能（授权和访问控制）和日志记录或审核功能
可能包含转换和监视中介以提供加密和日志记录或审核还可能会采用一对多关系对消息进行聚合和取消聚合
示例充当多个服务的单个接触点并隐藏内部服务的服务门户
复杂 ESB 模式
这些模式从更为现实的角度说明了如何使用 ESB 来实现所需的丰富服务虚拟化在很多大型组织或没有 SOA 合作伙伴的组织中经常会需要多个 ESB很多原因都会导致此需求的出现包括
安全性
性能
可说明性/可审核性
资源控制
以下模式供演示之用绝不能视为全面的叙述其中很多模式都可以彼此进行结合具体取决于特定项目的需求
全局 ESB
全局 ESB 为所有服务请求者提供对一个注册中心的访问每个服务对每个服务请求者都可见此模式虽然可能适合小型系统测试环境但可能不适合在生产环境中使用这个适用性讨论所指的是没有其他 ESB 的全局 ESB也就是说采用的是非混合方法混合方法将在此部分稍后进行讨论
在集中管理但地理位置分散的整个异类环境中所有服务共享一个命名空间而且每个服务提供者对每个服务请求者都可见
供所有服务可能适用于整个组织的部门或小型企业使用
对于全局 ESB 的情况有两个主要 ESB 技术选项WebSphere Message Broker 和 WebSphere ESBWebSphere ESB 是首选技术其整个环境都基于 JEE 和相关标准存在与非 JEE 系统的复杂转换和交互时WebSphere Message Broker 可能更为适用大型组织可能会发现同时运行这两个产品的做法更为合适在此方法中按照下一个示例联合 ESB 中所讨论的方式根据消息类型和目的地对消息进行路由
ESB 网关
ESB 网关模式提供内部和外部域边界间的受控制的安全服务交互
ESB 网关模式经常使用 DataPower 设备进行实例化因为这样可以在提
供所需的网关功能之外提供 XML 防火墙DataPower 非常适合用于网络边界因为它使用的是嵌入式操作系统和软件实现因此能减少设置操作系统环境所固有的风险
联合 ESB
联合 ESB 提供了使用多个服务注册中心和管理域的功能并同时将异类注册中心映射为服务联合集联合 ESB 可促进采用多个 ESB 实现时的服务交互联合 ESB 经常用于提供适用于整个企业的服务子集
多个从 ESB 联合到一个主 ESB 中
服务使用者和提供者连接到主 ESB 或从 ESB以访问整个网络中的服务
供希望将一系列具有适度自主控制的部门联合到一个监管部门之下的组织使用
对于联合 ESB核心ESB 可能为 WebSphere Message Broker而非核心 ESB 可以为 WebSphere ESB或者对于小型远程办公室的情况可以使用 DataPower 设备在此模式中每个站点都有自己的服务注册中心在联合 ESB 模式中最佳实践是在网络边界使用 DataPower 设备以执行授权和身份验证以及在提交给内部系统前解析和验证 XML通过这样DataPower 设备可以加快事务处理速度和降低 ESB 服务器的 CPU 使用率
代理 ESB
代理 ESB 用于在以下情况下支持多个注册中心即服务子集适用于整个组织但其中不存在单个服务的多个实现
对选择性地将请求者或提供者向其他 ESB 域中的合作伙伴公开的服务进行桥接
每个 ESB 管理自己的命名空间
ESB 间的服务交互通过实现桥接服务的公用代理来加以促进
如果各个部门开发和管理自己的服务但共享其中的部分服务或选择性地访问整个企业中提供的服务则可使用此模式
代理 ESB 模式与联合 ESB 模式非常相似不过代理 ESB 充当执行点和服务路由器
JBI 标准 (JSR ) 的讨论中经常提到联合 ESB到目前为止IBM 已经放弃了 JBI 规范因为此规范并没有在客户已经能实现的工作之上有足够的发展很多技术和开放规范都提供了更为有竞争力的互操作性和更好的组件组合机制IBM 首先关注的是支持最广泛的产品应用程序和现有业务资产集成
ESB 场景 ABC Hotel
ABC Hotel 是一家全球性的酒店与休闲企业该公司拥有多个品牌提供豪华与高档全面服务的酒店这包括超过 家全资托管或特许经营酒店房间总数超过 间
ABC 开始了一个持续多年的大型 IT 项目将其基于大型机的大型独立中央预订系统（Central Reservations SystemCRS）替换为作为分布式 JEE 服务实现的系统进行此项目的推动因素是要减少成本（替换大型机）和提高业务灵活性该项目被普遍认为是将采用 SOA 的概念和理论的项目服务要部署在两个分布在不同地方的数据中心中将为各个服务部署多个实例以促进系统吞吐能力和可用性
值得注意的是CRS 项目最初并没有考虑通用 ESB 框架随着项目的逐渐成熟服务集成的复杂性达到了不可接受的程度这给架构师开发人员和操作带来了极大的负担成为了成功完成 CRS 项目的阻碍因素因此作出了进行重构来包含 ESB 的决策ABC 进行了相关评估以选择合适的行动方案
向 IBM 提出的 ESB 需求的摘要
请求路由和工作负载管理在基础设施内为各个服务部署多个副本以提高可靠性可服务性和可用性ESB 应该将客户机请求路由到所请求服务相应的版本和实例ESB 还应该进行一些工作负载管理的部署将请求分发到相同的服务实例这可以为简单的负载分布算法但该公司对更为主动性的端点驱动的负载工作负载管理有着很强烈的兴趣
注册中心集成ABC 采用了基于 UDDI 的服务注册中心处理构建时服务目录没有部署更为主动的运行时服务注册中心但支持此类注册中心的需求得到了公司的认可
中介ABC 希望使用 ESB 来在客户机和服务之间进行中介服务数据以 WSDL / XML 格式表示因此不需要处理更为深奥的数据格式消息验证（WSI 和 XSD）以及对性能/转换加速的支持是主要的推动因素
事务管理ABC 具有某些特殊的用例此类用户将需要对提交的服务请求进行补偿和回滚（组合服务中的分布式事务支持）他们需要支持基于规则流程驱动的原子事务
服务编排和工作流复杂工作流支持是服务交互的小子集的一项需求最好在这些情况下有 BPEL 支持最好还支持业务状态机交互的计划和安排事件相关和涉及人工交互的工作流
能够促进与后端系统的集成希望有直接与 Siebel 及其他后端系统集成的能力
高性能/低延迟ESB 应该对总体性能和延迟的负面影响最小
监视管理维护总的说来在服务级别监视收集标准和自定义标准错误检查根源分享报告和历史分析方面存在各种广泛的需求自动操作员警告和通知工具非常关键
安全性需要与 Tivoli Access ManagerLDAP 和其他第三方安全产品实现集成凭据和密钥管理功能基于标准的身份验证访问控制加密/解密SSL 加速SarbanesOxley (SOX) 控制和 DMZ 部署的适合性都需要考虑
SDLCABC 使用基于 Eclipse 的 Rational Application Developer 和 Rational Software Architect最好能使用适合其现有环境的 ESB 开发工具
快速部署ABC 在选择重构来包含 ESB 之前已经进行了大量的投资部署的成本和速度是非常关键的考虑事项
减少操作复杂性减少风险和复杂性是推动 ABC 进行重构以获得基于 ESB 的体系结构的重要因素ABC 非常希望得到了高效且复杂度低的解决方案
示例用例
调用后端服务的业务合作伙伴
ABC 定期与业务合作伙伴通信以获得房间可用性和预订请求需要使用 DMZ 部署模式实现后端服务调用的虚拟化必须对客户进行身份验证和授权另外必须监视和记录所有活动
将来可能会需要按客户机请求类型或其他信息对通信流量进行划分
调用后端服务的酒店属性
各个属性都具有本地属性管理系统（Property Management SystemPMS）
而这些系统必须通过接口与 CRS 连接一个场景是更新房间和清算可租房间总量的属性CRS 必须注意可租房间总量的变化属性使用 XML over MQ 通过接口与 CRS 连接而 CRS 服务可能使用其他连接协议（如 SOAP/HTTP）部署
类似地可以对此模式进行扩展添加按端点使用率统计数据进行路由的能力
上面两个用例一起处理了所有 ESB 通信流量中的大部分流量
复杂恢复错误场景
在此场景中假定在从属性满足客户机请求时在组合服务交互中出现错误从错误恢复非常重要需要可能包括人工任务的工作流核心 ESB 模式并不会更改不过执行体系结构将包括额外的组件以支持这个功能
包含后端集成的复杂工作流
在此场景中一个创建客户的请求进入了首选客户跟蹤系统业务用户希望将此信息中的各个部分输入到作为中介的一部分 Siebel 中 ESB 充当现有服务的标准中介而同时还包括对 ISV 后端系统的更新这里适用传输监视路由 ESB 聚合模式但执行体系结构将利用多个 IT 组件来处理服务请求
解决方案体系结构概述
IBM 建议采用混合 ESB 体系结构其中既包括硬件 ESB 实现也包括软件 ESB 实现每个实现的 ESB 功能方面存在不同的优缺点
设备
经过优化可提供很高的性能而且处理延迟非常小
配置部署和操作最简单
安全篡改防护
从通用平台分流开销大的处理负载
软件
应用程序承载支持工作流支持和复杂中介
通过适配器进行应用程序集成
支持业务活动监视
IBM 希望广大客户都部署可充分利用这两个方法的优势的混合体系结构在混合体系结构中增加了 SOA 服务注册中心和管理功能
解决方案组件
DataPower XI（硬件 ESB）
WebSphere Process Server（包括 WebSphere ESB）
WebSphere Business Integration Adapter（与后端系统集成）
IBM Tivoli Composite Application Management for SOA（服务监视和管理）
WebSphere Service Registry and Repository（服务注册中心）
以下系统上下文关系图说明了这些组件的交互
DataPower XI 在此体系结构中充当两个角色服务网关（在 DMZ 中）和通用硬件 ESB（在受信任区域中）需要软件 ESB 实现的任务（如使用 Siebel Adapter 或涉及人工交互的复杂错误恢复）分流到 WebSphere Process Server（其中包括核心组件 WebSphere ESB）
DataPower 处理 ABC 的大部分 ESB 通信请求可保证非常高的性能WebSphere Process Server 和 WebSphere ESB 对 DataPower 的功能进行补充以支持在体系结构中实现最大的灵活性
IBM Tivoli Composite Application Management 产品支持对 ESB 及与其交互的组件进行监视和管理监视代理收集的信息可以支持复杂的 ESB 充实和路由模式如动态服务选择（根据监视代理收集的承载服务器负载之类的信息选择目标服务）
WebSphere Service Registry and Repository 支持服务的完整生命周期管理在支持 ESB 中的动态服务选择方面扮演着重要的角色正如上面所述仅仅 UDDI 并不足以处理这些任务
此体系结构旨在在性能和灵活性方面取得较好的平衡
ESB 场景 XYZ Insurance
XYZ Insurance 是一家医疗保险提供商该公司为数百万客户提供保险服务必须与客户提供商第三方代理和其他实体进行交互此示例是多个实际保险项目的组合
XYZ 决定开始 SOA 项目以实现其信息技术的现代化并充分利用在使用 COBOLAssembler 和 PL/I 编写的大型机 (z/OS) 应用程序方面的大量投资这些系统适用 DB 和 IMS 数据库与最终用户的大量通信都是通过客户信息控制系统（Customer Information Control SystemCICS）进行的IBM 的 WebSphere MQ 提供了应用程序内和应用程序间的消息传递中枢的大部分功能其中有一个主数据中心该数据中心连接到多个外围数据中心和第三方系统
XYZ 决定使用面向服务的体系结构 (SOA) 来构建新呼叫中心环境（Call Center EnvironmentCCE）和构建新的索赔处理应用程序（Claims Processing ApplicationCPA）还有很多其他应用程序和更改但我们将重点关注这两个主要系统
IBM 和 XYZ 用于定义体系结构的总体项目需求包括
在无需重新编写代码的情况下利用遗留应用程序
利用大型机系统并同时在为该应用程序所选的平台上创建新服务
支持多通信协议（SOAP/HTTMWebSphere MQ 等）
安全地支持与外部组织的 SOA 交互
在包含分散在不同位置的多个数据中心的环境中操作
提供实时监视和根据所需的服务级别路由事务的能力
其 ESB 需求与 ABC 案例研究类似不过需要更为复杂的中介另外
由于很多法律法规的要求其安全性和可审核性必须比 ABC 案例研究中更为可靠
示例用例
调用主数据中心服务的远程数据中心
远程数据中心之一频繁调用主数据中心以支持呼叫中心环境 (CCE)虽然这是在组织内进行但这种情况下仍然使用了网关来确保满足应用程序安全性和审核要求
在本例中对主数据中心的单个服务调用可能会导致遗留应用程序内出现多次服务调用从而需要服务编排和工作流组件将所得到的信息组装为单个服务响应
服务交互的远程数据中心端如下所示
服务交互的主数据中心端如下所示请注意为了清楚起见并没有在关系图中给出网关和监视组件不过它们当然是解决方案中至关重要的组件
主数据中心调用远程数据中心服务
主数据中心将频繁调用远程数据中心之一以确认最新的呼叫中心环境 (CCE) 活动这就要求远程数据中心具有完整的 SOA 环境并具有与主数据中心完全相同的安全性和审核功能
服务交互的主数据中心端如下所示
主数据中心调用第三方服务进行地址验证
在接受地址并将其存储在 XYZ 的数据中之前主数据中心将调用第三方服务来验证地址是否有效
外部代理对遗留应用程序服务进行服务调用
虽然外部第三方应用程序将没有必要知道所调用的服务是遗留应用程序但此用例在体系结构的角度非常有意义
服务交互的远程数据中心端如下所示
服务交互的主数据中心端如下所示请注意为了清楚起见并没有在关系图中给出网关和监视组件不过它们当然是解决方案中至关重要的组件
基于服务调用模式的欺诈检测
基于服务调用模式的欺诈检测是较为复杂的情况不仅需要监视调用的数量还要监视进行调用的实体以及调用的时间在本例中如果获知某个特定用户涉嫌对一个使用者或提供者进行异常的大量调用将临时禁止用户的访问权限并通知 XYZ 调查此异常行为这个监视记录相关和安全系统集成存在着极大的挑战不过可以使用现有 ESB 技术并结合其他 SOA 技术来加以处理
解决方案体系结构概述
IBM 和 XYZ 合作创建了包含硬件和软件 ESB 组件的混合 ESB 体系结构在本例中应用了所有三项 IBM 的 ESB 技术来提供所需的功能对遗留集成服务编排和基本工作流的需求推动了关于使用这组技术的体系结构决策
以下系统上下文关系图说明了这些组件的交互
和 ABC 示例中的情况一样DataPower XI 扮演着两个角色DMZ 中的安全防火墙和受信任区域中的 ESBWebSphere Process Server/ESB 用于对复杂服务交互进行编排负责从数据结构获取数据并将其组合为更为复杂的业务服务响应WebSphere Message Broker 用于处理与遗留系统交互所需的复杂消息转换此示例说明了在一个设计中使用所有三个 IBM ESB 解决方案的价值其中的每个解决方案都得到了充分的利用体现了各自最重要的功能
IBM 认识到很多组织将具有与 XYZ 类似的复杂需求这些需求将对多项技术的使用起到促进作用从而提供最为恰当的功能满足可用性性能和安全性需求
解决方案组件
XYZ 使用的解决方案包括
DataPower XI（硬件 ESBXML 安全网关）
WebSphere Process Server（包括 WebSphere ESB 和复杂服务交互的流程编排）
WebSphere Message Broker（支持复杂消息转换和非标准消息传递的软件 ESB）
结束语
本文提供了 ESB 使用的概念和实际示例文中讨论了创建 ESB 的技术选项以及哪些产品最适合各个特定情况和任何技术主题一样使用本指南时应该结合有经验的专业人员的经验来设计最适合特定情况的解决方案
致谢
作者要感谢 MarcThomas SchmidtKyle Brown 和 Rachel Reinitz 所做的工作他们的工作为大部分 IBM SOA 活动提供了基础尤其在 ESB 领域特别重要
关于作者
Victor Grund 是 IBM 的一位 WebSphere 技术销售经理负责 WebSphere 产品在 New England 及北部 New York 地区的销售他拥有 年的 IT 专业从业背景其中至少有 年在 IBM 工作他曾担任过经理软件架构师首席 SOA 架构师IT 专家和顾问等众多职务他在设计和实现企业应用程序和集成解决方案方面有丰富的经验您可以通过 与 Victor 联系
Chuck Rexroad 是 IBM 在 New England 及北部 New York 地区的首席软件 IT 架构师他于 年加入 IBM担任 Tivoli 品牌的技术专家在系统管理的所有方面都有着丰富的经验多年来他一直在从事 SOA 项目和技术相关的工作帮助大中型组织客户实现其 SOA 环境您可以通过 与 Chuck 联系
