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