canonical

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

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

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


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

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