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的使用者和創建者都需要與之取得安全信任。
推薦資料