SOAP 節點基礎

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 服務，這將在使用者場景部分進行介紹）。

圖 1. 使用同步實現（通過 WebSphere MQ）的提供者


圖 2. 使用非同步實現（通過 WebSphere MQ）的提供者

在這些示例中，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 場景。

圖 3. 使用者：同步 (Facade)


圖 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 服務訊息。

圖 5. SOAPInput——SOAPReply 配置

在圖 6 中，訊息集中的 WSDL 定義用於配置 SOAPRequest 節點。Web 服務請求和響應訊息均在執行時根據 WSDL 進行驗證。

圖 6. SOAPRequest 配置

在圖 7 中，訊息集中的 WSDL 定義用於配置 SOAPAsyncRequest 節點。相同的定義將自動應用於 SOAPAsyncResponse 節點。Web 服務請求和響應均在執行時根據 WSDL 進行驗證。您通過為兩個節點配置相同的唯一識別符號，從而將它們關聯起來：在節點屬性的 Basic 選項卡上指定的 URL 片段。

圖 7. SOAPAsyncRequest——SOAPAsyncResponse 配置
 

提供者場景中的相關性

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 邏輯樹及其使用。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-429349/，如需轉載，請註明出處，否則將追究法律責任。