從OLE到SOA,SOA其實很簡單!

阿三看到一個非常有興趣的網頁,想把它儲存下來,於是,阿三點擊"檔案->另存新檔",選擇"網頁,全部(*.htm,*.html)".

OK,阿三的硬碟上多了一個a.html檔案和一個a檔案夾,裡面儲存了這個網頁上的所有資源,圖片,css,js一大堆.

阿三看著這一大堆檔案,想整理又不太方便,於是阿三打電話給Axman,"大哥,我能不能把當前網頁儲存為一個檔案又能顯示

原來的效果啊?"

Axman暈了半天,沒敢吱聲,心想這世上竟然有人能笨到這樣,也算沒白活了.但沒敢說出來,因為Axman欠了阿三幾萬塊錢,所以

阿三再笨,一有問題Axman就會馬上就會給他解答.於是Axman那種冷豔的來自於原古冰河紀的聲音在電話另一端響起:

"阿三啊,你應該這樣,檔案->另存新檔,選擇Web檔案,單一檔案(*.mht),這樣就會存為一個複合文檔".

"啊,大哥,原來這樣啊,複合文檔是不是就是多種格式的文檔被壓在一起的啊?"

"是啊,這樣瀏覽器解釋時就可以把複合文檔分解開來重新顯示".

"啊,我知道了,Word也是這樣".

"轟!",Axman暈倒時,激起千重浪~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"那叫結構化文檔,算了跟你說你也不懂."

邊上Axman養了多年的浣熊多多不停地跳來跳去,這傢伙的聰靈程度不可小視,幾年下來寫個小程式已經不在話下,加上聰明好學,對什麼都

非常好奇,深得Axman的寵愛.

多多聽了阿三和Axman的對話,不住好奇地問道:"主人,什麼是複合文檔,什麼是結構話文檔呢"?

Axman換了一種慈祥的語氣,緩緩道來.......

複合文檔就是在一個文檔中以設定的boundary來分隔多個文檔,不同類型的文檔在以boundary為分隔字元的地區內以特定方式編碼為可視

的文字檔,在應用程式解釋複合文檔時再根據boundary和編碼規則還原成多種文檔然後由同一應用程式解釋.

但是複合文檔有一個缺點就是不能被多個應用程式同時開啟,而且一般而言可寫性極差,因為事實上它是被編碼後以文本形式順序儲存的,

所以當一個應用將該檔載入記憶體後,如果其它應用程式再重寫其中的內容,兩個應用程式訪問的內容就會發生衝突.

而結構化文檔從儲存模型上而言,類似於目錄形式,在目錄中可以有子目錄和檔案,在結構化文檔中叫子儲存和流.這種儲存形式最大的好處

就是不同應用程式可以同時訪問同一結構化文檔的不同部分,就象訪問同一個檔案系統中不同目錄下的檔案一樣不會發生任何衝突.

多多聽得似懂非懂,眨眨眼睛又問:那它和您要說的OLE有什麼聯絡呢?

結構化文檔的概念才會有後來的OLE的出現,在此基礎才有組件,從local CALL到RPC,到SOA,這些技術的出現都因為有解決結構化文檔

的初衷.MS office在這個曆史發展中起著不可磨滅的偉大作用.

最先,MS的一批牛人開發了MS WORD這個東西,它的功能性和易用性一下子把中國流行了十多年的WPS踢出了峨眉山頂,關且從此再也沒

有爬起來過.這批牛人不僅有牛的技術,更有牛的理念,這一點WPS連提鞋的水平都不能比.他們在設計出WORD的同時,還同時設計出excel,

powerpoint等office套件,最關鍵的是,他們成功地解決了在套件中每個應用程式之間的功能調用.

比如在一個word文檔中,如果要插入excel表格,一般人的思想就是把試算表的邏輯COPY到WORD中,也就是解釋Wrod中必須有解釋電子

表格的功能代碼.但MS的牛人們並沒有這麼做,而是利用結構化文檔的功能將試算表存為doc檔案中的一個子儲存,並在其中儲存了用什麼

應用程式來解釋的一段編碼,在windows中csid,根據它就能從註冊表中找到要解釋這個子儲存中的流的應用程式.這樣其實結構化文檔可以

儲存任何其它應用程式能處理的內容.

這樣,具有單一功能的"組件"(這時還沒有叫組件,但我現在就提前用組件這個詞,因為當前叫什麼我也不知道),就可以被其它應用程式多次重複

地調用,使單個組件能夠組成具有複雜功能的系統.MS的牛人開始把多個應用不斷地用local CALL方式調用其它組件的模型修改成元件服務

模型,即把有某個功能的組件發布成服務,其它應用程式要調用組件的功能,只要向這個系統服務提供相應的參數就行了,而應用程式本身根本

不必關心它所儲存和訪問的子儲存是什麼內容,以及如何處理.要做的是僅僅向組件提供基礎的存諸訪問API環境即基礎輸入輸出.組件自身就

可以完全處理應用程式指定要處理的內容.

雖然OLE最後被發展成COM,COM+,REMOTING,但最初它確實是為瞭解決office套件中功能的互調用的.把功能相對完善,穩定且被多次訪問

的部分獨立出來發布為服務.加上對服務訪問的協議和控制,就演變成了組件模式.

組件模型的改變功能的調用邊界從的locall API CALL變成了異構訪問.舉個最簡單的例子,作業系統命令如果單單實現一段程式,那麼它只能被

以API方式去連結,但系統命令通過shell這個容器被發布成了一個服務,那麼它在系統中可就以被多種能進行shell調用的程式設計語言所調用.而完成

相同的功能,實上這就是弱化模型的元件服務.

多多忍不住拍手稱讚,太好了,太好了,這樣以後大家都方便了.

Axman摸了摸多多的頭:"多多,你太善良了,事實並不象你想的那樣."

這世界就是如此,任何事情都具有相對性,人類社會中,有些人本來就是一個P(person),但一旦給了他們一個特定的名稱,比如把他們叫官員時,讓他

們提供相應的服務就不是尋麼容易的事了.

"組件"本質上只是完成些特定功能的代碼,但現在它的位置升到了組件,要想讓它服務,你就要遵循一定的協議,這些協議規定了訪問組件的很多介面.

在MS這個領土上,即使是MS家族的貴族成員VC/VB要訪問這些組件也要通過IUnknow,IDispatch這些介面,加上令有頭暈的UUID之類不是人能理解

的參數之類複雜的關係和手續才能讓"組件"為你服務.在java領土上你通過複雜的EJB訪問協議來讓組件為你服務.其複雜程度不是你能想象的.比如

我上次要去交480塊錢的車船稅,卻要以請一天假(扣掉1500大洋)的代價來向通州地稅這個組件請求服務,因為這個組件周末不上班.

後來組件調用者不樂意了,他們向"組織"提意見了,要求提供功能的組件應該有統一的方便的調用介面,我們只要向這個介面提供足夠的資訊,組件就

應該提供服務,這些介面不能耦合於某一特定環境,能接受外國人,本地人這些不同類型的人的相同請求.於是"組織"讓組件們把自己封裝成WEB服務.

任何調用者只要通過http連結髮送定義好的文檔,組件就提供服務.組織發現有一種叫SOAP的東西正好能完成這樣的通訊,而不同國家不同種類的

調用者也樂意使用這樣協議,於是大家都過統一的WEB服務模型來向請求服務,至於他是如何提供服務的調用者並不關心,這下一來確實方便多了.

 

SOA從本質上並不複雜,它只是組件調用方式網路化的一種設計思想,並不是指具體的實現技術.在此之前已經很多"概念"實現了這個功能,把一定功能的

組件加上網路的功能,這可以把調用的邊界從同一機器擴充到機器間調用,這從設計上其實擴大通用的功能共用範圍.加上調用協議的控制使調用更新方

便靈活.這種"方便為民的思想"確實不僅給調用者帶來方便,而且給服務提供者也帶來了方便,同一套組件作為WEB服務方式發布可以為所有能訪問該

WEB伺服器的人提供服務(這裡不涉及安全討論),從"組織"的觀點看提了機構的工作效率,而且得到調用者的好評,於是"組織"把這種模式提高為"為人民服務"

的思想,英文名就叫"SOA".我們以前設計系統是以功能為著眼點,使用者要什麼我們就給什麼,現在,我們以服務為主,我們有很多專業的服務隊伍發布在多個

伺服器上,當你需要服務時就來訪問我們.這就是SOA的本質.

Axman回頭看了看多多,多多已經流著口水要打酣了......................

 

幾句重要的話:

SOA是一種設計思想,Web Service是SOA的一種實現手段.(意味著你可以不用Web Service來實現SOA,只要你的架構符合SOA思想)

SOA不是靈丹妙藥,不是所有系統架構都適合SOA的,比如無遠程調用和分布式應用的案頭應用系統,這樣的系統使用SOA的唯一好處就是讓你的系統變慢.

SOA是早已存在的思想,只是近來又被一些廠商拿出來封裝一下,所以它是經濟產物而不是技術產物.