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.javaeye.com/topic/13888?page=1
http://canonical.javaeye.com/blog/33794
http://canonical.javaeye.com/blog/33795
http://www.bjug.org/20050524.html

是啊，EOS在技术圈子里就像是脑白金，大家好像都知道没什么用，但是还是有很多人花钱买，呵呵，这就是商业的作用，你看，连对EOS抨击最厉害的javaeye不也开辟了普元专区了吗？

有一位化学家说过：“当我在解决一个问题是，我从不想美的问题。我只想如何解决问题。但当我完成以后，如果这个解决方案是不美的，我知道这个方案一定是错误的。”

那大家可以思想一下，EOS可以解决多少问题，解决的方案美吗？

正如robbin在2005-12-09时说的http://www.javaeye.com/topic/17295：


三年后的今天，这句话依然重要：


EOS卖得越好，越能看出国内与国外在技术上的差距。

这。。。很好玩。
给钱就开专区啊。
不过这客观上也不是坏事。是骡子是马，还得出来遛遛才知道啊。不管是好是坏，结果就是大家都知道了。

普元这东西看来真的是骗钱的。什么国家扶植、什么863项目，大多数都是骗钱的，已经彻底是普遍现象了。

这个帖子好啊，总结了EOS，到此为止，可算是基本了解什么是EOS了。

如果能总结出什么功能是EOS不能实现的、绝对致命性的问题列表，那才好呀！
省的被忽悠也没办法反驳，列举一些名词对比，对领导层不会有什么震撼力，起不了决定性作用。

还是从语言层面来看，仅仅具备基本语法元素的EOS（这里是指图形化的EOS）可能有很多功能都不能实现，但不要忘了EOS的宿主语言--java语言，有什么功能是java语言所不能实现的呢？因此从EOS的角度来看，如果有什么功能是图形化所无法解决的，那也没关系，因为可以在java中实现，然后再封装成“运算逻辑”，这样就等于无限扩充了EOS，所以从这个角度来说，只要java能实现的功能，EOS就能实现。

但我们将EOS做为一个底层/基础平台的时候，难道考虑的仅仅是它是否能实现我们的功能吗？这显然不够！

事实上我们有很多项目需要移植，而一般人在考虑可行性的时候，所得到的结论往往是：用EOS做要做的系统绝对没问题，技术上绝对可行！

这里又是在偷换概念，项目的性能、可维护性、可扩展性等等，是否有考虑呢？我想这是我们每个做项目的人都必须思考的问题。

商业运作~毕竟客户中不懂技术的占大部分。我记得网上还有一个开源的ERP炒得挺火，其源码写的很烂。这年头，赚钱才是硬道理~毕竟是商业公司，要的是利润。又不是科研机构~

HOHO 我们的客户也想引入EOS 我也是存在很多的疑惑 哈哈 这个帖子长进不少认识 希望有更多讨论

to jxb8901:

首先，我很理解你的抱怨。毕竟我也是一个狂热的技术爱好者和钻研者。不过，说句实在话：你们公司选择Primeton EOS这是明智的选择，而不仅仅只是所谓的“商业行为”。—— 对于企业来说，“开源节流”是时时需要考虑的问题。

当你在抨击Primeton EOS平台的问题的时候，是否考虑过它的价值呢？对一个像你们这样的应用软件提供商来说，你觉得什么是最重要的呢？—— 是业务，是业务到IT系统的实现，这才是最最最重要的。

EOS肯定无法解决所有的问题，毕竟它不是一门“语言”，而是在尝试用“Component”的思想来解决软件基础层面的一些问题：帮助你解决事务、缓存、Component Lifecycle、快速开发、管控、流程等等问题。—— 对于一个做应用实施的软件企业来说，如何获取更大的收益呢？
    （1）快速项目实施
    （2）低成本实施
    （3）后期便于维护和管理、可管控
    （4）把有限的人员更多的投入到业务实施上，而不是底层架构的开发上。

当然还有一些其他方式来获取更大收益，但上面四条是哪个软件提供商都会考虑的。—— 几年前，哪家应用提供商都在考虑自己做平台（有些大企业在巨资投入中总算做出一些，诸如东软、中软等等），但是更多的企业却不得不挣扎中徘徊。—— 平台要想做好，这是高成本的投入。—— 决不是拿spring封装一下，拿seam改造一下那么简单，那仅仅是解决了最为初级的问题。

=============================
另外，我想从其他角度来阐述一些问题：

当大家都在谈国内技术怎么怎么的时候，有真正几家软件企业在走国际化标准呢？有真正几家企业在基础软件产品层面跟IBM、Oracle、BEA在PK呢？

说实话，国内只有寥寥几个软件企业在做着这样的事情，Primeton是其中之一（SCA/SDO的标准的制定者、OASIS标准成员之一、开源SCA引擎的commiter）。在银行、在电信领域，基本上都是在跟IBM、Oracle、BEA在PK。—— 在IBM内部，已经将Primeton列为主要的研究的竞争对手行列。

在javaeye似乎还有一篇名为“忽悠！忽悠！继续忽悠”的帖子，忘了地址了，大家自己查吧。—— 几乎把SOA说的一无是处。—— 其实，只要真正静下心来研究这些公司的对SOA的理解和产品规划，就会发现，这里面有很深厚的软件技术和对软件发展趋势的把握。—— 只有不理解的人，看不懂的人，才会以为这是“忽悠”。

楼上的是普元的员工吧？如果是，那就拿的真东西来讨论一下？不要总说跟谁谁PK，以前什么“挑战微软”“挑战IBM”的口号听得太多了。