Webservice 的設計和模式

本文是篇譯文（原文在devx），對于想初步了解webservice的朋友可能有些幫助。 Webservice 作為一項新的技術出現在我們面前，它的出世是用于解決在不同的平台下的應用的協同的。目前幾乎每家廠商都要去開發Webservice 應用，然而如果缺乏對Webservice更深的了解，不能很好的在設計階段處理好一些重要的問題，那麼最終完成的系統必然是效率低下，沒有可靠性的産品。 在設計Webservice 應用時，以下幾點務必要考慮到： l 管理好與外系統的協同關系 l 掌握底層的傳輸模型 l 提供與應用相适應的安全政策 l 計劃好部署的相關事項 以下，将就這幾條相關的設計需求和一些常用模式是如何應用于Webservice模型展開詳細讨論。在讨論中，你會發現Webservice這項新的技術是如何與我們在以往的軟體開發相結合的。 l 标準提供了協同的能力 Webservice的一個最基本的目的就是提供在各個不同平台的不同應用系統的協同工作能力。為了使得一個公司的網絡應用達到最高的效率，存在它自己和它的合作夥伴，供應商以及客戶之間的Webservice，應該能夠實作無縫的互動。如果在衆多的Webservice之間不能輕松的實作互動，那麼該應用的效率将大打折扣。但是，在現實中這種情況是極有可能出現的。由于各個公司對業務的了解各不相同，就是了解相同的情況下，對于相同的概念也可能用不同的形式加以表現，具體而言就是對于同一資料可能采取不同的xml表示。由于以上的原因，對于協同性的問題應該在設計應用架構時就加以考慮，而不是留待以後去改變。 Webservice 主要由以下幾塊技術所構成，SOAP (Simple Object Access Protocol), WSDL (Web service Description Language), 以及UDDI (Universal Description, Discovery and Integration)。 在這裡我們不會去詳細研究這些技術，而是揭示他們的一些重要特性，這些特性需要在Webservice的設計時詳加考慮。 WSDL是實作協同能力的關鍵，它提供了一份契約用于與新老的應用之間互動。這項技術使得各個組織可以将标準的制定集中在Service的外部接口，而不用考慮各組織的具體實作。簡而言之，它實作了Webservice的接口與實作的分離。進而使得标準的制定，更加容易。并且，基于這份接口描述，很多工具可以從中自動生成用戶端代碼，減少了開發者的工作量，并使得大部分開發者擺脫了編寫SOAP消息傳遞代碼過程。 SOAP是實作在各個Webservice元件之間傳遞消息的傳輸層。是以，SOAP應該是一項透明的協同技術。但是，由于很多的SOAP實作方法卻與标準背道而馳，要麼添加了新的擴充功能要麼删減了一些标準功能。由于對SOAP标準的支援程度不同，使得Webservice的協同能力大打折扣，實作協同的困難加大了。基于這種情況，當開發者需要Webservice運作在不同平台上時，就要對具體情況加以了解并相應的編碼以解決這種不一緻性。如果所有的SOAP實作組織都能夠遵循标準的話，那麼Webservice的開發者就不需要考慮使用該Webservice的底層平台了。 盡管如此，不同SOAP實作的協同還是相當困難，因為協同标準的制定存在大量的分歧，目前一些組織正緻力于标準的制定，比如SOAP Builders 和 WS-I。然而，現在Webservice開發者隻有針對不同平台，給予不同的實作，使得開發的成本和負擔加大了。 l 了解傳輸模型 SOAP并不是完全透明的解決方案，它把一些複雜的實作細節隐藏起來。Webservice的開發者必須深入的了解SOAP，了解底層的傳輸機制以及模型,進而知道SOAP是如何實作的。在一些簡單的應用中，某些工具可以幫助Webservice的開發者生成SOAP消息傳遞的代碼，但是這隻在最簡單的應用中有效。真正的情況不可能那麼簡單，可能在某些方面你需要有特殊的處理（這種情況在實際開發中是很常見的），這個時候，你就需要直接操縱SOAP的消息傳遞代碼，以及一些底層的XML内容。是以，Webservice的開發者需要深入了解SOAP和XML層的内容。 在開發Webservice的接口的時候，不要以為使用XML技術，協作性的問題就迎刃而解了，XML并不是解決內建問題的靈丹妙藥。這裡同樣需要标準的制定，需要一個在業界公認的詞彙表。僅僅在你的設計架構中引入XML技術并不能保證系統具有協同性，XML僅僅是用來描述資料的語言，XML自己并不提供語義去了解資料。就如同英語和德語都使用拉丁字母，但是他們的語義卻并不相同。 即使你使用相同的語言，也不能保證具有良好的協作性。比如你的公司可能使用Order描述一個訂單，但你的合作夥伴可能使用Purchase_Order，而另一個夥伴可能又不相同。你不可能強迫你所有的合作夥伴都采用和你相同的詞彙。是以需要有一項技術可以在衆多的描述之間充當翻譯的角色。XSLT就是這麼一種技術，它用于不同語言的轉換。和XSLT的配合使用XML才能解決協同性的問題。 l DOM vs. SAX 許多的Webservice開發環境，将開發者從底層的XML文檔的解析和進行中解放出來，他們提供了自動化或者很友善的工具，使得這一過程變得很簡單。但是對于一些有特殊要求的Webservice應用，比如需要更好的柔性或者對速度要求特别高的應用，就需要手工處理XML文檔。這時候兩種XML解析的模型－DOM 和SAX的選擇，将成為重要的問題。 DOM使用樹狀圖的方式解析XML文檔，而SAX則更多的采用事件驅動的模型。 DOM先将XML文檔映射成一顆樹，然後通過采用一系列與樹相關的操作去處理這份文檔。這種方法有很多的好處，首先開發者很容易了解，使用一顆樹這對于開發者來說是最常見不過的了。DOM最常用于XML在Service中需要頻繁修改的場合。當然DOM也有它的缺點，在處理XML文檔的時候，它需要載入整個文檔，而不管你需要修改的是否隻是其中的一小部分。是以它的運作效率以及對記憶體的使用顯然是不能接受的，尤其是面對很大的XML文檔。 SAX使用事件驅動的模型來處理XML文檔。通過一系列事件的觸發，來完成對XML的解析，你可以隻關心你所要處理的事件，當這些事件發生時，會調用到相應的回調函數來通知到你。采用這種方式就可以在很大程度上提高XML文檔解析的效率。但是它的缺點在于難于使用，以及對同一文檔的多次處理會存在一些問題。總而言之，DOM更适合處理那種文檔型的XML檔案，而SAX則适于那種想直接将XML結構映射成在你系統中的一個對象的操作。（比如将一個XML結構直接映射成JAVA中的一個Class）或者那種針對XML檔案中特殊Tag的操作。 l 文檔交換vs. RPC模型這兩種互動方式應該在應用架構的設計初始就應該詳加考慮，因為它将在很大程度上決定系統的耦合程度。 RPC（Remote Procedure Call）本質上就是遠端方法的調用。盡管Webservice是基于XML的但是你仍然可以使用遠端方法調用這種模式來進行Webservice的實作，尤其是在那種簡單的請求相應的模型中。在這個過程中，傳輸中的XML檔案所描述的更多是有關遠端方法的資訊，比如方法名，方法參數等等。而文檔交換方式，與RPC相比較在XML檔案中不是做遠端方法的映射，而是一份完整的自包含的業務文檔，當Service端收到這份文檔後，先進行預處理（比如詞彙的翻譯和映射），然後再構造出傳回消息。這個構造傳回消息的過程中，往往不再是簡簡單單的一個方法調用，而是多個對象協同完成一個事務的處理，再将結果傳回。這兩種方式的差別，類似與打電話和發郵件的不同處理方法。在目前，對于第一種方法提供了很多自動化的工具使得遠端方法的調用能夠很容易的完成，而後一種方法缺少一系列工具的支援，需要開發者手工完成。盡管如此，在此還是推薦使用文檔交換的方式。由于它在以下方面具有RPC所不具備的優點。使用文檔方式，你可以充分利用XML檔案的功能去描述和驗證一份業務文檔，而在RPC模型中XML僅僅被用于描述方法的資訊。使用文檔方式，在客戶的Service的提供者之間不再需要緊密的約定，而RPC模型需要客戶和Service的提供者緊密相連，一旦方法發生變化，用戶端就需要做相應的改動。這不符合低耦合系統的要求，而在文檔交換方式中則靈活的多。由于業務資料是自包含的，顯然文檔模型更利于采用異步處理。 l 利用設計模式設計模式在設計Webservice的時候顯然可以起到相當大的作用。設計模式的主要目的就是為解決某些在類似環境下的相像問題提供已有的較為成熟的設計方案。在這裡，隻簡單的提及一些很常用的模式，讓我們了解到模式在Webservice中可以起到的作用。 Adapter ：為内部系統提供一個不同的接口 Fa

本文轉自yonghu86 51CTO部落格，原文連結：http://blog.51cto.com/yonghu/1321396，如需轉載請自行聯系原作者