Witrix開(kāi)發(fā)平臺(tái)基于級(jí)列設(shè)計(jì)理論發(fā)展了一系列新的設(shè)計(jì)思想和軟件分解機(jī)制。并提出了一種新的Web體系架構(gòu)。
http://canonical.javaeye.com/blog/33824 Witrix架構(gòu)呈"可"字形態(tài)，其中定義了三條主要的分界線:
1. 瀏覽器和服務(wù)器之間通過(guò)語(yǔ)義結(jié)構(gòu)明晰的URL形成兩分結(jié)構(gòu)。
http://canonical.javaeye.com/blog/991222. 系統(tǒng)前臺(tái)至后臺(tái)存在一條預(yù)制的非侵入的信道. 它維持了一種無(wú)害的可擴(kuò)展結(jié)構(gòu). 具體的說(shuō),系統(tǒng)從前臺(tái)js到后臺(tái)處理,對(duì)于所有$為前綴的參數(shù)是自動(dòng)傳遞的,沒(méi)有識(shí)別出的層將自動(dòng)把這些參數(shù)傳遞下去.系統(tǒng)通過(guò)這一信道實(shí)現(xiàn)退化過(guò)程。在我以前的文章中曾經(jīng)指出過(guò)， 每一種可退化形式都對(duì)應(yīng)存在一種非侵入性的可擴(kuò)展設(shè)計(jì)。
http://canonical.blogdriver.com/canonical/993807.html3. Witrix內(nèi)置了對(duì)于CRUD模型的支持， 而B(niǎo)izFlow通過(guò)類(lèi)似AOP的方法對(duì)CRUD模型進(jìn)行了擴(kuò)展。這使得Witrix的模型驅(qū)動(dòng)部分并不是僅僅針對(duì)單表或者單實(shí)體的維護(hù), 而是可以實(shí)現(xiàn)特定的業(yè)務(wù)邏輯和CRUD邏輯的混雜.
這三條分界線分別規(guī)范了基礎(chǔ)狀態(tài)空間，對(duì)已有知識(shí)的重用以及面向未來(lái)的可擴(kuò)展性。在這種大的宏觀結(jié)構(gòu)下，Witrix應(yīng)用了如下技術(shù)手段:
1. 對(duì)象化。Witrix中的Jsplet框架以對(duì)象的名義提供了對(duì)后臺(tái)的狀態(tài)和行為空間進(jìn)行分解的基礎(chǔ)手段。
http://canonical.javaeye.com/blog/33873。Witrix 依托于Jsplet對(duì)象實(shí)現(xiàn)相關(guān)性的局域化, 而不需要像一般面向action的框架那樣直接訪問(wèn)http session這一全局狀態(tài)空間. 前臺(tái)發(fā)送的objectName參數(shù)同時(shí)在系統(tǒng)的不同層面標(biāo)定了WebAction響應(yīng)函數(shù), Biz配置, DataSourceMeta元數(shù)據(jù), Hibernate實(shí)體等一系列相關(guān)概念, 使得它們構(gòu)成一個(gè)統(tǒng)一的整體.
2. 標(biāo)準(zhǔn)化。與REST架構(gòu)風(fēng)格類(lèi)似，DaoWebAction規(guī)范化了后臺(tái)響應(yīng)事件。DaoWebAction上支持的標(biāo)準(zhǔn)事件有Query, ViewDetail,Add, Update, Remove等, 它們構(gòu)成一個(gè)完整的CRUD模型。與REST不同的是，DaoWebAction提供了一個(gè)空的響應(yīng)事件BizAction。它相當(dāng)于是CRUD模型中的零元操作。在BizFlow模型下，它將被擴(kuò)展為一個(gè)操作子空間，從而實(shí)現(xiàn)對(duì)于CRUD模型的超越。而在REST模型下所有的擴(kuò)展操作必須依附于一個(gè)已經(jīng)具有固定語(yǔ)義的Method上，例如POST.
http://canonical.javaeye.com/blog/991223. 實(shí)體化。在Witrix中充分發(fā)掘了ORM技術(shù)的能力, 使得單一業(yè)務(wù)對(duì)象上可以聚集到某一范圍內(nèi)的所有相關(guān)結(jié)構(gòu)信息.
http://canonical.javaeye.com/blog/111500. 同時(shí)在DaoWebAction中通過(guò)EntityFilter機(jī)制實(shí)現(xiàn)了單實(shí)體化過(guò)程. 這意味著前臺(tái)應(yīng)用可以一次性提交多個(gè)批量操作, 后臺(tái)框架負(fù)責(zé)把它們分解為針對(duì)單個(gè)實(shí)體的一次確定性操作, 在后臺(tái)實(shí)現(xiàn)時(shí)只需要考慮單實(shí)體的情況即可. 一個(gè)簡(jiǎn)單的例子是前臺(tái)提交objectEvent=Remove&id=1&id=2&id=3 , WebAction層會(huì)為每一個(gè)id對(duì)應(yīng)的實(shí)體調(diào)用BizFlow中的Remove-default操作. 實(shí)體化是一個(gè)非常重要的過(guò)程, 它使我們關(guān)注的核心成為單實(shí)體, 正是因?yàn)槊鞔_了單實(shí)體作為基本的關(guān)注點(diǎn), 我們才可以建立更加復(fù)雜的狀態(tài)機(jī)機(jī)制, 驅(qū)動(dòng)系統(tǒng)狀態(tài)變化.
4. 組件化. 前臺(tái)的tpl模板和后臺(tái)的WebAction共享一個(gè)thisObj指針, 結(jié)合自定義標(biāo)簽機(jī)制, 資源(js/css等)管理機(jī)制等構(gòu)成可以重用的組件結(jié)構(gòu).
5. 偏置的AOP. BizFlow通過(guò)一種類(lèi)似于AOP的操作對(duì)DaoWebAction提供的CRUD模型進(jìn)行擴(kuò)展, 使得模型的能力得到本質(zhì)性的擴(kuò)張. 這種AOP操作與通常意義的AOP的區(qū)別在于: 缺省行為在默認(rèn)情況下發(fā)生, 除非顯式禁止. 通過(guò)這種方式, 反轉(zhuǎn)了base和extension之間的主體地位. 此外BizFlow所提供的不僅僅是行為的擴(kuò)展,它同時(shí)提供了對(duì)界面的描述. 在前臺(tái)tpl頁(yè)面中通過(guò)
<ds:BizViewOps/>等無(wú)參數(shù)的標(biāo)簽調(diào)用來(lái)定義嵌入坐標(biāo). http://canonical.javaeye.com/blog/34941
與傳統(tǒng)的J2EE相比較, Witrix表現(xiàn)出很多變化:
1. 不使用全局的session, 而是使用局域化的thisObj
2. 不定義service層，其功能分解到BizFlow和Handler中，它們都不負(fù)責(zé)日常的DAO操作。獨(dú)立的MDA部分負(fù)責(zé)所有的實(shí)體CRUD(Create Read Update Delete)操作。
3. 不定義頁(yè)面跳轉(zhuǎn)規(guī)則，在前臺(tái)使用拉模式直接表明跳轉(zhuǎn)目標(biāo)。結(jié)合前臺(tái)stdPage對(duì)象在前臺(tái)控制跳轉(zhuǎn)目標(biāo)。并可以在BizFlow中配置覆蓋的規(guī)則，這樣就可以針對(duì)不同的應(yīng)用場(chǎng)景定義不同的跳轉(zhuǎn)規(guī)則。
4. 不是為每個(gè)模塊, 每個(gè)應(yīng)用場(chǎng)景編制一組新的頁(yè)面,而是大多數(shù)模塊共用少數(shù)幾個(gè)標(biāo)準(zhǔn)頁(yè)面.
5. 不在與網(wǎng)絡(luò)無(wú)關(guān)的service層上定義權(quán)限和事務(wù)管理。Witrix架構(gòu)下通過(guò)URL明確區(qū)分了系統(tǒng)內(nèi)部和外部, 前臺(tái)訪問(wèn)后臺(tái)時(shí)調(diào)用者的全部意圖是以規(guī)范化的形式表達(dá)在url中的. 因此權(quán)限和事務(wù)管理作用在WebObject上在概念上也可以認(rèn)為是約束直接作用在URL上, 這與REST風(fēng)格是統(tǒng)一的. 當(dāng)然我們也可以規(guī)范service方法的命名等, 但是顯然要求一種隨意性消失是有代價(jià)的, 在URL上我們已經(jīng)付出了代價(jià),為什么要在service上再付出一次. Witrix中Transaction和Auth的配置更加直觀, 因?yàn)橐?guī)范化了WebObject上的事件響應(yīng)函數(shù),一般我們也不需要進(jìn)行特殊的配置. Witrix這種設(shè)計(jì)更加適合于網(wǎng)絡(luò)這一兩分結(jié)構(gòu)的，更加充分的利用這一架構(gòu)邊界所提供的隔離性.
6. 不在頁(yè)面中使用實(shí)體的字段名，而是大量通過(guò)元數(shù)據(jù)表達(dá)程序意圖。http://canonical.javaeye.com/blog/114066
一般J2EE多層架構(gòu)下，所謂的架構(gòu)分解主要是對(duì)程序縱向的分解，但是程序結(jié)構(gòu)方面是沒(méi)有橫向分解的。而witrix架構(gòu)的一個(gè)核心就是橫向存在著 CRUD模型和Biz的分解。在系統(tǒng)的所有實(shí)現(xiàn)過(guò)程中，所有CRUD操作都剝離到MDA模型中，而不需要任何代碼編制。典型的, witrix后臺(tái)代碼一般寫(xiě)在handler中，命名為handler而不是service是因?yàn)閔andler中負(fù)責(zé)的內(nèi)容和j2ee傳統(tǒng)上的 service有所不同，一般service總是要負(fù)責(zé)某個(gè)實(shí)體的CRUD操作，大量的findxxx代碼。一般提倡的最佳實(shí)踐是實(shí)現(xiàn)某個(gè)通用的基類(lèi)，所有service都繼承該基類(lèi)獲得CRUD能力。但是在Witrix架構(gòu)中，根本沒(méi)有這一需要。Handler只要完成自己特定的功能，它不追求操作概念在其本身的完整性。沒(méi)有CRUD, handler沒(méi)有意義。但是handler之所以有意義是因?yàn)樗峁┝薈RUD之外的操作。當(dāng)CRUD成為系統(tǒng)一種自動(dòng)進(jìn)行的背景操作時(shí)，我們不再需要明確意識(shí)到它的存在。
我們需要認(rèn)識(shí)到我們最終所需要的東西可能不是規(guī)整結(jié)構(gòu)的, 它可能要求對(duì)于某個(gè)規(guī)整結(jié)構(gòu)進(jìn)行剪裁并增補(bǔ)附加元素. 但是這樣的規(guī)整結(jié)構(gòu)不應(yīng)只存在于我們的想象之中，相應(yīng)的剪裁過(guò)程應(yīng)該是可以增量進(jìn)行, 反復(fù)進(jìn)行的. 在Witrix平臺(tái)中， 基本的一種圖景變化是: Witrix中不再需要從頭開(kāi)始構(gòu)造結(jié)構(gòu), 而只要指定當(dāng)前業(yè)務(wù)和背景模型之間的差異部分. 在Witrix中所寫(xiě)的業(yè)務(wù)代碼是對(duì)核心模型的擴(kuò)展。這不僅僅是概念上的，而是實(shí)際體系架構(gòu)上精確的體現(xiàn)。CRUD作為獨(dú)立的模型吸收了系統(tǒng)中大量的變化。整個(gè)模型內(nèi)核是采用通用方式借助meta實(shí)現(xiàn)功能，并不涉及到特定于業(yè)務(wù)的類(lèi)。對(duì)于那些我們已經(jīng)掌握的知識(shí), Witrix提供了超越對(duì)象繼承,AOP和組件重用的結(jié)構(gòu)抽取手段, 使得知識(shí)可以穩(wěn)步積累.
數(shù)學(xué)中存在兩種基本的分解方式， 一種是加性分解 (a,b) + (c, d) => (a,b,c,d)， 另一種是乘性分解 (a,b) X (c, d) => (ac,bc,ad,bd)， 它也對(duì)應(yīng)于張量(Tensor)運(yùn)算. 在群論(Group Theory)中，直積對(duì)于復(fù)雜性的化簡(jiǎn)至關(guān)重要，它的重要性要遠(yuǎn)在加和之上。實(shí)際上AOP操作類(lèi)似于直積分解， 只是它的能力尚未得到充分的探索。在Witrix中，biz的作用在感覺(jué)上很象是陪集(coset)運(yùn)算：CURD * biz。不同的biz作用到同樣的CRUD模型上產(chǎn)生不同的操作集合，而所有biz組成的集合構(gòu)成獨(dú)立的整體。
Witrix平臺(tái)中作為內(nèi)核的MDA部分首先是物理模型驅(qū)動(dòng), 而不是邏輯模型或者對(duì)象模型驅(qū)動(dòng). 我們通過(guò)在物理模型上標(biāo)注的方法恢復(fù)部分對(duì)象模型的信息, 但是我們并不試圖把整個(gè)軟件建立為模型. 所建立的僅僅是整個(gè)程序模型的內(nèi)核. http://canonical.javaeye.com/blog/29412 一般業(yè)內(nèi)鼓吹的所謂MDA成功的關(guān)鍵是要提高抽象層次。但是陪集是更抽象嗎。 正規(guī)子群更抽象嗎。 它們只是系統(tǒng)的指標(biāo)性表征，使對(duì)信息的distill, 是更容易理解的一個(gè)側(cè)面而已, 抽象性并不是一個(gè)真正的目標(biāo)。很多時(shí)候我們需要的是把系統(tǒng)降維到某個(gè)子空間中，形成一種可控性。 但是這個(gè)子空間并不一定是更抽象的。
群作為基本的代數(shù)系，一個(gè)本質(zhì)特征是具有逆元。Witrix的MDA中明確定義了逆元結(jié)構(gòu)，即界面上的元素 empty = buttonA + (-buttonA)，這一分解公式應(yīng)用到后臺(tái) OpA = Update * (-Update) * OpA。假設(shè)我們已經(jīng)建立了結(jié)構(gòu)X, 現(xiàn)在需要建立一個(gè)與X略有不同的結(jié)構(gòu)Y
X = a + b + c
Y = a + d + c = (a + b + c) - b + d = X - b + d
雖然Y的兩種構(gòu)造方式在數(shù)學(xué)上是等價(jià)的，但在物理上并不等價(jià)。第一種方式對(duì)原有系統(tǒng)進(jìn)行分解后再組裝，而第二種方式?jīng)]有打破原有的東西，不需要拆分。拆分總是可能存在問(wèn)題的，正如你把所有電腦零件拆裝下來(lái)再裝上很可能會(huì)發(fā)現(xiàn)多出幾個(gè)零件。一般情況下第二種方式的構(gòu)建成本要低. 特別是當(dāng)一切都糾纏在一起的時(shí)候, 一種細(xì)粒度的逆元結(jié)構(gòu)對(duì)于一種試圖重用的結(jié)構(gòu)是非常關(guān)鍵的. 可重用性的障礙不僅僅是來(lái)自于無(wú)法追加新的功能，很多時(shí)候也在于無(wú)法屏蔽原先已經(jīng)提供的功能。目前所有的設(shè)計(jì)原則都未能適時(shí)識(shí)別出逆元的重要性。所有的設(shè)計(jì)教條其實(shí)所指的方向都是加和, 如何分解出更小的組元, 如何把它們加和在一起, 如何從細(xì)部開(kāi)始進(jìn)行重新構(gòu)建, 而不是說(shuō)依賴于現(xiàn)有已經(jīng)形成的宏觀結(jié)構(gòu), 如何進(jìn)行細(xì)粒度的調(diào)整. 所謂的AOP技術(shù)思考的關(guān)鍵點(diǎn)也在于如何給系統(tǒng)增加功能, 很少有人想到場(chǎng)景是為系統(tǒng)減少功能并把這種概念大規(guī)模正式應(yīng)用的, 雖然說(shuō)AOP已經(jīng)在某種程度上具有了這種能力, 但是真正應(yīng)用它仍然需要對(duì)AOP進(jìn)行進(jìn)一步的詮釋. 當(dāng)然，現(xiàn)在的軟件業(yè)連基本結(jié)構(gòu)的構(gòu)造問(wèn)題都沒(méi)有完全搞清楚, 更別提所謂結(jié)構(gòu)穩(wěn)定性的問(wèn)題了.
從物理上說(shuō)，Y = X - b + d的分解方式具有特殊的意味。如果沒(méi)有逆元，我們必然需要分解。但是如果發(fā)掘了背景這一概念，在逆元運(yùn)算下，對(duì)背景不是分解讓其成為可見(jiàn)的部分，而是采用追加的，增刪的方法對(duì)背景結(jié)構(gòu)進(jìn)行修正，則我們有可能在沒(méi)有完整背景知識(shí)的情況下，獨(dú)立的理解局部變化的結(jié)構(gòu)。即背景是透明的，知識(shí)成為局部的。
Witrix試圖提供的一種圖景是永遠(yuǎn)只寫(xiě)代碼片斷，而所有的代碼片斷組合在一起又構(gòu)成一個(gè)可理解的整體。這個(gè)整體可以獨(dú)立理解，不需要額外的結(jié)構(gòu)元素。 Witrix架構(gòu)所追求的是在不完全信息下建模，不進(jìn)行整體建模。整體模型 + 不斷變化的局部修正 構(gòu)成最終模型。平臺(tái)技術(shù)的目標(biāo)是讓一切應(yīng)該發(fā)生的自動(dòng)發(fā)生，讓一切不該發(fā)生的無(wú)法發(fā)生。這一模型的構(gòu)建并不是trivial的，在概念和實(shí)現(xiàn)方面都要作出很多的努力。
