哎諍

????其實仔細分析我們開發的各種軟件，其實質可以說都是以一定的控制邏輯進行某種數據處理的過程，而數據處理不免涉及到數據的交互問題，一個系統內部當然需要進行數據交互，不同的系統之間也需要進行數據交互，否則就成了一個個的信息孤島，以下就是分析不同的系統間數據交互的幾種典型方式，以及演變過程。
??? 最早也是最通用的一種方式，就是通過文件方式進行系統間數據交互，通過定義好文件交互的格式，使雙方的系統都能識別，來滿足交互的要求。這種方式雖然很古老，但確實相當有用，不少的系統都是這么干的，而且這種方式有一個很大的好處，就是可以在異構系統間進行交互，甚至跨越平臺的限制。不同的平臺間通過文件交互的話，由于無法直接進行文件共享，所以通常采用FTP進行文件交互，但是這會帶來一個問題，文件需要以阻塞方式進行讀寫，否則會引起沖突或者丟失。
??? 文件交互方式最大的缺點，就是交互不夠實時，很難應付同步數據交互，socket方式的出現解決了這個問題，s ocket方式更準確的說應該是一種通信協議，不過確實可以用于數據交互，通過在雙方系統指定IP和Port的套接字上進行數據傳輸。這種方式也是需要系統雙方自己定義交互格式，而且是以字節的方式進行定義，發送方需要將數據組織成指定的socket報文，接收方又需要根據報文格式，進行相應的解析，才能轉到相應的處理，這也是socket方式最大問題，實現起來相當繁瑣。
??? 在socket基礎上，引入成熟的HTTP、UDP等通信協議，作為數據交互的基礎，利用這些協議的特點，定義交互格式相對就簡單多了，無須糾纏于字節長度，只要按照通用的http報文格式組織數據即可。不過郁于通信層交互方式的特點，還是需要接受方先解析數據后，再轉向自己的內部流程進行處理，那有沒有一種機制，就是支持一個系統能夠直接調用另一個系統提供的方法呢。
??? 這就是RPC--遠程過程調用機制出現的原因，通過RPC一個系統能夠直接調用另一個系統提供的方法，其核心就是將數據交互從通信層上身到表示層，讓使用者無須關心具體的通信實現。最早的實現方式就是CORBA，然后是微軟的COM/COM+機制。前幾年ASP流行的時候，就曾經有一種很經典的開發模式:ASP+COM+數據庫，在COM中實現對數據庫的訪問，以及邏輯控制，然后在ASP頁面中調用COM提供的方法，這種方式在安全性和可重用性上有明顯的提高。
??? 當JAVA時代到來后，當然不會忘記RPC機制，早先是RMI-遠程調用接口，然后隨著J2EE規范的成熟，其EJB技術也是大行其道，不過RMI和EJB都有一個顯著的缺陷，只能在JAVA構建的應用系統間進行數據交互，對于非JAVA系統則無法使用了。
??? 因此早兩年java開始推出WebSevices機制，引入服務方和客戶方的概念，通過標準的服務發布方式，以及標準的調用方式，使得在異構系統間進行實時的數據交互不再有問題，其底層的通信方式還是采用的HTTP協議。
??? 關于WebServices的具體內容參見4月17日的描述。