WebSphere Message Broker V6 中的 HTTP 传输节点

引言

超文本传输协议 (HTTP) 是广泛使用的标准协议，建立在 TCP/IP 堆栈基础上，用于基于请求/应答的通信。该协议当然主要由 Web 浏览器用于从服务器请求页面。随着企业服务总线（Enterprise Service Bus，ESB）技术和面向服务的体系结构（Service-Oriented Architecture，SOA）的发展，HTTP 正在越来越广泛地用作调用服务（包括 Web 服务）的传输机制。HTTP 只是一种用于 HTTP 客户机和 HTTP 服务器间通信的协议。它不允许您与企业中不支持 HTTP 的服务交互。

IBM® WebSphere® Message Broker V6.0.0.1（以下称为 Message Broker）中的 HTTP 节点帮助您解决了这个问题。本文描述 HTTP 节点，说明如何配置和使用它们，并讨论在实现使用 HTTP 节点的消息流时要考虑的性能和可伸缩性问题，并包括了若干使用场景的性能特征。有关使用 WSDL 来实现 Web 服务的更多信息，请参见 Web services support in WebSphere Message Broker V6。

有关 HTTP 的更多信息

HTTP 协议设计得简单、快速、可扩展并且与以前版本兼容。虽然使用 HTTP 进行的数据检索很高效，但是在存在多个数据请求的情况下，处理客户机和服务器间连接的方式并不高效。每个请求/响应对都需要一个新连接，从而给通信施加了沉重的开销。为克服此问题，HTTP 1.0 或更高版本支持客户机和服务器间的持久性连接，多个请求/响应对通过同一连接来发送。此功能通过 connection: keep-alive 标头提供，并在 HTTP 1.1 中成为缺省设置，要求客户机和服务器使用 connection: close 标头来显式关闭连接。持久性连接在某些情况下非常有用，例如在尝试重复调用某个服务的时候，因为此时不再需要为每个请求创建新的套接字，从而显著提高性能。

通过对请求内容使用诸如简单对象访问协议（Simple Object Access Protocol，SOAP）等标准，HTTP 正在成为通过 TCP/IP 调用服务的流行方法。由于 HTTP 和 SOAP 是广泛使用的标准，因此这种方法是调用 Web 服务的理想途径，虽然也可以使用诸如消息（例如使用 WebSphere MQ）或 JMS 上的 SOAP 等其他技术和标准来调用服务。HTTP 的一个关键优点在于，它通常不会被防火墙阻止，从而提高了使用 HTTP 的应用程序的可用性。

在企业中集成 HTTP

HTTP 的一个主要优点在于，它是良好定义且与供应商无关的标准。然而，HTTP 本身并不适合于所有企业 Web 服务调用，因为大多数大型企业都有许多不支持 HTTP 的应用程序和服务，并且通常需要先转换来自这些应用程序的数据，其他企业应用程序才能理解那些数据。另外，这其中许多现有应用程序是良好定义、可靠和高性能的，因此通常需要将它们与企业的其余部分集成，而不是重新设计或重新构建。

HTTP 传输节点

Message Broker 支持许多不同的协议，包括：

• HTTP
• WebSphereMQ
• WebSphereMQ Telemetry Transport
• Multicast
• WebSphereMQ Real-time
• JMS Transport

HTTP 传输节点使 Message Broker 能够接收来自任何 HTTP 客户机的数据和将数据发回该客户机。此外，这些节点还提供了作为 HTTP 客户机发出 HTTP 请求的能力。

HTTP 节点不过是充当了将数据传入 Message Broker 的途径。一旦数据到达，通常与 Message Broker 关联的所有功能都将变得可用。例如：

使用以下方式的数据计算和转换：

• ESQL
• Java 计算机节点
• 外部来源的数据充实
• 路由

Message Broker 中存在三种 HTTP 传输节点：

HTTPInput 节点

与诸如 MQInput 等其他输入节点一样，HTTPInput 节点使用 HTTP 而不是 WebSphere MQ 或 JMS 作为通信协议来从客户机获取数据。HTTPInput 节点对传入数据支持几种消息域格式：

• MRM
• XML
• XMLNS
• XMLNSC
• JMS
• JMSStream
• IDOC
• MIME
• BLOB

一旦接收到数据，HTTPInput 就会将数据解析为内部 Message Broker 消息树，从而支持在消息流的其余部分使用所有正常的 Message Broker 功能。HTTPInput 节点必须与某个 HTTPReply 节点在同一工作流中，或者它必须将消息传递给包含某个 HTTPReply 节点的另一个流（例如通过 MQOutput 节点），因为 HTTP 是一种请求/应答协议，因此连接客户机始终期待某种应答。HTTPInput 节点同时支持 HTTP 和 SSL 上的 HTTP (HTTPS)。

HTTPReply 节点

HTTPReply 节点将响应从 Message Broker 发回到最初调用该流的 HTTP 客户机。响应与原始请求进行匹配。HTTPReply 节点必须在包含某个 HTTPInput 节点的流中，或者原始消息必须是从包含某个 HTTPInput 节点的流中接收的。整个消息树用作响应的正文。

HTTPRequest 节点

HTTPRequest 节点可在消息流中用于支持 Message Broker 调用现有基于 HTTP 的服务。请求可由整个消息流消息树或其指定部分组成。可以使用来自 HTTP 服务的响应来扩充原始输入消息（发送到 HTTP 服务的请求），以便在将消息传播到流中的后续节点之前创建新消息。HTTPRequest 节点对传入数据支持几种不同的消息域格式：

• MRM
• XML
• XMLNS
• XMLNSC
• JMS
• JMSStream
• IDOC
• MIME
• BLOB

HTTPRequest 同时支持 HTTP 和 SSL 上的 HTTP (HTTPS)。

节点配置

请参考有关配置 HTTP 传输节点的更多信息。

HTTP 连接性

前一部分描述了 HTTP 节点。这一部分将解释 Message Broker 消息流与可能调用该消息流的客户机或可从该消息流中调用的基于 HTTP 的服务之间的 HTTP 通信是如何处理的。

作为服务器的代理

客户机必须能够使用 HTTP 协议。Message Broker 中的 HTTP 请求的接收是通过名为 biphttplistener 的侦听器进程来处理的。下面的图 1 显示了此交互是如何进行的。客户机发出的 HTTP 请求由 Message Broker 侦听器进程接收。然后消息传递到 HTTPInput 节点，消息中的处理就开始了。当消息流完成时，HTTPReply 节点发出响应，该响应通过 Message Broker HTTP 侦听器进程发送到 HTTP 客户机。

图 1. HTTP 请求和响应

每个 Message Broker 实例只有一个多线程（可配置）的 biphttplistener 进程。biphttplistener 进程是弹性的——如果它失败，则会自动重新启动。单个侦听器为所有包含部署到单个代理的 HTTPInput 节点的流服务。然而，通过设置 HTTPInput 节点上的属性，您可以基于传入 URL 将传入 HTTP 请求筛选到不同的流。可以使用整个 URL 或某个模式。例如，如果您希望的 URL 是 http://<hostname>[:<port>]/[<path>]，则指定 /<path> 或 /<path fragment>/*，其中 * 是通配符。

作为客户机的代理

在与基于 HTTP 的服务进行交互时，处理序列是不同的，并涉及到一个不同的处理节点。图 2 显示了消息流如何调用基于 HTTP 的服务。在此情况下，消息流充当使用 HTTPRequest 节点的客户机：

图 2. 基于 HTTP 的服务

技术好处和业务价值

到目前为止，我们主要集中于 HTTP 传输节点是什么以及如何在消息流中配置和使用它们。这一部分将通过一些常见使用场景来表明如何使用节点来为现有企业消息基础设施增添价值。这一部分展示的场景还将在“性能特征和可伸缩性”部分中进行展示。

对现有应用程序进行 Facade 处理

在实现 SOA 时，您希望在整个企业中提供的许多服务可能并不支持 HTTP。许多应用程序可能执行关键业务处理，并且必须跨企业的其他领域使用。通过使用 HTTPInput 和 HTTPReply 节点来使此类应用程序或功能部分支持 HTTP，您可以使它们更便于使用。本文讨论两类可使用 WebSphere Message Broker 来进行 Facade 处理的应用程序——支持 WebSphere MQ 和不支持 WebSphere MQ 的应用程序，例如 DB2 存储过程或 CORBA 应用程序。

对于支持 WebSphere MQ 的应用程序，典型的场景涉及请求/应答应用程序：

图 3. 请求/应答应用程序

在此场景中，您首先使用 HTTPInput 节点来构造 Flow1，后者接收来自 HTTP 客户机的请求。该请求针对一个支持 WebSphere MQ 的服务。该请求被转换为适当的格式（包含 WebSphere MQ 标头），并放在业务应用程序从中进行读取的队列上。另外还存储了传入消息的请求标识符，以支持协调由 Flow2 从应用程序中向请求 HTTP 客户机发回的应答。

业务应用程序执行自己的操作，并将结果消息放在自己的输出队列上，应答消息流 Flow2 通过标准 MQInput 节点从那里获得该消息。随后检索该消息的请求标识符，并将消息转换为包含 HTTP 标头的适当格式，然后通过 HTTPReply 节点将其发回给最初的请求 HTTP 客户机。

此过程简单易懂，所创建的消息流也非常简单。一旦 HTTP 请求进入 Message Broker，就可以使用所有正常功能了。正如上面所示的那样，您可以执行消息格式间的转换——从 XML 到自定义有线格式 (Wire Format)——从而与一系列外部应用程序通信。

您希望作为服务来公开的应用程序或业务流程部分并非全都支持 WebSphere MQ。例子包括 DB2 存储过程或 CORBA 应用程序。对于不支持 WebSphere MQ 的应用程序，可设想一个“直通”(straight-through) 场景：

图 4. 不支持 WebSphere MQ 的应用程序

在此场景中，消息流接收到一个来自 HTTP 客户机的请求，并从一个计算节点中调用了所请求的应用程序（一个 DB2 存储过程）。然后从传入 HTTP 请求消息中提取出应用程序的参数，并将其转换为适当的格式。您对该应用程序发出一个同步调用并接收响应，该响应内置在原始 HTTP 请求消息中，并作为一个 HTTP 响应被发回到 HTTP 客户机。同样，这是一个非常简单的消息流，但是非常强大。

HTTP 客户机只知道一个同步调用。消息流的内容可能是同步或异步的，这对请求客户机是透明的，从而在组合服务的方式方面提供了相当的灵活性。

除了消息流的组合外，您还需要考虑 HTTP 客户机/服务器之间的连接和消息流的持续时间。可以将 HTTP 连接配置为短期的或长期的。

当许多（数百或数千）客户机希望发出各个请求然后断开连接时，短期的非持久性连接是最合适的。由于所需的内存和其他资源，您不应该在这种情况下维持大量的连接。

当少量请求应用程序需要大容量的消息吞吐量时，长期的持久性连接是最合适的。长期连接避免了会话创建和删除的开销。当集中器 (concentrator) 应用程序将来自大量用户的请求集中到某个消息流时，这种连接非常普遍。

短期和长期连接类型在 Message Broker V6.0.0.1 中都受到支持。本文后面在“性能和优化”部分将介绍配置详细信息。

从消息中枢内发出 HTTP 请求

另一种常见使用场景是调用已经支持 HTTP 的服务。这可以使用 HTTPRequest 节点来实现：

图 5. 支持 HTTP 的服务

在此场景中，您构造一个消息流来通过 MQInput 节点从 WebSphere MQ 队列中读取消息。您在通过 HTTPRequest 节点向 HTTP 服务发出同步调用之前存储 MQ 标头，并使用 MQ 消息的正文作为请求的正文（此选项是可配置的）。然后您接收来自 HTTP 服务的响应，并使用该响应连同原先存储的 MQ 标头（同样，此选项是可配置的）作为写入 WebSphere MQ 队列的响应消息。如上所述，该消息流非常容易构造，并且所有正常 Message Broker 功能都可以使用。

对现有 HTTP 服务进行 Facade 处理

您已看到，可以将现有的业务应用程序经 Facade 处理成为 HTTP 服务，还可以从消息中枢内调用现有的 HTTP 服务。另外一个场景是充实现有的 HTTP 服务，在此场景中，您不仅希望调用现有的 HTTP，而且还还希望通过 Message Broker 功能向其增添价值。这可以使用 HTTPInput 节点、HTTPRequest 节点和 HTTPReply 节点来实现：

图 6. 调用现有服务

在此场景中，您构造一个消息流来接收来自 HTTP 客户机的 HTTP 上的请求，并将该请求修改为向 Message Broker 的 URL 而不是向现有 HTTP 服务的 URL 发出请求。在将原始请求转发到现有 HTTP 服务之前，将该 HTTP 请求存档到数据库中以用于审核目的，然后将来自 HTTP 服务的响应转发回 HTTP 客户机。此场景演示了传入请求的审核，但不一定仅限于此类用途。可以使用任何 Message Broker 功能来充实现有的 HTTP 服务。此场景没有包括在下面的“性能特征和可伸缩性”部分中，因为它实际上是前三种场景的简单扩展。

负载平衡和故障转移

若要构建能够处理大量消息并提供高可用性的系统，您需要确定所需的可用性级别，以及在服务器或消息代理失败时隔离数据是否可接受。记住，被阻止的不仅只是原始请求，而且还包括失败服务器上正在运行的中间处理。两种主要的可用性方法是负载平衡和诸如 Message Broker 等处理组件的自动故障转移。

负载平衡是在可用服务器或消息代理池中分布传入的工作，以便能够完成更大数量的工作。通过绕过失败或低性能的消息代理来路由请求，负载平衡可以提高系统可用性，前提是负载平衡器要通过运行状况监视探测或“检测信号处理”(heartbeat processing) 来监视其中每个服务器的运行状况。下面是两种提高可用性的方法：

使用服务器池的负载平衡

即使一个或多个服务器失败，也可以使用池中的其他服务器来继续提供服务。但是在某个服务器失败时，可能会有某些数据被隔离在失败的服务器上。这种状况将保持到该服务器重新启动。如果问题与硬件相关，则可能要花一些时间才能恢复。

使用诸如 HACMP 等能够在另一台计算机上自动重新启动失败服务器的软件

这具有数据不会被隔离的优点。当在另一个系统上重新启动该服务器时，将存在短时间的延迟，但是一旦它重新启动，原始数据仍然可以访问。使用 WebSphere Message Broker V6，您可以使用 HACMP 来在另一个系统上重新启动失败的代理。过去在传入工作来自 WebSphere MQ 客户机的场合中，这种方法被广泛使用。当传入工作来自 HTTP 客户机时，它同样非常有效。应该牢记传入请求是不可恢复的，除非以某种方式对其进行日志记录，这完全与传输协议的性质一致。

这一部分的其余内容集中于不同负载平衡解决方案的使用，并讨论它们的优点。诸如 HACMP 等提供高可用性的软件就不再进一步讨论了。下图显示了一个可提供负载平衡和可用性（但是不提供恢复）的环境：

图 7. 负载平衡和可用性

此图表明，通过使用诸如 WebSphere Edge Server Load Balancer 等网络分配器，您可以将多个 HTTP 客户机连接到同一个 URL 和连接到任意数量的后端 Message Broker。服务器实例的数量是可变的，从而使得通过水平扩展来提高消息吞吐量非常容易。

使用网络分配器允许您在所有连接的代理之间分布工作负载。实现这个目的的机制是可配置的——例如通过轮流检查服务器响应时间。通过验证每个连接的服务器上的 HTTP 侦听器端口是否在正常工作，使用网络分配器还添加了故障转移功能。它尝试建立从分配器到每个服务器的 TCP 连接，如果失败，则将该服务器标记为“停机”，并停止向该代理的 HTTP 侦听器转发请求。

有了 WebSphere Edge Server，使用预打包的顾问可以提供更高级的运行状况检查。还可以编写自定义顾问来实现您自己的运行状况检查。

图 8 显示了一个替代的体系结构方法：

图 8. 使用代理将 HTTP 连接处理从 Broker 移开

此设置与图 7 中的设置类似，但是使用代理将 HTTP 连接处理从 Broker 移开了。代理是运行于诸如 WebSphere Application Server 等应用程序服务器中的 Servlet 引擎，其作用就像图 1 中的 Message Broker 内部进程。该 Servlet 引擎作为一个 Category 3 SupportPac 来提供。

如上图所示，一个代理 Servlet 只能为单个 Message Broker 服务。但是您可以拥有许多连接到单个 Message Broker 的代理 Servlet。

网络分配器 (Network Dispatcher) 纯粹用于分发传入的 HTTP 请求。它不是代理 Servlet 的先决条件。使用代理 Servlet 体系结构的主要原因在于，它能够支持比使用缺省侦听器更多的并发连接。通过使用代理 Servlet 的多个副本，您可以支持更多并发用户。有关设置并发连接数量的详细信息，请参见下面的性能注意事项和优化。Message Broker 能够支持大约 1200 个到单个 biphttplistener 进程的并发连接。当然，如果需要支持的并发会话数量少于 1200，则不需要在这样的任务中使用代理 Servlet。

使用 HTTP 处理事务

HTTP 消息始终是非持久性的，并且没有关联的顺序

HTTP 消息是非事务性的。然而，如果消息流与数据库或诸如 WebSphere MQ 队列等外部资源交互，则可以通过执行相关配置来事务性地执行这些交互。HTTPInput 节点提交或回滚，具体取决于消息流是如何发送，以及是如何配置它进行错误处理的（例如，失败端是如何连接的）。如果消息流由该节点回滚，则会生成错误消息并将其返回到客户机。错误的格式由 Fault Format 属性来定义。

如果消息流中的下游发生异常，并且未捕获而是返回到 HTTPInput 节点，则该节点将构造一个针对客户机的错误应答。这个错误是从该异常派生而来的，错误的格式由 Fault Format 属性来定义。

性能注意事项和优化

可以在企业中使用 Message Broker 的标准安装来处理 HTTP 和发出 HTTP 请求。在某些情况下，您可能需要优化 Message Broker 以实现更高级别的吞吐量。这一部分将讨论标准配置和如何修改它。

持久性连接

Message Broker 同时支持 HTTP 1.0 和 1.1，因此能够处理持久性连接。在处理需要大容量消息吞吐量的少量请求应用程序（也许是通过使用将请求集中到消息流中的集中器应用程序）时，您应该使用持久性连接来防止不必要地为每个连接创建和删除套接字。如果 HTTP 客户机使用 HTTP 1.1 并且未指定 Connection: close 请求标头，则会缺省使用持久性连接。然而，存在一个名为 maxKeepAliveRequests 的可配置属性，它指定可以通过单个连接发送多少个请求。

Message Broker 将该属性缺省设置为 100。因此，当某个 HTTP 客户机连接时，它能够在 Message Broker 发出 Connection: close 并关闭套接字之前发送 100 个请求。该客户机发送的下一个请求将创建一个新的套接字，并且同样最多可以发送 100 个请求。在许多环境中，此设置也许足够了。但是当需要最大限度的吞吐量时，您可能需要将此值设置得更高或无限大，以便达到所需的吞吐量。

下面是一个命令：mqsichangeproperties MyBroker -b httplistener -o HTTPConnector -n maxKeepAliveRequests -v 0.

MyBroker

Message Broker 的名称

-b

您要更改的组件

-o

您希望更改的组件中的对象

-n

要更改的特定参数的名称

-v

值

上面的命令中指定了值 0，将允许通过单个套接字发送的请求数量设置为无限大。此设置用于下面的性能特征和可伸缩性部分中所示的测量。

正如前面几个部分所指出的，您可以从 Message Broker 调用 HTTP 服务，此时 Message Broker 就像任何其他 HTTP 客户机一样工作，从而能够创建持久性连接。HTTPRequest 节点具有一个使用持活 (keep alive) 连接的配置选项，虽然只有在您选择 HTTP 1.1 时才支持该选项。HTTPRequest 节点上所连接到的服务器上的 maxKeepAliveRequests 参数的值确定创建新连接的频率。

并发连接

除了通过使用持久性连接来处理少量长期连接外，您可能还有大量的短期连接，其中涉及到希望发出各个请求然后断开连接的数百或数千个客户机。HTTP 客户机可以发出标头中指定了 Connection: close 的 HTTP 请求，从而确保为每个新请求创建新连接。

可以设置 maxThreads 参数来确定 Message Broker 接受的最大并发连接数。但是计算机资源（如可寻址的内存量）决定了能够向 Message Broker 发出的绝对最大并发 HTTP 客户机连接数量，并且这些资源可能在还未到达 maxThreads 限制时就已经耗尽。

缺省值为 250，意味着尝试连接的第 251 个客户机将获得“访问被拒绝”响应。（实际上，少数超过 maxThreads 值的连接可能会得到允许，因为可以将连接排入队列，直至达到 acceptCount 参数所设定的限制，而该参数同样是可配置的）。在许多环境中，缺省设置可能就足够了，但是在某些情况下，您可能需要通过运行如下命令来将该值设置得更高：mqsichangeproperties MyBroker -b httplistener -o HTTPConnector -n maxThreads -v 2000。（有关参数的含义，请参见上面的列表。）

上面的命令将允许的并发连接数量设置为 2000。此设置用于性能特征和可伸缩性部分中所示的测量。

增加运行 biphttplistener 进程的 JVM 的堆大小以允许 JVM 为传入连接分配更多线程。侦听器 JVM 的缺省堆大小是 192 MB，但是在处理大量并发连接时，应将其增加到 512 MB。若要更改该值，请修改 Message Broker 注册表。

Windows®

在注册表项 HKEY_LOCAL_MACHINE\SOFTWARE\IBM\WebSphereMQIntegrator\2\<BrokerName>\CurrentVersion 下面创建一个名为 MaxJVMHeapSize 的新 String 值。将这个新的 String 值设置为所需的最大 JVM 堆大小（以字节为单位）。例如：536870912 表示 512 MB。

UNIX®

在目录 <Broker File Path>/<Broker Name>/CurrentVersion/ 中，创建一个名为 MaxJVMHeapSize 的新文件。将此文件的内容设置为所需的最大 JVM 堆大小（以字节为单位）。例如：536870912 表示 512 MB。

若要使更改生效，您需要停止并重新启动 Message Broker。

上面描述的方法增加 biphttplistener 进程所在的特定 JVM 的堆大小。该 JVM 与用于运行执行组进程的 JVM 独立，因此无法使用 mqsichangeproperties 命令来修改。

在处理大量打开的套接字（每个并发连接对应一个套接字）时，操作系统可能会限制单个进程一次所能打开的文件数量。在 UNIX 上，对一个进程所能打开的文件数量的限制还适用于套接字，因此您需要提高最大的打开文件句柄数量设置以反映预期的并发连接数量。若要检查当前设置，请运行命令 ulimit -a。有关提高该设置的帮助，请咨询系统管理员。通常，您可以使用命令 ulimit -n 4096 来更改它。

此设置仅适用于 UNIX。当使用上述参数 maxrtheads=2000, JVM=512, ulimit=4096 运行时（在适当的情况下），由于达到了 WebSphere MQ 中的硬限制，将会在 Solaris、Windows 和 AIX 上使用单个 Message Broker 实例创建 1200 个并发连接。

性能特征和可伸缩性

这一部分包含在运行许多测试用例时获得的吞吐量结果。测试包括本文中讨论的测试再加上许多大容量的简单测试用例。为了减少测试数量，只在整个执行组中对 1K 的消息大小进行了扩展。

Windows

图 9. Windows 上的吞吐量结果

Solaris

图 10. Solaris 上的吞吐量结果

可以看到，在 Windows 和 Solaris 上，HTTPInput 节点/HTTPReply 节点对和 HTTPRequest 节点都性能良好。所有这些测试用例都能很好地扩展到不再剩下 CPU 资源的状态，到达该状态的不同时间点取决于测试用例和计算机中的 CPU 数量。

计算机详细信息

Windows

硬件：

• 1 台 IBM xSeries 360，带 4 个 2.00 GHz Intel Xeon 处理器
• 3 个 69 GB 的 SCSI 硬盘驱动器，格式化为 NTFS
• 4 GB RAM
• 1 个 GB 以太网卡

软件：

• Microsoft Windows 2000，带 Service Pack 4
• WebSphere MQ V6
• WebSphere Message Broker V6，带 Fix Pack 1
• DB2 for Windows V8.1，带 Fix Pack 4

Solaris

硬件：

• 1 台 Sun Fire V1280 Server，带 8 个 1.2 GHz 处理器
• 2 个 72 GB 的 SCSI 硬盘驱动器
• 1 个 StorEdge Fast 3510 阵列，带 2 个 LUN 和快写缓存——2 个 275 GB 和 16 GB 的 RAM
• 1 个 GB 以太网卡

软件：

• Solaris 9
• WebSphere MQ V6
• WebSphere Message Broker V6，带 Fix Pack 1
• DB2 for Solaris V8.1，带 Fix Pack 4

结束语

本文介绍了 WebSphere Message Broker V6.0.0.1 中的 HTTP 传输节点的作用和功能。其中说明了如何能够使用节点来处理许多场景，包括：

• 对现有的应用程序进行 Facade 处理，无论它们是支持 WebSphere MQ 还是不支持 WebSphere MQ
• 对现有的 HTTP 服务进行 Facade 处理和充实
• 从现有消息中枢内请求 HTTP 服务

WebSphere Message Broker HTTP 传输节点允许您方便快捷地为上述场景开发解决方案。不需要对现有服务进行复杂的记录——相反，可以通过 Message Broker 流的拖放式开发来使那些服务支持 HTTP，从而极大地降低将 HTTP 服务整合到现有企业应用程序中的成本。本文还讨论了设计消息流应用程序时的性能和可伸缩性注意事项。