SOAP 节点发送和接收基于 SOAP 的 Web 服务消息，并允许消息流与 Web 服务端点进行交互。该消息可能是纯 SOAP、带附件的 SOAP（SOAP with Attachments，SwA）或消息传输优化机制（Message Transmission Optimization Mechanism，MTOM）。节点是使用 Web 服务描述语言（Web Services Description Language，WSDL）来配置的，并支持 WS-Security 和 WS-Addressing。这个由四部分组成的系列描述 SOAP 节点、新的 SOAP 域的逻辑树，以及配置和运行时行为的详细信息。在这第一篇文章中，您将了解节点的基本使用。要按照本系列中的说明进行操作，您应该大致熟悉基于 SOAP 的 Web 服务和 WSDL。

引言

SOAP 节点用于实现常见的 Web 服务场景，并且一般是使用 Web 服务的新消息流的最佳选择。使用 WSDL 1.1 来配置的 SOAP 节点支持基于 SOAP 的 Web 服务，并发送和接收消息，这些消息可以是纯 SOAP（1.1 或 1.2 版）、SwA 或 MTOM（有关本文中使用的术语的定义，请参阅术语列表）。SOAP 节点组合了消息传输和 SOAP 语义，以支持一致的 SOAP 域逻辑树格式和下一代 Web 服务标准 WS-Security 和 WS-Addressing。

特定于传输的节点（例如 HTTPInput 和 HTTPReply）在某些情况下仍然有用。例如，如果您有使用特定于传输的节点的现有流，并且预期不需要任何 WS-Addressing 或 WS-Security 支持，或者您没有 WSDL 定义，并且不打算创建这样的定义——也许是因为您在使用诸如 XML 远程过程调用（XML Remote Procedure Call，XML-RPC）或代表性状态传输（Representational State Transfer，REST）等非基于 SOAP 的 Web 服务技术——那么您就可以使用特定于传输的节点。但是，如果您在创建新的消息流并使用 WSDL，则 SOAP 节点可以提供更完整的解决方案。

SOAP 节点

SOAP 节点使用新的 SOAP 解析器和 SOAP 逻辑树格式。新节点包括：

• SOAPInput 和 SOAPReply：结合用于提供（即实现）Web 服务。
• SOAPRequest：用于调用 Web 服务。
• SOAPAsyncRequest 和 SOAPAsyncResponse：结合用于异步地（这只是意味着消息流在等待响应时不会被阻塞在 SOAPAsyncRequest 上）调用 Web 服务。

存在两种基本的 Web 服务场景，下面几个部分将对此进行介绍：提供者和使用者。

提供者场景

消息流提供或实现 Web 服务。当然，您完全可以在消息流中实现简单的 Web 服务。然而，在更典型的提供者场景中，消息流将部分工作委托给一个或多个外部代理。例如，消息流可以完成以下任务之一：

• 查询或更新数据库。
• 将某些业务处理委托给某个现有的应用程序。

在某些情况下，可以认为这样的消息流为现有的应用程序提供了新的 Web 服务接口。然而请注意，消息流还可以增强、限制或以其他方式调整现有应用程序的功能，或者组合多个应用程序和其他数据存储库的功能。

在图 1 和 2 中，您可以看到两种风格的 Web 服务提供者，其中调用了一个现有的应用程序。这些示例表明现有的应用程序是通过 IBM® WebSphere® MQ 调用的，但是您可以使用其他传输（事实上，现有的应用程序可以是另一个 Web 服务，这将在使用者场景部分进行介绍）。

在这些示例中，Compute 节点针对所需的外部应用程序格式来回转换 SOAP 消息。您还可以使用 Mapping 节点或 Java™ Compute 节点。

在图 1 中，单个事务负责处理请求-应答转换。这支持简单的回滚和恢复，但是如果所调用的应用程序无法快速响应，则会影响性能。

在图 2 中，SOAPInput-MQOutput 流（请求流）在将消息发送到应用程序以后完成。然后在所调用的应用程序做出响应之前，可以使用该流来处理进一步的请求。在此场景中，必须将相关性上下文保存在请求流中并在应答流中恢复（请参阅本文稍后的提供者场景中的相关性部分）。

提供者场景的一些常见功能如下：

• 缺省情况下，SOAP 节点侦听端口 7800 (HTTP) 或 7843 (HTTPS)。
• SOAPInput 节点可以接受由已配置的 WSDL 绑定（请参阅使用 WSDL 来配置 SOAP 节点部分）所定义的任何操作。
• 可以在对外部应用程序接口建模的现有消息集的基础上生成 WSDL，或者可以使用现有的 WSDL 来进行导入。
• 如果在 SOAPInput 节点上发生 SOAP 处理错误，它可以直接向发送者或者向某个不同的端点（如果 WS-Addressing 指示这样做的话）返回 SOAP 错误。
• 您可以连接 Catch 和/或 Failure 端点，并构建自己的 SOAP 错误消息，该消息同样将根据 WS-Addressing 的指示由 SOAPReply 节点返回（如果指定这样使用的话）。
• SOAPInput 节点可以向客户端返回 SOAP 错误以指示发生了超时。如果 SOAPReply 节点没有在 SOAPInput 节点属性的 HTTP Transport 选项卡上的属性 Maximum client wait time (sec)* 所指定的时间内发送响应消息，就会发生超时。

本系列的第 4 部分将更详细地描述可伸缩性、错误处理和 WS-Addressing。

使用者场景

消息流将调用某个 Web 服务。常见的使用者场景是这样的消息流，其集成某些可作为 Web 服务来提供的现有业务逻辑。此场景的一种特定变体在于消息流也提供 Web 服务。这有时称为 Facade，因为它实际上是使用稍微不同的接口或在执行某些附加处理的情况下重新公开同一个 Web 服务。

图 3 和 4 演示了 Facade 场景。

在这些示例中，Compute 节点对 SOAP 消息做出任何必需的调整。您还可以使用 Mapping 节点或 Java Compute 节点。在图 3 中，消息流发出了一个同步请求。该流被阻塞，直到接收到响应或超时，从而可能具有性能影响。

在图 4 中，请求是异步的。该流的前半部分在发出请求之后完成，从而使其可以分派进一步的请求而不会导致不适当的延迟。（通过配置流的附加实例，在同步情况下也可以实现及时分派，如图 3 所示，但是这会使用更多的代理资源，因此其可伸缩性不尽如人意。）

响应由 SOAPAsyncResponse 节点接收，通常是在一个不同的消息流中接收。此节点必须与 SOAPAsyncRequest 节点在同一个执行组中，但是使用单独的线程。

提供者场景的一些常见功能如下：

• 外部服务的 WSDL 通常存在并且可用于导入。
• SOAPRequest（或 SOAPAsyncRequest）配置必须指定特定的 WSDL 操作和绑定（请参阅使用 WSDL 来配置 SOAP 节点部分）。
• SOAPRequest（或 SOAPAsyncResponse）节点可以接收有效的 Web 服务响应或 SOAP 错误。通常，您将连接错误端端点，以将错误作为特殊情况进行处理，如图 3 所示。

SOAPAsyncRequest 和 SOAPAsyncResponse 节点始终使用 WS-Addressing。本系列的第 4 部分将更详细地描述 WS-Addressing，但是有一个要点值得在这里提一下：如果您创建消息流，如图 4 所示，那么现有的 Web 服务必须支持 WS-Addressing。特别是，如果您使用 SOAPInput - SOAPReply 流来实现现有的 Web 服务，那么您必须在 SOAPInput 节点的 WS Extensions 选项卡上选择 Use WS-Addressing。

使用 WSDL 来配置 SOAP 节点

您将使用 WSDL 来配置 SOAP 节点以定义：

• 要发送和接收的消息。
• 端点详细信息。

然后您可以进一步配置节点来覆盖端点详细信息（如果有必要的话），以配置对 WS-Addressing、WS-Security 和 SOAP mustUnderstand 标头的任何使用，以及修改其它与解析（例如验证）或传输（例如，您可能需要配置 HTTPS 传输的使用，以便将 SSL 与 WS-Security 和 UsernameToken 一起结合使用）相关的属性。

图 5 和 6 显示了如何使用此 WSDL 来配置在前一个部分中介绍的 SOAP 节点。本系列的第 2 部分将描述 SOAP 逻辑树。第 3 部分将描述 WSDL 来自何处，并提供有关各个配置设置的更多详细信息。

眼下，只需假设您有一个 WSDL 定义，并在某个代理消息集中作为 Deployable WSDL 可用。注意：只有 SOAPInput、SOAPRequest 和 SOAPAsyncRequest 才是使用 WSDL 来显式配置的。SOAPReply 和 SOAPAsyncResponse 继承在它们的合作伙伴节点上提供的定义。

在图 5 中，您可以看到消息集中的 WSDL 定义用于配置 SOAPInput 节点。相同的定义将自动应用于 SOAPReply 节点。Web 服务请求和响应（输入和输出消息）在运行时根据 WSDL 进行验证。SOAP 逻辑树表示流中的 Web 服务消息。

在图 6 中，消息集中的 WSDL 定义用于配置 SOAPRequest 节点。Web 服务请求和响应消息均在运行时根据 WSDL 进行验证。

在图 7 中，消息集中的 WSDL 定义用于配置 SOAPAsyncRequest 节点。相同的定义将自动应用于 SOAPAsyncResponse 节点。Web 服务请求和响应均在运行时根据 WSDL 进行验证。您通过为两个节点配置相同的唯一标识符，从而将它们关联起来：在节点属性的 Basic 选项卡上指定的 URL 片段。

提供者场景中的相关性

SOAPInput 节点和 SOAPReply 节点旨在结合在一起使用。SOAPReply 节点必须始终与其对应的 SOAPInput 节点在同一个执行组中。

这两个节点通常在同一个消息流中，在这样的情况下，SOAPReply 节点自动检测自己在应答哪一个请求。否则，将使用 LocalEnvironment 树中的 ReplyIdentifier 来允许您将入站 SOAP 消息与从 SOAPReply 节点发送的对应应答关联起来。

作为特例，即使两个节点在单独的消息流中，如果这些流使用 SOAPAsyncRequest 和 SOAPAsyncResponse 节点，您也可能不需要做任何特定的事情，如图 4 所示。在这种情况下，只要在 AsyncRequest 节点发送消息时，ReplyIdentifier 在 LocalEnvironment 中，则 ReplyIdentifier 将自动在 WS-Addressing 标头中从请求流流向响应流。

然而，在一般情况下，当两个节点在单独的消息流中时（例如，图 2），您需要自己将必要的相关性信息转发给应答流。SOAPInput 节点在 LocalEnvironment 中的以下位置设置 ReplyIdentifier：LocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier。您需要将此值保存在某个地方，然后在 SOAPReply 节点之前的某个位置在应答流中设置此值。

在流之间保存 ReplyIdentifier 的一种方法是将该值存储在队列上，然后在应答流中使用 MQGet 节点来检索该值。其他的可能方法包括将其保存在数据库或 WebSphere MQ RFH2 header 中。

结束语

本文是此系列中的第 1 部分，其中描述了 SOAP 节点是什么，如何使用 WSDL 来配置它们，以及如何在基本的 Web 服务场景中使用它们。请继续关注第 2 部分，其中将介绍 SOAP 逻辑树及其使用。