论坛首页 行业解决方案版

EOS/普元:中国IT业的悲哀

浏览 6518 次
精华帖 (6) :: 良好帖 (6) :: 新手帖 (1) :: 隐藏帖 (0)
作者 正文
最后更新时间:2008-07-17
根本还是缺少核心技术,EOS不能提供自己的编程语言,复杂的东西只能依赖java直接处理,应该说EOS就是一个工具,一个比较大的代码生成工具,还不到产品的程度。
   
0 请登录后投票
最后更新时间:2008-07-24
银狐999 写道
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的理解和产品规划,就会发现,这里面有很深厚的软件技术和对软件发展趋势的把握。—— 只有不理解的人,看不懂的人,才会以为这是“忽悠”。


说实话,普元能做出这个东西,在国内已实属不易,但不容易并不代表它就好,从实施项目公司来讲,
这个EOS的确有可能提高开发效率,但本着对客户负责的态度,EOS就等于把系统绑在了普元身上,在
技术发展快速的大环境下,绑定一个小公司(相对于IBM,Oracle和美国的标准制定组织)来讲,实在
是风险很大,将来多个系统集成的问题,升级的问题,架构重构的可能性,等等,全要依赖于这个EOS,
依赖于普元,这不是一个好CTO下的决定。
   
6 请登录后投票
最后更新时间:2008-07-29
以我们现在对EOS的了解,开发EOS主要包括以下几部分工作:
1、EOS的解释引擎,也就是EOS Server:这部分主要就是要写一个解释器,实现对EOSStudio 所生成的XML流程的解释执行。一般来讲写一个解释还是有一定难度的,特别是要把解释做好,可能不是那么容易。但从我们上面对EOS的语法分析来看,这个解释要解释的语法实在太简单了,因此我认为这部分工作没有任何难度(当然可能有一定工作量),甚至比ajoo写的jaskell都要简单得多。
2、EOS Studio,也就是基于Eclipse的IDE:这部分是EOS的重中之重,所谓可视化开发全部要仰赖IDE实现。这部分的工作量要比EOS Server大得多,主要包括各种插件的编写。但这些插件从实现难度看,并不高,因为基于Eclipse的GEF和EMF框架,开发可视化流程是轻而易举的事。IDE中唯一有一块东西,我无法判断其实现难度和工作量:就是流程的可视化调试。因为不了解Eclipse和JDK对程序调试的支持,所以很难说这块难度有多大。但可以肯定的是,Eclipse绝对会对调试有支持的,所以这块的工作量应该不是问题,关键在于实现的难度。
3、EOS 工作流:这部分不能作为基础平台,最多只能算是一个特定的工作流产品,因为没有深入了解,所以无法判断其开发的难度和工作量。但国内做工作流产品而且做得不错的公司还是比较多的,所以我推断这块不会有太大的难度。
4、EOS 报表:和其工作流产品类似。
5、产品的版本/文档/技术支持等管理:感觉普元在这块做得比较好,也比较正规,这块也是我对普元最认可的一块。

终上所述,要做好EOS确实不容易,有很大的开发量,而且技术上也有一定的难度(比如可视化调试)。但仔细想想,从技术层面看EOS的哪些东西能构成其核心技术呢?我们看不到,所以我认为普元至少在技术上是缺少核心竞争力的。

那普元是如何成功(也许说它成功还为时过早,我们先这样期待吧)的呢?我认为是因为普元很好地抓住了国内软件开发的现实,很好地适应了目前国内软件整体的开发能力。从上面的分析可以看到,普元把他大部精力放在了EOS Studio上面,也就是他把宝压在了Eclipse上面,把各种可视化功能做好做完善,以吸引我们许多技术管理者和老板的眼球,然而在其核心EOS Server上面,却投入极少,从这里也可以看出普元的短视形为。
   
16 请登录后投票
最后更新时间:2008-07-24
EOS studio,java中的vb,呵呵
   
0 请登录后投票
最后更新时间:2008-07-24
我们公司也准备用普元的EOS,问下领导为啥不用IBM的WPS。领导答:便宜。
看了帖子后,终于知道EOS为啥便宜了。
   
0 请登录后投票
最后更新时间:2008-07-25
to 银狐999:

SOA的理念没有错,问题在于SOA有具体的技术了吗?凭什么说普元的构件是面向SOA的呢?

以前参加过普元的培训,我说说我对普元的理解。

什么是构件??我觉得普元的宣传资料和他们的大会都没有说清楚。如果说构件和以前的组件是
一样的话,那么,我觉得普元的整个理论基础就轰然倒塌了,就是说构件这个没有什么意义。

如果说,构件是比组件更大的、封装功能更强的,我想说的是,有如何保证这些构件的适应性?

还有,普元宣传的所谓的可以提高快速部署,我觉得也不靠谱,你如何去适应需求,如果说,你
针对特定的行业应用开发了一套组件的话,那么,你本身对行业的理解就需要很深,而普元本身
定位就是通用领域,所以,不客气地说,你们根本就不懂行业,怎么可能开发出一个行业的通用
平台呢?

我觉得还是MDA加上部分的代码自动生成功能靠谱点,当然,生成的代码还是需要开发人员来修改。
   
0 请登录后投票
最后更新时间:2008-07-26
没有用过普元,不过我觉得一个工具如果能快速解决哪怕60%以上的简单重复劳动,少量的复杂逻辑通过宿主语言解决,我觉得这个工具也是值得使用的,至于是否符合IOC、AOP什么概念那无所谓。
   
0 请登录后投票
最后更新时间:2008-07-26
mirage 写道
没有用过普元,不过我觉得一个工具如果能快速解决哪怕60%以上的简单重复劳动,少量的复杂逻辑通过宿主语言解决,我觉得这个工具也是值得使用的,至于是否符合IOC、AOP什么概念那无所谓。

简单的数据库单表操作用EOS是很快的,流程定制也很快,不过和别的工作流产品也没什么区别,
关键我是觉得,把自己的平台绑在普元身上是一个风险。
   
0 请登录后投票
最后更新时间:2008-07-29
这些 偶都不曾见识过,口水不少啊!
   
0 请登录后投票
最后更新时间:2008-07-29
银狐999 在工作流方面很强的
   
0 请登录后投票
论坛首页 行业解决方案版

跳转论坛:
JavaEye推荐