IBM SOA Foundation 产品集成: 包括 WebSphere DataPower、Tivoli Access Manager 和 WebSphere Service Registry and Repository 的完整 ESB 网关解决方案

要利用面向服务的体系结构概念,一般要求能够连接到数量日益增加的系统——这些系统不仅在企业中,而且还跨越企业。在支持更高程度的自动化和减少处理时间的同时,这还导致有关管理和保护异构 IT 系统之间的基础连接的顾虑日益增加。

本文描述如何通过使用 IBM® SOA Foundation 平台中的其中三个产品实现 ESB 网关来处理这些顾虑,并首先集成 IBM WebSphere® DataPower® SOA Appliance 与 IBM Tivoli® Access Manager 以实现安全性,然后添加 IBM WebSphere Service Registry and Repository 以实现端点地址管理。 本文来自于 IBM WebSphere Developer Technical Journal

Héctor García Tellado, IT 专家 , IBM

作者照片Héctor García Tellado 是 IBM Software Services for WebSphere 组织的一名 IT 专家,主要从事面向服务的体系结构的 DataPower 和 ESB 层的工作。他作为毕业生计划 (Graduate program) 的一部分被选入 IBM Spain,从那以后参与了若干个 DataPower 和 SOA 合作项目。他出生于加利西亚省,现居住在马德里。他在业余时间喜欢弹电吉他、听音乐和外出访友。



Andre Tost, 高级技术人员, IBM

Andre Tost 是 IBM Software Services for WebSphere 组织的一名高级技术人员,他在这个部门帮助 IBM 的客户建立面向服务的体系结构。他专长于 Web 服务和企业服务总线技术。在从事目前的工作之前,他有十年的时间在 IBM 软件开发工作中担任各种合作伙伴支持、开发和构架设计方面的角色,目前他在 WebSphere Business Development 小组工作。


developerWorks 大师作者

2009 年 5 月 26 日

引言

使用作为体系结构模式的企业服务总线(Enterprise Service Bus,ESB)来描述面向服务的体系结构的基础结构级别的功能已有很长时间了。通过向服务使用者提供虚拟服务接口,并对服务使用者与服务提供者之间的交互进行中转,ESB 提供了两者之间的连接。这将使用者与提供者分离,从而产生更加灵活的解决方案,能够支持广泛的运行时平台、协议和消息格式之间的交互。

IBM developerWorks 上以及其他地方存在大量的资源,它们描述了有关 ESB 模式及其各种形式的实现的更多详细信息,并映射到具体用例场景中的产品和使用。这里就不再对它们进行重复了。相反,本文将重点集中于 ESB 中的这样一个子组件,当服务交互延伸到内部可用的网络和服务之外,以将企业彼此连接起来或连接企业中的域时,该子组件将变得非常重要。我们将该组件称为 ESB 网关,并将通常作为整体包括在 ESB 中的某些功能委托给它。

在引入该组件及其所包括的功能以后,我们将考虑一组可用于实现 ESB 网关的产品,以及一些有关如何容易地集成它们的信息。


ESB 网关模式

到目前为止,您已注意到模式的概念通常用于提供某个建议的解决方案的抽象视图,然后您可以将该抽象视图与特定的实现联系起来。这有利于从各个解决方案元素的公共和一致的命名及关联方法开始,而不依赖任何特定的技术或平台。然后可以对模式应用详细的功能和非功能需求以选择用于具体实现的相应产品集。

图 1 显示了 IBM 电子商务模式中包括的作为运行时模式的企业服务总线。

图 1. ESB 运行时模式
图 1. ESB 运行时模式

正如前面提到过的,可以通过将中心分解为许多子组件来定义该模式,其中一个子组件就是 ESB 网关,如图 2 所示。

图 2. 公开的 ESB 网关组合模式
图 2. 公开的 ESB 网关组合模式

请注意其中添加了连接器组件,它们支持与可能使用专有平台和协议的服务建立连接。此外,还引入了服务注册中心,并将其定位在 ESB 之外,但是与 ESB 紧密联系在一起。隔离区允许进一步抵御来自企业安全区之外的恶意或未经授权的访问尝试。

IBM 电子商务模式词汇表提供了以下 ESB 网关组件定义,其中阐明了其功能范围:

“ESB 网关至少提供 ESB 与外部使用者/提供者之间的服务地址转换。在实践中,ESB 网关通常提供附加服务,例如安全性、消息转换和合作伙伴数据管理。”

换句话说,该网关负责以安全和一致的方式提供服务,以便能够在安全性和总体治理方面以相同的方式处理来自广泛来源的请求。

就实现具体的解决方案而论,将此功能放在单独的网关组件中可以支持进一步的关注事项分离。例如,您稍后将在本文中看到某些 DataPower 设备功能是直接为用作这样的网关而设计的。

在本文中,我们不是在讨论所提到的各产品的任何特定版本。所提供的屏幕快照示例基于最近版本的 DataPower 设备。但是,我们预期所介绍的概念将同等地适用于将来的版本。

此外,还可以将该网关转移到隔离区中以进一步提高安全性和可伸缩性。而且,正如前面提到过的,这并非仅限用于外部合作伙伴,而是还可以利用来连接大型企业中以其他方式断开连接的域。

返回到上面的 ESB 网关定义,您可以隔离以下功能集,您预期将从可用于实现该模式的产品中获得这些功能:

  • 服务地址转换
  • 安全性
  • 消息转换
  • 合作伙伴数据管理。

作为 ESB 网关的 WebSphere DataPower

考虑到上述预期从 ESB 网关模式中获得的功能,WebSphere DataPower 设备(例如 XI50 型)是作为主入口来公开的理想候选网关,用于所有的传入服务请求以及各自的响应。使用 DataPower 作为 ESB 网关使您可以利用直接反映前一部分中介绍的网关功能的功能,例如:

  • 服务虚拟化:通过拦截(并中转)服务提供者与服务使用者之间的所有交互,从而在不同级别(消息和传输)提供两者之间的真正松散耦合。
  • 服务安全性:
    • 充当策略强制点,以抵御未经授权的访问。
    • 使用令牌转换服务标准化企业中的用户标识格式。
    • 对诸如单位时间的请求数、拒绝访问、服务使用者分析等指标进行审核并做日志记录。
  • 协议转换:标准化企业中使用的网络协议。

图 3 显示了添加 DataPower 设备后的 ESB 网关。

图 3. 作为 ESB 网关的 WebSphere DataPower
图 3. 作为 ESB 网关的 WebSphere DataPower

请注意,在此例中,网关已转移到隔离区中以实现额外的安全性。但是,要在完整的解决方案中充分利用该设备,您必须通过使用分别与 DataPower 集成的 IBM Tivoli Access Manager 和 WebSphere Service Registry and Repository,从而添加对安全和治理方面的进一步支持。

图中所示的企业服务总线可以使用各种各样的产品来实现;例如,使用 IBM WebSphere ESB、IBM WebSphere Message Broker 或者使用单独的 WebSphere DataPower 实例。本文仅将重点放在网关部分,而不再对 ESB 部分做任何进一步的介绍。


添加安全性:Tivoli Access Manager

当与 IBM Tivoli Access Manager(以下称为 Access Manager)一起协同工作时,DataPower 可以提供完整的安全解决方案。从体系结构的角度看,DataPower 充当策略强制点,也就是每个请求都必须通过该实体才能访问相应的后端服务。另一方面,Access Manager 充当策略决策点和标识提供者,也就是针对特定用户评估特定安全策略的实体,并提供身份验证和授权决策。因此,向网关解决方案添加了以下功能:

  • 与策略决策点的集成。
  • 与标识提供者的集成。
  • “安全即服务:”Tivoli Access Manager 充当整个企业环境中的凭据和资源中心,特别是为 ESB 网关提供其作为受信任的入口点所需要的所有安全信息。

图 4 显示了与 ESB 网关集成的 Tivoli Access Manager。

图 4. 带 Tivoli Access Manager 的 ESB 网关
图 4. 带 Tivoli Access Manager 的 ESB 网关

上图显示了 Access Manager 如何同时连接到 ESB 网关和实际的 ESB,从而根据需要同时为两者提供安全性。

要配置 Tivoli Access Manager 与 DataPower 设备的集成,只需几个步骤即可完成。DataPower 充当 Access Manager 客户端,该客户端要求创建特定的配置文件。这很容易在 DataPower 管理控制台中完成,如图 5 所示。

图 5. 在 DataPower 中配置 Tivoli Access Manager 集成
图 5. 在 DataPower 中配置 Tivoli Access Manager 集成

图 6 中的屏幕快照显示了必须为该配置输入的参数的示例。通常,可以从 Access Manager 管理器检索该数据。

图 6. Access Manager 客户端配置参数
图 6. Access Manager 客户端配置参数

下一个也是最后一个步骤是配置所谓的“授权服务器副本”。此参数在运行时向用户授权的时候指示远程 Access Manager 服务器的网络位置。图 7 显示了此参数的大致情况示例。

图 7. 创建授权服务器副本
图 7. 创建授权服务器副本

DataPower 设备定义了一个称为 AAA(表示身份验证、授权和审核)的操作,可将其应用于所有的传入请求。这是在其中对任何特定请求执行所有身份验证和授权步骤的操作。

完成上述步骤以后,您就准备好通过已配置的 Access Manager 客户端在任何 AAA 操作中包括所有身份验证和授权活动了。


服务端点管理 WebSphere Services Registry and Repository

为了实现对服务的运行时治理,您下面将添加 WebSphere Service Registry and Repository(以下称为 Service Registry),并将其用于存储 WSDL 服务契约,包括服务提供者的端点地址,以及描述受支持的消息格式的模式文件。

将 Service Registry 与 WebSphere DataPower 结合使用可以同时在消息和传输层提供服务虚拟化。下面就是它的工作原理:

  • DataPower 和 Service Registry 通过 DataPower 中定义的“WSRR 订阅”联系在一起。
  • 创建这样的订阅以后,将自动(在某个轮询间隔内)从 Service Registry 检索 WSDL 定义,以便在运行时将任何 WSDL 更改传播到 DataPower,包括端点和绑定定义。这添加了以下功能:
    • 在运行时从 ESB 网关中为传入服务请求进行动态端点查找。
    • 在外部注册中心对 WSDL 及关联的元数据进行集中管理,从而支持总体 SOA 治理的建立。

图 8 显示了如何将 Service Registry 添加到该解决方案。

图 8. 带 Access Manager 和 Service Registry 的 ESB 网关
图 8. 带 Access Manager 和 Service Registry 的 ESB 网关

为了实现 DataPower 与 Service Registry 之间的连接,需要设置并启用两个配置对象:从 DataPower 到 Service Registry 的物理连接,名为“WSRR Server”;以及有关我们希望订阅的元数据的信息,在“WSRR Subscription”配置对象中捕获。

配置 WSRR Server

名为“WSRR server”的元素是物理地建立 DataPower 本身与 Service Registry 之间的连接所需要的 DataPower 对象。在 WSRR Server 面板中,需要输入几个值:

  • SOAPURL 是用于通过 WSRR SOAP API 与 Service Registry 通信的 URL。
  • 如果在 Service Registry 上启用了安全性(并且通常是这样),则必须配置具有适当注册中心访问权限的用户名和密码。此外,对 Service Registry 的安全访问需要配置 SSL 连接。

图 9 显示了如何在 DataPower 管理控制台中创建 WSRR Server。

图 9. 在 DataPower 中配置 WSRR Server
图 9. 在 DataPower 中配置 WSRR Server

配置 WSRR Subscription

“WSRR subscription”对象旨在提供有关从 WSRR Server 检索的目标资源(在此例中为 WSDL 文件)的数据。存储在 WSRR Server 上的资源通过命名空间和名称唯一地进行标识,命名空间和名称都是在将资源添加到注册中心时分配的。

WSRR Subscription 对象的配置还指定了用于确保定期将资源的本地副本与 Service Registry 副本进行同步的方法。

假设您定义了一个名为“Audit Echo Service”的服务,并由一个已加载到 Service Registry 中的 WSDL 文件来表示。要为此服务创建订阅对象,您可以按如图 10 所示填入参数。

图 10. 在 DataPower 中配置 WSRR Server
图 9. 在 DataPower 中配置 WSRR Server

该示例显示您定义了要使用的 WSRR Server 对象、注册中心的目标 WSDL 定义的命名空间和名称,以及将用于同步此信息的方法。

完成此配置后,就可以在 WS-Proxy 服务中使用与 Service Registry 的集成了,其中 WS-Proxy 服务是 Web 服务的中介在 DataPower 中的命名方式。


结束语

本文描述了作为总体 ESB 体系结构模式中的重要组件的 ESB 网关,它支持内部和外部服务使用者与服务提供者之间进行安全和一致的交互。

利用 WebSphere DataPower SOA 设备为支持服务虚拟化和安全性的 ESB 网关实现奠定了基础。然后您添加了 Tivoli Access Manager 以促进“安全即服务”的概念,并从网关提供了集中的身份验证和授权请求处理。这支持使用网关作为“策略强制点”,并使用 Access Manager 作为“策略决策点”。最后,WebSphere Service Registry and Repository 服务器充当 SOA 治理的支持因素,专门存储由网关在运行时检索和使用的端点地址和其他服务元数据。

最后补充一点。本文提及的所有产品所拥有的功能远远超越了 ESB 网关解决方案中所使用的功能!纯粹出于本文的目的,我们有意将视线专门转到 ESB 网关及其相关功能方面。

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, SOA and web services
ArticleID=390590
ArticleTitle=IBM SOA Foundation 产品集成: 包括 WebSphere DataPower、Tivoli Access Manager 和 WebSphere Service Registry and Repository 的完整 ESB 网关解决方案
publish-date=05262009