哎諍

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