前两天一位普元的朋友衣风
http://blog.sina.com.cn/u/1495516693在我的blog上留言,谈到对数据总线的不同看法. 我本人并未使用过普元EOS,所做的判断只是基于我个人肤浅的第一印象, 很有可能是不准确的. 不过, 目前我仍然坚持自己对于普元EOS的看法,呵呵.
1. EOS产生的xml描述文件中的大量条目都是EOS自身的结构要求，而与实际业务无关，即EOS描述文件中的有效信息量密度很低.
衣风认为条目并不是EOS自身的结构要求，而是业务对象的结构描述.
这里我的看法是业务对象应该尽量通过领域(Domain)语言来描述, 领域信息的外在表象应该尽量是卷缩的,而不是展开的,
应该尽量是抽象的而不是实现细节层面上的.例如:
<function class="test.MyFunctionProvider">
<args>
<arg>
<name>argA</name>
<value>3</value>
</arg>
</args>
</function>
以上信息可以描述一个方法调用, 这里的function, args, arg, name,
value等标签的设置都是解析器为了理解该调用的语义而规定的结构元素,这些元素并不属于函数本身.
例如我们可以规定如下的调用格式来简化描述文件而不损失信息,
<function class="test.MyFunctionProvider">
<arg name="argA">3</arg>
</function>
而在我们的工作流引擎中, 业务操作的调用以封装后的形式出现
<BusinessA:DoWorkA argA="3"/>
通过标签封装之后, 我们在调用的时候所需要提供的信息是最小化的, 每一个涉及到的元素都是有着业务含义的,
而将解析器本身的结构要求隐蔽在封装的标签定义中.此后我们如果更换了实现,而业务需求不变, 则我们的调用处是不会受到影响的.
现在基于xml语法的文件格式很多, 我们的工作流引擎也采用了xml描述. 但是我们的一个基本观点是,
xml配置文件解析器不应该直接理解文件中所有的标签, 即它只需要理解自身的结构元素, 而为引入Domain知识保留余地.
2. 普元EOS中的结构似乎很难进行有效的扩展。而所谓的xml总线技术更加剧了这一点
衣风认为"正是将XML作为数据传递的总线，才使应用在数据层次上具有了较强的扩展能力"。从面向对象的观点看,
程序中普适性的基本基元是数据与行为的集合体, 而程序模块之间的交互也绝不仅仅是通过数据来进行, 而是往往呈现出一种数据与行为的交织状况.
普元的模型应该包含了大量发生紧密关联的局部元素, 它们应该处在同一进程(状态)空间中, 直接访问对象应该是最简单,最经济,
最完备的信息传递方式,
而"xml节点的表达能力远远超越了普通的数据类型，但充其量也不过是对现有数据的规整的树形表示，并不具有动态计算能力（甚至是最简单的lazy
evaluation）". 实际上对于所谓的总线, 最简单的模型是一个可以动态管理的变量集合, 那么一个Map就足够了.
在集合中我们可以保存各种对象, 比如xml节点, 但是又不限于xml节点. 从建模的角度上说,
把xml节点定义为一级集合元素我认为是不合适的. 通过对象的成员函数, 我们在对象图中可以包含大量的动态计算信息, 例如
obj.getSomeCalculatedAttribute().getLazyLoadValue()
这些动态语义在纯数据含义的xml总线技术中不知道如何表达.
对象图表达数据关联的能力也强于树形结构的xml节点, 例如 obj.getRefObj().getRefObj() == obj, 不知道这样的关联在普元EOS的数据总线中如何表达.
在并发访问中如果需要同步, 对于对象, 我们可以使用synchronized机制, 但是对于xml节点不知道如何才能有通用的处理方式.