作者 Paul Hammant, Ian Cartwright, ThoughtWorks, Inc譯者 Jason Lai 發(fā)布于 2008年1月17日 下午8時(shí)0分
在本文中，我們打算展示一下如何使用簡(jiǎn)單的技術(shù)加上以文檔為中心的方式帶來(lái)有價(jià)值的業(yè)務(wù)服務(wù)，而無(wú)須使用專(zhuān)有的中間件，也不必引入Web服務(wù)棧的復雜性。我們的靈感來(lái)自于REST的架構風(fēng)格，以及把XML移到HTTP協(xié)議之上的能力。
介紹我們這個(gè)方式的最好辦法就是將它和一個(gè)簡(jiǎn)單的Web服務(wù)例子相對比。假設有一個(gè)簡(jiǎn)單的天氣服務(wù)，暴露出一個(gè)名為“WeatherQuery”的Web方法，這個(gè)方法返回一個(gè)對象，包含溫度和氣壓值。在通常情況下，人們拿現成代碼，使用工具來(lái)暴露方法，并生成WSDL。
如果你相信這個(gè)騙局，那么要做的無(wú)非就是找到一個(gè)WSDL在Java下的等價(jià)工具，然后生成存根（Stub）代碼。
不巧的是，事情并沒(méi)有那么簡(jiǎn)單，WSDL是一個(gè)概括性的標準，而且實(shí)際上范圍到可以讓人自由詮釋。在我們的例子里，我們發(fā)現.NET強制使用基于文檔的方法，而Java工具則采用了相反的RPC方法。此外，我們還發(fā)現以下方面存在問(wèn)題：命名空間混淆，Schema的包含，以及工具將WSDL切分成若干獨立部分。簡(jiǎn)而言之，這項技術(shù)已經(jīng)開(kāi)始把注意力放在我們試圖解決的實(shí)際問(wèn)題之外了。
除了這些問(wèn)題，我們還發(fā)現Web服務(wù)的工具之間存在不一致性。例如，對于自動(dòng)發(fā)布的WSDL文檔，不同版本的Internet Information Server和Web Services Enhancements之間，還有它們的Java等價(jià)產(chǎn)品，彼此之間只能部分兼容。
有些東西今天七拼八湊起來(lái)可以工作，但到了明天，如果服務(wù)的后續版本需要更復雜的Web方法時(shí)就得拋錨。這些東西真是令我們倍感厭煩。
上面的方法里存在兩個(gè)關(guān)鍵性假設：首先，僅暴露一個(gè)已有方法調用就足以給我們帶來(lái)一個(gè)有意義的服務(wù)；其次，使用工具能使通過(guò)Web服務(wù)訪(fǎng)問(wèn)到這個(gè)服務(wù)的工作變成小菜一碟。
我們可以把請求看做一個(gè)包含請求的類(lèi)型還有相應參數的文檔，而不是考慮請求的參數和返回的類(lèi)型。把這個(gè)文檔當成對試圖建模的業(yè)務(wù)過(guò)程中契約的一部分的描述。如果我們以相同的WeatherQuery方法為例，用常見(jiàn)的XML來(lái)描述它，那么就可以得到類(lèi)似下面的東西——
同樣，作為文檔，返回類(lèi)型看起來(lái)會(huì )像這樣——
現在我們可以定義一個(gè)簡(jiǎn)單的類(lèi)，用于表示文檔中的相同字段——
關(guān)于這兩個(gè)文檔，有意思的是它們在.NET和Java中都比較容易序列化和反序列化。對于.NET來(lái)說(shuō)，內建的XML序列化機制（帶標注/Annotations）可以很輕松地完成這項工作。對于同樣一個(gè)類(lèi)，C#代碼如下：
Java開(kāi)發(fā)人員就沒(méi)那么幸運了，因為Java并不提供內建的XML序列化工具：不過(guò)有一個(gè)名為XStream的開(kāi)源項目（http://xstream.codehaus.org），能幫我們完美地完成這項工作：
我們的Weather服務(wù)目前僅需負責文檔的交換，而作為結果，我們就可以使用簡(jiǎn)單的HTTP而不用使用Web服務(wù)了。
有了這樣的轉變，我們就可以考慮讓多個(gè)文件類(lèi)型使用同一個(gè)進(jìn)入系統的入口點(diǎn)，從而為我們帶來(lái)一個(gè)更可擴展的方法。
用于此服務(wù)Java實(shí)現的技術(shù)包括XStream序列化類(lèi)庫，以及任意一個(gè)Servlet容器，因為我們選擇用Servlet提供這些服務(wù)。XStream類(lèi)庫的源碼是開(kāi)放的，而Servlet容器可以是WebLogic、WebSphere、JBoss、Geronimo或者Orion。如果對J2EE中的E（企業(yè)特性）要求沒(méi)有那么高，那么甚至只用Resin、Tomcat或者Jetty就可以了。
我們的Servlet應當實(shí)現doPost()方法，而不是doGet()方法。對于XML，我們沒(méi)有使用名稱(chēng)/鍵值對：我們僅僅使用完整的POST內容主體，這有點(diǎn)超出HTTP規范涵蓋的范圍了。不過(guò)，這只是個(gè)人喜好的問(wèn)題——只要在服務(wù)器端和客戶(hù)端相同就可以了。
在請求傳入時(shí)，我們使用XStream將XML反序列化成一個(gè)命令對象，然后合理地進(jìn)行處理就可以了。
用于.NET服務(wù)器端的代碼要簡(jiǎn)單得多——我們僅需使用Internet Information Server（IIS）和.NET的內建XML序列化機制就可以了。內建的序列化機制要求C#屬性將字段標記成XML元素而不是XML屬性。當然，還存在著(zhù)XStream的一個(gè).NET移植版本，不過(guò)我們還沒(méi)有拿它做過(guò)實(shí)驗，而我們也聽(tīng)說(shuō)過(guò)開(kāi)源社區還將有另外一個(gè)移植版本發(fā)布。
對于Java客戶(hù)端，除了XStream以外，我們還得使用Apache的HttpClient類(lèi)庫（以及相應的依賴(lài)類(lèi)庫）。
請參見(jiàn)http://jakarta.apache.org/commons/httpclient。
HttpClient類(lèi)庫用起來(lái)很簡(jiǎn)單，并且允許POST操作在執行之前被以編程的方式創(chuàng )建。記住，POST內容主體完全是用XStream生成的XML，形式可以是名稱(chēng)/鍵值對，或者是除去HTTP構造的完整請求。如果你希望為服務(wù)創(chuàng )建一個(gè)測試Web表單，那么前者可能更有吸引力一些。
對于.NET客戶(hù)端，只要有.NET框架就沒(méi)問(wèn)題了，不管是1.1或者2.0都可以。
對于POST操作，可以使用內建的WebRequest類(lèi)和內建的序列化機制。
簡(jiǎn)單POST表達命令的XML的好處在于，我們可以在稍后加入更多的命令，而不需要改變我們的消息實(shí)現方式。服務(wù)器可以在運行期決定是否可以處理相應的XML：
要處理今后可能出現的多種類(lèi)型，好的解決方案是為每個(gè)類(lèi)型注冊一個(gè)處理器，如此一來(lái)就可以避免大量的if/else或者switch/case代碼塊了：
在使用XML是，人們面臨著(zhù)過(guò)分依賴(lài)于相關(guān)Schema的誘惑，我們必須仔細了解Schema驗證和客戶(hù)實(shí)際所需信息之間的差別。
如果Schema驗證在運行期執行，會(huì )帶給開(kāi)發(fā)人員不恰當的安全感。錯誤仍然可能發(fā)生——可能錯誤的XML還是會(huì )被發(fā)出。但這時(shí)候出現了什么？答案是會(huì )有一個(gè)Schema無(wú)效的異常信息被拋出。使用把XML映射到類(lèi)定義的方法，可能存在兩種情況：要么得到一個(gè)正確的對象，要么該對象會(huì )丟失某些字段。在這種情況下，可以?huà)伋鲆粋€(gè)帶有真實(shí)原因的真正異常，它可以很容易地被轉換回一條清晰的XML回復信息提供給客戶(hù)。關(guān)鍵的區別在于，異常只在必要信息缺失的情況下拋出——其它東西都可以有變更。
這種設計所固有的可能性在于，XML中可以加入新的元素（對應于類(lèi)中的字段），從而使得讓API在表義性上更上一層樓成為可能。經(jīng)過(guò)仔細的測試之后，服務(wù)將可以支持客戶(hù)發(fā)送舊版本的請求文檔。一般意義上的API變更，以及“額外字段”級別上的變更，也會(huì )變得更加意義深遠：
不過(guò)，要是把版本號也加入URL就更好了：http://x.com/weather/WeatherQuery/2.0
如果你要在同一臺服務(wù)器上放上另外一個(gè)服務(wù)，用于使剛才的服務(wù)處理標準的Web服務(wù)請求，那么沒(méi)有什么可以阻止你這樣去做。你所需要的，不過(guò)是WSDL指定的方法而已，就像這樣：
在工具上的選擇，包括：.NET平臺下的WSE 2.0/3.0，Java平臺下是Glue、AXIS、JAX-WS或者J2EE容器內建的適配器。進(jìn)行SOAP編碼的方法可以簡(jiǎn)單交給為純REST實(shí)現開(kāi)發(fā)的反序列化-執行-序列化的代碼來(lái)完成。這樣一來(lái)，你就可以避免負責公司標準監控的人來(lái)找麻煩了。
在使用了TIBCO Rendezvous之后，我們就可以將請求的相同XML表現形式發(fā)送到隱式的異步服務(wù)執行了。我們還沒(méi)有嘗試過(guò)MQ系列，不過(guò)應該沒(méi)有什么問(wèn)題。
就我們的范例來(lái)說(shuō)，這意味著(zhù)針對天氣詳情的請求不會(huì )馬上得到回復。相反，在等待片刻之后才會(huì )收到響應。這是一個(gè)巨大的變化，可能意味著(zhù)你不得不改變或者放棄對API的某些簡(jiǎn)單設計。例如，下面的Façade方法可能派不上用場(chǎng)了：
取而代之的是兩個(gè)接口，每一個(gè)都帶了單獨的方法，這樣會(huì )更合適些：
關(guān)于消息傳送的模式，有許多值得學(xué)習，不過(guò)在這里我們不打算深入探討。然而，值得一提的是，存在兩個(gè)常用的模式值得我們考慮一下。第一種設計是隊列，在這個(gè)設計中，你發(fā)送的請求只能接受返回給你的請求。第二種概念是多播（Multicast），其中線(xiàn)上的事件被發(fā)送到多個(gè)訂閱者處（出版者/訂閱者模式）。此外，一個(gè)沒(méi)有明確指出的事實(shí)，你可以設計出一個(gè)隊列，讓它持續不斷地發(fā)送修正的信息。如果你熟悉JMS的話(huà)，那么Rendezvous在這方面和它只有些許不同。
我們編碼完成的生產(chǎn)者/消費者設計以簡(jiǎn)單的形式交換XML。但是，在正式的Web服務(wù)設計中發(fā)現階段所固有的協(xié)議檢查在我們這個(gè)例子里是不存在的。
對此，我們的建議是，這并不是必要的。相反，全面遵循敏捷思維，設計出一套全面符合持續集成（Continuous Integration）的集成測試。這樣，在部署上線(xiàn)之前，服務(wù)的不兼容問(wèn)題就可以事先發(fā)現。因此，你可以把一套復雜的WSDL規范丟在一旁，取而代之擁有的是一系列從提供者和使用者角度斷言描述服務(wù)的單元測試。不管怎么說(shuō)，WSDL只能在運行期提示不兼容問(wèn)題，而這時(shí)候恢復已經(jīng)不是一件容易的事情了。這么說(shuō)來(lái)，我們是不是錯為它建了神龕了？
要以平臺無(wú)關(guān)的方式創(chuàng )建這類(lèi)測試，Schematron是可選方案之一。
要輔助調試和文檔，你還得準備一些范例文檔：
此外，你還可以使用XML Schema（XSD）來(lái)控制文檔格式：
同時(shí)靜態(tài)提供XSD和范例XML是個(gè)不錯的注意（碰巧作者們在XSD方面意見(jiàn)不統一）。在這里“靜態(tài)提供”指的是，API可以由人們通過(guò)Web瀏覽器手動(dòng)請求調用——
http://x.com/weather/xsd/WeatherQuer
http://x.com/weather/sample/WeatherQuery
記住，XSD和范例文檔都只是可選方案，也可以很容易地生成。
本例中的法寶是使用Codehaus的XStream，通過(guò)HTTP-POST而不是GET與.NET進(jìn)行文檔交換。其它的所有內容早就有人在博客上撰文詳述或者寫(xiě)過(guò)相應白皮書(shū)了。選用XStream意味著(zhù)消息本身的“規范”存在與Java和/或C#的代碼當中，而不存在于基于XML、常常讓你不得不面對WS-*規范的設計中。
此外，傳統的REST金科玉律推薦使用HTTP-GET，因為它更適合對命令進(jìn)行編碼……
http://x.com/weather/WeatherQuery?locn=Chicago
……在結果可以被Web服務(wù)器緩存的情況下尤其如此?；蛟S我們這種風(fēng)格最適用于通訊的場(chǎng)景，在這種情況下，試圖進(jìn)行緩存是沒(méi)有意義的。在GET方案中存在著(zhù)另外一些優(yōu)勢，這些優(yōu)勢是我們的方案所不具備的。GET方案更優(yōu)雅，并且在可測試性上更突出，人們可以使用瀏覽器通過(guò)完整的URL完成測試。然而，它所或缺的，是POST方法所帶來(lái)多功能性，對于參數格式上不僅局限于名稱(chēng)/鍵值對；而且XML的有效載荷的復雜程度也可以任意指定。當然，在更大型的解決方案中，GET和POST都擁有一席之地。
在這篇論文撰寫(xiě)過(guò)程中，我們向XStream團隊提了一項建議（用補丁的形式），讓XStream在合適的地方對屬性的支持更加游刃有余。XStream開(kāi)發(fā)團隊實(shí)現了必要的功能，而XStream今后的版本將可以支持XML屬性，以便與.NET實(shí)現更加無(wú)縫的互操作。
我們還提到，這個(gè)方法對于異步傳輸，如Tibco RV，也同樣適用。在這方面，目前WS-*規范的工具基本上沒(méi)有提供支持。
在文章末尾，我們不能肯定這是否是POST-REST（PREST），或者只是傳統的REST，不帶緩存和URL簡(jiǎn)化功能，也沒(méi)有新造的名詞。
聯(lián)系客服
