canonical

     http://www.primeton.com/

    普 元软件公司是国内专业的中间件提供商，从国家得到了不少投资，做出来的东西也是相当的庞大。最近普元EOS的宣传和发展的势头都很盛。其宣传材料中屡次提 到“软件的涅磐“这一用语，这明显是一种危言耸听之举，当然这在业内也不算什么新鲜的事情。按照EOS的宣传，"以图形化的构件组装方式“画”出来的软件 无论从结构上、形式上还是开发过程上都堪称简捷而美的软件"。这一提法倒是别开生面。图形化与简洁，与美竟然还存在着这样必然的联系，实在是一种创举。
     从普元公开的资料来看，EOS的一个鲜明特征是全面基于xml描述，即所谓的xml数据总线。表面上看起来，xml结构内置于系统内核中似乎很时尚，但实 际上，EOS产生的xml描述文件中的大量条目都是EOS自身的结构要求，而与实际业务无关，即EOS描述文件中的有效信息量密度很低。这是一个危险的信 号。EOS的xml描述本身可以看作是一种完全新的编程语言，但这个语言似乎没有什么抽象能力和组合能力，对于关联的表达能力也很弱（到处都是数字 id)。如果直接手工编写，那是一件要死人的事情。只有通过集成开发环境的可视化界面，EOS才呈现出可理解的一面。
     EOS的概念与Language Workbench是不同的，其中的结构似乎很难进行有效的扩展。而所谓的xml总线技术更加剧了这一点。xml数据总线其实与面向过程编程类似，只是过 程变成了service，数据变成了xml节点而已。对象与简单数据结构在结构表达上的本质差异就在于对象通过成员函数可以封装动态结构。虽然xml节点 的表达能力远远超越了普通的数据类型，但充其量也不过是对现有数据的规整的树形表示，并不具有动态计算能力（甚至是最简单的lazy evaluation）。丧失了动态计算能力，就意味着我们很难在系统中动态引入结构，程序中所操纵的结构都需要事前定义出来，这将极大的限制系统的可扩 展性。另一方面，xml节点受限于自身格式，其描述关联的能力也要弱于java对象结构本身。对象通过引用访问相关对象，其隐含意义是对象处于同一地址 （状态）空间中，可以非常自然的保证对象的唯一性并实现同步访问。在跨越状态空间的边界时，xml表示是有意义的，因为我们需要把所有的结构都暴露出来并 加以描述(外在化）。而在状态空间内部，我们需要更加紧致有效的表述方式。
     在具体的实现中， EOS暴露给程序员的xml操纵API相当的原始，使用起来很繁琐。在前台展示页面中，如果不使用EOS的界面组件，提取数据本身就是一种不小的困难。 EOS的前台展示组件与后台的结合也比较弱，后台改变之后，缺乏有效的手段来检测并保证前后台结构的同步性。所谓的前台构件层似乎只是提供了一些帮助函数 和功能固化的组件，并没有提供什么有效的利于结构抽象和结构重组的机制。
     整个EOS的构架看起来很象是一个monster, 我很难想象它的各个部分如何才能独立的，深入的发展下去。