EOS/普元：概述：中国IT业的悲哀

公司引入了普元的EOS作为公司的基础架构平台，今后的所有项目将逐步向EOS的迁移，但对EOS的研究又让我不得不说出以下话：

1、EOS确实够简单，但未免简单过了头：从语言层面看EOS 
因为EOS将成为我们的开发语言，所以有必要从语言的层面认识EOS。 
去除EOS的图形化外衣，我们看到EOS就是一门以XML表示的类似Basic的脚本语言，这门语言相当简单，因为其语法元素极少，如下：

过程声明 <-> 构件的创建 
过程调用 <-> 构件调用 
条件语句 <-> 构件图中的IF结点 
循环语句 <-> 构件图中的"{" 和 "}"结点

因为语法元素少，加之图形化的编程方式，这就形成了EOS的”入门容易“的优势。

现在让我们理清思绪，仔细考察这门简单的语言，我们会发现这门语言竟是如此简单，甚至连最基本”变量声明与赋值操作“的语法元素都不具备，大家是否会觉得惊呀？这是因为EOS不需要声明变量，EOS提供了一个全局变量给所有的构件使用，这就是EOS大力吹捧的”XML数据总线“。 
全局变量和局部变量都不需声明，可以直接使用，那么语言编译器是否可以提供类型检查，或者是否能提供”未用变量“的警告的呢？答案是不能，这些问题必须在运行时才能解决。

进一步沿着语言层面思考下去，我们会发现这门语言”没有类型“，注意我说的不是”弱类型“或”类型检查“。这门语言中所有变量全部都是”字符串“，系统也不能提供格式化的机制实现其宿主语言(java)类型与字符串间的转换。

有人可能会怀疑，既然这门语言这么简单，功能这么弱，那它根本就不可能在实际项目中使用，而我们从普元的宣传和他长长的客户名单列表里头看到的并不是这样的状况，这是为什么呢？其实答案还是在java，因为java是EOS的宿主语言，也就是说我们可将EOS看作类似groovy/jruby之类的扩展语言，当这些扩展语言实现不了某些功能时，我们就可以直接使用宿主语言进行开发，这就与在C语言中使用汇编类似。

好了，现在我们已经清楚EOS实际提供了两个语言层面：一个是简单但功能弱的语言层面，一个是复杂（java复杂吗？）但功能强大的语言层面。这种做法其实和groovy/jruby没什么区别。

讨论了语言，现在可以设想一下这门语言的应用，我设想的EOS应用的最佳方式是将EOS作为一个工具包，以利用EOS的图形化能力给应用提供可视化的配置能力，当然对于以工作流为核心的应用，将EOS作为流程配置的工具也是极佳的应用方式。这样的应用方式就类似于将groovy应用于项目的单元测试一样，因为这些扩展语言因为其某些不足不可以成为应用的基础（核心）语言。

然而，普元公司可不这样定位自己的产品，他们希望自己的EOS作为应用的平台或者核心语言，现在扯上SOA的大旗后，EOS甚至可以作为企业的基础架构，我想问：EOS能当此大任吗？

2、构件？ 
EOS宣传的”构件“是什么意思呢？其对”构件“的定义是”构之件也”，好象还是不明白吧？ 
让我们再次从语言层面来看这个问题，EOS中的构件就是过程，其实再简单不过，更准备地说，EOS中的构件就是一个不过参数没有返回值的过程，这样的过程其语义如何准确描述和定义呢？EOS的构件同样无法解决这一问题，那么构件的组装就和过程的嵌套没有什么两样。 
甚至于EOS中的构件都算不上是”模块“，因为模块通常包括了一组功能或者说一组接口。而EOS的构件只有一个功能，因此将EOS的构件理解为”接口“也是错误的。然而EOS的产品白皮书以及EOS在市面上的宣传都有意忽略了EOS构件的本质的特征，这些只是为了忽悠的需要，说的和做的根本不是一个东西。当然我们大家都能理解，这就是国情。

3、IDE的作用？ 
图形化的IDE对我们应用的作用是核心的，本质性的吗？应用甚至企业的基础架构的图形化有这么重要吗？开个玩笑，也许EOS的插件本身就可以用EOS本身来实现，这样这门语言就是自洽的了。

4、EOS与IOC有关系？ 
EOS和IOC有关系，这个说法比较新鲜。EOS的构件本就是过程式的，何来依赖注入？难道是说EOS能自动注入一个构件所需要的嵌套构件，这就可以称为IOC了？这样说任何语言都是IOC的。

5、EOS的O-X mapping？ 
O-X mapping？照猫画虎也画得太不象了吧，EOS中何来对象，何来“O”？竟敢也赶这个时髦。 
我理解EOS所说的O-X mapping只是将数据库中的记录取出放到其XML总线上，这就叫记录到XML的映射了，只是仔细了解过EOS的数据库操作构件的人都应该明白这个O-X mapping的含义吧。这样的名词只能拿来吓唬一下半懂不懂的经理级人物，李佳不也说这应该叫做X-R mapping吗？

6、EOS与AOP？ 
EOS有一个组件拦截功能，具体说就是允许为组件配置一个过滤器，以实现组件调用前的处理和组件调用后的处理，这个功能实在是太简单了，达到几乎没有实用价值的地步。这样一个功能也能扯上AOP吗？诸位自己判断吧。

说了这么多，在不断佩服EOS的攻关能力的同时，也不断地为国内的IT技术人而悲哀。在我看来，稍有技术敏感的人都应该能看到EOS作为企业技术平台的严重问题，然而现实是那么多的做了多年技术的程序员/经理/老总们，竟然都那么迷信图形化，那么讨厌代码，轻易做出将EOS做为基础架构的决策。这不是中国IT产业的悲哀吗？

参考资料： 
http://www.iteye.com/topic/13888?page=1 
http://canonical.iteye.com/blog/33794 
http://canonical.iteye.com/blog/33795 
http://www.bjug.org/20050524.html

http://www.iteye.com/topic/210475