Webservice 的設計和模式
[1] Webservice 的設計和模式
[2] Webservice 的設計和模式
[2] Webservice 的設計和模式
系列文章導航：
本文轉自：http://www.cnblogs.com/idior/（收藏看著不方便，還是放在自己的園子里）
本文是篇譯文（原文在devx），對于想初步了解webservice的朋友可能有些幫助。
Webservice 作為一項新的技術出現在我們面前，它的出世是用于解決在不同的平臺下的應用的協同的。目前幾乎每家廠商都要去開發Webservice 應用，然而如果缺乏對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的提供者緊密相連，一旦方法發生變化，客戶端就需要做相應的改動。這不符合低耦合系統的要求，而在文檔交換方式中則靈活的多。
由于業務數據是自包含的，顯然文檔模型更利于采用異步處理。
[第1頁][第2頁]
全站熱搜
留言列表
