安全环境中的 WebSphere 代理服务器路由功能

本文将讨论 IBM® WebSphere Application Server Network Deployment 的特性之一 WebSphere® 代理服务器的各种路由功能。文中将介绍多种配置方案,附带背景信息、设置说明和技巧,帮助您在安全的环境中利用代理服务器特性实现成功的内容路由。 本文来自于 IBM WebSphere Developer Technical Journal 中文版

Hermann Huebler, IT 专家, IBM

Hermann Huebler 于 1994 年加入 IBM,担任 AS/400(即今天的 System i)系统工程师一职。在从事了几年的缺陷和非缺陷方面的服务工作之后,Hermann 于 2000 年开始从事分布式平台上的 WebSphere Application Server 方面的工作。Hermann 参与了多个客户项目,在多个国家实现了 WebSphere Application Server。2005 年以来,Hermann 一直作为 WebSphere Application Server 专家,负责高容量客户环境。Hermann 是 “ITSO WebSphere Application Server V6.1:性能与可伸缩性” 研讨会的联合创作者和讲师,还与其他人合著了《WebSphere Application Server V7.0:概念、规划和设计》Redbook (SG24-7708-00)。自 2010 年 12 月以来,Hermann 被派遣至印度班加罗尔的交付中心,这是技能发展计划的一部分。



2012 年 4 月 19 日

免费下载:IBM® WebSphere® Application Server Network Deployment 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

为了帮助以最优成本提供足够高的性能,高容量网站往往依赖于使内容接近客户端的机制。这通常意味着某种类型的缓存和缓存管理。

尽管静态内容所导致的负载不容低估,但仅仅缓存静态内容对于大多数情况来说并不够。如今的现代缓存机制还必须提供缓存动态内容的能力。

IBM WebSphere Application Server Network Deployment(下文简称为 Network Deployment)提供了多种内置的解决方案,这些解决方案既可用作中介服务,也可提供静态和动态缓存功能。除了应用服务器本身提供的动态缓存特性之外,以下这些产品也提供了缓存功能:

IBM WebSphere 软件产品系列提供了特殊的解决方案,专门为应用程序和业务数据缓存进行了优化,例如 IBM WebSphere DataPower® Appliance XC10。

  • HTTP 插件。
  • WebSphere 代理服务器。
  • DMZ 安全代理服务器。
  • 边缘组件缓存代理。

这些解决方案都有着自己的优缺点。《代理服务器与 HTTP 插件的对比:选择最佳 WebSphere Application Server 工作负载管理选项》一文很好地介绍了 Network Deployment 提供的中介服务。另外有一个分为两部分的系列文章提供了其他有关 WebSphere 代理服务器安置拓扑结构和配置方面的宝贵信息,第一部分是《超级集群解决方案,第 1 部分》

这篇文章深入观察了 WebSphere 代理服务器提供的路由功能。此外还讨论了托管通过代理服务器交付的内容的安全 WebSphere Application Server cell 的必要配置步骤。


WebSphere 代理服务器管理概述

WebSphere 代理服务器最初是在 WebSphere Application Server Network Deployment V6.0.2 中引入的,需要增加 Deployment Manager 配置文件才能看到。在较新版本的 WebSphere Application Server 中,WebSphere 代理服务器可以在 Deployment Manager 管理控制台中开箱即用地配置。

WebSphere 代理服务器作为 Network Deployment cell 的一部分运行,因此不适合置于网络拓扑结构的 DMZ 之中。在 Network Deployment V7.0 中发布了经过加强、DMZ 就绪的 WebSphere 代理服务器版本,即 DMZ 安全代理服务器。不过,本文仅介绍在 cell 内运行的 WebSphere 代理服务器。

从管理和配置的角度来看,WebSphere 代理服务器是一种独立的服务器类型,在托管节点的 WebSphere Application Server cell 内运行。您可以在 cell 内创建和配置 WebSphere 代理服务器定义,方法可以是打开 WebSphere Application Server 管理控制台,也可以是使用 wsadmin 进行基于脚本的管理。

要使用管理控制台管理您的 cell 的 WebSphere 代理服务器,可导航至 Servers > Server Types > WebSphere proxy servers。您可以在这里按照创建服务器的标准过程创建一个 WebSphere 代理服务器。要使用 WebSphere 代理服务器将请求路由至 cell 内部署的应用程序,必须执行以下最低要求配置:

  1. 代理服务器定义的 PROXY_HTTP_ADDRESS 和 PROXY_HTTPS_ADDRESS 端口必须位于所部署应用程序的虚拟主机定义的主机别名列表之中。
  2. 需要通过代理服务器提供的模块必须具有 Enable Proxy 属性集(请参见下一节)。

实际上,WebSphere 代理服务器可将请求路由至两类内容资源:

  • 托管资源

    托管资源是由 WebSphere Application Server 在与 WebSphere 代理服务器相同的 cell 内或远程 cell 内托管的资源。这些资源完全受 WebSphere Application Server 的管理,因此各资源的状态以及该资源的路由信息将通过高可用性管理器的公告板服务动态传播。因此,托管资源的路由是动态的,依赖于环境,它需要恰当的核心组配置,以使高可用性管理器能够传播各资源的状态。

    为了启用托管资源的动态路由,您需要选择针对所部署的应用程序模块的 Enable Proxy 复选框;在应用程序部署过程中,此复选框默认为选中。

    为了确认已经为一个模块选中了 Enable Proxy 选项,请打开管理控制台,导航至 Applications > Application Types > WebSphere enterprise application ><application_name> > Manage modules > <module_name> > Web Module Proxy Configuration (图 1)。

    图 1. Web 模块代理配置
    图 1. Web 模块代理配置

    Enable Proxy 复选框默认是活动状态,启用代理服务器路由的模块。Web Module Transport Protocol 下拉列表框使您能够选择在代理服务器与应用服务器之间使用的协议(HTTP 或者 HTTPS)。

  • 非托管资源

    非托管资源是不受 WebSphere Application Server 的管理与控制的资源。由于 WebSphere Application Server 不能控制这些资源,因此它对这些资源的当前状态和可用性所知有限,因此需要手动配置。因此,WebSphere 代理服务器仅能在 TCP/IP 通信级别上检查可用性以及托管内容的服务器是否可用。

    除此之外,WebSphere Application Server 没有机会收集此类资源的路由信息,因此到非托管资源的路由同样需要手动配置。非托管内容资源的典型示例包括 HTTP 服务器、其他 J2EE™ 应用服务器等提供的资源,这些资源可以使用 HTTP 或 HTTPS 协议访问。


动态路由和核心组

使用 WebSphere 代理服务器,可以根据托管内容的服务器类型以及环境的构建方式通过不同的方法实现路由。尽管托管内容资源支持全面动态的请求路由,但非托管内容资源需要手动路由配置。

如前所述,动态路由仅可对托管资源实现。托管资源的路由信息将通过高可用性管理器的公告板服务传播。这项服务将基于核心组传播路由和可用性信息。这使 WebSphere 代理服务器的路由配置不再以代理配置为中心,而是以核心组配置为中心。因此,可行的配置受可行的核心组配置所限。WebSphere Application Server 信息中心 提供了有关核心组桥接的具体信息。

核心组配置是 WebSphere 代理服务器路由配置任务的重要组成部分,因此有必要充分理解核心组和核心组术语。本文中将使用以下核心组术语。(有关更具体的解释,请参见 WebSphere Application Server v7.0 信息中心。)

  • 核心组是高可用性管理器内的一种高可用性域。它定义了一组流程,通过它可以建立直接的高可用性关系。高可用组件仅可故障转移至相同核心组内的流程。
  • 访问点组定义了一组彼此通信且可交换高可用性信息的核心组。
  • 访问点定义了用于与其他核心组通信的一个核心组内的一组应用服务器。在访问点中,配置为桥接接口的应用服务器称为核心组桥接服务器
  • 核心组桥接接口定义了用于跨核心组边界交换数据的节点、应用服务器和传输信道链。
  • 核心组桥接服务是 WebSphere Application Server 内的一种高可用性管理器相关服务,支持在核心组之间共享高可用性信息。
  • 对等核心组即相互连接可交换核心组相关信息的核心组,但位于不同的 cell 中。
  • 对等访问点即用于对等核心组间通信的访问点。一个核心组的每个对等访问点都需要对等 cell 中具有一个对应的核心组访问点。

示例配置

配置的复杂度实际上是无限的,图 2 显示了将在本文中使用的示例拓扑结构,本文使用这个拓扑结构来演示动态路由功能和 WebSphere 代理服务器的必要配置。

图 2. 文中使用的示例拓扑结构
图 2. 文中使用的示例拓扑结构

这个拓扑结构由两个 cell 组成。第一个 cell 是 d0002,托管代理服务器,并分为两个核心组,即 DefaultCoreGroup 和 WebCoreGroup。代理服务器是 DefaultCoreGroup 的成员。第二个 cell 是 d0003,其中包含一个核心组 DefaultCoreGroup。通过配置核心组桥接,cell d0002 的代理服务器就能够动态路由流量,不仅可路由至相同核心组 (d0002-DefaultCoreGroup) 内的应用服务器,还可路由至不同核心组 (d0002-WebCoreGroup) 中的服务器内部署的应用程序,也能路由至不同 cell (d0003-DefaultCoreGroup) 中部署的应用程序。

作为生产环境的最佳实践,该环境将使用 WebSphere Application Server 安全性进行保护。因此,cell 内的所有管理通信都将经过验证、授权和加密。然而,管理员需要负责确保与其他系统(例如 LDAP 服务器、数据库服务器等)之间的通信同样安全。


相同 cell 和相同核心组内的 WebSphere Application Server

在这种方案中,WebSphere 代理服务器位于与托管请求路由至的应用程序的 WebSphere Application Server 相同的 cell 和核心组中。图 3 展示了使用代理服务器集群的简单拓扑结构(出于高可用性和负载平衡方面的原因)。

图 3. 路由至相同核心组内的应用服务器
图 3. 路由至相同核心组内的应用服务器

这种配置是非常基本的设置,通过 WebSphere 代理服务器将请求路由至托管内容服务器。这种设置仅需对路由流量做出最少的配置即可。实现 WebSphere 代理服务器并将流量路由至相同 cell 和核心组内的应用服务器的步骤仅要求为应用程序模块启用该代理。甚至不需要将模块映射到代理服务器。只需为应用程序模块设置 Enable Proxy 选项即可。


位于相同 cell、不同核心组内的 WebSphere Application Server

在这种设置中,代理服务器将流量路由至与代理服务器本身处于相同核心组的应用服务器,同时路由至相同 cell 内不同核心组的托管内容服务器。

图 4 展示了单 cell 配置的拓扑结构,使用代理服务器将请求路由至与代理服务器处于相同核心组 (DefaultCoreGroup) 的应用服务器,同时路由至另外一个核心组 (WebCoreGroup)。请注意,需要在这两个核心组之间配置核心组桥接,以使核心组能够交换状态和可用性信息。

图 4. 路由至相同 cell 的不同核心组内的应用服务器
图 4. 路由至相同 cell 的不同核心组内的应用服务器

如前文所述,托管资源的路由和可用性信息将使用高可用性管理器公告板服务传播。尽管核心组定义了在 WebSphere Application Server cell 内交换可用性信息的便捷,但核心组桥接服务允许在相同 cell 的不同核心组之间交换高可用性信息,也支持在不同 cell 的核心组之间交换此类信息。

为了确保代理服务器能够合理地路由请求,各核心组内必须至少有一个核心组桥接接口服务器保持活动。出于可用性方面的原因,您应在各核心组的不同节点上配置两个核心组桥接接口服务器。配置两个以上的核心组桥接接口服务器会增加内存和 CPU 开销,仅应在经过慎重考虑的特定情况下使用。举一个例子,如果各核心组的节点分布在两台以上的服务器上,那么就需要最大限度地提高弹性,以便保证两台服务器的故障或者维护不会中断核心组桥接通信。

此外,请务必牢记,核心组桥接服务要占用内存和 CPU 资源。因此,最佳实践是配置专用服务器作为核心组桥接接口服务器,并将其监视策略配置为自动重启。

在相同 cell 内的两个核心组之间设置核心组桥接服务的基本步骤可汇总如下:

  1. 定义一个访问点组(或者使用现有的 DefaultAccessPointGroup)。
  2. 为访问点组中的各核心组配置核心组访问点。
  3. 为各核心组访问点配置核心组桥接接口。

下面的步骤将具体描述 DefaultCoreGroup 与 WebCoreGroup 之间的核心组桥接的配置。所使用的拓扑结构如 图 2 所示。创建 WebCoreGroup 以及将必要的应用服务器指派给 WebCoreGroup 是设置核心组桥接的先决条件。

图 5 展示了管理控制台内的核心组桥接设置,在设置桥接之前配置了两个核心组。

图 5. 在桥接配置之前,两个核心组的核心组桥接设置
图 5. 在桥接配置之前,两个核心组的核心组桥接设置

总体而言,使用一致的命名规范将使管理更简单、更准确。

表 1 提供了用于为示例拓扑结构配置核心组桥接服务的配置对象的概述。

表 1. 核心组桥接配置参数
Cell 核心组节点核心组访问点名称核心组桥接接口服务器主机名称/IP 地址桥接接口服务器的 DCS 端口
d0002DefaultCoreGrouphhuelinux_m00021d0002_dft_ap01d0002DftCgBr_01hhuelinux41266
hhuelinux_m00022d0002DftCgBr_0242266
d0002WebCoreGrouphhuelinux_m00021d0002_web_ap01d0002WebCgBr_01hhuelinux41291
hhuelinux_m00022d0002WebCgBr_0242291

要在两个核心组之间设置核心组桥接,请按以下步骤执行:

  1. 在针对 cell d0002 的 WebSphere Application Server 管理控制台中,导航至 Servers > Core Groups > Core group bridge settings
  2. 核心组通过核心组访问点组彼此通信。对于本方案,要在相同 cell 内的两个核心组之间创建桥接,可以使用预先定义的 DefaultAccessPointGroup。添加核心组访问点,方法是使用 DefaultAccessPointGroup 为 WebCoreGroup 配置核心组桥接接口服务器。单击 DefaultAccessPointGroup,如图 6 所示。
    图 6. 选择核心组访问点
    图 6. 选择核心组访问点
  3. 单击浏览路径记录中的 Core group access points,为 WebCoreGroup 配置核心组访问点(图 7)。
    图 7. 核心组访问点的配置
    图 7. 核心组访问点的配置

如果访问点组还包括对等访问点,则一个访问点组的每个核心组仅可具有一个核心组访问点。

  1. 在核心组访问点面板中,您可以更新现有核心组访问点,方法是选中要更新的核心组访问点,并按下 Show Detail,或者单击 New。图 8 显示了如何选择一个核心组访问点来更新设置。
    图 8. 选择一个核心组访问点以便编辑其值
    图 8. 选择一个核心组访问点以便编辑其值

尽管并非必须,但为核心组访问点指定一个有意义的名称是一种良好的做法。

  1. 核心组访问点的配置基本上需要配置:
    1. 核心组访问点名称。
    2. 为之配置访问点的核心组。
    3. 桥接接口的定义。
    4. 自定义属性。
    输入核心组访问点的名称,从下拉列表框中选择为之定义访问点的核心组(图 9)。按下 Apply 按钮,并单击 Bridge interfaces 来配置桥接接口服务器。
    图 9. 重命名核心组访问点并选择桥接接口
    图 9. 重命名核心组访问点并选择桥接接口
  2. 对于您希望添加到此核心组访问点的每一个核心组桥接接口服务器重复这些步骤:
    1. 单击 New 添加新桥接接口服务器(图 10)。
    2. 根据 “表 1. 核心组桥接配置参数” 所示,从下拉列表框中选择应作为核心组桥接接口服务器的服务器。图 10 展示了为 DefaultCoreGroup 指定的桥接接口服务器。
    图 10. 为 DefaultCoreGroup 配置的桥接接口服务器
    图 10. 为 DefaultCoreGroup 配置的桥接接口服务器
  3. 为 WebCoreGroup 重复第 5 步到第 9 步,为该核心组定义桥接接口服务器。
  4. 定义了针对核心组访问点组的所有核心组桥接服务器之后,单击浏览路径 (breadcrumb path) 中的 Core group bridge settings 返回核心组桥接设置面板。展开项目,检查您的核心组桥接设置。

核心组通信通过服务器的 DCS 端口运行。因此,请确保防火墙中打开了这些端口,以防不同网络区域中的核心组被防火墙阻隔。

  1. 图 11 展示了展开了全部访问点、核心组桥接服务器及其属性的 DefaultAccessPointGroup,提供了桥接配置和相关网络配置的概览。在这个 cell d0002 的核心组桥接配置概览中,您可以看到,DefaultCoreGroup 通过 d0002DftCgBr_01、d0002DftCgBr_02、d0002WebCgBr_01 和 d0002WebCgBr_02 服务器的 DCS 端口桥接至 WebCoreGroup。
    图 11. 核心组桥接设置及所有桥接接口
    图 11. 核心组桥接设置及所有桥接接口
  2. 关闭并重启该访问点组内的所有经过配置的核心组桥接接口服务器,通过桥接使用的 JVM 日志进行验证。检查日志中的以下消息:
    • CWRCB0106I
    • CWRCB0107I
    清单 1
    [11/27/11 16:38:37:081 IST] 00000008 CGBridge      I   CWRCB0106I: This core group 
    bridge service (d0002\hhuelinux_m0002 1\d0002DftCgBr_01) uses the following DCS 
    endpoint: 127.0.0.1:41266 
    [11/27/11 16:38:54:009 IST] 00000008 CGBridge      I   CWRCB0107I: This core group 
    bridge is stable and has the following Access Point Group member(s) available: 
    DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01 
    (127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291) 
    DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr_01
    (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)

确定核心组桥接服务正常工作之后,也就准备好了通过 WebSphere 代理服务器在两个核心组中访问您的应用程序。要使用 HTTP 协议访问各核心组内的 WebSphere Application Server(s) 中部署的应用程序,您需要在浏览器的 URL 中指定代理服务器的 PROXY_HTTP_ADDRESS 端口(例如,80)。要通过 HTTPS 协议访问应用程序,请在浏览器的 URL 中使用代理服务器的 PROXY_HTTPS_ADDRESS 端口(例如,443)。用于访问应用程序的主机名是 WebSphere 代理服务器的 Internet 主机名称。因此,举例来说,用于访问 Information.ear 的 Web 模块的 URL 是:https://proxyhost/info/Information.jsp;用于访问 CoeTest.ear 的 Web 模块的 URL 是 https://proxyhost/jdbctest/index.jsp

如果 WebSphere 代理服务器路由的请求导致 503 HTTP 返回代码(还有其他一些代码),那么常见的原因包括:

  • 核心组桥接工作不正常。检查并验证每个核心组访问点中至少有一个核心组桥接服务器正在运行。
  • 企业应用程序本身未启动。

现在就是执行测试,确保应用程序可通过代理服务器访问的最好时机。根据 图 2 中的示例拓扑结构,这些应用程序现在应该能够正常工作:

  • Information.ear
  • CoETest.ear

请牢记,各核心组内必须至少有个核心组桥接接口服务器正常运行。

请参阅 WebSphere Application Server 信息中心,获得有关设置核心组桥接服务的具体信息。


与代理服务器位于不同 cell 的 WebSphere Application Server

在这种设置中,代理服务器将流量路由至与代理服务器本身处于相同核心组的应用服务器,同时路由至相同 cell 内不同核心组的应用服务器,以及位于远程 cell 的托管内容服务器。

图 12 展示的拓扑结构使用一个代理服务器集群,将请求路由至与代理服务器处于相同核心组 (DefaultCoreGroup) 的应用服务器,同时路由至位于代理服务器的 cell (d0002) 中的另外一个核心组 (WebCoreGroup)。在这种方案内,代理服务器也会将请求路由至与代理服务器所在 cell 不同的 cell (d0003) 内的应用服务器。需要在相同 cell 内的两个核心组之间配置一个核心组桥接,如 上一个方案 所述。除此之外,必须在代理服务器的核心组与应将请求路由至的远程 cell 之间建立一个对等核心组桥接。

图 12. 路由至不同 cell 内的应用服务器
图 12. 路由至不同 cell 内的应用服务器

如前文所述,托管资源的路由和可用性信息将使用高可用性管理器的公告板服务传播。然而,核心组定义了在 WebSphere Application Server cell 内交换可用性信息的边界。因此,您需要配置核心组桥接,启用核心组与 cell 之间的高可用性信息交换。上文 已经介绍了将请求路由至部署在相同 cell 的独立核心组中的服务器之中的应用程序时必需的核心组配置。在这里,我们将重点关注将请求路由至远程 cell 中的服务器时所需的核心组配置,这也称为对等核心组桥接

为了跨 cell 桥接核心组,请确保满足以下条件:

为了确保代理服务器能够合理地路由请求,各核心组内必须至少有一个核心组桥接接口服务器保持活动。出于可用性方面的原因,您应在各核心组的不同节点上配置两个核心组桥接接口服务器。配置两个以上的核心组桥接接口服务器会增加内存和 CPU 开销,仅应在经过慎重考虑的特定情况下使用。例如,如果各核心组的节点分布在两台以上的服务器上,那么就需要最大限度地提高弹性,以便保证两台服务器的故障或维护不会导致核心组桥接通信中断。

此外,请务必牢记,核心组桥接服务要占用内存和 CPU 资源。因此,最佳实践是配置专用服务器作为核心组桥接接口服务器,并将其监视策略设置配置为自动重启。

  • 您正在配置期间的核心组桥接通信的两个 cell 必须具有惟一名称。
  • 用于连接两个对等核心组的核心组访问点组必须在各 cell 中具有相同的名称。
  • 各访问点组必须包含:
    • 针对本地 cell 的核心组的一个核心组访问点。
    • 分别与远程 cell 中的每个核心组相对应的一个核心组访问点。
    • 必须为相同 cell 内的核心组之间的桥接以及远程 cell 中核心组的桥接使用相同的核心组桥接服务器。
  • 在安全环境中工作时(通常生产环境就是此类环境),跨 cell 设置核心组桥接时还有其他一些条件需要考虑,即:
    • 两个 cell 的安全域名称必须匹配。
    • 两个 cell 必须彼此信任,因为两个 cell 之间必须交换签名证书。
    • cell 之间必须交换 LTPA 密钥。因此,如果不采取恰当的手动措施,LTPA 密钥的自动重新生成将破坏核心组桥接。出于这方面的原因,您应该考虑禁用 LTPA 密钥的自动重新生成。

为在两个 cell 之间设置核心组桥接服务:

  1. 定义一个访问点组。请务必牢记,两个 cell 中的访问点组的名称必须匹配。
  2. 为访问点组中的各核心组配置核心组访问点。
  3. 为各核心组访问点配置核心组桥接接口。

下面的步骤描述了 cell d0002 与 d0003 之间的核心组桥接服务的配置。在两个 cell 中,核心组桥接接口服务器都将是 DefaultCoreGroup 的成员。

表 2 提供了用于配置核心组桥接服务的配置对象的概述:

表 2. 对等核心组桥接的核心组桥接配置参数
Cell 核心组节点核心组访问点名称核心组桥接接口服务器主机名称/IP 地址桥接接口服务器的 DCS 端口
d0002DefaultCoreGrouphhuelinux_m00021d0002_dft_ap01d0002DftCgBr_01hhuelinux41266
hhuelinux_m00022d0002DftCgBr_0242266
d0003DefaultCoreGrouphhuelinux_m00031d0003_dft_ap01d0003DftCgBr_01hhuelinux41366
hhuelinux_m00032d0003DftCgBr_0242366

必须使用恰当的配置值,为每个 cell 执行设置此环节的必要步骤。首先,cell d0002 的配置步骤:

  1. 打开针对 cell d0002 的 WebSphere Application Server 管理控制台,导航至 Servers > Core Groups > Core group bridge settings
  2. 选择 Access points 容器中的 Peer access points,如图 13 所示。
    图 13. 对等访问点的配置
    图 13. 对等访问点的配置
  3. 单击 New 创建新的对等访问点。
  4. 按照表 2 中的配置值输入配置(图 14)。
    图 14. 创建一个新的核心组对等访问点
    图 14. 创建一个新的核心组对等访问点
  5. 单击 Next 进入下一个面板。
  6. 为远程 cell 中的第一个桥接接口服务器输入 DCS 连接信息。在您的设置中,这是 cell d0003 内 DefaultCoreGroup 的第一个核心组桥接服务器。根据表 2,这是服务器 d0003DftCgBr_01 的主机名和端口名。图 15 展示了第一个对等端口定义的配置。
    图 15. 核心组访问点对等端口的配置
    图 15. 核心组访问点对等端口的配置
  7. 单击 Next 进入总结面板。
  8. 单击 Finish 确定创建第一个对等访问点。
  9. 如需添加其他对等访问点,请单击对等访问点名称,如图 16 所示。
    图 16. 选择核心组对等访问点来添加一个端口
    图 16. 选择核心组对等访问点来添加一个端口
  10. 单击浏览路径记录中的 Peer ports 再添加一个访问点端口,以实现对等核心组桥接的高可用性(图 17)。
    图 17. 添加额外的对等端口定义
    图 17. 添加额外的对等端口定义
  11. 单击 New 添加额外的对等端口。
  12. 为远程 cell 中的第二个桥接接口服务器输入 DCS 连接信息。根据表 2,这是服务器 d0003DftCgBr_02 的主机名和端口名称。
  13. 再次单击 Peer ports 验证对等访问点的对等的端口定义(图 18)。
    图 18. 对等端口定义的验证
    图 18. 对等端口定义的验证

配置核心组访问点组以便桥接至 d0003

下一个主要步骤就是为核心组桥接服务配置核心组访问点组。在核心组访问点组的创建过程中,您可以在同一个步骤中指派访问点和对等访问点。此外,您也可以稍后为组指派访问点信息。对于本例,您将首先创建一个空的访问点组,随后指派访问点和对等访问点。

请务必牢记,两个 cell 中的访问点组的名称必须匹配。

  1. 在针对 cell d0002 的 WebSphere Application Server 管理控制台中,导航至 Servers > Core Groups > Core group bridge settings > Access point groups,随后单击 New
  2. Access point group name 字段中输入您要创建的核心组访问点组名称。在本方案中,名称是 dft_d0002_to_dft_d0003
  3. 单击 Next,完成接下来的三个面板,随后单击 Finish
  4. 单击您刚刚创建的访问点组的名称,如图 19 所示。
    图 19. 选择核心组访问点组来添加访问点
    图 19. 选择核心组访问点组来添加访问点
  5. 要指派对等访问点,请单击 Access points 容器中的 Peer access points
  6. 从可用对等访问点容器中选择之前创建的对等访问点,并单击向右箭头,将对等访问点指派给访问点组,如图 20 所示。
    图 20. 将一个对等访问点添加到一个访问点组中
    图 20. 将一个对等访问点添加到一个访问点组中
  7. 单击 OK
  8. 接下来,将本地核心组的访问点指派给访问点组。如果 cell 仅包含一个核心组,则将跳过此步骤。请单击 Access points 容器中的 Core groups access points,如图 21 所示。
    图 21. 为核心组访问点组添加本地访问点
    图 21. 为核心组访问点组添加本地访问点

为了实现核心组桥接的最大弹性,每个桥接接口服务器都必须在独立的节点、独立的系统上运行。

核心组通信通过服务器的 DCS 端口运行。因此,请确保防火墙中打开了这些端口,以防不同网络区域中的核心组被防火墙阻隔。

  1. 从 available peer access points 容器中选择您希望添加的核心组访问点,并单击向右箭头,将访问点指派给访问点组,如图 22 所示。在本例中,您正在配置 cell d0002 中的 DefaultCoreGroup 与 cell d0003 中的 DefaultCoreGroup 之间的核心组桥接。因此,必须选中 d0002_dft_ap01\DefaultCoreGroup 访问点,并添加到核心组访问点组之中。
    图 22. 选择要添加到核心组访问点组中的访问点
    图 22. 选择要添加到核心组访问点组中的访问点
  2. 单击 OK
  3. 单击浏览路径记录中的 Core group bridge settings。展开项目,检查您的核心组桥接设置。
    图 23. cell d0002 的核心组桥接配置概览
    图 23. cell d0002 的核心组桥接配置概览

图 23 展示 cell d0002 的两个核心组访问点组以及全部访问点、核心组桥接服务器,同时也展开了它们的属性,提供了桥接配置以及相关网络配置的概览。在 cell d0002 核心组桥接配置的这份概览中,您可以看到,cell d0002 的 DefaultCoreGroup 通过服务器 d0002DftCgBr_01 和 d0002DftCgBr_02 桥接至 cell d0003 的 DefaultCoreGroup。核心组桥接流量在这两台服务器之间流动,这些服务器均具有侦听服务器 hhuelinux.huebler.at:41366 和 hhuelinux.huebler.at:42366 的 DCS 端口。

cell d0002 的核心组桥接配置至此完成。

cell d0003 的核心组桥接配置

接下来,您将为 cell d0003 重复相同的配置步骤。必须使用相同的命名为 cell d0003 执行这些步骤。同样,可以通过 表 2 确定配置值。由于步骤基本相同,因此此处仅给出汇总:

  1. 在针对 d0003 的 WebSphere Application Server 管理控制台中,导航至 Servers > Core Groups > Core group bridge settings
  2. 由于 cell d0002 与 d0003 之间的核心组访问点组名称必须匹配,因此第一步是创建名为 dft_d0002_to_dft_d0003 的核心组访问点组。
  3. 单击核心组访问点组名称,选择 Core group access points
  4. 在可用核心组访问点下,单击 CGAP_1\DefaultCoreGroup 并选择 Show detail
  5. 重新命名核心组访问点,按照 表 2 添加桥接接口服务器。图 9 详细地展示了必要的步骤。
  6. d0003_dft_ap01 核心组访问点添加至核心组访问点组 dft_d0002_to_dft_d0003。
  7. 为 cell d0002 配置对等访问点,如 图 13 所示,并将对等访问点 d0002_dft_peer_ap01 添加到核心组访问点组 dft_d0002_to_dft_d0003。
  8. cell d0003 的核心组桥接配置应类似于图 24 所示。
    图 24. cell d0003 的核心组桥接配置
    图 24. cell d0003 的核心组桥接配置
  9. 关闭并重启两个 cell 中全部已配置的核心组桥接接口服务器。
  10. 启动 cell d0002 的核心组桥接服务器,并通过桥接正在工作的核心组桥接服务器的 JVM 日志进行验证。检查日志中的以下消息:
    • CWRCB0106I
    • CWRCB0107I
    仅启动了 cell d0002 的核心组桥接服务器,并验证了 cell d0002 的 DefaultCoreGroup 的核心组桥接服务器的 SystemOut.log 之后,清单 2 中的这条消息表明与 WebCoreGroup 的桥接正常工作。然而,访问点组 dft_d0002_to_dft_d0003 的消息 NO BRIDGES 表示到 cell d0003 的桥接目前不可用。
    清单 2
    [12/6/11 12:08:58:846 IST] 0000000b CGBridge      I   CWRCB0106I: This core group 
    bridge service (d0002\hhuelinux_m00021\d0002DftCgBr_01) uses the following DCS 
    endpoint: 127.0.0.1:41266 
    [12/6/11 12:08:58:850 IST] 0000000b CGBridge      I   CWRCB0107I: This core group 
    bridge is stable and has the following Access Point Group member(s) available: 
    DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01 
    (127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291) 
    DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr
    _01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266) 
    dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup NO BRIDGES 
    dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr
    _01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)
  11. 启动 cell d0003 的核心组桥接服务器,并通过桥接正在工作的核心组桥接服务器的 JVM 日志进行验证。检查日志中的以下消息:
    • CWRCB0106I
    • CWRCB0107I
    启动了 cell d0003 的核心组桥接服务器,并验证了 cell d0003 的 DefaultCoreGroup 的核心组桥接服务器的 SystemOut.log 之后,访问点组 dft_d0002_to_dft_d0003 的 NO BRIDGES 消息仍然表明到 cell d0002 的消息不可用,而核心组桥接接口服务器仍在正在运行(清单 3)。
    清单 3
    [12/6/11 13:19:19:685 IST] 00000009 CGBridge      I   CWRCB0106I: This core group 
    bridge service (d0003\hhuelinux_m00031 
    \d0003DftCgBr_01) uses the following DCS endpoint: 127.0.0.1:41366 
    [12/6/11 13:19:19:694 IST] 00000009 CGBridge      I   CWRCB0107I: This core group 
    bridge is stable and has the following 
     Access Point Group member(s) available: 
    dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01
    (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) 
    dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup NO BRIDGES 
    [12/6/11 13:19:19:702 IST] 00000009 CGBridge      I   CWRCB0108I: The core group 
    bridge service is currently unstable for Access Point Group(s) DefaultAccessPoint
    Group.
    [12/6/11 13:19:21:487 IST] 0000000a CGBridge      I   CWRCB0106I: This core group 
    bridge service (d0003\hhuelinux_m00031\d0003DftCgBr_01) uses the following DCS 
    endpoint:
    127.0.0.1:41366 
    [12/6/11 13:19:21:495 IST] 0000000a CGBridge      I   CWRCB0107I: This core group
    bridge is stable and has the following Access Point Group member(s) available: 
    DefaultAccessPointGroup d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01
    (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) 
    dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01
    (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) 
    dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup NO BRIDGES
  12. 进一步检查 SystemOut.log 表明另外还出现了 HMGR0149E 错误消息(清单 4),这将您引向了问题的核心所在。
    清单 4
    [12/6/11 13:19:41:763 IST] 00000023 DefaultTokenP E   HMGR0149E: An attempt to open 
    a connection to core group dft_d0002_to_dft_d0003 has been rejected. The sending 
    process has a name of 127.0.0.1:41266 and an IP address of /127.0.0.1. Global 
    security in the local process is Enabled. Global security in the sending process 
    is Enabled. The received token starts with lf>c%$oO. The exception is com.ibm.
    websphere.security.auth.WSLoginFailedException: Validation of LTPA token failed due 
    to invalid keys or token type. 
            at com.ibm.ws.security.ltpa.LTPAServerObject.validateToken
    (LTPAServerObject.java:1161) 
            at com.ibm.ws.security.ltpa.LTPAServerObject.validateToken
    (LTPAServerObject.java:1078) 
            at com.ibm.ws.security.token.WSCredentialTokenMapper.validateLTPAToken
    (WSCredentialTokenMapper.java:1376) 
            at com.ibm.ws.hamanager.runtime.DefaultTokenProvider.authenticateMember
    (DefaultTokenProvider.java:214) 
            at com.ibm.ws.hamanager.coordinator.dcs.MemberAuthenticatorImpl.
    authenticateMember(MemberAuthenticatorImpl.java:87) 
            at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.ptpDiscovery.DiscoveryRcv.
    acceptStream(DiscoveryRcv.java:185) 
            at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor.fetchStream(Packet
    Processor.java:470) 
    at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor.run(PacketProcessor.java:860)

    之所以得到 HMGR0149E 错误消息,是因为您尝试在两个启用了安全性的 cell 之间建立核心组桥接(在任何生产环境中都应启用了安全性),但并未设置 cell 间的单点登录。

核心组桥接服务为跨 cell 身份验证使用 LTPA 身份验证机制。

  1. 您需要在 WebSphere Application Server 中进行 轻量级第三方身份验证使用 LTPA cookie 的单点登录身份验证 设置,为对等核心组桥接启用通过 LTPA 进行的身份验证。需要考虑的要点可汇总如下:
    • 在 cell 之间共享 LTPA 密钥。为了避免未来发生问题,应该禁用自动重新生成,新密钥应手动重新生成和分发。
    • 服务日期和时间必须同步。
    • 用户注册库必须是集中管理的注册库,例如 LDAP 或者 Windows® Active directory。
    • 如果您正在使用实现了 LDAPS 协议连接到 LDAP 服务器的安全环境,请将 LDAP 服务器的签名证书导入到 WebSphere 代理服务器使用的 truststore。默认情况下,在 WebSphere Application Server V7.0 中为 CellDefaultTrustStore。

在使用 SSL 访问站点时,您需要将内容服务器的服务证书的签名证书添加到代理使用的 trust store 中。请务必确保将签名证书添加到代理使用的 trust store 中,而不是服务器证书!由于 WebSphere Application Server 使用一种 mini-CA,因此一份签名证书用于签署一个 cell 的全部证书。在两个 cell 之间交换此签名证书 (root) 通常便已足够。

  1. 如果您正在计划使用 HTTPS 协议访问您的 web 页面,WebSphere 代理服务器将使用 SSL 通过 WC_defaulthost_secure 端口访问托管应用程序的服务器。尽管这通常对于相同 cell 中的服务器不构成问题(WebSphere Application Server V7.0 及更新版本中即采用这种默认设定;一个 cell 中的所有服务器均彼此信任),但如果代理服务器和内容服务器处于不同的 cell 之中,那么就需要交换签名证书。如果未能交换签名证书,则将导致 CWPKI0022E:SSL HANDSHAKE FAILURE: 错误消息,后接一条 “CWPKI0428I:The signer might need to be added to the local trust store” 错误消息,这些错误消息记录在代理服务器的 SystemOut.log 之中。在这种情况下,最终用户将看到 503 服务不可用响应代码。
  2. 注意了上述要点、重启了服务器之后,代理 cell(本方案中为 d0002)的默认核心组的核心组桥接服务器应包含恰当的消息,表明已在两个 cell 之间建立了核心组桥接服务。检查日志中的以下消息:
    • CWRCB0106I
    • CWRCB0107I
    清单 5
    [12/7/11 14:43:05:039 IST] 0000000b CGBridge      I   CWRCB0106I: This core group 
    bridge service (d0002\hhuelinux_m00021\d0002DftCgBr_01) uses the following DCS 
    endpoint: 127.0.0.1:41266
    [12/7/11 14:43:05:045 IST] 0000000b CGBridge      I   CWRCB0107I: This core group 
    bridge is stable and has the following Access Point Group member(s) available: 
    DefaultAccessPointGroup d0002:WebCoreGroup d0002\hhuelinux_m00021\d0002WebCgBr_01 
    (127.0.0.1:41291), d0002\hhuelinux_m00022\d0002WebCgBr_02 (127.0.0.1:42291) 
    DefaultAccessPointGroup d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr
    _01 (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266) 
    dft_d0002_to_dft_d0003 d0003:DefaultCoreGroup d0003\hhuelinux_m00031\d0003DftCgBr_01 
    (127.0.0.1:41366), d0003\hhuelinux_m00032\d0003DftCgBr_02 (127.0.0.1:42366) 
    dft_d0002_to_dft_d0003 d0002:DefaultCoreGroup d0002\hhuelinux_m00021\d0002DftCgBr_01 
    (127.0.0.1:41266), d0002\hhuelinux_m00022\d0002DftCgBr_02 (127.0.0.1:42266)

确定核心组桥接服务正常工作之后,也就准备好了通过 WebSphere 代理服务器在两个核心组中访问您的应用程序。要使用 HTTP 协议访问部署到各核心组的 WebSphere Application Servers 中的应用程序,您需要在浏览器 URL 中指定代理服务器的 PROXY_HTTP_ADDRESS 端口(本例中为 80)。要通过 HTTPS 协议访问您的应用程序,请在浏览器的 URL 中使用代理服务器的 PROXY_HTTPS_ADDRESS 端口(本例中为 443)。用于访问应用程序的主机名是 WebSphere 代理服务器的 Internet 主机名称。

因此,举例来说,用于访问 Information.ear 的 Web 模块的 URL 是:https://proxyhost/info/Information.jsp;用于访问 CoeTest.ear 的 Web 模块的 URL 是 https://proxyhost/jdbctest/index.jsp。按照相同的规则,即可使用 URL https://proxyhost/dft/snoop,通过 WebSphere 代理服务器访问使用 /dft 上下文根部署到 cell d0003 的 Web 模块 DefaultApplication.ear。

如果 WebSphere 代理服务器路由的请求导致 503 HTTP 返回代码或类似的代码,那么最常见的原因如下:

  • 核心组桥接工作不正常。检查并验证每个核心组访问点中至少有一个核心组桥接服务器正在运行。
  • 企业应用程序本身未启动。
  • 不同 cell 间的 SSL 设置存在问题。

现在就是执行测试,确保以下应用程序可通过代理服务器访问的最好时机。根据 图 2 中的示例拓扑结构,这些应用程序现在应该能够正常工作:

  • Information.ear
  • CoETest.ear
  • DefaultApplication.ear

请牢记,各核心组内必须至少有个核心组桥接接口服务器正常运行。


路由至非托管资源

相对于托管资源和动态路由,必须为非托管资源执行手动路由配置,因为非托管资源不在 WebSphere Application Server 的管理和控制之下。因此,不会通过核心组机制交换任何状态信息。

图 25 展示了 WebSphere 代理服务器如何用于将请求路由至非托管服务器。图中展示了提供请求的非托管服务器需要配置为 WebSphere Application Server 中的一般服务器集群成员。

图 25. 将请求路由至非托管服务器。
图 25. 将请求路由至非托管服务器。

一般服务器集群的配置

使用 WebSphere 代理服务器将请求路由至非托管资源的第一步就是在 WebSphere Application Server 中配置一个一般服务器集群。要在您的 WebSphere Application Server cell 中配置一个一般服务器集群:

  1. 在托管您的 WebSphere 代理服务器的 cell 的管理控制台中,导航至 Servers > Clusters > Generic server clusters > New
  2. 输入您希望创建的一般服务器集群的名称和要使用的协议(HTTP 或 HTTPS)(图 26)。
    图 26. 一般服务器集群创建
    图 26. 一般服务器集群创建
  3. 创建了一般服务器集群之后,输入连接信息以及各集群成员的权重。图 27 展示了一般服务器集群的一个成员的配置。您需要以主机名/IP 地址以及端口和权重的方式指定 TCP/IP 连接信息。权重不得为零,因为权重为零就表示不会向此集群成路由任何请求。除此之外,这张图片还展示了来自一个 IBM HTTP 服务器配置的匹配配置关键说明。
    图 27. 一般服务器集群成员创建
    图 27. 一般服务器集群成员创建
  4. 在一般服务器集群定义中注册一般服务器集群的每一个成员。这将使 WebSphere 代理服务器能够实现在集群成员之间实现负载平衡和故障转移:
    • 负载平衡是一种加权轮叫算法,类似于 Web 服务器插件使用的算法。
    • 一般服务器集群的成员仅通过 HTTP 或 HTTPS 连接,因此故障检测受 TCP/IP 功能所限。在 WebSphere 代理服务器确定一个一般服务器集群成员发生故障后,它将定期(每隔 5 秒)尝试建立连接,检查服务器是否已经再次可用。
  5. 如果您正在使用 HTTPS 协议,那么您必须确保非托管服务器的服务证书的签名证书处于 WebSphere 代理服务器所用的 trust store 内。默认情况下,在 WebSphere Application Server V7.0 及更新版本中为 CellDefaultTrustStore。

完成上述步骤之后,一般服务器集群的基本 WebSphere 配置便完成了。有关配置一般服务器集群的更多细节,请参阅 WebSphere Application Server 信息中心

一般服务器集群的路由配置

由于一般服务器集群代表着非托管资源,WebSphere Application Server 不会注意到通过一般服务器集群提供的任何应用程序。因此,必须进行手动配置,使代理能够 “得知” 将哪些请求转发给一般服务器集群。

对于托管资源,路由决策基于为代理路由启用的 Web 模块的上下文根,如上文所述。要为非托管资源实现相同的目标,您需要配置一个 URI 组,它基本上提供了上下文根和 “路由规则”。WebSphere Application Server 中的这两个配置项使代理能够为非托管资源制定路由决策。

下面给出了创建 URI 组和路由规则的最低限度的步骤:

每个一般集群成员中都必须具备 URI 组定义中使用的 URI 模式。此模式是转发给目标服务器的请求的一部分。

  1. 在托管您的 WebSphere 代理服务器的 cell 的管理控制台中,导航至 Servers > Server types > WebSphere proxy servers ><proxy_name> < HTTP Proxy Server settings > Proxy settings > URI Groups > New。图 28 展示了大体由符号名称和一个或多个 URI 模式构成的 URI 组的配置。WebSphere 代理服务器处理的每个请求都将与这些 URI 模式对比,以确定请求是否属于该 URI 组。
    图 28. URI 组定义屏幕
    图 28. URI 组定义屏幕
  2. 配置了 URI 组之后,必须显式配置路由,以便使 WebSphere 代理服务器能够得知将请求路由到何处。这同样是通过管理控制台完成的,方法是导航至 Servers > Server types > WebSphere proxy servers ><proxy_name> > HTTP Proxy Server settings > Routing rules > New

    图 29 展示了代理服务器的路由规则的基本配置。该规则的定义方式基本上就是指定一个符号名称,并选择应用此规则的 WebSphere 虚拟主机和 URI 组。在路由活动下,选择 Generic Server Cluster 单选按钮,随后从下拉列表框中选择一般服务器集群。确保已选中 Enable this rule 复选框。

    图 29. 路由规则配置屏幕
    图 29. 路由规则配置屏幕
  3. 重新启动 WebSphere 代理服务器。
  4. 发送一条与 URI 组定义的 URI 模式匹配的请求,测试对非托管资源的访问。

有关 WebSphere 代理服务器的路由规则配置的更多细节,请参见 WebSphere Application Server 信息中心


结束语

本文讨论了可供 WebSphere 代理服务器使用的各种资源类别,以及 WebSphere 代理服务器提供的路由功能。我们提供了一个示例拓扑结构的具体说明,强调了几种配置方案的依赖关系和可能存在的问题。希望本文能帮助您快速成功实现文中给出的任何方案。


致谢

作者特此感谢 Tim Blank、Marie Gann、Kevin Kelle、John T. Pape、Ying Wang 和 Bill Wigger 在本文创作过程中的宝贵贡献。

参考资料

学习

获得产品和技术

讨论

条评论

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, Web development
ArticleID=810778
ArticleTitle=安全环境中的 WebSphere 代理服务器路由功能
publish-date=04192012