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

引言

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

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

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

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

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

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

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

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

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

3.?我的?XML?模式不適用于您的產(chǎn)品

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

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

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

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

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

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

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

5.?Web?服務的同步

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

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

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

6.?ESB?或非?ESB

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

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

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

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

7.?標頭和其他上下文數(shù)據(jù)

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

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

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

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

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

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

而且，對此也沒有很好的方法！業(yè)務分析師和?IT?架構(gòu)師以適當?shù)募毞旨墑e定義和創(chuàng)建適當?shù)姆障喈敳蝗菀住?/p>

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

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

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

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

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

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

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

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

參考資料?

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

關(guān)于作者

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

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