知识大全 ASP.NET企业服务总线实现模式

Posted 2022-07-18 消息

篇首语：人间有三愿，一愿识尽世间好人，二愿读尽世间好书，三愿看尽世间好风光。人间最美四月天，祝你三愿皆有所获。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 ASP.NET企业服务总线实现模式相关的知识，希望对你有一定的参考价值。

ASP.NET企业服务总线实现模式  以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

ESB 在企业体系结构中的角色和价值

　　面向服务的体系结构（Service Oriented Architecture SOA）提供了灵活 可扩展且可组合的方法来重用及扩展现有应用程序和构造新应用程序 SOA 最为重要的特征是其灵活性 其中将业务流程和底层 IT 基础设施作为安全的标准化服务对待 可供重用和组装 以处理不断变化的业务需求 SOA 中的服务具有定义良好的接口 此接口由消息接收和发送的一组消息定义 而且接口的实现在部署之后将绑定到所记录的服务端口

　　企业服务总线（Enterprise Service Bus ESB）是一种体系结构模式 支持通信各方间的服务交互的虚拟化和管理 它充当 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 Excellence COE）价值很大 能促进 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 serviceability RAS）

　　ESB 产品具有不同的操作特征 它们通过不同的机制和体系结构规模（例如 应用服务区集群和操作系统级别的集群）来实现可伸缩性和高可用性 必须对此加以考虑 而且所得到的解决方案体系结构必须在 RAS 考虑事项和现有预算 组织内的技能以及操作复杂性方面求得平衡

　　所需的中介

　　ESB 产品在不采用自定义编程的情况下处理中介的能力方面存在差异 最值得注意的是 WebSphere Message Broker 提供了对各种标准数据格式（如 ACORD SWIFT 和 COBOL Copybook）的广泛支持 如果数据格式是 XML 和 Web Services 则最适合使用 Websphere DataPower® SOA Appliances 此产品可提供非常高的性能

　　IBM ESB 产品

　　很多产品都可以用于创建企业服务总线（Enterprise Service Bus ESB） IBM 提供了创建 ESB 的多个选项 这就允许客户根据其具体的需求选择 ESB 技术 在很多大型组织中 由于地理位置 技术或其他原因 可能会使用多项 ESB 技术来创建混合 ESB 当两个大型部门各自以独立的方式开始 SOA 然后又发现需要彼此进行互操作时 可能采用混合 ESB

　　IBM 的三个主要 ESB 产品是 WebSphere Message Broker WebSphere ESB 和 WebSphere DataPower SOA Appliances

WebSphere Message Broker

　　WebSphere Message Broker 提供了很多客户用于创建其 ESB（或混合解决方案中的中央 ESB）的功能 WebSphere Message Broker 源自 WebSphere MQ 消息传递领域 特别适合 MQ 消息传递的环境 该产品提供 WSDL 和其他消息格式的接口定义 通过消息流提供中介功能 并支持各种通信格式 包括 WMQ 和 HTTP WebSphere Message Broker 还基于发布/订阅交互和托管主题空间提供内容

　　WebSphere Message Broker 支持各种服务交互端点的中介模式实现 它支持各种行业标准消息集（当然 只有其中一部分使用 XML 编码） 支持添加对其他用户定义的消息格式的支持 以下典型客户需求非常适合使用 WebSphere Message Broker 解决方案加以处理

　　事务

　　发布/订阅

　　ACORD SWIFT 或 COBOL Copybook 标准格式

　　采用 XML 格式的数据

　　符合 WS * 标准

　　WebSphere MQ 消息传递

　　复杂转换

　　复杂事件处理

　　WebSphere Message Broker 提供了多个 ESB 连接选项和任意格式间的数据转换 通过这样 遗留应用程序和不符合标准的应用程序就可以连接到 ESB

WebSphere ESB

　　WebSphere ESB 是 ESB 的 J EE 实例化成果 WebSphere ESB 在 IBM WebSphere Application Server 内的 J EE 容器中运行 该产品非常适合基于 J EE 和 WS * 标准的应用程序 特别是只需要与其他应用服务器通信的应用程序 另外 该产品可作为进入 SOA 世界的敲门砖 允许将基本 Web 服务作为进入更为可靠的 SOA 环境的垫脚石加以利用

　　WebSphere ESB 提供基于标准的 Web Services 连接性 JMS 消息传递和面向服务的集成 用于端到端和发布/订阅消息传递的 JMS 应用程序和面向 JAX RPC 服务的应用程序可以直接连接到 WebSphere ESB 或者可以通过各种传输协议（包括 WMQ SOAP/HTTP 和 SOAP/JMS）将消息交付到 WebSphere ESB WebSphere ESB 实现了 Web 服务网关 此网关可以在基于 SOAP/HTTP 和 SOAP/JMS 的应用程序之间进行中介 最后 它还提供了统一描述 发现和集成（Universal Description Discovery and Integration UDDI）的实现 以下典型客户需求非常适合使用 WebSphere ESB 解决方案加以处理

　　J EE 实现

　　Web Services 接口

　　SOAP/HTTP

WebSphere DataPower SOA Appliance

　　WebSphere DataPower SOA Appliance 是同时包含硬件和软件的产品 提供了大量的重要功能 XML 加速 安全措施执行和 ESB 功能 DataPower 具有多个重要特征

　　经过优化的硬件 固件和嵌入式操作系统

　　确保配置锁定的高级保证措施

　　减少安全漏洞

　　加密密钥的硬件存储和锁定的审核日志

　　没有硬盘 CD ROM 或 USB 端口

　　篡改防护机箱 在机箱打开的情况下机器将变为不可用状态

　　降低操作复杂性 真正的 SOA 设备 通过 DataPower 能以最快的速度实现 SOA 入门 而且同时还能提供增强的安全环境

　　以下典型客户需求非常适合使用 DataPower 解决方案加以处理

　　安全网关

　　XML 防火墙 解析和验证

　　基本路由

　　基于内容的路由

　　协议桥接（HTTP WebSphere MQ 客户机 FTP ODBC 等）

　　辅助技术

　　除了上面讨论的 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 用例可以表示为这些核心模式的组装

　　协议切换

　　修饰符

　　路由器 (Router)

　　发现

　　分发

　　监视

　　相关（复杂事件处理）

　　可以对这些基本模式进行聚合 以得到更为复杂的模式

　　规范适配器

　　转换 记录 路由

　　代理或网关模式

　　示例 充当多个服务的单个接触点并隐藏 内部 服务的服务门户

复杂 ESB 模式

　　这些模式从更为现实的角度说明了如何使用 ESB 来实现所需的丰富服务虚拟化 在很多大型组织或没有 SOA 合作伙伴的组织中 经常会需要多个 ESB 很多原因都会导致此需求的出现 包括

　　安全性

　　性能

　　可说明性/可审核性

　　资源控制

　　以下模式供演示之用 绝不能视为全面的叙述 其中很多模式都可以彼此进行结合 具体取决于特定项目的需求

全局 ESB

　　全局 ESB 为所有服务请求者提供对一个注册中心的访问 每个服务对每个服务请求者都可见 此模式虽然可能适合小型系统测试环境 但可能不适合在生产环境中使用 这个适用性讨论所指的是没有其他 ESB 的全局 ESB 也就是说采用的是非混合方法 混合方法将在此部分稍后进行讨论

　　在集中管理但地理位置分散的整个异类环境中 所有服务共享一个命名空间 而且每个服务提供者对每个服务请求者都可见

　　供所有服务可能适用于整个组织的部门或小型企业使用

　　对于全局 ESB 的情况 有两个主要 ESB 技术选项 WebSphere Message Broker 和 WebSphere ESB WebSphere ESB 是首选技术 其整个环境都基于 J EE 和相关标准 存在与非 J EE 系统的复杂转换和交互时 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 System CRS）替换为作为分布式 J EE 服务实现的系统 进行此项目的推动因素是要减少成本（替换大型机）和提高业务灵活性 该项目被普遍认为是将采用 SOA 的概念和理论的项目 服务要部署在两个分布在不同地方的数据中心中 将为各个服务部署多个实例 以促进系统吞吐能力和可用性

　　值得注意的是 CRS 项目最初并没有考虑通用 ESB 框架 随着项目的逐渐成熟 服务集成的复杂性达到了不可接受的程度 这给架构师 开发人员和操作带来了极大的负担 成为了成功完成 CRS 项目的阻碍因素 因此作出了进行重构来包含 ESB 的决策 ABC 进行了相关评估 以选择合适的行动方案

　　向 IBM 提出的 ESB 需求的摘要

　　请求路由和工作负载管理 在基础设施内为各个服务部署多个副本 以提高可靠性 可服务性和可用性 ESB 应该将客户机请求路由到所请求服务相应的版本和实例 ESB 还应该进行一些工作负载管理的部署 将请求分发到相同的服务实例 这可以为简单的负载分布算法 但该公司对更为主动性的端点驱动的负载工作负载管理有着很强烈的兴趣

　　注册中心集成 ABC 采用了基于 UDDI 的服务注册中心处理构建时服务目录 没有部署更为主动的运行时服务注册中心 但支持此类注册中心的需求得到了公司的认可

　　中介 ABC 希望使用 ESB 来在客户机和服务之间进行中介 服务数据以 WSDL / XML 格式表示 因此不需要处理更为深奥的数据格式 消息验证（WS I 和 XSD）以及对性能/转换加速的支持是主要的推动因素

　　事务管理 ABC 具有某些特殊的用例 此类用户将需要对提交的服务请求进行补偿和回滚（组合服务中的分布式事务支持） 他们需要支持基于规则 流程驱动的原子事务

　　服务编排和工作流 复杂工作流支持是服务交互的小子集的一项需求 最好在这些情况下有 BPEL 支持 最好还支持业务状态机 交互的计划和安排 事件相关和涉及人工交互的工作流

　　能够促进与后端系统的集成 希望有直接与 Siebel 及其他后端系统集成的能力

　　高性能/低延迟 ESB 应该对总体性能和延迟的负面影响最小

　　监视 管理 维护 总的说来 在服务级别监视 收集标准和自定义标准 错误检查 根源分享 报告和历史分析方面存在各种广泛的需求 自动操作员警告和通知工具非常关键

　　安全性 需要与 Tivoli Access Manager LDAP 和其他第三方安全产品实现集成 凭据和密钥管理功能 基于标准的身份验证 访问控制 加密/解密 SSL 加速 Sarbanes Oxley (SOX) 控制和 DMZ 部署的适合性都需要考虑

　　SDLC ABC 使用基于 Eclipse 的 Rational Application Developer 和 Rational Sofare Architect 最好能使用适合其现有环境的 ESB 开发工具

　　快速部署 ABC 在选择重构来包含 ESB 之前已经进行了大量的投资 部署的成本和速度是非常关键的考虑事项

　　减少操作复杂性 减少风险和复杂性是推动 ABC 进行重构以获得基于 ESB 的体系结构的重要因素 ABC 非常希望得到了高效且复杂度低的解决方案

示例用例

调用后端服务的业务合作伙伴

　　ABC 定期与业务合作伙伴通信 以获得房间可用性和预订请求 需要使用 DMZ 部署模式实现后端服务调用的虚拟化 必须对客户进行身份验证和授权 另外 必须监视和记录所有活动

　　将来可能会需要按客户机 请求类型或其他信息对通信流量进行划分

调用后端服务的酒店属性

　　各个属性都具有本地属性管理系统（Property Management System PMS）

　　而这些系统必须通过接口与 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 在此体系结构中充当两个角色 服务网关（在 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 项目 以实现其信息技术的现代化 并充分利用在使用 COBOL Assembler 和 PL/I 编写的大型机 (z/OS) 应用程序方面的大量投资 这些系统适用 DB 和 IMS 数据库 与最终用户的大量通信都是通过客户信息控制系统（Customer Information Control System CICS）进行的 IBM 的 WebSphere MQ 提供了应用程序内和应用程序间的消息传递中枢的大部分功能 其中有一个主数据中心 该数据中心连接到多个外围数据中心和第三方系统

　　XYZ 决定使用面向服务的体系结构 (SOA) 来构建新呼叫中心环境（Call Center Environment CCE）和构建新的索赔处理应用程序（Claims Processing Application CPA） 还有很多其他应用程序和更改 但我们将重点关注这两个主要系统

　　IBM 和 XYZ 用于定义体系结构的总体项目需求包括

　　在无需重新编写代码的情况下利用遗留应用程序

　　利用大型机系统 并同时在为该应用程序所选的平台上创建新服务

　　支持多通信协议（SOAP/HTTM WebSphere MQ 等）

　　安全地支持与外部组织的 SOA 交互

　　在包含分散在不同位置的多个数据中心的环境中操作

　　提供实时监视和根据所需的服务级别路由事务的能力

　　其 ESB 需求与 ABC 案例研究类似 不过需要更为复杂的中介 另外

　　由于很多法律法规的要求 其安全性和可审核性必须比 ABC 案例研究中更为可靠

　　示例用例

调用主数据中心服务的远程数据中心

　　远程数据中心之一频繁调用主数据中心 以支持呼叫中心环境 (CCE) 虽然这是在组织内进行 但这种情况下仍然使用了网关来确保满足应用程序安全性和审核要求

　　在本例中 对主数据中心的单个服务调用可能会导致遗留应用程序内出现多次服务调用 从而需要服务编排和工作流组件将所得到的信息组装为单个服务响应

　　服务交互的远程数据中心端如下所示

　　服务交互的主数据中心端如下所示 请注意 为了清楚起见 并没有在关系图中给出网关和监视组件 不过它们当然是解决方案中至关重要的组件

主数据中心调用远程数据中心服务

　　主数据中心将频繁调用远程数据中心之一 以确认最新的呼叫中心环境 (CCE) 活动 这就要求远程数据中心具有完整的 SOA 环境 并具有与主数据中心完全相同的安全性和审核功能

　　服务交互的主数据中心端如下所示

主数据中心调用第三方服务进行地址验证

　　在接受地址并将其存储在 XYZ 的数据中之前 主数据中心将调用第三方服务来验证地址是否有效

外部代理对遗留应用程序服务进行服务调用

　　虽然外部第三方应用程序将没有必要知道所调用的服务是遗留应用程序 但此用例在体系结构的角度非常有意义

　　服务交互的远程数据中心端如下所示

　　服务交互的主数据中心端如下所示 请注意 为了清楚起见 并没有在关系图中给出网关和监视组件 不过它们当然是解决方案中至关重要的组件

基于服务调用模式的欺诈检测

　　基于服务调用模式的欺诈检测是较为复杂的情况 不仅需要监视调用的数量 还要监视进行调用的实体以及调用的时间 在本例中 如果获知某个特定用户涉嫌对一个使用者或提供者进行异常的大量调用 将临时禁止用户的访问权限 并通知 XYZ 调查此异常行为 这个监视 记录 相关和安全系统集成存在着极大的挑战 不过可以使用现有 ESB 技术并结合其他 SOA 技术来加以处理

解决方案体系结构概述

　　IBM 和 XYZ 合作创建了包含硬件和软件 ESB 组件的混合 ESB 体系结构 在本例中 应用了所有三项 IBM 的 ESB 技术来提供所需的功能 对遗留集成 服务编排和基本工作流的需求推动了关于使用这组技术的体系结构决策

　　以下系统上下文关系图说明了这些组件的交互

　　和 ABC 示例中的情况一样 DataPower XI 扮演着两个角色 DMZ 中的安全防火墙和受信任区域中的 ESB WebSphere Process Server/ESB 用于对复杂服务交互进行编排 负责从数据结构获取数据并将其组合为更为复杂的业务服务响应 WebSphere Message Broker 用于处理与遗留系统交互所需的复杂消息转换 此示例说明了在一个设计中使用所有三个 IBM ESB 解决方案的价值 其中的每个解决方案都得到了充分的利用 体现了各自最重要的功能

　　IBM 认识到很多组织将具有与 XYZ 类似的复杂需求 这些需求将对多项技术的使用起到促进作用 从而提供最为恰当的功能 满足可用性 性能和安全性需求

解决方案组件

　　XYZ 使用的解决方案包括

　　DataPower XI （硬件 ESB XML 安全网关）

　　WebSphere Process Server（包括 WebSphere ESB 和复杂服务交互的流程编排）

　　WebSphere Message Broker（支持复杂消息转换和非标准消息传递的软件 ESB）

结束语

　　本文提供了 ESB 使用的概念和实际示例 文中讨论了创建 ESB 的技术选项以及哪些产品最适合各个特定情况 和任何技术主题一样 使用本指南时应该结合有经验的专业人员的经验来设计最适合特定情况的解决方案

致谢

　　作者要感谢 Marc Thomas Schmidt Kyle Brown 和 Rachel Reinitz 所做的工作 他们的工作为大部分 IBM SOA 活动提供了基础 尤其在 ESB 领域特别重要

 关于作者

　　Victor Grund 是 IBM 的一位 WebSphere 技术销售经理 负责 WebSphere 产品在 New England 及北部 New York 地区的销售 他拥有 年的 IT 专业从业背景 其中至少有 年在 IBM 工作 他曾担任过经理 软件架构师 首席 SOA 架构师 IT 专家和顾问等众多职务 他在设计和实现企业应用程序和集成解决方案方面有丰富的经验 您可以通过 与 Victor 联系

相关参考

知识大全 ASP.NET中的session存储模式运用

ASP.NET中的session存储模式运用  以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！　　在中

知识大全 分享关于ASP.NET中等安全模式的一些经验

分享关于ASP.NET中等安全模式的一些经验  以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！　　如果

知识大全 开发设计模式——asp.net中实现观察者模式

   在中实现观察者模式？难道中的观察者模式有什么特别么？嗯基于Http协议的Application难免有些健忘我是这样实现的不知道有没有更好的办法？　　先谈谈需求吧以免

知识大全 ASP.NET谈三层结构与MVC模式的区别

ASP.NET谈三层结构与MVC模式的区别  以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！　　在CS

知识大全 浅谈ASP.NET开发下的MVC设计模式的实现

浅谈ASP.NET开发下的MVC设计模式的实现  以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！&nb

知识大全 ASP.NET服务器控件语法

ASP.NET开发宝典：ASP.NET服务器控件语法  以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

知识大全 在ASP.NET开发中使用非.Net Web服务

在ASP.NET开发中使用非.NetWeb服务  以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！lis

知识大全 简单介绍ASP.net服务器控件

简单介绍ASP.net服务器控件  以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！　　ASPNET服务

知识大全 ASP.NET服务器控件视图浅析

ASP.NET服务器控件视图浅析  以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！　　ASPNET服务

知识大全 ASP.NET创建Web服务之管理Web服务状态

ASP.NET创建Web服务之管理Web服务状态  以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！