canonical

    地址(Address)是現代計算機體系架構中的核心概念，它在程序設計語言上的體現就是C語言中的指針(Pointer)。在C語言中，所有的高級技巧都和指針這個概念相關。指針只是一個存放了一個地址的變量，但是C語言中提供了一個方便的間接訪問方式，p->x, 它使得擁有指針在概念上就等價于擁有了指針所指的全部內容。在這種誘導下，我們漸漸模糊了地址和地址所存儲的內容之間的區別。這也是指針的指針這樣的概念總是讓初學者迷惑不解的重要原因。
    指針是對地址的符號化。它所帶來的第一大好處是使得我們擺脫了對絕對地址空間的依賴。如同Newton第一定律所闡述的：物理規律與所發生的慣性坐標系無關。同樣，數字空間中發生的的事件與所處的絕對地址也是無關的。在符號化的方向上更進一步，如果我們專注于指針的關聯語義，而放棄指針的指針這樣的混雜概念，就會得到具有獨立價值的引用(Reference)概念.
    從表面上看起來，數字空間只是一個無限延展的一維地址空間，每一地址處只能存放一個有限大小的離散數值，似乎它的幾何學是貧瘠的。但是因為在軟件設計中，一般是不考慮尋址時間的。這意味著在擁有指針的情況下，我們可以“立刻”訪問到數字空間的任意遙遠的地方。這種超時空的信息傳遞過程使得我們可以利用“引用”概念輕松的構建一個多維的表示空間。在面向對象的技術背景下，x.y.z這樣的形式表示暗示著x,y,z是同時存在的。當z發生變化的時候，通過y.z和x.y的信息傳導，x對象本身也發生了某種變化。
    隨著web技術的流行，獨立的狀態/地址空間的存在性逐漸成為系統不可回避的假設, "同時性"的物理約束越來越難以維持. 相對論規定了物理現象的定域性, 在數字空間我們一直忽視了它.但有趣的是, 網絡上的傳輸時延卻迫使我們重新發現了"引用"形式下必然存在著的物理過程. 引用本身只是標記了某種信息關聯, 并不一定意味著同時性約束. 并發編程領域的所謂的Future對象是對傳統引用概念的一種有趣擴展.
   result = obj.callMethod(args) ==>  future = obj.callMethod(args)
future對象可以被自由傳遞, 只有當實際訪問到它的屬性的時候, 才會觸發時序約束. 

    判斷和循環是程序中最基本的語句結構。而在vonNeumann體系架構下，循環是對集合進行操作所需的基本步驟。一個有趣的事實是，函數式語言所宣稱的 生產力的來源很大程度上在于集合操作的便捷性。在數學中我們通過張量分析，泛函分析等可以清楚地意識到集合之間的相互作用是可抽象的，是可以獨立理解的， 即我們可以在不涉及具體基元結構的層面上獨立的定義并執行集合運算。如何將這種概念獨立性在框架層面展開是一個非常深刻的命題。
    在基元結構上應用基礎操作p(d)這一微觀場景一般情況下是容易理解并實現的, 但通常程序中所定義的大量邊界是基于集合變量的, 因此很多代碼都是封包和解包操作, 在層層嵌套的循環結構深處我們才能發現真正具有業務價值的基元結構. 將集合操作提升到系統層，減少或簡化在應用層需要顯式編制的循環結構是框架設計層面需要考慮的問題.
    一個最基本的方法是盡量定義通用的同構操作, 避免構造中間集合. 例如前后臺之間通過json等通用協議交換復雜結構的對象, 避免定義特殊的中間處理過程. 一個與之相配合的重要技術手段是通過類查詢語句(描述方式)直接構造特定的集合. 例如prototype.js中提供的$$('div div.myclass').each(op)這樣的處理方式顯然要比在循環過程中基于特定條件過濾要方便的多. 而在AOP操作中切點的集合定義方式也是其提供的核心價值之一. 與集合操作相適應的一種代碼風格是流式設計(stream), 這正是jQuery試圖鼓吹的主要價值(雖然我個人認為它有些走極端). 流式設計的核心結構實際上是 x += dx, 它不需要集合是一次性構造的, 便于支持一種逐步部分修正的概念模型.
    為了支持集合的隱式構造, 我們需要以通用的方式定義元素到集合的組裝規則. 在Witrix平臺的前臺js框架中我們定義了由獨立的html組件到復合查詢條件的拼接規則, 定義了由每個html組件的數據校驗函數到整個form的數據校驗函數之間的組裝規則, 定義了由單個html組件提交參數到整個form提交參數之間的組裝規則. 在Witrix平臺的標準界面上, 框架本身的編制基于js.query.buildCondition(frmQuery), js.validate.validateForm(frmUpdate), ajax.addForm(frmUpdate)等少量集合操作進行, 在不同的應用場景下, 我們只需要關心每一個字段如何顯示, 提交哪些屬性, 而由系統負責將它們自動組裝并在后臺進行分派. 面向不同的應用, 框架代碼不需要做出任何修改, 確保了系統結構的可重用性.
   Witrix平臺的后臺處理模型中定義了實體化過程, DaoWebAction基于CRUD等原子操作定義了批量提交, 數據導入導出等復合的甚至是嵌套的集合操作. 在不同的應用中, 我們通過修改bizflow文件中<action id="ViewDetail-default">, <action id="Update-default">等針對單實體的業務規則即可適應不同的業務場景, 而不需要為特定的應用重復編制集合處理過程.
    面向集合+通用組裝規則是Witrix平臺設計中采用的基本設計手法之一, 它使得我們在一般應用中只需要考慮單實體,單字段等基元結構上發生的特定業務, 大大簡化了系統構造過程. 但是也需要認識到從個體到集合的擴張(p(d) -> P(D) )是非平凡的, 集合比個體的簡單加和要更多, 為此架構中需要保留對集合邊界的識別能力, 例如需要允許在數據導入完成之后執行特定的業務規則而不是僅僅針對每一數據行執行業務規則.

   由于各個公司的領域，規模，人員配備等差異很大，形形色色的公司中頂著架構師頭銜的諸般人等所從事工作的內容以及所承擔的責任也是大相徑庭。務虛者有之，務實者也有之, 難以一概而論。甚至關于架構一詞的具體含義在不同語境下也是很難達成共識的。然而作為架構師，他應該做什么，能夠做什么，卻是我在自己的職業生涯中需要加以回答的問題。
    軟件公司中的工作大致分為銷售，技術，財務，打雜這幾類。架構師所從事的工作大致上屬于技術這一攤，應該是一種高度專業化的技術工作。在我看來，一般所謂架構師的工作主要是負責設計規范整個軟件項目/產品/產品線的整體結構，他所擺弄的是各種相關的技術元素。雖然作為公司的技術利益的代表者，架構師會在某種程度上參與到公司的商業活動中（在某些巨型公司中，架構師甚至可以通過標準規范對整個產業結構施加影響），但是他更多的是接收商業需求將其轉化為技術約束，而很少是商業目標的制定者。業務架構方面的設計更理想的是由業務專家進行，這個工作多半只需要技術的常識，而不需要對于技術本身的深刻洞察。在另一方面，雖然架構師對于技術實現所需的技術/人力等資源需求會提出自己的估算和建議，但是他一般并不具備相應的手段和責任來具體管理整個實現過程。因此在我看來架構師的管理職責并不是很大。當然，有些架構師會更加接近商業和管理而遠離技術，將他們稱之為"資深架構師"可能更加合適。在某些大型系統的建設過程中，總體設計人員可以只負責收集各個子系統的技術要求，匯總后制定整體技術規范，所起的作用類似于協調人員，在這種情況下倒是對技術要求較低而對管理素質要求較高了。
    關于架構的一個有趣的事實是，技術架構本身其實很少存在設計問題。大部分問題只在于業務問題如何分解到既定的技術架構上，一般的技術架構也只是現有技術元素的簡單組合而已。所謂的架構設計工作并不是在真正的系統全景下進行，它往往是基于已有經驗所作的短暫延伸，是對業內其他類似結構的復制變形。我們所面臨的大量問題是選型問題，不是創造性問題，而是選擇性問題。架構師最富技巧性的工作不是現在確定什么，做出選擇，而是確定現在可以不確定什么，可以將哪些選擇延遲。
    在一般人看來，架構師對于系統成敗必然起著關鍵性作用，否則他們憑什么屬于“活少錢多”的那伙人呢。但真實情況是，商業上的成敗很少是由技術架構直接決定的。因為技術開放和快速傳播等原因造成了技術的趨同性，在技術層面上，大多數公司很難依靠技術形成差異化優勢。競爭優勢主要來源于業務理解和與用戶的接觸性，來自于歷史形成的業務格局。而在中國這樣一個營銷制導的商業世界中，架構師的工作更難說是在構造某種與眾不同的東西。只有少數大公司依靠把握標準才形成技術的話語權，大部分人不過是在技術的大潮中隨波逐流罷了。“不求有功，但求無過”應該是架構師基本的工作精神。技術失敗最常見的原因除了不夠專業以外（在中國，“專業”的標準也許是不同的），就是過于自信，試圖去創造些新的結構，或者試圖全面應用某種不熟悉的技術。架構建設應該是一個逐步改進的過程，不要激進盲動。
    國內的架構師多數是從高級程序員發展而來，在工作期間多半是學習掌握外部知識，以掌握知識的細節程度和廣度為優先。因為總是在別人搭好的平臺上活動，即使是參與過眾多大型系統的建設，對于系統整體結構一般也沒有提煉出自己的認識觀點。而有些大學設置了專業，宣傳培養架構師，但是實際上缺乏系統的實踐訓練，學生所學到的多半是高舉高打的套路，在實戰中的表現往往更差。掌握技術細節和自主的整體性思考對于架構師而言都是不可或缺的。
    雖然創新的技術未必是商業中核心的元素，但是真正的創造性仍然是每一個設計師的希冀。作為一名實踐者，我們都在某種程度上期望超越所經歷的偶然，達到某種普遍的真理，在外部的物質世界中留下自己的精神烙印。在這種意義下，架構師的工作便不是簡單的技術背景或者技術理解可以涵蓋的了。我相信，在業務層和基礎技術設施之間存在著物理性的厚重的通用技術層，其中存在著大量的結構規律等待我們的探索，這也正是Witrix平臺一直努力的方向。

   我們總認為認識的最高境界是認識到事物的本質。但是越明晰的認識意味著越明晰的區分，而區分意味著認識到事物的獨特性，割裂了它與普遍事實之間的聯系。我們是否會說這一本質和那一本質是本質上不同的？本質最根本的意義在于內在的規律，在于內在的協調而不是和普遍事物的對立。我們對本質的認識是如何成為可能的？現代語言哲學發掘的一個基礎事實是我們的語言中涉及到抽象事物的部分存在含混性和自我證明的邏輯循環。在抽象的概念上我們很難達到共識, 而這恰恰是通常我們認為所謂本質所寄居的地方. 語言文字是人類所創造的思維的工具，我們對它們的存在早已習以為常。只有研究詞源的時候, 我們才能清楚地意識到人們的思維和世界的現象之間的巨大鴻溝. 通過千百年的文化積淀和不斷的自我強化, 我們才形成了共同的民族心理結構, 看到同樣的文字的時候才能激發我們類似的情感, 才能引起類似的意向，但是具體的過程仍然是不可言說的.
    辯證法的兩端都能夠成為我們認識的對象，因此我們會感到矛盾對立的存在. 但是隨著我們認識方向的轉移, 很多矛盾可能被弱化,被消解. 在本世紀初, 相對論和量子論無論在理智或者情感上都是如此讓人難以接受, 但是新一代的學生接受起來已經自然了很多. 現在我們只需要盲目的遵守規則,而不再需要去尋求自我證明的解釋. 在現代物理的框架下, 慣性不是物質本身的屬性, 它來自物質之外. 萬有引力不是物質之間的額外的相互作用,而是時空扭曲后造成的內蘊約束. 但是在局部情況下, 并不妨礙我們建立一個形式系統使得這個屬性內在化。在很多時候只有偏執的認識才能引導我們穿越未知.
    中國人的認識論是整體性的，但卻不是公理化的.傳統上我們說微言大義，總試圖從真切的細節處領悟超越的真理. 這是和分析法不同的認識的途徑, 但也很難說它是歸納法. 思維中的意象是符號化的, 但是也是具體的，擁有自己的形象，并具有某種潛在的活動性。

   讀書在傳統意義上是走向精英階層的一條路徑，這種功利目的一直深刻在我們的心中。學校也是按照培養高于平均水平之上的人才而設定的。只是在如今這個人人都是大學生的時代，大學生早已不是什么“天之驕子”。缺乏可以用于創造或者交換的技能和資源，知識階層的相對貶值也在情理之中。依然持有著自己應該高于普通生活水平的錯覺，非要在面子上有所交待，負擔高于平均水準的車/房，很多時候只是徒增煩惱而已。
   讀書是獲取知識的主要途徑，即使在影音世界空前繁榮的今天，它仍然是不可替代的。不知是學生的問題，老師的問題，抑或是整個教育機制的問題，現在接觸到的很多人既沒有從學校學習到必要的知識，也沒有掌握基本的學習方法。很多人津津樂道的是某某很聰明，沒見他用功也取得好成績，某某很能來事，沒干多久就掙了大錢之類的傳聞。不勞而獲可以是一種希望，卻很難成為發生在自己身上的現實。我見過的聰明人很多，但是真正能做出一些自己的東西的人，都具備某種專注的能力，都要在某個方向上做出一般人難以達到的持久的努力，所付出的成本往往是不為人所知的。
   學習沒有捷徑，但卻是有方法的。有效的閱讀需要在一定的時間內完成，在最短的時間內獲得整體的階段性的認識。太厚或者太過艱難的書會耗盡我們的耐心。循序漸進，舉一反三，溫故知新是平凡的真理。讀書一定要做筆記, 否則所獲得的印像很快就會因為沒有物質憑依而消逝. 筆記不是抄書，而是從自己的視角重新整理并組織，一般最多兩三頁紙而已。不要糾纏在文字細節上, 而要努力把握其中的一種圖景. 物理中非常強調物理圖象的重要, 這些圖象未必是仿真的, 未必是要把事實世界中的事情復原，它們更多的是符號性的, 所指向的是一種感覺。有些人總是糾纏在什么是OOA, 什么是OOD這樣的概念區分上，但是多數時候這些區分都是毫無意義的。我們需要脫離紙面上的圖形和文字，想象它們的真實，這絕不是UML那種已經定義了的符號, 而是與世界上更多事物可以發生共鳴的某種形式. 我們所需要的是利劍迎面擊來的那一剎那間對它最直接的感受. 思考問題的時候是現在這種感覺和曾經想過或者曾經看過的其他問題的相似, 而不涉及到任何文字上嚴謹的表述. 很多書上都列出很多條規則, 但是誰能保證這些規則是完備的, 如何才能從唯一的規則實現逐步的分化, 將它們演變出來. 能不能采用自己的語言復述, 能不能找出一個特定的視角重建這些概念的關聯. 當把信息抽離到少數符號的時候, 通過空間形象思維我們有可能把握這一點. 空間優于時間, 實際上對于時間的感受我們是通過空間運動來定義的.
   現在的世界與百年之前已經是有著本質的區別，知識成為公開市場上兜售甚至免費公開的東西。在前所未有的開放中，人人都具有了創造的可能，所謂的創意早已成為我們慣常的生活，以至于一階變化已經無法稱其為真正的創造了。但另一方面，真正的思想仍然具有本質的稀缺性。原創的思想往往來自于少數人，其他人往往是在某一方向上進行衍生。現在很多人已經習慣了快餐式的文化消費，卻不知更應該去閱讀大師的原著而不是經過別人蒸餾后的轉述。原創的思想在文字中躍動，它所關注的不僅是眼前的事實，而是整個世界和當前事實之間的關聯，試圖為它尋求到真正存在的價值。
   讀書是一件有趣的事情，但是將一切都歸結于某種感官的快樂，無疑是一種過分淺薄的觀念。讀書之樂趣未必是真的愉悅的感受。
讀書不能使你更加富有,也不一定能帶給你安寧, 不一定對你的工作生活有什么幫助. 它只是Kill Time的一種方式而已. 只是相對于電視影像的強制傾銷, 游戲競技的自我沉迷, 它比較適中的維持了一定的自主性和外部性的平衡. 我常說, 讀書只是使你明白自己生活在怎樣的一個時代, 自己不是一個蒙昧的原始人. 不清楚相對論, 不知道量子力學, 不了解基因技術, 只是很遺憾的在二十一世紀走過.
  讀書也是讀書人在社會上得以自持的一種方式，因為畢竟我們還可以說：拽什么拽，沒文化，不稀的理你。

    雖然現代物理的標準表述采納了嚴密的數學語言，物理學和數學的精神還是有著深刻區別的。數學的目標在于在既定的范圍內把有限規則的推理推進到極致。物理學格物以致知，我們所了解到的永遠只是這個世界變化的部分。當一種物理機制位于我們的視野之外時，物理學將選擇直接無視它。因此物理學對數學是按需使用的，是有限理性的，總要受到所謂物理直觀的制約。再完美的物理模型也不過是在不完全信息下建立的一種完備的數學模型。當我們沿著一條推理的鏈條越走越遠的時候，一種本能的懷疑便會油然而生。

        Witrix開發平臺基于級列設計理論發展了一系列新的設計思想和軟件分解機制。并提出了一種新的Web體系架構。http://canonical.javaeye.com/blog/33824
 

Witrix架構呈"可"字形態，其中定義了三條主要的分界線:
1. 瀏覽器和服務器之間通過語義結構明晰的URL形成兩分結構。http://canonical.javaeye.com/blog/99122
2. 系統前臺至后臺存在一條預制的非侵入的信道. 它維持了一種無害的可擴展結構. 具體的說,系統從前臺js到后臺處理,對于所有$為前綴的參數是自動傳遞的,沒有識別出的層將自動把這些參數傳遞下去.系統通過這一信道實現退化過程。在 我以前的文章中曾經指出過， 每一種可退化形式都對應存在一種非侵入性的可擴展設計。http://canonical.blogdriver.com/canonical/993807.html
3. Witrix內置了對于CRUD模型的支持， 而BizFlow通過類似AOP的方法對CRUD模型進行了擴展。這使得Witrix的模型驅動部分并不是僅僅針對單表或者單實體的維護, 而是可以實現特定的業務邏輯和CRUD邏輯的混雜.

    這三條分界線分別規范了基礎狀態空間，對已有知識的重用以及面向未來的可擴展性。在這種大的宏觀結構下，Witrix應用了如下技術手段:
1. 對象化。Witrix中的Jsplet框架以對象的名義提供了對后臺的狀態和行為空間進行分解的基礎手段。 http://canonical.javaeye.com/blog/33873。Witrix 依托于Jsplet對象實現相關性的局域化, 而不需要像一般面向action的框架那樣直接訪問http session這一全局狀態空間. 前臺發送的objectName參數同時在系統的不同層面標定了WebAction響應函數, Biz配置, DataSourceMeta元數據, Hibernate實體等一系列相關概念, 使得它們構成一個統一的整體.
2. 標準化。與REST架構風格類似，DaoWebAction規范化了后臺響應事件。DaoWebAction上支持的標準事件有Query, ViewDetail,Add, Update, Remove等, 它們構成一個完整的CRUD模型。與REST不同的是，DaoWebAction提供了一個空的響應事件BizAction。它相當于是CRUD模型中的 零元操作。在BizFlow模型下，它將被擴展為一個操作子空間，從而實現對于CRUD模型的超越。而在REST模型下所有的擴展操作必須依附于一個已經 具有固定語義的Method上，例如POST. http://canonical.javaeye.com/blog/99122
3. 實體化。在Witrix中充分發掘了ORM技術的能力, 使得單一業務對象上可以聚集到某一范圍內的所有相關結構信息. http://canonical.javaeye.com/blog/111500. 同時在DaoWebAction中通過EntityFilter機制實現了單實體化過程. 這意味著前臺應用可以一次性提交多個批量操作, 后臺框架負責把它們分解為針對單個實體的一次確定性操作, 在后臺實現時只需要考慮單實體的情況即可. 一個簡單的例子是前臺提交objectEvent=Remove&id=1&id=2&id=3 , WebAction層會為每一個id對應的實體調用BizFlow中的Remove-default操作. 實體化是一個非常重要的過程, 它使我們關注的核心成為單實體, 正是因為明確了單實體作為基本的關注點, 我們才可以建立更加復雜的狀態機機制, 驅動系統狀態變化.
4. 組件化. 前臺的tpl模板和后臺的WebAction共享一個thisObj指針, 結合自定義標簽機制, 資源(js/css等)管理機制等構成可以重用的組件結構.
5. 偏置的AOP. BizFlow通過一種類似于AOP的操作對DaoWebAction提供的CRUD模型進行擴展, 使得模型的能力得到本質性的擴張. 這種AOP操作與通常意義的AOP的區別在于: 缺省行為在默認情況下發生, 除非顯式禁止. 通過這種方式, 反轉了base和extension之間的主體地位. 此外BizFlow所提供的不僅僅是行為的擴展,它同時提供了對界面的描述. 在前臺tpl頁面中通過<ds:BizViewOps/>等無參數的標簽調用來定義嵌入坐標. http://canonical.javaeye.com/blog/34941


     與傳統的J2EE相比較, Witrix表現出很多變化:
1. 不使用全局的session, 而是使用局域化的thisObj
2. 不定義service層，其功能分解到BizFlow和Handler中，它們都不負責日常的DAO操作。獨立的MDA部分負責所有的實體CRUD(Create Read Update Delete)操作。
3. 不定義頁面跳轉規則，在前臺使用拉模式直接表明跳轉目標。結合前臺stdPage對象在前臺控制跳轉目標。并可以在BizFlow中配置覆蓋的規則，這樣就可以針對不同的應用場景定義不同的跳轉規則。
4. 不是為每個模塊, 每個應用場景編制一組新的頁面,而是大多數模塊共用少數幾個標準頁面.
5. 不在與網絡無關的service層上定義權限和事務管理。Witrix架構下通過URL明確區分了系統內部和外部, 前臺訪問后臺時調用者的全部意圖是以規范化的形式表達在url中的. 因此權限和事務管理作用在WebObject上在概念上也可以認為是約束直接作用在URL上, 這與REST風格是統一的. 當然我們也可以規范service方法的命名等, 但是顯然要求一種隨意性消失是有代價的, 在URL上我們已經付出了代價,為什么要在service上再付出一次. Witrix中Transaction和Auth的配置更加直觀, 因為規范化了WebObject上的事件響應函數,一般我們也不需要進行特殊的配置. Witrix這種設計更加適合于網絡這一兩分結構的，更加充分的利用這一架構邊界所提供的隔離性.
6. 不在頁面中使用實體的字段名，而是大量通過元數據表達程序意圖。http://canonical.javaeye.com/blog/114066

   一般J2EE多層架構下，所謂的架構分解主要是對程序縱向的分解，但是程序結構方面是沒有橫向分解的。而witrix架構的一個核心就是橫向存在著 CRUD模型和Biz的分解。在系統的所有實現過程中，所有CRUD操作都剝離到MDA模型中，而不需要任何代碼編制。典型的, witrix后臺代碼一般寫在handler中，命名為handler而不是service是因為handler中負責的內容和j2ee傳統上的 service有所不同，一般service總是要負責某個實體的CRUD操作，大量的findxxx代碼。一般提倡的最佳實踐是實現某個通用的基類，所 有service都繼承該基類獲得CRUD能力。但是在Witrix架構中，根本沒有這一需要。Handler只要完成自己特定的功能，它不追求操作概念 在其本身的完整性。沒有CRUD, handler沒有意義。但是handler之所以有意義是因為它提供了CRUD之外的操作。當CRUD成為系統一種自動進行的背景操作時，我們不再需要 明確意識到它的存在。
    我們需要認識到我們最終所需要的東西可能不是規整結構的, 它可能要求對于某個規整結構進行剪裁并增補附加元素. 但是這樣的規整結構不應只存在于我們的想象之中，相應的剪裁過程應該是可以增量進行, 反復進行的. 在Witrix平臺中， 基本的一種圖景變化是: Witrix中不再需要從頭開始構造結構, 而只要指定當前業務和背景模型之間的差異部分. 在Witrix中所寫的業務代碼是對核心模型的擴展。這不僅僅是概念上的，而是實際體系架構上精確的體現。CRUD作為獨立的模型吸收了系統中大量的變 化。整個模型內核是采用通用方式借助meta實現功能，并不涉及到特定于業務的類。對于那些我們已經掌握的知識, Witrix提供了超越對象繼承,AOP和組件重用的結構抽取手段, 使得知識可以穩步積累.
      數學中存在兩種基本的分解方式， 一種是加性分解 (a,b) + (c, d) => (a,b,c,d)， 另一種是乘性分解 (a,b) X (c, d) => (ac,bc,ad,bd)， 它也對應于張量(Tensor)運算. 在群論(Group Theory)中，直積對于復雜性的化簡至關重要，它的重要性要遠在加和之上。實際上AOP操作類似于直積分解， 只是它的能力尚未得到充分的探索。 在Witrix中，biz的作用在感覺上很象是陪集(coset)運算：CURD * biz。不同的biz作用到同樣的CRUD模型上產生不同的操作集合，而所有biz組成的集合構成獨立的整體。   
      Witrix平臺中作為內核的MDA部分首先是物理模型驅動, 而不是邏輯模型或者對象模型驅動. 我們通過在物理模型上標注的方法恢復部分對象模型的信息, 但是我們并不試圖把整個軟件建立為模型. 所建立的僅僅是整個程序模型的內核. http://canonical.javaeye.com/blog/29412 一般業內鼓吹的所謂MDA成功的關鍵是要提高抽象層次。 但是陪集是更抽象嗎。 正規子群更抽象嗎。 它們只是系統的指標性表征，使對信息的distill, 是更容易理解的一個側面而已, 抽象性并不是一個真正的目標。很多時候我們需要的是把系統降維到某個子空間中，形成一種可控性。 但是這個子空間并不一定是更抽象的。
      群作為基本的代數系，一個本質特征是具有逆元。Witrix的MDA中明確定義了逆元結構，即界面上的元素 empty = buttonA + (-buttonA)，這一分解公式應用到后臺 OpA = Update * (-Update)  * OpA。假設我們已經建立了結構X, 現在需要建立一個與X略有不同的結構Y
       X = a + b + c
       Y = a + d + c = (a + b + c) - b + d = X - b + d
雖然Y的兩種構造方式在數學上是等價的， 但在物理上并不等價。第一種方式對原有系統進行分解后再組裝，而第二種方式沒有打破原有的東西，不需要拆分。拆分總是可能存在問題的，正如你把所有電腦零 件拆裝下來再裝上很可能會發現多出幾個零件。一般情況下第二種方式的構建成本要低. 特別是當一切都糾纏在一起的時候, 一種細粒度的逆元結構對于一種試圖重用的結構是非常關鍵的. 可重用性的障礙不僅僅是來自于無法追加新的功能，很多時候也在于無法屏蔽原先已經提供的功能。目前所有的設計原則都未能適時識別出逆元的重要性。所有的設 計教條其實所指的方向都是加和, 如何分解出更小的組元, 如何把它們加和在一起, 如何從細部開始進行重新構建, 而不是說依賴于現有已經形成的宏觀結構, 如何進行細粒度的調整. 所謂的AOP技術思考的關鍵點也在于如何給系統增加功能, 很少有人想到場景是為系統減少功能并把這種概念大規模正式應用的, 雖然說AOP已經在某種程度上具有了這種能力, 但是真正應用它仍然需要對AOP進行進一步的詮釋. 當然，現在的軟件業連基本結構的構造問題都沒有完全搞清楚, 更別提所謂結構穩定性的問題了.
     從物理上說，Y = X - b + d的分解方式具有特殊的意味。如果沒有逆元，我們必然需要分解。但是如果發掘了背景這一概念，在逆元運算下，對背景不是分解讓其成為可見的部分，而是采用 追加的，增刪的方法對背景結構進行修正，則我們有可能在沒有完整背景知識的情況下，獨立的理解局部變化的結構。即背景是透明的，知識成為局部的。      
    Witrix試圖提供的一種圖景是永遠只寫代碼片斷，而所有的代碼片斷組合在一起又構成一個可理解的整體。這個整體可以獨立理解，不需要額外的結構元素。 Witrix架構所追求的是在不完全信息下建模，不進行整體建模。整體模型 + 不斷變化的局部修正 構成 最終模型。平臺技術的目標是讓一切應該發生的自動發生，讓一切不該發生的無法發生。這一模型的構建并不是trivial的，在概念和實現方面都要作出很多 的努力。
     
題外：
     今天中午參加同學的婚禮, 席間和一個與同方有些淵源的同學談到ezOne的現狀, 大致的評語是: 垃圾, 自己人也不用. 聽來也讓人有些感嘆. 中國原創的技術總是欺騙的代名詞,  這一斷言不應總是得到證實.

  建筑學的隱喻在軟件業中一直很流行。開發軟件和建筑樓房從某種意義上說都是一種構造過程，而建筑學的成熟無疑讓很多軟件工程師非常羨慕。Design Pattern的始作俑者坦承受到建筑學著作的影響更是讓一些人對建筑學的精深頂禮膜拜不已。不過，建筑決不只是表面上的形象/功能設計，也決不是民工就可以干的活計，在現代建筑設計背后是土木工程的蓬勃發展。正是框架結構的出現和材料工藝的進步才使得批量生產的大型現代建筑成為可能。
  雖然建筑學有著它不為人知的復雜性的一面，但是與軟件開發相比，它也有著簡單貧瘠的一面。現在架構師言必稱設計模式，但是估計很少有人讀過Christopher Alexander的原著"A Pattern Language"。在Alexander的概念中，所謂的模式"describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". 關鍵在于這些模式在建筑學中往往映射為某種獨立的原子化的實體(entity), 因此可以把它們作為一種語言的基礎組分，構成所謂的Pattern Language. 例如現在要開發一個門廊，你可以從"私家的沿街露臺(140)"開始，在"有陽光的地方(161)"做成一個"有圍合的戶外小空間(163)", 選擇"6英尺深的陽臺(167)", 保留"小路和標志物(120)", 注意"天花高度變化(190)"和"角柱(212)"的位置，在"各式座椅(251)"的旁邊安排一個"高花臺(245)". Alexander共定義了253個模式，括號中的便是模式的編號。很明顯，物理空間的不可重入性直接規范了建筑設計空間的有限性。
  在軟件設計中，類似VB/Delphi的可視化界面設計的操作過程與此類似：理想情況下界面開發基本就是用各種界面元素填滿一個Form的過程。但是軟件的一個本質復雜性在于它的基本結構單元是函數，而設計空間中同一個功能點對應的實現函數的個數和形式并不存在有限性的約束，函數的組合形式也不是線性延展的。建筑基本上依賴的是靜力學，而軟件無疑需要用動力學來刻畫。即使是界面開發，我們所關注的也決不僅僅是靜態擺放問題，而更重要的往往是界面元素動態相關和動態變化的問題。
  在Web開發領域，一直有人鼓吹模仿VB/Delphi的快速開發工具，但是我并不認為這其中的設計哲學是與軟件的本質相匹配的。軟件中所蘊含的無限的動態變化不應該僅僅通過有限的配置過程來應對，我們需要更加強大的結構抽象和結構構建手段。

    程序中大量的工作其實都是在定義結構以及結構之間的關系. 一般情況下我們應該識別出結構,并把它們封裝到函數,對象和組件中去. 但是封裝并不永遠都是有利的. 將某個結構獨立出來, 在某種程度上也就割裂了它和其他元素之間的關系, 這會引發結構融合的障礙, 也會造成思維上的負擔. 事實上如果程序整體具有足夠的可理解性和概念穩定性, 我們并不需要獨立識別出什么子部分. 一個簡單的例子是數組循環. 一般情況下我們應該盡量把循環查找等操作封裝到函數中, 避免多重循環嵌套時產生過于復雜的代碼塊. 但是如果數組或者語言本身提供了each, map等函數式操作符,則這種封裝需求就大大減弱了.
    隨著系統結構的日益復雜化, 在系統中會積累大量的背景知識.此時當我們需要完成一個功能的的時候, 往往不再需要指定所有的信息, 而只需要指定背景知識之外的部分信息即可. 例如在界面上通過一個分頁表格來顯示實體列表這樣一個功能, 在Witrix平臺中通過模型驅動的標準頁面即可自動完成. 一般的定制需求往往是過濾顯示部分數據, 在表格行上增加一些操作按鈕, 定制表格的表頭等. Witrix平臺實現這些需求并不需要封裝出一個獨立的表格組件, 調用它的屬性修改方法等, 而是把定制部分嵌入到BizFlow的配置中, 這里并沒有明確的結構界限.
  <biz id="default">
    <filter>
       <eq name="status" value="1" />
    <filter>
     <tpls>
        <tpl id="thead>
         <thead>
          <tr rowspan="2">...</tr>
          <tr>...</tr>
         </thead>
        </tpl>
        <tpl id="rowOps">
          <ui:FlatButton .../>
        </tpl>
     </tpls>
      其他與表格無關的信息
  </biz>
  注意到對于我們理解業務而言, 我們并不需要知道表格具有分頁, 排序, 隔行變色等功能. 所有和業務相關的代碼聚集到BizFlow文件中, 它們構成一個可以獨立理解的整體, 在此過程中也通過背景知識實現了大量結構的消解.

   傳統上報表引擎主要完成兩項工作：結構描述和結構轉換。一般報表設計人員通過可視化設計工具完成對報表結構的描述，然后報表引擎根據這些描述生成不同格式的報表文件，如PDF格式，XLS格式等。這一圖景中報表設計工具扮演著關鍵角色，因為它不僅僅是向用戶提供一個直觀的界面，更重要的是配置過程本身就是一種分步驟的結構構造過程。理想的情況是用戶指定報表中具體有哪些單元格，表格具體有哪些列，而在運行期報表引擎負責向單元格中填充數據。但是對于設計期只能進行動態描述，無法預先確定所有結構元素的報表（例如交叉表的列只能在執行時確定），這種報表模型就會出現問題。一般處理方式都是在報表引擎中內置所有可能的動態報表模型。無論設計工具多么復雜，其內置的原理如果是基于靜態結構模型，就無法建立一種抽象機制，這樣我們就只能通過重復勞動來應對眾多結構類似但是略有不同的報表。
   Witrix平臺的報表引擎是對程序友好的，它引入了編譯期結構運算，在報表編譯時可以通過程序吸收大部分結構差異性。在Witrix平臺中，報表制作分為三個階段：設計期 -> 編譯期 -> 運行期。報表引擎負責完成三種工作：結構描述，結構生成和結構轉換。具體實現動態結構生成的過程其實非常簡單。目前所有的Witrix配置文件都通過基礎配置引擎進行解析，它定義了統一的dynamic和extends元機制。
   <report dynamic="true">
定義了dynamic="true"的報表定義文件首先作為tpl模板文件來運行，其運行結果再作為報表格式解析。在這種模型下，報表引擎并沒有內置如何把動態結構拼接出來的知識，這些知識存在于編譯期，而tpl標簽的抽象能力使得我們可以把復雜的報表結構生成過程抽象成簡單的標簽調用形式。
   <report dynamic="true">
      <body>
        <table>
         <thead>
            <c:forEach var="_h" items="${cols}">
             ....
        </table>
      </body>
   </report>

==>
   <report dynamic="true">
      <body>
         <rpt:GenCrossTable tableMeta="${tableMeta}" loopVar="tableData" />
      </body>
   </report>

   在編譯期通過tpl封裝可以解決大部分結構生成問題，在運行期報表引擎主要負責的結構問題就簡化為數據行展開和單元格合并等確定操作。
   Witrix報表引擎的另一個特點是運行期結構生成過程和結構轉換過程同時進行，因此不需要在內存中構造一個完整的報表數據對象，大大減輕了內存壓力。Witrix報表引擎輸出的文件格式目前有html, XML格式的Word文件和XML格式的Excel文件等。每一種輸出格式相當于定義了一種渲染模型，它們都是對報表模型的一種展現方式。從某種程度上說這些模型的結構都是等價的，但是完成模型轉換所需要的操作往往不是局域化的。例如在html的table中某一單元格具體對應哪一列是受到其他單元格的rowspan和colspan屬性影響的, 在Excel中則需要明確指定列的index屬性。為了簡化運行期邏輯，內置的報表模型必須提供一些冗余結構，從而兼容多種渲染模型。