公司引入了普元的EOS做为公司的基础架构平台,从此的全部项目将逐步向EOS的迁移,但对EOS的研究又让我不得不说出如下话:
一、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能当此大任吗?
二、构件?
EOS宣传的”构件“是什么意思呢?其对”构件“的定义是”构之件也”,好象仍是不明白吧?
让咱们再次从语言层面来看这个问题,EOS中的构件就是过程,其实再简单不过,更准备地说,EOS中的构件就是一个不过参数没有返回值的过程,这样的过程其语义如何准确描述和定义呢?EOS的构件一样没法解决这一问题,那么构件的组装就和过程的嵌套没有什么两样。
甚至于EOS中的构件都算不上是”模块“,由于模块一般包括了一组功能或者说一组接口。而EOS的构件只有一个功能,所以将EOS的构件理解为”接口“也是错误的。然而EOS的产品白皮书以及EOS在市面上的宣传都有意忽略了EOS构件的本质的特征,这些只是为了忽悠的须要,说的和作的根本不是一个东西。固然咱们你们都能理解,这就是国情。
三、IDE的做用?
图形化的IDE对咱们应用的做用是核心的,本质性的吗?应用甚至企业的基础架构的图形化有这么重要吗?开个玩笑,也许EOS的插件自己就能够用EOS自己来实现,这样这门语言就是自洽的了。
四、EOS与IOC有关系?
EOS和IOC有关系,这个说法比较新鲜。EOS的构件本就是过程式的,何来依赖注入?难道是说EOS能自动注入一个构件所须要的嵌套构件,这就能够称为IOC了?这样说任何语言都是IOC的。
五、EOS的O-X mapping?
O-X mapping?照猫画虎也画得太不象了吧,EOS中何来对象,何来“O”?竟敢也赶这个时髦。
我理解EOS所说的O-X mapping只是将数据库中的记录取出放到其XML总线上,这就叫记录到XML的映射了,只是仔细了解过EOS的数据库操做构件的人都应该明白这个O-X mapping的含义吧。这样的名词只能拿来吓唬一下半懂不懂的经理级人物,李佳不也说这应该叫作X-R mapping吗?
六、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 html