本文列出了本人與?IBM?內部和外部的架構師、開發人員在談論?Web?服務以及?SOA?時所涉及到的大家共同關注的事項、問題和資源。
摘自?IBM?WebSphere?開發者技術期刊。

引言

在為?IBM?WebSphere®?開發者技術期刊撰寫專欄之前，我花費了大量的時間與架構師、開發人員談論了他們在基于?Web?服務和?SOA?設計以及構建解決方案時所面臨的問題。有一些問題和主題一再成為討論的焦點，因此，我把我個人認為是與?Web?服務相關的?10?大問題列出來與大家分享。?

注意，我沒有把它們稱為最佳實踐，是因為其中有許多問題并不太容易回答。相反，別人對這些問題已經回答過許多次，對于這些內容，我只是想指導您了解一下我比較喜歡的資源，這些資源對該主題進行了較為詳細的說明（當然這些資源大多數是一些?developerWorks?文章）。我認為這些主題涉及的領域非常廣泛，對于我的某些觀點，您可以完全贊同也可以完全不贊同；您也可以添加其他主題。這里為您敞開了一扇大門，歡迎您對我的看法提出意見。

1.?文檔/文本?Web?服務到底是什么？

這無疑是我聽到的首要問題。事實上，我們在數年前就聽到這一問題，令人感到有些驚奇的是，到目前為止仍有人時常提出這一問題，而且對這一問題仍存在一些誤解。您可能知道，您可以在?WSDL?定義中定義?Web?服務的調用樣式和編碼樣式。盡管這對構建網絡?SOAP?消息的確切方式存在影響，但對整體解決方案、交互樣式或編程模型幾乎毫無效果。因此我的建議始終是：

不要將使用某個特定的樣式作為整個企業范圍的規則。使用不同的樣式有各種各樣的原因，而且您很可能會碰到所有這些樣式。?
將該主題看作是一種實現細節，不要讓該主題推動或影響您的系統設計。?
請閱讀?Russ?Butek?撰寫的優秀文章?我應該采用哪一種?WSDL?樣式？，我認為這篇文章對這些不同之處做出了最好的解釋。?

2.?Web?服務非常慢，或者?Web?服務是否非常慢？

眾所周知，使用?Web?服務在性能上會受到一定程度的影響。這幾乎不會令人感到驚奇，因為使用?Web?服務時通常會涉及到把使用某種本機格式設置的數據構建為?XML?文檔，并在網絡中發送此文檔。盡管交叉處理（甚至是跨網絡處理）始終比本地調用要慢得多，但是如果聽到已經對?Web?服務的性能進行了一些改進，您可能會感到驚奇。

有許多技術可以實現這一點；例如，智能?XML?解析器技術（為處理?SOAP?和?XML?構件而進行了高級優化）或?XML?應用程序的出現（如?IBM?DataPower®，該應用程序支持硬件級別的?XML?處理）。還有?WebSphere?Application?Server?中的?Web?服務緩存支持功能，該功能也有助于大大提高性能。事實上，在某些情況下，在最新?WebSphere?Application?Server?運行時上的?SOAP?over?HTTP?調用比使用?RMI?over?IIOP?調用相同的功能要快。

因此，我的建議是應繼續對分布式計算應用基本的最佳實踐（例如，減少網絡通信量等），但開始考慮使用?Web?服務，甚至是用在對性能要求關鍵的情況中。?

3.?我的?XML?模式不適用于您的產品

在經過了開發?Hello?World?樣式的測試應用程序之后，您可能會注意到，在您的工具中，XML?模式規范中的某些更高級別的元素或者不受支持或者不能很好地?支持。例如，在?WebSphere?工具中，不存在對?<xsd:choice>?元素的映射，該元素在模式中非常通用。對于?<xsd:group>?也是這種情況。在這些情況下，您可以選擇更改模式，也可以選擇開發自己的代碼來處理基于此模式的?XML。請注意，可能需要手動干預才能將您的模式映射到?Web?服務實現。我建議的兩篇文章是：

Web?服務技巧:?將多態性作為?xsd:choice?的備選方法 ?
如何為?Web?服務選擇一種自定義映射技術?
總之，這里沒有一次性解決所有問題的萬能方法。不過，我們有理由期望這些標準和產品的未來版本也能夠提供對高級模式不斷增強的支持。

4.?UDDI?是什么情況？還有人在使用它嗎？

在?Web?服務首次開始流行之后，人們始終指出在任何?SOA?環境中都存在以下三種主要角色：?

服務請求程序?
服務提供程序?
服務代理程序?
代理程序角色一般由遵循?UDDI?標準的注冊中心表示。提供公共注冊中心可讓您創建自己的項和重復使用其他項。WebSphere?Application?Server?還附帶了一個專用?UDDI?注冊中心。?

不過，在實際情形中我仍沒有看到?UDDI?有多大用處（如果有）。大多數?IT?組織或者構建自己的方式來獲取服務定義和連接端點（例如使用?LDAP），或者棄用?UDDI，等待注冊中心的新標準。其他還有將專有擴展添加到?UDDI。公共?UDDI?注冊中心由?IBM?支持，其他組織已經放棄。

我的預測是，在這一領域，隨著時間的推移?UDDI?將由未來的新技術代替。

5.?Web?服務的同步

另一個經常討論的主題是，服務是同步的還是異步的，與編程模型相比，使用的通信協議充當什么角色。例如，假設使用?SOAP?over?JMS?綁定提供了?Web?服務。使用?JMS（支持異步交互）好像意味著這是一個異步?Web?服務。不過，如果在?WebSphere?Application?Server?中使用?JAX-RPC?支持，則服務使用者將在返回控制之前等待返回響應。這一原因是，無論是否使用了該協議，JAX-RPC?1.1?都在請求程序和提供程序之間強制執行了一個同步交互。換句話說，用來調用?Web?服務的編程模型通常確定調用的同步性，而不是網絡協議。

要構建真正的異步交互，您有兩個主要選項。第一個選項是構建一系列交換信息的單向服務，例如使用?WebSphere?Application?Server?V6.1?中的?WS-Addressing?支持。我推薦的一篇?developerWorks?上的文章對此內容進行了詳細說明：Web?服務尋址（WS-Addressing）對?SOAP?的隱式影響。

另一個選項是對異步調用使用服務組件體系結構?(SCA)?支持。SCA?提供了一個客戶端?API，后者可以將發送的請求與接收的響應分離開。將來，新的?JAX-WS?2.0?標準將提供類似的支持。

6.?ESB?或非?ESB

有許多問題都與企業服務總線?(ESB)?這一主題相關：

ESB?究竟是什么？它是一種產品還是一種模式，或者二者兼具？?
每個?SOA?實現是否都需要?ESB？?
假設?ESB?集線器，它是否有可能存在瓶頸問題？?
ESB?中?是什么，ESB?上?是什么？?
在嘗試回答這些問題之前，先為您提供一項關鍵資源，該資源很好地解釋了?IBM?對?SOA?編程模型上下文中的?ESB?的看法：IBM?企業服務總線介紹。?

回答上述問題涉及到整個系列文章，因此我在這里僅提供一些主要解答要點，讓您有個初步了解；它們分別是：

企業服務總線是一種體系結構模式。產品可以方便創建該模式的特定實例。?
ESB?的關鍵特性是分離關注點。像通信協議差異、路由和審核交互、安全性之類的內容可以在實際的服務請求程序和提供程序之外處理。如果不使用此分離方法就能夠開始您的解決方案，則不需要立即使用?ESB。不過，在大多數項目中都不會出現這種情況。?
ESB?是一種概念上的集線器，在幾乎所有實例中都以分布式方式物理地部署。?
盡管這有時很難說清楚（而且通常由您使用的產品驅動），但談論的一個較好切入點是考慮基礎結構?邏輯和業務?邏輯。與基礎結構相關的內容在總線中發生，而與業務相關的內容則不是。?
而且，我不主張這些簡單的解答就是對該主題的正當解釋，但它們也許為您的理解提供一些幫助。

7.?標頭和其他上下文數據

Web?服務設計的一個關鍵部分是定義進出服務的消息。可以保險地說消息始終有兩個關鍵部分：與業務功能相關的實際負載和上下文數據（如消息?ID、事務或會話?ID、安全信息等）。每個消息協議都為此上下文信息（SOAP?標頭、JMS?標頭、WebSphere“工作區”等）提供一個位置。問題是沒有一個一致的方法或?API?來處理這些不同的機制，而且在大多數實際的?SOA?環境中，您會遇到多個消息傳遞協議。

最適于您處理這種不同、而且實際上可讓您將一個標頭結構映射到另一個結構的位置是?ESB（這是使用?ESB?的又一好處；下文至少還會提供一個這樣的示例）。此映射很可能需要一些手工工作。?

無論您是如何處理的，關鍵是要為其盡早規劃和設計一個策略，并盡量在您的所有項目中保持一致。

8.?最終需要使用多少?(Web)?服務？

我對該問題的第一反應始終是建議采用一種方法，以便在確定服務的過程中作為指導。其中一個這樣的示例是由?IBM?全球業務服務部提倡的面向服務的建模和體系結構?(SOMA)?方法。與?IBM?Rational&reg;?Unified?Process?(RUP)?聯合在一起通常可促使您使用?SOA?的方法。

第二，不要因為能夠包裝而將每項?IT?功能都包裝在?Web?服務中。有時會使您對此采用整個“自下而上”的方法并使用富工具支持。在大多數（甚至是所有）情況下，采用此方法會導致服務太多，分得太細，沒有重用而且與業務不相關。

而且，對此也沒有很好的方法！業務分析師和?IT?架構師以適當的細分級別定義和創建適當的服務相當不容易。

9.?作為?Web?服務使用者的遺留應用程序

我們對通過?Web?服務支持現有功能給予了較多的關注。我所了解到的談論得比較少（即使也同等重要）的是現有應用程序利用新服務的能力。例如，假設公司在對?SOA?采用發展的方法，隨著時間的推移創建新服務，并將它們集成到現有環境中。其中一個現有應用程序是使用?RPG?編寫的，并運行于?IBM?iSeries?系統。現在需要將此應用程序更改為調用其中一個新服務。但負責此系統的開發人員對?SOAP?或?XML?不太熟悉，而且沒有基于?RPG?的?Web?服務包。

對此問題的最通用的解決方法是將?SOAP?和?XML?處理委托給?ESB。例如，使用?COBOL?或?RPG?編寫的應用程序可以容易地與?WebSphere?MQ?隊列交換記錄格式的消息。已經建立了對這種方法的很好支持，而且已經并且經常使用。像?WebSphere?ESB?或?WebSphere?Message?Broker?之類?ESB?產品可以從?MQ?接收數據，將其轉換為?XML，然后處理新?Web?服務的調用。

換句話說，通常較為可取的方法是，將新服務對現有應用程序的影響保持在最低限度，并將協議和消息格式的細節委托給?ESB。

10.?“困難在于具體實施”

最近，我訪問了法國的?IBM?工業解決方案中心。該中心展示了針對不同行業（如零售業、衛生保健業或銀行業）的基于?IBM?的解決方案。展示人員并沒有提及任何特定的?IT?產品，而且重點說明了解決方案的實際（業務）功能。但是他不經意地指出一點：“當然，您在這里看到的一切都基于?SOA”。盡管我認為他不是太關注如何針對異步交互在多個協議之間維護?WS-Addressing?標頭。

不過，構建、設計和實現?Web?服務和?SOA?會帶來許多詳細的?IT?技術問題。我們在使用新標準、新編程模型，而且經常使用新產品。創建支持諸如異類平臺之間交互的應用程序、企業范圍重用?IT?服務并按業務線需求不斷更改系統的功能要求，通常會導致不可預見的問題。

因此，下次您的經理進入您的辦公室說：“我希望構建一個每個人都說非常容易做到的這種?SOA?解決方案”時，您可以按照我的同事?Greg?Flurry?這時愛講的一句話說：“困難在于具體實施！”

參考資料?

您可以參閱本文在?developerWorks?全球站點上的?英文原文?。
我應該采用哪一種?WSDL?樣式？
Web?服務技巧:?將多態性作為?xsd:choice?的備選方法
Web?服務自定義數據綁定——第?1?部分:?如何為?Web?服務選擇一種自定義映射技術
Web?服務尋址（WS-Addressing）對?SOAP?的隱式影響
用于實現?Web?服務的?SOA?編程模型，第?4?部分:?IBM?企業服務總線介紹

關于作者

??Andre?Tost?是?Software?Group?的?Enterprise?Integration?Solutions?組織的一名高級技術人員，他在這個部門幫助?IBM?的客戶建立面向服務的體系結構。他專長于?Web?服務技術。在開始從事目前的工作之前，他有十年的時間在?IBM?軟件開發工作中擔任各種合作伙伴啟動、開發和構架的角色，目前他在?WebSphere?Business?Development?小組工作。他出生于德國，目前在美國明尼蘇達州的羅徹斯特居住和工作。在業余時間，他喜歡和家人在一起，并且有空就去踢球或看球賽。

點擊查看原文地址：http://www-128.ibm.com/developerworks/cn/websphere/techjournal/0608_col_tost/0608_col_tost.html?ca=drs-