Webservice的設計和模式

-.zWebservice的設計和模式本系列文章導航創(chuàng)立一個例如和WebMethod特性解析WebService特性和數(shù)組類型解析類和構造體解析利用公開API做天氣預報Web效勞Webservice的設計和模式Remoting和Webservice的區(qū)別本文轉自：.blogs./idior/〔收藏看著不方便，還是放在自己的園子里〕本文是篇譯文〔原文在dev*〕，對于想初步了解webservice的朋友可能有些幫助。

Webservice作為一項新的技術出現(xiàn)在我們面前，它的出世是用于解決在不同的平臺下的應用的協(xié)同的。目前幾乎每家廠商都要去開發(fā)Webservice應用，然而如果缺乏對Webservice更深的了解，不能很好的在設計階段處理好一些重要的問題，則最終完成的系統(tǒng)必然是效率低下，沒有可靠性的產(chǎn)品。在設計Webservice應用時，以下幾點務必要考慮到：l

管理好與外系統(tǒng)的協(xié)同關系l

掌握底層的傳輸模型l

提供與應用相適應的平安策略l

方案好部署的相關事項以下，將就這幾條相關的設計需求和一些常用模式是如何應用于Webservice模型展開詳細討論。在討論中，你會發(fā)現(xiàn)Webservice這項新的技術是如何與我們在以往的軟件開發(fā)相結合的。l

標準提供了協(xié)同的能力Webservice的一個最根本的目的就是提供在各個不同平臺的不同應用系統(tǒng)的協(xié)同工作能力。為了使得一個公司的網(wǎng)絡應用到達最高的效率，存在它自己和它的合作伙伴，供給商以及客戶之間的Webservice，應該能夠實現(xiàn)無縫的交互。如果在眾多的Webservice之間不能輕松的實現(xiàn)交互，則該應用的效率將大打折扣。但是，在現(xiàn)實中這種情況是極有可能出現(xiàn)的。由于各個公司對業(yè)務的理解各不一樣，就是理解一樣的情況下，對于一樣的概念也可能用不同的形式加以表現(xiàn)，具體而言就是對于同一數(shù)據(jù)可能采取不同的*ml表示。由于以上的原因，對于協(xié)同性的問題應該在設計應用架構時就加以考慮，而不是留待以后去改變。Webservice主要由以下幾塊技術所構成，SOAP(SimpleObjectAccessProtocol),WSDL(WebserviceDescriptionLanguage),以及UDDI(UniversalDescription,DiscoveryandIntegration)。在這里我們不會去詳細研究這些技術，而是提醒他們的一些重要特性，這些特性需要在Webservice的設計時詳加考慮。WSDL是實現(xiàn)協(xié)同能力的關鍵，它提供了一份契約用于與新老的應用之間交互。這項技術使得各個組織可以將標準的制定集中在Service的外部接口，而不用考慮各組織的具體實現(xiàn)。簡而言之，它實現(xiàn)了Webservice的接口與實現(xiàn)的別離。從而使得標準的制定，更加容易。并且，基于這份接口描述，很多工具可以從中自動生成客戶端代碼，減少了開發(fā)者的工作量，并使得大局部開發(fā)者擺脫了編寫SOAP消息傳遞代碼過程。SOAP是實現(xiàn)在各個Webservice組件之間傳遞消息的傳輸層。因此，SOAP應該是一項透明的協(xié)同技術。但是，由于很多的SOAP實現(xiàn)方法卻與標準背道而馳，要么添加了新的擴展功能要么刪減了一些標準功能。由于對SOAP標準的支持程度不同，使得Webservice的協(xié)同能力大打折扣，實現(xiàn)協(xié)同的困難加大了?；谶@種情況，當開發(fā)者需要Webservice運行在不同平臺上時，就要對具體情況加以了解并相應的編碼以解決這種不一致性。如果所有的SOAP實現(xiàn)組織都能夠遵循標準的話，則Webservice的開發(fā)者就不需要考慮使用該Webservice的底層平臺了。盡管如此，不同SOAP實現(xiàn)的協(xié)同還是相當困難，因為協(xié)同標準的制定存在大量的分歧，目前一些組織正致力于標準的制定，比方SOAPBuilders和WS-I。然而，現(xiàn)在Webservice開發(fā)者只有針對不同平臺，給予不同的實現(xiàn)，使得開發(fā)的本錢和負擔加大了。l

理解傳輸模型SOAP并不是完全透明的解決方案，它把一些復雜的實現(xiàn)細節(jié)隱藏起來。Webservice的開發(fā)者必須深入的了解SOAP，了解底層的傳輸機制以及模型,從而知道SOAP是如何實現(xiàn)的。在一些簡單的應用中，*些工具可以幫助Webservice的開發(fā)者生成SOAP消息傳遞的代碼，但是這只在最簡單的應用中有效。真正的情況不可能則簡單，可能在*些方面你需要有特殊的處理〔這種情況在實際開發(fā)中是很常見的〕，這個時候，你就需要直接操縱SOAP的消息傳遞代碼，以及一些底層的*ML內(nèi)容。因此，Webservice的開發(fā)者需要深入了解SOAP和*ML層的內(nèi)容。在開發(fā)Webservice的接口的時候，不要以為使用*ML技術，協(xié)作性的問題就迎刃而解了，*ML并不是解決集成問題的靈丹妙藥。這里同樣需要標準的制定，需要一個在業(yè)界公認的詞匯表。僅僅在你的設計框架中引入*ML技術并不能保證系統(tǒng)具有協(xié)同性，*ML僅僅是用來描述數(shù)據(jù)的語言，*ML自己并不提供語義去理解數(shù)據(jù)。就如同英語和德語都使用拉丁字母，但是他們的語義卻并不一樣。即使你使用一樣的語言，也不能保證具有良好的協(xié)作性。比方你的公司可能使用Order描述一個訂單，但你的合作伙伴可能使用Purchase_Order，而另一個伙伴可能又不一樣。你不可能強迫你所有的合作伙伴都采用和你一樣的詞匯。因此需要有一項技術可以在眾多的描述之間充當翻譯的角色。*SLT就是這么一種技術，它用于不同語言的轉換。和*SLT的配合使用*ML才能解決協(xié)同性的問題。l

DOMvs.SA*許多的Webservice開發(fā)環(huán)境，將開發(fā)者從底層的*ML文檔的解析和處理中解放出來，他們提供了自動化或者很方便的工具，使得這一過程變得很簡單。但是對于一些有特殊要求的Webservice應用，比方需要更好的柔性或者對速度要求特別高的應用，就需要手工處理*ML文檔。這時候兩種*ML解析的模型－DOM和SA*的選擇，將成為重要的問題。DOM使用樹狀圖的方式解析*ML文檔，而SA*則更多的采用事件驅動的模型。DOM先將*ML文檔映射成一顆樹，然后通過采用一系列與樹相關的操作去處理這份文檔。這種方法有很多的好處，首先開發(fā)者很容易理解，使用一顆樹這對于開發(fā)者來說是最常見不過的了。DOM最常用于*ML在Service中需要頻繁修改的場合。當然DOM也有它的缺點，在處理*ML文檔的時候，它需要載入整個文檔，而不管你需要修改的是否只是其中的一小局部。因此它的運行效率以及對內(nèi)存的使用顯然是不能承受的，尤其是面對很大的*ML文檔。SA*使用事件驅動的模型來處理*ML文檔。通過一系列事件的觸發(fā)，來完成對*ML的解析，你可以只關心你所要處理的事件，當這些事件發(fā)生時，會調(diào)用到相應的回調(diào)函數(shù)來通知到你。采用這種方式就可以在很大程度上提高*ML文檔解析的效率。但是它的缺點在于難于使用，以及對同一文檔的屢次處理會存在一些問題。總而言之，DOM更適合處理那種文檔型的*ML文件，而SA*則適于那種想直接將*ML構造映射成在你系統(tǒng)中的一個對象的操作。〔比方將一個*ML構造直接映射成JAVA中的一個Class〕或者那種針對*ML文件中特殊Tag的操作。l

文檔交換vs.RPC模型這兩種交互方式應該在應用架構的設計初始就應該詳加考慮，因為它將在很大程度上決定系統(tǒng)的耦合程度。RPC〔RemoteProcedureCall〕本質上就是遠程方法的調(diào)用。盡管Webservice是基于*ML的但是你仍然可以使用遠程方法調(diào)用這種模式來進展Webservice的實現(xiàn)，尤其是在那種簡單的請求相應的模型中。在這個過程中，傳輸中的*ML文件所描述的更多是有關遠程方法的信息，比方方法名，方法參數(shù)等等。而文檔交換方式，與RPC相比擬在*ML文件中不是做遠程方法的映射，而是一份完整的自包含的業(yè)務文檔，當Service端收到這份文檔后，先進展預處理〔比方詞匯的翻譯和映射〕，然后再構造出返回消息。這個構造返回消息的過程中，往往不再是簡簡單單的一個方法調(diào)用，而是多個對象協(xié)同完成一個事務的處理，再將結果返回。這兩種方式的區(qū)別，類似與打和發(fā)的不同處理方法。在目前，對于第一種方法提供了很多自動化的工具使得遠程方法的調(diào)用能夠很容易的完成，而后一種方法缺少一系列工具的支持，需要開發(fā)者手工完成。盡管如此，在此還是推薦使用文檔交換的方式。由于它在以下方面具有RPC所不具備的優(yōu)點。使用文檔方式，你可以充分利用*ML文件的功能去描述和驗證一份業(yè)務文檔，而在RPC模型中*ML僅僅被用于描述方法的信息。使用文檔方式，在客戶的Service的提供者之間不再需要嚴密的約定，而RPC模型需要客戶和Service的提供者嚴密相連，一旦方法發(fā)生變化，客戶端就需要做相應的改動。這不符合低耦合系統(tǒng)的要求，而在文檔交換方式中則靈活的多。由于業(yè)務數(shù)據(jù)是自包含的，顯然文檔模型更利于采用異步處理。

利用設計模式設計模式在設計Webservice的時候顯然可以起到相當大的作用。設計模式的主要目的就是為解決*些在類似環(huán)境下的相像問題提供已有的較為成熟的設計方案。在這里，只簡單的提及一些很常用的模式，讓我們了解到模式在Webservice中可以起到的作用。Adapter：為內(nèi)部系統(tǒng)提供一個不同的接口Fa?ade：封裝復雜的內(nèi)部實現(xiàn)，提供一系列簡單的接口Pro*y：作為其他對象的代理，代替它提供效勞Adapter模式用于將一個組件的接口轉化成客戶所需要的樣子，這里的客戶就是Webservice。一個常見的情況就是將原有的老的系統(tǒng)包裝成一個Webservice。比方現(xiàn)在使用的是J2EE的平臺，而原來有一個C++的系統(tǒng)實現(xiàn)了*些功能，現(xiàn)在需要將它發(fā)布成Webservice，則就需要利用JNI技術做一個Adapter，為原來的C++組件提供一個Java的接口，然后再轉化為Webservice。Fa?ade模式用于構建粗粒度的效勞，它包裝了細粒度的效勞，從而為復雜的系統(tǒng)提供了一個簡單的接口。在J2EE中，SessionBean就象是一個Fa?ade，而EntityBean則是細粒度的效勞。在Webservice中也一樣，使用Fa?ade模式可以將已有的組件的功能發(fā)揮殆盡。Pro*y模式用于充當其他對象的代理，類似于中間人的作用，將處理工作從一個對象傳遞到另一個對象。在Webservice中，它主要用于隱藏Soap消息構造的過程。也可以用于模擬對象〔MockObject〕的創(chuàng)立。以上僅僅是一些可以用于Webservice開發(fā)的模式，如果你熟練的將這些模式應用于Webservice開發(fā)，你將會發(fā)現(xiàn)開發(fā)Webservice應用，將好似做一種特殊的面向對象設計。l

平安Webservice為作為方便的效勞被用廣闊領域使用的同時，也成為了黑客們的美食。在這里，本文將就目前對Webservice平安所能做的改良做簡單介紹。在Webservice中的平安主要分為以下三個方面。傳輸

SSL/HTTPS對連接加密，而不是傳輸數(shù)據(jù)消息

數(shù)據(jù)加密(*MLEncryption)

數(shù)字簽名(*ML-DSIG)底層架構

利用應用效勞平安機制傳輸時的平安是最容易被參加到你的Webservice應用中的，利用現(xiàn)有的SSL和HTTPS協(xié)議，就可以很容易的獲得連接過程中的平安。然而這種平安實現(xiàn)方法有兩個弱點。一是它只能保證數(shù)據(jù)傳輸?shù)钠桨玻皇菙?shù)據(jù)本身的平安，數(shù)據(jù)一旦到達*地，則就可以被任何人所查看。而在Webservice中，一份數(shù)據(jù)可能到達多個地方，而這份數(shù)據(jù)卻不該被所有的承受者所查看。二是它提供的是要么全有要么全無的保護，你不能選擇哪局部數(shù)據(jù)要被保護，而這種可選擇性也是在Webservice中所常要用到的。第二層的保護是對于消息本身的保護。你可以使用已有的*ML平安擴展標準，實現(xiàn)數(shù)字簽名的功能，從而保證你的消息是來自特定方并沒有被修改正。*ML文件的加密技術從更大程度上加強了Webservice的平安，它能夠定制數(shù)據(jù)傳輸?shù)胶?，能否被承受者所查看，進一步完善了傳輸后的平安，業(yè)界也在不斷的制定Webservice的平安標準，比方SAM