Witrix架构分析

        Witrix开发平台基于级列设计理论发展了一系列新的设计思想和软件分解机制。并提出了一种新的Web体系架构。http://canonical.iteye.com/blog/33824
 

 

Witrix架构呈"可"字形态，其中定义了三条主要的分界线:
1. 浏览器和服务器之间通过语义结构明晰的URL形成两分结构。http://canonical.iteye.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.iteye.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.iteye.com/blog/99122
3. 实体化。在Witrix中充分发掘了ORM技术的能力, 使得单一业务对象上可以聚集到某一范围内的所有相关结构信息. http://canonical.iteye.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页面中通过 等无参数的标签调用来定义嵌入坐标. http://canonical.iteye.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.iteye.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.iteye.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的现状, 大致的评语是: 垃圾, 自己人也不用. 听来也让人有些感叹. 中国原创的技术总是欺骗的代名词,  这一断言不应总是得到证实.