軟件技術(shù)的發(fā)展是一個結(jié)構(gòu)化不斷加深的過程，我們逐漸擁有了越來越豐富的結(jié)構(gòu)識別, 表達(dá)和處理手段。在這一方向上,
組件技術(shù)最終取得了巨大的商業(yè)成功。但是區(qū)分同時也就意味著隔閡。面向?qū)ο蠹夹g(shù)最基礎(chǔ)的概念在于 O = C(O),
對象的復(fù)合(Composition)仍然是對象. 然而在越來越復(fù)雜的軟件生態(tài)環(huán)境中,這一圖景實現(xiàn)的可能性被大大的壓縮.
面對層層封裝造成的形態(tài)各異的表達(dá)方式, 不同來源, 不同目標(biāo), 不同運行環(huán)境下的信息的交互變得越來越困難。我們逐漸喪失了概念上的簡潔性,
也喪失了數(shù)學(xué)世界中的那種穿透一切的統(tǒng)一的力量. 所謂SOA（Serivce Oriented
Architecture)技術(shù)試圖通過補(bǔ)充更多的環(huán)境信息，放棄狀態(tài)關(guān)聯(lián)，暴露元知識等方式來突破現(xiàn)有的困境。 http://canonical.javaeye.com/blog/33803
這其中一項關(guān)鍵的技術(shù)抉擇是基于文本格式進(jìn)行信息表達(dá)。
在過去10年中Web技術(shù)取得了空前的成功，它造就了互聯(lián)網(wǎng)這一世界上最大的分布式集成應(yīng)用。SOA從某種程度上說是對這一事實在技術(shù)層面上的反思。基于
文本傳遞的web技術(shù)所表現(xiàn)出來的開放性，可理解性和可觀測性，與封閉的，難以直接解讀的，必須擁有大量相關(guān)知識才能正確操作的二進(jìn)制結(jié)構(gòu)相比，這本身就
是革命性的創(chuàng)新。不需要特殊的工具就可以非常輕易的察看到網(wǎng)頁程序的輸入輸出，所有交互過程都處在完全透明的檢查下，各種不曾事先規(guī)劃的文本處理手段都可
以參與到web創(chuàng)建的過程中。隨著速度，存儲不再是我們考慮的首要問題，文本化作為一種技術(shù)趨勢逐漸變得明確起來。但是任何一種技術(shù)思想的成功或失敗都不
可能是因為某種單一的原因所造成的，因此有必要對文本化的技術(shù)價值做更加細(xì)致的剖析。
1.
文本化是一定程度上的去結(jié)構(gòu)化，但是通過這種方式我們獲得了對程序結(jié)構(gòu)的更強(qiáng)的控制力。無論我們所關(guān)心的文本片斷層層嵌套在大段文本的哪個部分，我們都可
以通過text.indexOf(subStr)來實現(xiàn)定位，通過text.replace(oldStr,newStr)實現(xiàn)變換。而在組件系統(tǒng)中，我
們只有通過某種預(yù)定的遍歷方式逐步遞歸才有可能訪問到組件內(nèi)部的組成對象。如果某個組件不按照規(guī)范實現(xiàn)或者規(guī)范中缺少明確的設(shè)定，則這一信息關(guān)聯(lián)鏈條將會
斷裂。在一些組件系統(tǒng)中，甚至沒有規(guī)定一種統(tǒng)一的遍歷方式，則我們根本無法定義出通用的大范圍的結(jié)構(gòu)定位/變換手段。即使是在設(shè)計精良的組件框架中，受限
制于組件的封裝性要求，我們也不可能訪問到全部的信息。當(dāng)我們以組件設(shè)計者意料之外的方式使用這些組件的時候，就會遇到重重障礙。即使所需的只是微小的局
部調(diào)整，因為無法觸及到需要修改的部分，我們也可能被迫放棄整個組件。
2.
文本是普適的信道。各種操作系統(tǒng)，各種程序語言所具有的最基本的能力就是文本處理能力，對于文本格式的約定是最容易達(dá)成共識的。雖然對于機(jī)器而言，理解基
于地址定位的二進(jìn)制數(shù)字可能更加直接，但是所有的應(yīng)用程序都是由人來負(fù)責(zé)編制，調(diào)試，部署，維護(hù)的，如果人可以不借助特殊的工具就可以明確了解到系統(tǒng)內(nèi)發(fā)
生的過程，則系統(tǒng)的構(gòu)建和維護(hù)成本就會大幅下降。
3.
文本表述形式上的冗余性增強(qiáng)了系統(tǒng)的概念穩(wěn)定性和局部可理解性。在二進(jìn)制格式中，經(jīng)常出現(xiàn)的是根據(jù)相對地址定位，這要求我們完整理解整個二進(jìn)制結(jié)構(gòu)，才能
夠逐步定位到局部數(shù)據(jù)塊。同時，二進(jìn)制格式中也經(jīng)常使用一些外部的信息，例如某個位置處的數(shù)據(jù)為整型，占用四個字節(jié)等。這樣的信息可能只能在文檔說明里查
到，而在數(shù)據(jù)體中沒有任何的體現(xiàn)，這限制了獨立的理解可能性。與此相反，文本格式經(jīng)常是自說明式的，例如width:3.5px,
這提高了系統(tǒng)的可理解性，特別是局部可理解性。即使我們對系統(tǒng)只具有很少的知識，一般也能根據(jù)數(shù)據(jù)周圍的相關(guān)信息進(jìn)行局部操作。一般很容易就能夠定位到特
殊的局部數(shù)據(jù)區(qū)，安全的跳過眾多未知的或者不被關(guān)心的結(jié)構(gòu). 一個程序新手也可以在很短時間內(nèi)靠著連蒙帶猜,
實現(xiàn)xml格式的word文件中的書簽替換功能,而要搞清楚word的二進(jìn)制格式,并獨立編制出正確的替換功能,顯然就不是一兩周的工作量可以解決的了.
這其中, 可理解性的差異是存在著數(shù)量級上的鴻溝的.
4. xml這種半結(jié)構(gòu)化的文本格式規(guī)范的興起, 以通用的方式為文本描述引入了基本的形式約束, 實現(xiàn)了結(jié)構(gòu)表達(dá)的均一性.
C語言中的宏(Macro)本質(zhì)上就是一種文本替換技術(shù),它的威力在于沒有預(yù)定義的語義, 因此可以超越其他語法成分, 破除現(xiàn)有語法無法跨越的限制.
但是它的危險性在于缺乏與其能力相適應(yīng)的形式約束, 難以控制. 而在xml格式規(guī)范下, 不同語義,
不同抽象層面的節(jié)點可以共存在同一個形式體系中, 可以用通用的方式進(jìn)行定位,校驗, 轉(zhuǎn)換等. Witrix平臺在動態(tài)xml方面發(fā)展了一系列技術(shù),
為文本處理引入了更多應(yīng)用相關(guān)的規(guī)則, 增強(qiáng)了文本描述的抽象能力和表達(dá)能力.
5. 文本作為描述(description)而不是執(zhí)行指令(execution). C語言的源代碼與機(jī)器碼基本上是一一對應(yīng)的,
即源代碼本身所表達(dá)的就是指令的執(zhí)行過程. 而在Web應(yīng)用領(lǐng)域, HTML語言僅僅是聲明界面上需要展現(xiàn)什么,
但是如何去實現(xiàn)是由通用的解析引擎負(fù)責(zé),它并不是我們關(guān)注的重點. 描述需要結(jié)合詮釋(解釋)才能夠產(chǎn)生實際的運行效果,
才能對現(xiàn)實的物理世界產(chǎn)生影響.這在某種程度上實際上是延遲了執(zhí)行過程. 一種描述可以對應(yīng)多種詮釋,
例如同樣的元數(shù)據(jù)在前臺可以用來生成界面,在后臺可以用于生成數(shù)據(jù)庫, 進(jìn)行數(shù)據(jù)有效性校驗等. 在特定的應(yīng)用領(lǐng)域中,執(zhí)行引擎可以是通用的,
可以獨立于描述本身不斷演化, 因此一種領(lǐng)域特定的描述,它所承載的內(nèi)容并不是固化的, 而是可以隨著執(zhí)行引擎的升級不斷增強(qiáng)的. 例如,
在Witrix平臺中, FlowDSL本身所做出的流程描述是穩(wěn)定的,
但是隨著流程引擎不斷改進(jìn),不斷引入新的功能,所有使用DSL的已實現(xiàn)的應(yīng)用都同步得到升級. http://canonical.javaeye.com/blog/275015
6. Text = Process(Text) 這個不動點在Unix系統(tǒng)中得到了充分的應(yīng)用: 多個小程序通過管道(Pipe)組合在一起,
可以完成相當(dāng)復(fù)雜的功能. 一個更加豐富的處理模型是 XML = Process(XML). 文本描述很自然的支持多趟處理,
它使得我們可以充分利用全局知識(后續(xù)的處理過程可以使用前次處理過程收集的全局信息), 可以同時支持多個抽象層面(例如DSL的不斷動態(tài)展開).
Witrix平臺中的編譯期運行技術(shù)實際上就對應(yīng)于如下簡單規(guī)則: 編譯期運行產(chǎn)生文本輸出, 對輸出文本再次進(jìn)行編譯. 通過這一遞歸模式,
可以簡單的實現(xiàn)動態(tài)解析與靜態(tài)描述之間的平衡. 模板(Template)技術(shù)是具有關(guān)鍵性作用的文本生成技術(shù).
out.write("<div>");out.write(value);out.write("</div>");這種
API拼接方式顯然不如<div>${value}</div>這種模板生成方式直觀且易于使用.
在Witrix平臺的tpl模板語言中, xml的規(guī)范性使得在多趟編譯過程中我們一直可以維持某種形式約束.
7. 不是所有的情況下都應(yīng)該使用文本. 普元EOS中所鼓吹的XML總線之類的技術(shù)是我所極力反對的. http://canonical.javaeye.com/blog/33794