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çade： 封裝複雜的內部實現，提供一系列簡單的接口
Proxy： 作爲其他對象的代理，代替它提供服務
Adapter模式用於將一個組件的接口轉化成客戶所需要的樣子，這裏的客戶就是Webservice。一個常見的情況就是將原有的老的系統包裝成一個Webservice。比如現在使用的是J2EE的平臺，而原來有一個C++的系統實現了某些功能，現在需要將它發佈成Webservice，那麼就需要利用JNI技術做一個Adapter，爲原來的C++組件提供一個Java的接口，然後再轉化爲Webservice。
Façade模式用於構建粗粒度的服務，它包裝了細粒度的服務，從而爲複雜的系統提供了一個簡單的接口。在J2EE中，Session
Bean就象是一個Façade，而Entity
Bean則是細粒度的服務。在Webservice中也一樣，使用Façade模式可以將已有的組件的功能發揮殆盡。
Proxy
模式用於充當其他對象的代理，類似於中間人的作用，將處理工作從一個對象傳遞到另一個對象。在Webservice中，它主要用於隱藏Soap消息構造的過程。也可以用於模擬對象（Mock
Object）的創建。
以上僅僅是一些可以用於Webservice開發的模式，如果你熟練的將這些模式應用於Webservice開發，你將會發現開發Webservice應用，將好像做一種特殊的面向對象設計。
l 安全
Webservice爲作爲方便的服務被用廣大領域使用的同時，也成爲了黑客們的美食。在這裏，本文將就目前對Webservice安全所能做的改進做簡單介紹。
在Webservice中的安全主要分爲以下三個方面。
傳輸 SSL/HTTPS 對連接加密，而不是傳輸數據
消息 數據加密(XML Encryption) 數字簽名(XML-DSIG)
底層架構 利用應用服務安全機制
傳輸時的安全是最容易被加入到你的Webservice應用中的，利用現有的SSL 和HTTPS協議，就可以很容易的獲得連接過程中的安全。
然而這種安全實現方法有兩個弱點。一是它只能保證數據傳輸的安全，而不是數據本身的安全，數據一旦到達某地，那麼就可以被任何人所查看。而在
Webservice中，一份數據可能到達多個地方，而這份數據卻不該被所有的接受者所查看。二是它提供的是要麼全有要麼全無的保護，你不能選擇哪部分數據要被保護，而這種可選擇性也是在Webservice中所常要用到的。
第二層的保護是對於消息本身的保護。你可以使用已有的XML安全擴展標準，實現數字簽名的功能，從而保證你的消息是來自特定方並沒有被修改過。
XML文件的加密技術從更大程度上加強了Webservice的安全，它能夠定製數據傳輸到後，能否被接受者所查看，進一步完善了傳輸後的安全，業界也在不斷的制定Webservice的安全標準，比如SAML
和 WS-Security。
最後一層保護就是依靠底層架構的安全，這更多的來自於操作系統和某些中間件的保護。比如在J2EE中，主持Webservice的應用服務器。目前很多的J2EE應用服務器都支持Java
Authentication and Authorization Service (JAAS)，這是最近被加入到J2SE
1.4當中的。利用主持Webservice的服務器，實現一些安全機制這是很自然的做法。另一種利用底層架構的安全方法就是，做一個獨立的負責安全的服務器，Webservice的使用者和創建者都需要與之取得安全信任。
推薦資料
Web Services
Security
