這片文章是片譯文（原文在devx，具體記不得了），對(duì)于想初步了解webservice的朋友可能有些幫助。其中有一些模式的應(yīng)用，不過(guò)個(gè)人覺得太簡(jiǎn)單了，忘大家多想想，發(fā)表些意見。
Webservice 作為一項(xiàng)新的技術(shù)出現(xiàn)在我們面前，它的出世是用于解決在不同的平臺(tái)下的應(yīng)用的協(xié)同的。目前幾乎每家廠商都要去開發(fā)Webservice 應(yīng)用，然而如果缺乏對(duì)Webservice更深的了解，不能很好的在設(shè)計(jì)階段處理好一些重要的問(wèn)題，那么最終完成的系統(tǒng)必然是效率低下，沒有可靠性的產(chǎn)品。
在設(shè)計(jì)Webservice 應(yīng)用時(shí)，以下幾點(diǎn)務(wù)必要考慮到：
l 管理好與外系統(tǒng)的協(xié)同關(guān)系
l 掌握底層的傳輸模型
l 提供與應(yīng)用相適應(yīng)的安全策略
l 計(jì)劃好部署的相關(guān)事項(xiàng)
以下，將就這幾條相關(guān)的設(shè)計(jì)需求和一些常用模式是如何應(yīng)用于Webservice模型展開詳細(xì)討論。在討論中，你會(huì)發(fā)現(xiàn)Webservice這項(xiàng)新的技術(shù)是如何與我們?cè)谝酝能浖_發(fā)相結(jié)合的。
l 標(biāo)準(zhǔn)提供了協(xié)同的能力
Webservice的一個(gè)最基本的目的就是提供在各個(gè)不同平臺(tái)的不同應(yīng)用系統(tǒng)的協(xié)同工作能力。
為了使得一個(gè)公司的網(wǎng)絡(luò)應(yīng)用達(dá)到最高的效率，存在它自己和它的合作伙伴，供應(yīng)商以及客戶之間的Webservice，應(yīng)該能夠?qū)崿F(xiàn)無(wú)縫的交互。如果在眾多的Webservice之間不能輕松的實(shí)現(xiàn)交互，那么該應(yīng)用的效率將大打折扣。但是，在現(xiàn)實(shí)中這種情況是極有可能出現(xiàn)的。由于各個(gè)公司對(duì)業(yè)務(wù)的理解各不相同，就是理解相同的情況下，對(duì)于相同的概念也可能用不同的形式加以表現(xiàn)，具體而言就是對(duì)于同一數(shù)據(jù)可能采取不同的xml表示。由于以上的原因，對(duì)于協(xié)同性的問(wèn)題應(yīng)該在設(shè)計(jì)應(yīng)用架構(gòu)時(shí)就加以考慮，而不是留待以后去改變。
Webservice 主要由以下幾塊技術(shù)所構(gòu)成，SOAP (Simple Object Access Protocol), WSDL (Web service Description Language), 以及UDDI (Universal Description, Discovery and Integration)。
在這里我們不會(huì)去詳細(xì)研究這些技術(shù)，而是揭示他們的一些重要特性，這些特性需要在Webservice的設(shè)計(jì)時(shí)詳加考慮。
WSDL是實(shí)現(xiàn)協(xié)同能力的關(guān)鍵，它提供了一份契約用于與新老的應(yīng)用之間交互。這項(xiàng)技術(shù)使得各個(gè)組織可以將標(biāo)準(zhǔn)的制定集中在Service的外部接口，而不用考慮各組織的具體實(shí)現(xiàn)。簡(jiǎn)而言之，它實(shí)現(xiàn)了Webservice的接口與實(shí)現(xiàn)的分離。從而使得標(biāo)準(zhǔn)的制定，更加容易。并且，基于這份接口描述，很多工具可以從中自動(dòng)生成客戶端代碼，減少了開發(fā)者的工作量，并使得大部分開發(fā)者擺脫了編寫SOAP消息傳遞代碼過(guò)程。
SOAP是實(shí)現(xiàn)在各個(gè)Webservice組件之間傳遞消息的傳輸層。因此，SOAP應(yīng)該是一項(xiàng)透明的協(xié)同技術(shù)。但是，由于很多的SOAP實(shí)現(xiàn)方法卻與標(biāo)準(zhǔn)背道而馳，要么添加了新的擴(kuò)展功能要么刪減了一些標(biāo)準(zhǔn)功能。由于對(duì)SOAP標(biāo)準(zhǔn)的支持程度不同，使得Webservice的協(xié)同能力大打折扣，實(shí)現(xiàn)協(xié)同的困難加大了?；谶@種情況，當(dāng)開發(fā)者需要Webservice運(yùn)行在不同平臺(tái)上時(shí)，就要對(duì)具體情況加以了解并相應(yīng)的編碼以解決這種不一致性。如果所有的SOAP實(shí)現(xiàn)組織都能夠遵循標(biāo)準(zhǔn)的話，那么Webservice的開發(fā)者就不需要考慮使用該Webservice的底層平臺(tái)了。
盡管如此，不同SOAP實(shí)現(xiàn)的協(xié)同還是相當(dāng)困難，因?yàn)閰f(xié)同標(biāo)準(zhǔn)的制定存在大量的分歧，目前一些組織正致力于標(biāo)準(zhǔn)的制定，比如SOAP Builders 和 WS-I。然而，現(xiàn)在Webservice開發(fā)者只有針對(duì)不同平臺(tái)，給予不同的實(shí)現(xiàn)，使得開發(fā)的成本和負(fù)擔(dān)加大了。
l 理解傳輸模型
SOAP并不是完全透明的解決方案，它把一些復(fù)雜的實(shí)現(xiàn)細(xì)節(jié)隱藏起來(lái)。Webservice的開發(fā)者必須深入的了解SOAP，了解底層的傳輸機(jī)制以及模型,從而知道SOAP是如何實(shí)現(xiàn)的。在一些簡(jiǎn)單的應(yīng)用中，某些工具可以幫助Webservice的開發(fā)者生成SOAP消息傳遞的代碼，但是這只在最簡(jiǎn)單的應(yīng)用中有效。真正的情況不可能那么簡(jiǎn)單，可能在某些方面你需要有特殊的處理（這種情況在實(shí)際開發(fā)中是很常見的），這個(gè)時(shí)候，你就需要直接操縱SOAP的消息傳遞代碼，以及一些底層的XML內(nèi)容。因此，Webservice的開發(fā)者需要深入了解SOAP和XML層的內(nèi)容。
在開發(fā)Webservice的接口的時(shí)候，不要以為使用XML技術(shù)，協(xié)作性的問(wèn)題就迎刃而解了，XML并不是解決集成問(wèn)題的靈丹妙藥。這里同樣需要標(biāo)準(zhǔn)的制定，需要一個(gè)在業(yè)界公認(rèn)的詞匯表。僅僅在你的設(shè)計(jì)框架中引入XML技術(shù)并不能保證系統(tǒng)具有協(xié)同性，XML僅僅是用來(lái)描述數(shù)據(jù)的語(yǔ)言，XML自己并不提供語(yǔ)義去理解數(shù)據(jù)。就如同英語(yǔ)和德語(yǔ)都使用拉丁字母，但是他們的語(yǔ)義卻并不相同。
即使你使用相同的語(yǔ)言，也不能保證具有良好的協(xié)作性。比如你的公司可能使用Order描述一個(gè)訂單，但你的合作伙伴可能使用Purchase_Order，而另一個(gè)伙伴可能又不相同。你不可能強(qiáng)迫你所有的合作伙伴都采用和你相同的詞匯。因此需要有一項(xiàng)技術(shù)可以在眾多的描述之間充當(dāng)翻譯的角色。XSLT就是這么一種技術(shù)，它用于不同語(yǔ)言的轉(zhuǎn)換。和XSLT的配合使用XML才能解決協(xié)同性的問(wèn)題。
l DOM vs. SAX
許多的Webservice開發(fā)環(huán)境，將開發(fā)者從底層的XML文檔的解析和處理中解放出來(lái)，他們提供了自動(dòng)化或者很方便的工具，使得這一過(guò)程變得很簡(jiǎn)單。但是對(duì)于一些有特殊要求的Webservice應(yīng)用，比如需要更好的柔性或者對(duì)速度要求特別高的應(yīng)用，就需要手工處理XML文檔。這時(shí)候兩種XML解析的模型－DOM 和SAX的選擇，將成為重要的問(wèn)題。
DOM使用樹狀圖的方式解析XML文檔，而SAX則更多的采用事件驅(qū)動(dòng)的模型。
DOM先將XML文檔映射成一顆樹，然后通過(guò)采用一系列與樹相關(guān)的操作去處理這份文檔。這種方法有很多的好處，首先開發(fā)者很容易理解，使用一顆樹這對(duì)于開發(fā)者來(lái)說(shuō)是最常見不過(guò)的了。DOM最常用于XML在Service中需要頻繁修改的場(chǎng)合。當(dāng)然DOM也有它的缺點(diǎn)，在處理XML文檔的時(shí)候，它需要載入整個(gè)文檔，而不管你需要修改的是否只是其中的一小部分。因此它的運(yùn)行效率以及對(duì)內(nèi)存的使用顯然是不能接受的，尤其是面對(duì)很大的XML文檔。
SAX使用事件驅(qū)動(dòng)的模型來(lái)處理XML文檔。通過(guò)一系列事件的觸發(fā)，來(lái)完成對(duì)XML的解析，你可以只關(guān)心你所要處理的事件，當(dāng)這些事件發(fā)生時(shí)，會(huì)調(diào)用到相應(yīng)的回調(diào)函數(shù)來(lái)通知到你。采用這種方式就可以在很大程度上提高XML文檔解析的效率。但是它的缺點(diǎn)在于難于使用，以及對(duì)同一文檔的多次處理會(huì)存在一些問(wèn)題。
總而言之，DOM更適合處理那種文檔型的XML文件，而SAX則適于那種想直接將XML結(jié)構(gòu)映射成在你系統(tǒng)中的一個(gè)對(duì)象的操作。（比如將一個(gè)XML結(jié)構(gòu)直接映射成JAVA中的一個(gè)Class）或者那種針對(duì)XML文件中特殊Tag的操作。
l 文檔交換vs. RPC模型
這兩種交互方式應(yīng)該在應(yīng)用架構(gòu)的設(shè)計(jì)初始就應(yīng)該詳加考慮，因?yàn)樗鼘⒃诤艽蟪潭壬蠜Q定系統(tǒng)的耦合程度。
RPC（Remote Procedure Call）本質(zhì)上就是遠(yuǎn)程方法的調(diào)用。盡管Webservice是基于XML的但是你仍然可以使用遠(yuǎn)程方法調(diào)用這種模式來(lái)進(jìn)行Webservice的實(shí)現(xiàn)，尤其是在那種簡(jiǎn)單的請(qǐng)求相應(yīng)的模型中。在這個(gè)過(guò)程中，傳輸中的XML文件所描述的更多是有關(guān)遠(yuǎn)程方法的信息，比如方法名，方法參數(shù)等等。
而文檔交換方式，與RPC相比較在XML文件中不是做遠(yuǎn)程方法的映射，而是一份完整的自包含的業(yè)務(wù)文檔，當(dāng)Service端收到這份文檔后，先進(jìn)行預(yù)處理（比如詞匯的翻譯和映射），然后再構(gòu)造出返回消息。這個(gè)構(gòu)造返回消息的過(guò)程中，往往不再是簡(jiǎn)簡(jiǎn)單單的一個(gè)方法調(diào)用，而是多個(gè)對(duì)象協(xié)同完成一個(gè)事務(wù)的處理，再將結(jié)果返回。
這兩種方式的區(qū)別，類似與打電話和發(fā)郵件的不同處理方法。在目前，對(duì)于第一種方法提供了很多自動(dòng)化的工具使得遠(yuǎn)程方法的調(diào)用能夠很容易的完成，而后一種方法缺少一系列工具的支持，需要開發(fā)者手工完成。
盡管如此，在此還是推薦使用文檔交換的方式。由于它在以下方面具有RPC所不具備的優(yōu)點(diǎn)。
使用文檔方式，你可以充分利用XML文件的功能去描述和驗(yàn)證一份業(yè)務(wù)文檔，而在RPC模型中XML僅僅被用于描述方法的信息。
使用文檔方式，在客戶的Service的提供者之間不再需要緊密的約定，而RPC模型需要客戶和Service的提供者緊密相連，一旦方法發(fā)生變化，客戶端就需要做相應(yīng)的改動(dòng)。這不符合低耦合系統(tǒng)的要求，而在文檔交換方式中則靈活的多。
由于業(yè)務(wù)數(shù)據(jù)是自包含的，顯然文檔模型更利于采用異步處理。
l 利用設(shè)計(jì)模式
設(shè)計(jì)模式在設(shè)計(jì)Webservice的時(shí)候顯然可以起到相當(dāng)大的作用。設(shè)計(jì)模式的主要目的就是為解決某些在類似環(huán)境下的相像問(wèn)題提供已有的較為成熟的設(shè)計(jì)方案。在這里，只簡(jiǎn)單的提及一些很常用的模式，讓我們了解到模式在Webservice中可以起到的作用。
Adapter ：為內(nèi)部系統(tǒng)提供一個(gè)不同的接口
Fa?ade： 封裝復(fù)雜的內(nèi)部實(shí)現(xiàn)，提供一系列簡(jiǎn)單的接口
Proxy： 作為其他對(duì)象的代理，代替它提供服務(wù)
Adapter模式用于將一個(gè)組件的接口轉(zhuǎn)化成客戶所需要的樣子，這里的客戶就是Webservice。一個(gè)常見的情況就是將原有的老的系統(tǒng)包裝成一個(gè)Webservice。比如現(xiàn)在使用的是J2EE的平臺(tái)，而原來(lái)有一個(gè)C++的系統(tǒng)實(shí)現(xiàn)了某些功能，現(xiàn)在需要將它發(fā)布成Webservice，那么就需要利用JNI技術(shù)做一個(gè)Adapter，為原來(lái)的C++組件提供一個(gè)Java的接口，然后再轉(zhuǎn)化為Webservice。
Fa?ade模式用于構(gòu)建粗粒度的服務(wù)，它包裝了細(xì)粒度的服務(wù)，從而為復(fù)雜的系統(tǒng)提供了一個(gè)簡(jiǎn)單的接口。在J2EE中，Session Bean就象是一個(gè)Fa?ade，而Entity Bean則是細(xì)粒度的服務(wù)。在Webservice中也一樣，使用Fa?ade模式可以將已有的組件的功能發(fā)揮殆盡。
Proxy 模式用于充當(dāng)其他對(duì)象的代理，類似于中間人的作用，將處理工作從一個(gè)對(duì)象傳遞到另一個(gè)對(duì)象。在Webservice中，它主要用于隱藏Soap消息構(gòu)造的過(guò)程。也可以用于模擬對(duì)象（Mock Object）的創(chuàng)建。
以上僅僅是一些可以用于Webservice開發(fā)的模式，如果你熟練的將這些模式應(yīng)用于Webservice開發(fā)，你將會(huì)發(fā)現(xiàn)開發(fā)Webservice應(yīng)用，將好像做一種特殊的面向?qū)ο笤O(shè)計(jì)。
l 安全
Webservice為作為方便的服務(wù)被用廣大領(lǐng)域使用的同時(shí)，也成為了黑客們的美食。在這里，本文將就目前對(duì)Webservice安全所能做的改進(jìn)做簡(jiǎn)單介紹。
在Webservice中的安全主要分為以下三個(gè)方面。
傳輸 SSL/HTTPS 對(duì)連接加密，而不是傳輸數(shù)據(jù)
消息 數(shù)據(jù)加密(XML Encryption) 數(shù)字簽名(XML-DSIG)
底層架構(gòu) 利用應(yīng)用服務(wù)安全機(jī)制
傳輸時(shí)的安全是最容易被加入到你的Webservice應(yīng)用中的，利用現(xiàn)有的SSL 和HTTPS協(xié)議，就可以很容易的獲得連接過(guò)程中的安全。
然而這種安全實(shí)現(xiàn)方法有兩個(gè)弱點(diǎn)。一是它只能保證數(shù)據(jù)傳輸?shù)陌踩?，而不是?shù)據(jù)本身的安全，數(shù)據(jù)一旦到達(dá)某地，那么就可以被任何人所查看。而在Webservice中，一份數(shù)據(jù)可能到達(dá)多個(gè)地方，而這份數(shù)據(jù)卻不該被所有的接受者所查看。二是它提供的是要么全有要么全無(wú)的保護(hù)，你不能選擇哪部分?jǐn)?shù)據(jù)要被保護(hù)，而這種可選擇性也是在Webservice中所常要用到的。
第二層的保護(hù)是對(duì)于消息本身的保護(hù)。你可以使用已有的XML安全擴(kuò)展標(biāo)準(zhǔn)，實(shí)現(xiàn)數(shù)字簽名的功能，從而保證你的消息是來(lái)自特定方并沒有被修改過(guò)。XML文件的加密技術(shù)從更大程度上加強(qiáng)了Webservice的安全，它能夠定制數(shù)據(jù)傳輸?shù)胶?，能否被接受者所查看，進(jìn)一步完善了傳輸后的安全，業(yè)界也在不斷的制定Webservice的安全標(biāo)準(zhǔn)，比如SAML 和 WS-Security。
最后一層保護(hù)就是依靠底層架構(gòu)的安全，這更多的來(lái)自于操作系統(tǒng)和某些中間件的保護(hù)。比如在J2EE中，主持Webservice的應(yīng)用服務(wù)器。目前很多的J2EE應(yīng)用服務(wù)器都支持Java Authentication and Authorization Service (JAAS)，這是最近被加入到J2SE 1.4當(dāng)中的。利用主持Webservice的服務(wù)器，實(shí)現(xiàn)一些安全機(jī)制這是很自然的做法。另一種利用底層架構(gòu)的安全方法就是，做一個(gè)獨(dú)立的負(fù)責(zé)安全的服務(wù)器，Webservice的使用者和創(chuàng)建者都需要與之取得安全信任。
本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)
點(diǎn)擊舉報(bào)。
