2009-07-10 作者：Bobby Woolf 來源：IBM
本文內容包括：
引言調用服務其他集成功能開發企業服務總線結束語參考資料 本文不僅僅是為架構師準備的：使用企業服務總線 (Enterprise Service Bus)，作為支持面向服務的體系結構 (SOA) 的基礎架構，也將使開發人員能夠更加輕松地工作。
重要的應用程序很少是單獨存在的；如果不能與其他的應用程序一起使用，應用程序將難以發揮很大的作用。面向服務的體系結構往往將應用程序集成在一起，這樣它們就可以協同工作并提高工作效率，每個應用程序都分成必須相互集成的各個部分。SOA 模型——服務使用者調用服務提供者——可能看起來相當簡單，但是它提出了兩個重要的問題：
使用者如何找到它需要調用的服務的提供者 使用者如何快速而可靠地調用服務，而網絡實際上很慢且不可靠？
對于這兩個問題，有一個相當簡單的答案，即采用稱為企業服務總線 (ESB) 的方法。ESB 處理使用者和提供者之間的所有復雜問題，從而使得服務調用對于兩者都比較簡單。ESB 不僅使應用程序（或其各個部分）可以更加容易地調用服務，而且還幫助它們轉換數據和廣播事件通知。ESB 的設計體現了許多已為大家接受的設計模式和標準規范。
本文旨在幫助開發人員理解 ESB 的作用以及應用程序集成的必要部分（包括 SOA）。重點不在于定義或產品，而在于 ESB 實現的功能，這樣您就不必自己實現這些功能。它展示了 ESB 可以為您做什么。
為了幫助您理解應用程序集成和 SOA，我將從介紹 Web 服務如何工作開始。Web 服務只不過是您可以用來實現服務調用的一種方法。它們甚至可能不是最好的方法，但卻是目前可用的最標準的方法，它們能夠幫助我形成正在嘗試完成的任務的設計。
首先，我必須解釋相關術語。Web 服務非常類似過程性編程中的功能：它具有名稱、參數和結果。名稱就是統一資源標識符 (URI)，通過 URI，Web 服務提供者 使 Web 服務可以作為端點使用。Web 服務使用者將端點 URI 作為查找和調用 Web 服務的地址。使用者調用端點時會將請求傳送到 Web 服務，請求中包含特定的操作和參數。在執行服務之后，端點將響應 傳送回使用者，響應指示成功（或錯誤），并且包含服務的結果。通過這種方式，使用者可以調用提供者的端點，傳入請求，并得到響應。
目前，定義實現 Web 服務的方式的是 WS-I Basic Profile 1.1，該概要包括 SOAP 1.1 over HTTP 1.1，后者由 Web 服務描述語言 (WSDL) 1.1 進行定義。（請參閱
參考資料以獲得指向規范本身的鏈接。）有了 SOAP over HTTP，使用者可以通過 HTTP 請求中的一個綁定 HTTP 消息傳輸的 SOAP 請求調用服務。使用者同步阻塞 HTTP 套接字，等待包含 SOAP 響應的 HTTP 響應。端點的 API 是由使用者和提供者之間的約定描述的。
既然您了解了相關術語，就讓我們來看一看使用者用于調用服務的通信選擇：同步或異步。
使用者可以同步或異步實現服務調用。從使用者的觀點來看，這兩種方式的不同之處在于：
同步——使用者通過單個線程調用服務；該線程發送請求，在服務運行時阻塞，并且等待響應。 異步——使用者通過兩個線程調用服務；一個線程發送請求，而另一個單獨的線程接收響應。
術語同步 和異步 經常與順序 和并發 混淆了。后面的這兩個術語與執行單獨的任務必須遵循的順序有關，而同步和異步 與線程執行單個任務（如調用單個服務）的方式有關。理解同步和異步調用之間的不同的一種很好的方法是考慮崩潰恢復的后果：
同步——如果使用者在服務運行的過程中阻塞時崩潰了，當它重新啟動時，將無法重新連接到正在進行的調用，所以響應丟失了。使用者必須重復調用過程，并且期望這次不會崩潰。 異步——如果使用者在發送了請求之后等待響應時崩潰了，當它重新啟動時，可以繼續等待響應，所以響應不會丟失。
崩潰恢復不是同步和異步調用之間的唯一不同，但是如果您嘗試確定某個調用采用哪一種方式，請考慮每一種調用如何處理崩潰恢復，這通常可以給您一個很好的答案。
既然您了解了使用者對服務調用通信方式的選擇，就可以看一看使用者對用于連接到提供者的連接方式的選擇。使用者可以從下列通信方式中選擇一種：
同步直接調用 同步代理調用 異步代理調用
我將分別解釋每一種方式。
調用 Web 服務的 SOAP over HTTP 方式就是直接的：非常類似于執行函數調用，使用者知道端點的地址，并直接調用它。為了使調用成功，Web 服務必須在使用者調用端點時可用，而且必須在使用者超時之前進行響應。如果將 Web 服務部署到新的位置（例如不同的 Internet 域），則必須讓使用者知道端點的新 URI。要部署具有相同服務類型的多個提供者，必須將每個提供者的端點部署到不同的 URI。要在不同的服務提供者之間進行選擇，使用者必須知道其中的每個 URI。
例如，考慮一個簡單的用于獲取股票報價的 Web 服務：使用者傳入股票代號，然后取回股票的當前價格。此服務可能由多個不同的代理公司提供，每個公司都有一個不同的 Internet URL。獲取 Web 服務的 URL 是一個先有雞還是先有蛋的問題。如果使用者知道端點的位置，它就可以詢問服務其地址是什么，但是使用者需要知道地址才能詢問地址。
為了解決這個問題，統一描述、發現和集成（Universal Description Discovery and Integration，UDDI）描述了一種 Web 服務，它是一個類似于電話簿的目錄，用于查找其他的 Web 服務。其思想就是，將 UDDI 部署到一個使用者已經知道的知名地址，然后使用者就可以使用 UDDI 來查找其他的 Web 服務。
對于股票報價服務，使用者知道 UDDI 服務的地址，而 UDDI 服務又知道股票報價服務的地址，如圖 1 所示。
圖 2 展示了使用者如何使用 UDDI 服務來查找股票報價提供者的端點，并且調用其中的一個端點。該流程的工作方式如下：
使用者向 UDDI 詢問服務提供者列表。 使用者從 UDDI 返回的列表中選擇一個提供者的端點。 使用者調用該端點。
請注意，選擇提供者的算法完全由使用者決定；在本例中，使用者只選擇列表中的第一個。實際實現可能要復雜一些。
還需要注意的是，因為服務端點可能改變，所以當使用者每次需要調用服務時，都應該重新查詢 UDDI，查看提供者的詳細信息是否有改變。必須為每次服務調用查詢 UDDI 大大增加了調用服務的開銷，特別是在提供者的詳細信息通常不改變的情況下。
直接調用方法的不足之處在于，使用者必須知道提供者的端點的 URI 才能調用服務。它使用 UDDI 作為查找 URI 的目錄。如果提供者更改其端點的 URI，它必須向 UDDI 服務器注冊，這樣 UDDI 就有新的 URI，然后使用者必須重新查詢 UDDI 以獲得新的 URI。事實上，這意味著每次使用者需要調用服務時，它都必須查詢 UDDI 以找到端點 URI，并從中進行選擇。這導致使用者把許多時間浪費在重復查找 UDDI 和選擇提供者這樣的工作上。這種方法還使得使用者必須以某種方式從看起來不可區分的列表中選擇提供者。
簡化這個問題的一個方法是引入 Broker，作為調用 Web 服務的中介。使用者不再直接調用服務提供者，而是調用 Broker 中的服務代理，而服務代理又調用服務提供者。使用者需要知道代理端點的 URI，以便使用 UDDI 查找地址，但是在本例中，UDDI 只返回單個 URI，因而使用者不必選擇。使用者甚至沒有意識到端點在代理中；而只是知道它可以使用此 URI 來調用 Web 服務。Broker 協調使用者與服務提供者，如圖 3 所示。
代理的 URI 應該是穩定的：在使用者使用 UDDI 獲取代理的 URI 之后，它第一次調用服務，在以后的調用中，使用者可以重用該 URI（至少在代理停止工作之前）。同時，代理跟蹤提供者及其 URI（可能在調用之間發生改變）、它們是否可用（上一次調用失敗了嗎？）、它們的負載（上一次調用花了多長時間），等等。然后，代理負責為每次調用選擇最好的提供者，從而免去了使用者這方面的責任。使用者每次都在同一地址調用同一代理，代理負責協調各個提供者。
圖 4 展示了使用者如何使用 Broker 調用服務，工作方式如下：
使用者向 UDDI 請求服務提供者列表。UDDI 返回的 URI 實際上是服務代理的 URI。UDDI 只返回一個 URI 而不是多個 URI，因為 Broker 只將一個代理用于特定的服務。 使用者使用代理的 URI 調用服務。 服務代理從其可用提供者列表中選擇服務提供者。 服務代理調用所選提供者的端點。
請注意，選擇提供者的工作已經從使用者轉走了，現在封裝在 Broker 的代理中。這簡化了使用者的工作。最后，代理使用的選擇流程可能不同于使用者使用的選擇流程。但是，因為 UDDI 服務器和代理都封裝在 Broker 中，所以可以更容易地提高某些方面的效率，例如在代理中緩存信息、在緩存的信息變得過時讓 UDDI 服務器通知代理。
還需要注意的是，因為代理的地址是穩定的，所以使用者不必重復地查詢 UDDI，每個服務調用只需查詢一次。更確切地說，使用者只需查詢 UDDI 一次，然后就可以安全地緩存代理的地址，并且重復地使用它來調用服務。這大大地降低了調用服務的開銷。
同步方法的不足之處在于，在執行服務時使用者必須阻塞——在服務運行時線程必須阻塞。如果服務花很長時間執行，使用者可能會在接收到響應之前放棄。當使用者發出請求時，如果沒有一個服務提供者正在運行或者它們都過載，則使用者將無法等待。如上所述，如果使用者在阻塞時崩潰，則即使它重新啟動，響應也會丟失，因而必須重新進行調用。
解決這個問題的常見方法是使用者異步調用服務。通過這種方法，使用者可以使用一個線程來發送請求，而使用另一個線程來接收響應。這樣，使用者就不必阻塞以等待響應，而且可以同時執行其他工作。因此，使用者對花多長時間執行服務不太敏感。
支持使用者異步調用 Web 服務的 Broker 是通過消息傳遞系統實現的，消息傳遞系統使用消息隊列來發送請求和接收響應。與同步消息代理一樣，這一對消息隊列擔當使用者用來調用服務的單個地址，而不管多少提供者可能正在偵聽，如圖 5 所示。
這種方法使用請求-響應模式來調用 Web 服務。與 WS-I BP 1.1 中指定的 HTTP 不同，消息隊列現在執行傳輸。SOAP 請求和響應與 WS-I BP 相同，但是它們現在包含在消息系統的消息中。
圖 6 展示了使用者如何使用 Broker 異步調用服務，具體步驟如下：
使用者以請求隊列中的消息的形式發送 SOAP 請求。現在，使用者的工作已經完成了，可以使用該線程來執行其他工作。 每個提供者都可以看到請求隊列中的使用者，這使得它們要競爭使用者。消息傳遞系統確定哪一個提供者能夠接收消息，并確保只有一個提供者接收消息。具體工作方式取決于消息傳遞系統的實現。 獲勝的提供者從請求隊列接收消息。 該提供者執行服務。 該提供者以應答隊列中的消息的形式發送 SOAP 響應。現在，提供者的工作已經完成了，可以使用其線程執行其他的工作（例如等待另一個請求）。 使用者的偵聽器線程接收包含 SOAP 響應的消息。
請注意，選擇提供者的工作現在封裝在消息傳遞系統中，從而簡化了使用者的工作。還需要注意的是，如果使用者在發出請求之后崩潰，則即使響應在這個期間返回，消息傳遞系統也會將響應保存在應答隊列中，直到使用者再次啟動為止。
同時需要注意，使用者不使用 UDDI 查找請求隊列和應答隊列。目前，沒有用于返回隊列地址對的標準服務，所以使用者必須確切地知道這些地址。使用者要么與這些地址硬編碼在一起，要么從外部配置文件中讀取它們。將來，需要擴展 UDDI 或者指定類似的服務供使用者查詢，以便發現用于調用特定服務的隊列對。
現在，您了解了服務調用的連接方式選擇。接下來，讓我們看一看也可能有用的其他集成功能，然后向您展示如何開發一個 ESB 來提供這些功能。
使用 ESB，您還可以超出服務調用，并且使用其他技術集成應用程序和 SOA 的各個部分。服務調用幾乎始終是雙向操作，這意味著請求是從使用者發送到提供者的，而響應是按照相反的方向返回的。其他的集成技術是以單向操作的方式進行工作的，其中，發送方將信息發送到接收方而不等待響應；接收方只是使用信息而不進行響應。
有時，應用程序只需將數據傳輸到另一個應用程序，而不必調用接收方的過程，而且肯定不等待結果。這是一個典型的集成問題：一個應用程序有數據，而另一個應用程序需要數據。發送方不需要告訴接收方如何處理數據；它只需使數據可用即可。
可以通過服務調用來傳輸數據，這等同于調用 setter 方法，但是使數據傳輸到 RPC 范型中。數據傳輸實際上更類似于文件傳輸：數據從發送方導出并導入接收方，不需要發送方公開地指導接收方如何處理數據。這更類似于文檔樣式的 SOAP 消息而不是 RPC 樣式的消息。
用 ESB 進行數據傳輸可以查找接收方，并可靠地傳輸數據。發送方不必知道如何查找接收方，它只需知道如何查找 ESB 并信任 ESB 將找到接收方即可。ESB 還負責可靠地傳輸數據。發送方只需將數據傳送到 ESB 并知道數據將傳遞即可。
有關數據傳輸技術的詳細信息，請參見文檔消息 (Document Message) 模式。（有關這方面的詳細信息，請參閱
參考資料中列出的 Enterprise Integration Patterns 一書。）
有時，需要將在一個應用程序中發生的更改通知給其他應用程序。例如，如果使用者在一個應用程序中編輯其地址，則應該通知其他的應用程序以及它們自己的數據庫，以便它們可以更新其記錄。
此外，一個應用程序可以對另一個應用程序調用服務來通知其更改情況，但是這種方法有三個問題。頭兩個問題與數據傳輸相同。首先，服務調用對接收方應該如何處理信息知道得太具體了，其次，它往往是雙向的，這使得發送方必須等待（甚至同步等待）它并非真正需要的應答。
通過調用服務進行事件通知的第三個也是最重要的是一個問題是，服務調用在本質上是一對一的，即使用者對提供者，而事件通知在本質上是一對多的，需要廣播到所有相關提供者。使用服務調用，發送方必須跟蹤所有相關的接收者，并且分別對其中的每一個進行服務調用。這種通知廣播最好留給發送方和接收方之間的 Broker。
用 ESB 進行消息傳遞可以跟蹤相關接收方并確保通知傳遞到每一個接收方。通過這種方法，發送方只需發出一次通知，即可確保通知傳遞到所有的相關接收方，而不管這些接收方是誰。因為此操作是單向的，所以在傳遞通知時發送方可以同時做其他工作，而且可以并發傳遞通知。
有關數據傳輸技術的詳細信息，請參見事件消息 (Event Message) 模式。（同時參閱
參考資料中列出的 Enterprise Integration Patterns 一書。）
現在，您知道了直接調用提供者中的 Web 服務和使用 Broker 進行調用之間的區別。您也了解了 Broker 如何支持使用者同步或異步地調用服務。
這樣的 Broker 常常稱為 ESB。那么，與已為大家接受的設計和模式相比，ESB 有什么特點呢？
Web 服務與以前的集成方法的不同之處在于，使用者可以動態綁定到服務的提供者。之所以能夠這樣做，是因為具有以下兩種主要功能：
自描述——Web 服務可以以機器可讀的方式描述自身。同一服務的兩個或更多提供者即使具有完全不同的實現也可以立即識別出來，因為它們的聲明性接口符合相同的描述。 可發現——Web 服務提供者可以組織到機器可執行的目錄中。使用者可以搜索這樣的目錄來查找所需服務的提供者。
這些自描述和自發現功能完全不同于以前的集成方法。使用其他方法，將在編譯時執行接口，與此同時使用者將被綁定到提供者。消息格式不是以聲明的方式表示的，而是暗含在雙方的約定中，并且在接收方成功地解析發送方創建的結構之前是不可執行的。
自描述服務通過聲明可以執行的接口簡化了集成。動態發現服務使得不需要在特定的地址將使用者綁定到特定的提供者，但是運行時發現本身也帶來了一些問題。使用者應該一次性地發現服務的提供者還是重復地發現服務的提供者？
在編譯時一次性將使用者綁定到提供者與在運行時潛在地針對每次調用發現新的提供者之間作出取舍非常困難。ESB 提供了第三種選擇，承諾在支持使用者動態地一次性綁定到服務代理的同時，仍然能夠通過代理使用多個提供者和選擇新的提供者。
因此，ESB 不僅使服務可用以便使用者能夠調用它們，而且為使用者提供了以編程方式查找服務的功能。
同步 ESB 的基礎稱為服務網關，它充當服務使用者和提供者之間的中介，以促進同步代理調用。通過服務網關，可以訪問所有知名的服務和其中每個服務的代理。采用這種方式，網關可以為希望調用該網關代理的任何提供者的任何服務的使用者提供一站式服務。
如果網關協調的服務是 Web 服務，則這些服務是自描述的。每個服務都使用 WSDL 聲明其接口，WSDL 由以下四個部分組成：
端口類型——Web 服務執行的操作集。端口類型可能是帶有端口/操作（如 getQuote）的 stockBrokerServices。 消息——請求和響應的格式，例如 getQuoteRequest（包含股票代號）和 getQuoteResponse（包含價格）。 類型——Web 服務使用的數據類型，例如代號和價格（或者只是 xs:string 和 xs:decimal）。 綁定——調用操作的地址，例如 http://stockbroker.example.com/getQuote。
這樣的網關的服務——或者更具體地說，其服務代理——也是可發現的。如前所述，網關以 UDDI 服務的形式提供這種功能。要發現調用服務的地址，使用者可以查詢網關的 UDDI 服務，以找到所需 WSDL 操作的提供者，并取回該操作的網關代理的綁定。
異步企業服務總線的基礎是已為大家接受的模式，稱為消息總線 (Message Bus)，如
參考資料中列出的 Enterprise Integration Patterns 一書所述。消息總線是消息通道（也稱為隊列或主題）的集合，通常配置為請求-應答通道對。每一對都表示使用者可以通過總線調用的服務。調用方將請求消息放在服務的請求隊列中，然后（異步）偵聽應答隊列中的結果。（調用方知道哪個結果對于特定的請求是正確的，因為它有正確的關聯標識符。）
調用服務的使用者實際上并不知道誰在提供服務。服務提供者也連接到消息總線，并偵聽請求消息。如果有多個服務提供者，則它們實際上將相互競爭，以便成為發出特定請求的使用者的服務提供者。實現消息總線的消息傳遞系統充當消息調度程序，并且將請求消息分發給服務提供者，在理想情況下，將根據負載均衡、網絡延遲等以某種方式優化這種分發。在服務提供者接收請求之后，它執行服務，然后將結果放在達成一致意見的應答通道中的消息內。這樣，提供者和使用者從不直接知道彼此的地址；它們只知道消息總線和如何查找適當的通道的地址，而且通過共享相同的通道，它們可以進行通信。
消息總線是 ESB 的基礎，并且不是什么新鮮事物。應用程序集成人員已經使用消息隊列產品（如 WebSphere® MQ 和 TIBCO Enterprise Message Service）做這項工作十多年了。其實，人們常說，如果您正在使用企業消息傳遞產品，您就有了 ESB。IBM 客戶已經使用 WebSphere Business Integration Message Broker 和 WebSphere MQ 這樣做了很長時間。
那么，ESB 就是消息總線嗎？不，消息總線肯定是異步 ESB 的基礎，但完整的 ESB 還包括其他的功能。ESB 具有消息總線一直缺少的功能：即上述描述和發現功能。
如此說來，如果消息總線不是完整的 ESB，那么 ESB 還可以做什么呢？
傳統消息總線方法的不足之處在于，它不是自描述的。從使用者的角度來看，有許多服務，也有許多用于調用服務的通道。但是哪一個通道是用來調用使用者所需的服務的合適通道呢？使用者不能將請求隨便放到一個請求通道中，它必須知道用于調用其所需的特定服務的合適通道。否則，它可能事與愿違，明明需要的是一本書，但最后買到的卻是一張飛機票。另外，即使使用者（以某種方式）知道了要使用哪一個通道（以及要偵聽哪一個通道以獲得應答），它也需要知道請求中的數據應該采用什么格式（以及應答需要采用什么數據格式）。
如上所述，WSDL 為同步 Web 服務解決了這個問題，并且暫時也是描述異步服務的標準選擇。與請求通道相關的 WSDL 描述通道提供什么服務，以及使用者必須提供的請求消息的格式。WSDL 還可能指定調用方應該偵聽以獲得應答的應答通道，以及應答消息必須具有的格式。采用這種方式，調用方應用程序可以以編程方式查看用于調用服務的通道對，并且知道它們以所要求的請求和應答消息格式提供了所需的服務。
自描述服務通道帶來了另一個問題，即通過 UDDI 發現哪些同步 Web 服務。如上所述，使用者向 UDDI 服務器請求 Web 服務提供者的地址，而該服務器以提供者的 URL 應答。然后，使用者使用該 URL 來調用該服務。
ESB 需要類似的目錄服務，一個帶有類似于 UDDI 的 API 的服務，使用者可以調用這樣的服務，來請求實現所需的 WSDL 操作的服務的地址。ESB 以合適的請求-應答通道對應答。所以 ESB 使用者（如 UDDI 使用者）只需知道以下內容即可：
描述需要調用的服務的 WSDL ESB 的目錄服務的地址（它可能派生于 ESB 的根地址）
對于查找服務的請求與應答通道和開始調用服務，這足夠了。此外，這個目錄服務還是 ESB 提供的另一個服務，查找其他服務的主服務。
服務使用者需要在通信方式之間做出選擇：同步還是異步？為了解決這個難題，許多 ESB 將同時支持同步和異步服務，并且事實上可以為同一服務提供兩種調用模型。在這種情況下，當使用者請求服務地址時，它可以獲得兩個匹配地址：一個用于同步，一個用于異步。然后，使用者可以選擇它最喜歡的調用模型。不管采用哪一種方式，執行的服務都是相同的，不過具體的服務提供者實例可能有所不同。
所以 ESB 比傳統的消息總線要好，因為它還使得服務可以自描述，并且提供了用于查找其他服務的目錄服務。這正是構建 ESB 的產品供應商努力提供的。
可以看出，服務可以通過以下三種方式之一進行調用：
直接同步 通過 Broker 同步 通過 Broker 異步
企業服務總線是支持同步和異步調用的 Broker。它還支持應用程序之間的數據傳輸和事件通知。它幫助使用者查找提供者和處理提供者之間的通信的細節。
同步 ESB 是充當各種服務的中間協調者的服務網關。異步 ESB 是其服務還支持自描述和可發現 Web 服務功能的消息總線。目前存在用于實現同步 ESB 和消息總線（簡化的異步 ESB）的標準和模式。異步 ESB 還需要其他標準，以便充分發揮他們的潛力。
您可以參閱本文在 developerWorks 全球站點上的
英文原文 。
SOA and Web services 新手入門 為希望了解 Web 服務但是不知從何處入手的讀者提供了很好的概述。
WS-I Basic Profile Version 1.1 (WS-I) 定義了 WS-I Basic Profile 1.1。
Simple Object Access Protocol (SOAP) 1.1 討論了 SOAP 1.1。 查找更多關于
超文本傳輸協議 (HTTP) 1.1 的內容。
Web 服務描述語言 (WSDL) 1.1 是一種描述網絡服務的 XML 格式，它將網絡服務描述成一組端點，用于對包含面向文檔或面向過程的信息的消息進行操作。
統一描述、發現和集成 (UDDI) 2.04 規范描述了所有 UDDI 注冊中心實例的編程接口和期望行為。 “
使用企業服務總線簡化集成體系結構”（developerWorks，2005 年 8 月）揭開了企業服務總線的神秘面紗，并且向您展示了可以如何應用這種體系結構樣式來實現基于面向服務的體系結構的應用程序。 Gregor Hohpe and Bobby Woolf 撰寫的 Enterprise Integration Patterns （Addison Wesley ISBN 0321200683；2003 年 10 月）提供了一系列模式和實際解決方案來演示消息傳遞的功能，可以幫助您為企業設計有效的消息傳遞解決方案。 “
Building a JMS Web service using SOAP over JMS and WebSphere Studio”（developerWorks，2004 年 2 月）描述了 JMS Web 服務的基本知識，并且向您展示了如何使用 WebSphere Studio V5.1 開發一個雙向請求和響應 JMS Web 服務。 在 Apache Web 站點上找到更多關于
WSDL JMS Extension 的內容。
Calling an Asynchronous Web Service Sample 演示了 Web 服務控件的使用。
