【IT168 技术文章】
您是否在寻找一种方法来使用不同的协议（需要交换保密数据）管理应用程序间的互操作性？那么可以考虑将 IBM? WebSphere? Enterprise Service Bus 和 IBM WebSphere DataPower SOA Appliances 的功能结合在一起使用。通过本文您可以了解如何仅通过很少的代码工作就获得安全、灵活且可扩展的解决方案。
引言
随着各种标准和技术的大量出现，我们经常会遇到通过 Internet 集成各种系统和应用程序的问题，以及需要促进使用不同语言开发且使用不同协议和技术的组件间的互操作性。在这种情况下，同步应用程序经常作为 Web 服务实现，而且必须与基于消息的异步系统进行通信。这种情况需要连接基础设施来直接管理服务交互，让应用程序不必考虑使用不同协议、实现且位于网络不同位置的服务之间的通信。
本系列共四个部分，将讨论卫生保健预约系统的实际场景，本文是其中的第一篇。系统采用了面向服务的体系结构（Service-Oriented Architecture，SOA），配备了 WebSphere Enterprise Service Bus。本系列文章将提供详细的步骤，帮助了解如何对其进行扩展，以实现基于消息传递中间件的新用例，并同时使用 WebSphere DataPower SOA Appliances 保证数据保密性。
为了帮助您了解这些概念，我们决定对每个功能部分用一篇单独的文章进行讨论：
第 1 部分假定您对 Web 服务和面向消息的框架有基本的了解，将提供此场景的完整概述，从而说明已采用的体系结构全貌。
第 2 部分讨论系统安全相关的部分、数据加密、证书管理和 WebSphere DataPower SOA Appliances。您将通过此部分深入了解后台的情况，并了解如何配置 WebSphere DataPower SOA Appliances 及其扩展功能来提升公钥基础设施（Pblic Key Infrastructure，PKI）。
第 3 部分将介绍企业服务总线（Enterprise Service Bus，ESB）中介模块，并说明让 ESB 识别保密信息的配置步骤。
第 4 部分讨论从企业服务总线接收 Java? Message Service (JMS) 消息的应用程序的客户端的问题，说明如何解密敏感数据来重新构造原始消息。
卫生保健预约系统
医疗活动、卫生保健系统和医院通常使用某种类型的卫生保健预约系统来改进客户预约工作，提高运作效率和降低成本。预约系统是患者的唯一访问点，可帮助他们找到距离自己最近的医生、更快得到特殊护理、安排延迟时间不长的预约或重新安排现有预约。患者通常通过电话或网络与预约系统交互。
集成的卫生保健系统还可以包含家庭保健机构、放射治疗机构、物理治疗机构、长期护理服务和其他健康相关的实体。注册为卫生保健服务提供者后，他们都可以享受中央预约系统的好处。他们可以选择完全委托预约管理，或仍然将内部预约系统和新系统同时使用。
如图 1 中所示，卫生保健预约系统包括中央预约系统和由各个卫生保健中心管理的本地系统。中央预约系统提供用于添加新卫生保健中心的 Web 服务界面 (registerNewPartner)。反过来，每个卫生保健中心必须实现一组 Web 服务界面来与中央卫生保健系统进行交互（makeReservation、queryReservation、cancelReservation）。
正如您看到的，我们已经确定了与系统交互的两个角色：
合作伙伴执行一组基本管理任务，如注册新合作伙伴和发布日程表。
患者代表对查询系统进行预约或重新预订感兴趣的预约系统的一般用户。
图 1 给出了基本流程：
图 1. 卫生保健预约系统
让我们逐个分析一下图 1 中所看到的内容：
1.希望利用中央预约系统提供的优势的卫生保健中心可以将自己注册为合作伙伴，并提供患者可以预约的服务和可用时间段列表（红色）：合作伙伴使用 Web UI (1.1) 与系统交互，调用 registerNewPartner (1.2)，而数据存储在卫生保健预约系统数据中 (1.3)。
2.患者提供所有所需的信息来完成初始表格 (2.1) 并将收到满足搜索条件的选择列表（蓝色）。
3.患者使用 Web UI 提交预约请求 (3.1)。中央预约系统 (3.2) 需要在运行时在线事务期间查找合作伙伴服务，以便系统查找满足患者需求的可用提供者。此任务由 WebSphere Enterprise Service Bus 完成，后者允许更高级别的抽象，可隐藏服务位置的细节并提供中介、动态查找、路由和日志记录支持 (3.3)。系统将请求转发到卫生保健提供者待批（即调用 makeReservation Web 服务）(3.4) 并最终向患者确认预约。
本系列将说明如何扩展系统功能来支持新卫生保健中心合作伙伴类型。这些大部分是没有本地预约系统的小机构。他们委托外部系统管理其日程表，每天连接一次（或很少连接）来获取新预约。与此类提供者预约时段的患者不会立即获得确认。中央预约系统会稍后在提供者连接时发送电子邮件，获取日程表，然后确认预约。为了支持此类诊所，中央预约系统在处理请求时会更新日程表并将其发布给合作伙伴。
您需要考虑以下事项：
*诊所通常并不随时在线，因此必须保证可靠地交付日程表，甚至使用者临时断开连接也应如此。
*由于这些诊所可能通过慢速链接进行连接，因此必须限制发送的数据量。
*日程表中包含的数据要严格保密，因此必须采用某种方式对其进行保密。保密性在异步场景中有些麻烦，因为不能应用 PKI 技术中使用的客户端和服务提供者之间的一对一交互。对于一对一交互，服务公钥的使用非常明确。但当涉及多个服务提供者时，问题就成了“系统将使用谁的公钥进行加密？”
寻找解决方案
由于此场景很显然属于异步方式，因此非常适合通过消息传递模式实现。事实上，使用面向消息的中间件通常可以利用高级功能来保证消息的可靠交付，即便使用者（诊所）暂时断开连接也可以保证这一点。这些功能在使用基于 Web 服务的单向交互时通常不可用。就这些考虑而言，ESB 非常适合此场景，因为它不仅能够保证基于消息的连接性，还提供了透明传输协议切换功能。这些功能利用了可以在 ESB 内为服务定义的绑定概念。通过这些绑定，用户可以提供协议特定的设置来告知 ESB 如何管理传入和传出消息。导出绑定描述客户机如何与中介模块通信。导入绑定则描述中介模块如何与所定义的服务通信。这些绑定使得不用在应用程序代码中放入任何通信逻辑的情况下连接到诊所成为可能。要实现所描述的场景，我们定义了中介模块，并将其连接到 SOAP/HTTP 导出绑定和 JMS 导入绑定，如图 2 中所示。
图 2. 中介模块
通过这样，中介模块可以接收采用 SOAP/HTTP 协议的消息，并能够根据 JMS 协议对这些消息进行转换。导入绑定允许用户指定必须将这些消息送到的目的地。此目的地可以为主题或队列，具体取决于应用程序的域。使用队列具有在服务请求者和服务提供者之间提供专用通信通道的优势，但同时也有缺点，即要求在 ESB 上为每个已部署的服务提供者配置一个队列。使用主题可以避免域队列相关的配置负担，但同时又要求注册到主题的所有诊所侦听送达的消息。这样做的话，诊所可能还会收到以其他提供者为目的地的消息，而在考虑保密性和带宽使用的情况下，这就成了需要考虑的问题。在本文稍后，我们将给出这些限制的实用解决方案。这里我们从体系结构的角度对此解决方案进行了描述，但您可以在本系列的第三篇文章中找到关于技术实现和配置相关方面的所有细节。
使用消息选择器避免带宽消耗
根据 JMS 规范，可以定义一些作为筛选器的消息，以告知 JMS 客户机应该处理哪些消息（仅处理以其为目的地的消息）。此信息在消息转发到 JMS 主题前可以放在某个非保留 JMS Header 中（例如，JMSType 中）或基于 JMS 的其他属性中。在此场景中，每个服务提供者通过 serviceProviderId 代码明确地标识。中央预约系统有一个包含这些标识代码的列表，每个提供者在其中都有一个标识代码。当预约系统向服务提供者发送更新日程表时，预约系统将准备一条 SOAP 消息（稍后将给出其格式），并将正确的标识代码添加到消息的主体，然后将其转发给 ESB。如果 ESB 负责将此消息转换为 JMS 有效负载并转发到预定义的主题，看起来似乎应该在 ESB 内实现逻辑来使用这些标识代码扩充 JMS 消息 Header，从而使用消息主体中包含的 serviceProviderId 作为消息选择器。幸运的是，ESB 提供了 message element setter 中介原语，可以将其用于检查传入消息格式并向传出消息 Header 添加一些信息。此原语已在 WebSphere Enterprise Service Bus V6.0.2 中引入，并在此解决方案中用于扩充 JMS 消息 Header，如图 3 中所示。
图 3. 消息选择器
中介模块收到请求消息时，会使用 message setter 原语从请求的 SOAP 主体检索 serviceProviderId，以便将其存储（通过复制操作）在传出消息的 JMSHeader 中。然后 ESB 将此消息转发到主题，从而使得诊所可靠地得到此消息。此解决方案不需要在 ESB 层提供代码。不过，显然有必要在客户端开发 JMS 独立应用程序或消息驱动的 Bean 来触发诊所与主题的交互。
保证主题上的数据保密性
正如前面所述的，使用主题可以避免队列相关的配置负担，但同时又有一个缺点，即要求注册到主题的所有诊所侦听送达主题的消息。即使在 ESB 上配置消息选择器可以让服务提供者仅仅获得自己的消息，但此解决方案并不会防止恶意客户机在没有消息选择器的情况下注册主题，从而侦听所有传入消息。为了克服这个限制，同时也为了让这个场景更有意义，我们决定采用 PKI。
图 4. 公钥基础设施
我们假定每个诊所都具有自己的证书，并将其发布到了中央预约系统。您可以在图 5 中看到其具体情况。正如前面所说的，进入预约系统的每个 SOAP 请求都在消息的主体中包含标识消息必须送达的提供者的信息 (serviceProviderId)。从特定服务提供者获取 SOAP 消息时，中央预约系统会解析消息，获取 serviceProviderId 并使用此信息动态地选择服务提供者所发布的证书，然后使用其加密消息。当然，在客户端，只有 serviceProviderId 标志标识的服务提供者能够理解此消息，因为其具有执行解密所需的正确私钥。不过，恶意注册主题的服务提供者将无法理解消息，因为无法使用匹配的私钥对其进行解密。通过这样，可以确保主题上的数据保密性，不过必须在中央预约系统上实现某种逻辑来加密消息。为了避免在加密消息时必须执行 SOAP/XML 封送和取消封送的负担，我们决定使用 SOA 设备，委托 WebSphere DataPower SOA Appliances 单元来负责对 SOA 消息主体的保密部分执行基于 XML 标准的加密操作。
图 5. 证书管理
中央预约系统的管理员负责从诊所获得证书，然后将证书上传到 WebSphere DataPower SOA Appliances。WebSphere DataPower SOA Appliances 充当 Web 服务代理；它将传入 SOAP 请求进行加密，并将经过加密的消息发送到 ESB（有关进一步的信息，请参见本系列的下一篇文章）。
解决方案说明
图 6 中所示为完整的体系结构图。
图 6. 体系结构
仔细研究这个完整的体系结构图，可能会注意到，其从功能的角度可以划分为三个部分。
预约系统为每个服务提供者准备日程表，加密（通过 WebSphere DataPower SOA Appliances）敏感数据，将经过加密的消息转发到 ESB。ESB 获得经过加密的数据，然后执行协议切换和中介。诊所然后注册主题。每个服务提供者都拥有一个私钥，将在消息送达主题时使用其正确地解密自己的消息。客户机可以实现为 JMS 客户机或 EJB 消息驱动的 Bean。
定义主题配置属性并导入 JMS 绑定
此部分将介绍定义导入 JMS 绑定所需的基本步骤。图 7 给出了关于此工作很好的图形表示形式。
图 7. 导入绑定
如前所述，ESB 获取 SOAP/HTTP 请求并将这些消息转发到 JMS 主题，从而透明地管理协议切换。为此，必须告知 ESB 主题的名称和连接属性，而且必须在将导入绑定定义为 JMS 消息传递时提供此信息。显然，提供此信息要求事先通过管理控制台执行一些配置。
接下来让我们了解如何在 ESB 内创建和配置以下组件的一些细节。这里我们的重点是配置主题空间、主题和主题连接工厂。另外还将了解如何导入主题空间。
配置主题空间
断开 Enterprise Service Bus 的 WebSphere 管理控制台。
从相应的可用任务筛选器启用所有事件。图 8 对此进行了说明。
图 8. 管理控制台：启用事件
在左侧的导航窗格中，选择 Service Integration，然后选择 Buses。将显示可用总线的列表，如图 9 中所示。
图 9. 管理控制台：总线配置
双击 SCA.APPLICATION.esbCell.Bus。将会随即打开新窗口。
选择 Destination Resources > Destinations。将显示当前定义的总线目的地列表。
选择 New > Topic Space。将会随即打开新窗口。
输入 TopicImportOut 作为标识符。所有其他字段保持缺省值，并单击 OK（请参见图 10）。
图 10. 管理控制台：主题连接工厂
出现提示时保存配置。
配置主题
接下来让我们讨论配置主题本身的具体细节：
在管理控制台的导航窗格中，选择 Resources > JMS Providers > Default Messaging。
在出现的窗口中，让 scope 设置保持为 Node（缺省值）。向下翻动页面，直至看到 Connection Factories 和 Destination 部分。
单击 Destinations 部分下的 JMS topic 链接（请参见图 11）。
图 11. 管理控制台：主题
在出现的窗口中，单击 New，以创建新主题。然后输入以下值：
名称： TopicImportOut
JNDI 名称： jms/TopicImportOut
主题空间： TopicImportOut
总线名称： SCA.APPLICATION.esbCell.Bus
选择 OK 并保存配置。将在 TopicImportOut 空间下创建新主题，如图 12 中所示。
图 12. 管理控制台：新主题
创建主题配置工厂
现在您已经准备好创建主题配置工厂：
为了让连接工厂工作，还必须为 Provider Endpoints 字段提供有效设置。此字段包含用于连接到引导引擎的端点列表。如果不希望在通过 JMS 客户机连接到主题时处理不需要的异常，则应该根据以下约定提供此设置：esbHostName:bootstrapPort:BootstrapBasicMessaging，其中：
esbHostName 为承载 ESB 的计算机的名称。
bootstrapPort 为引导端点。
如果要检查此端点的正确值，请选择 Server 部分下的 Application servers 链接。然后选择 default server (server1) 并在所显示的服务器详细信息页面中的 communication 部分下单击 ports 链接。将会打开包含 SIB_ENDPOINT_ADDRESS 行的窗口，此行中包含端口相关的信息（请参见图 13）。
图 13. 管理控制台：端口
在管理控制台的导航窗格中，选择 Resources > JMS Providers > Default Messaging。
选择 ConnectionFactories 部分下的 JMSTopicConnectionFactory 链接。在出现的窗口中选择 New，以创建新主题连接工厂（请参见图 14）。
图 14. 管理控制台：新建主题连接工厂
输入以下值，以配置主题配置工厂管理信息（请参见图 15）：
名称： sampleTCF
JNDI 名称： jms/sampleTCF
配置主题配置工厂连接信息。提供了前面步骤的所有信息后，请从下拉列表中选择以下值：
总线名称：SCA.APPLICATION.esbCell.Bus
提供者端点：esbHostName:bootstrapPort:BootstrapBasicMessaging
配置主题配置工厂可持续订阅信息。对于此场景，我们决定使用可持续主题来保证消息的交互，即使诊所暂时断开连接也无妨。要完成此步骤，应该进行以下工作：
提供在使用此连接工厂创建的所有连接上使用的客户端标识符。此设置还可以通过编程方式提供，但最好将其定义为配置步骤。您可以为此设置键入任何字符串。在我们使用的示例中，我们使用 ASLID 作为客户端标识符。
提供有效的可持续订阅主地址，此地址为用于存储交付到可持续订阅的消息的消息传递引擎名称。指定为主题使用的消息传递总线的完整名称。
在本例中，此值为 esbNode.server1-SCA.APPLICATION.esbCell.Bus，其中， esbNode 和 server1 分别为计算机上的 ESB 节点和缺省服务器的名称。
通过以下步骤配置主题配置工厂持久消息可靠性（请参见图 15）：
从 Persistent message reliability 下拉列表中选择 Assured persistent 选项。
选择要为主题连接使用的隔离级别。存在多种可能性，包括 Cluster、Always shared 和 Never shared。您可以根据您的应用程序域选择其中之一。对于此场景，我们决定使用 Always shared 选项来让主题在多个 JMS 订阅者之间共享。
图 15. 管理控制台：配置主题连接工厂
创建导入主题空间
创建了主题空间、主题和主题连接工厂后，可以定义新导入 JMS 消息传递绑定，并按照图 16 中所示提供此信息。
图 16. 管理控制台：JMS 导入绑定
在本系列的第三篇文章中将提供关于如何进行此工作的详细信息。务必强调的是，您必须选择 Business Object XML using JMSTextMessage 作为序列化类型。这样可以确保 SOAP 消息的加密主体采用 XML 形式传递到主题，然后可以使用某个 XML 安全标准解密算法进行解析和重新构建（如本系列的最后一篇文章中所述）。
结束语
本文完整地概述了关于卫生保健预约系统的真实场景，并描述了所采用的体系结构图。另外，我们还提供了关于如何配置 ESB 导入绑定的详细说明。请继续阅读本系列的第 2 部分，其中将重点讨论需要添加到解决方案中的其他组件。
