前几天，小错那篇EOS的文章招来了两位为普元说话的人，我很赞同小错后来这篇POST里的观点。先不说普元EOS在技术上的优劣，就拿他们最近在《程序员》的宣传来说，基本上都是属于高来高去的扯淡性质的东西，无非是反复在说EOS很好很好。但这是远远不够的，必须要能拿出清晰明了的技术说明才能让人信服并接受，比如像小错那篇《初窥EOS》这样的文章，把具体的技术细节拿出来接受检验——除非它在技术上的确有不便让人知道的不足之处。
再说来技术。普元的EOS其目标是想要实现“构件”级的可复用，正如恶魔在第六期的《程序员》中有一篇文章《质疑：从面向构件看软件复用》所指出的那样：所谓构件的粒度过大，注定不会有好的可复用性，并且他拿轻量容器PICO作比较说明，很有说服力。
而普元解决这个问题的办法似乎是通过用XML来作为构件间的接口，通过“弱”约束来改善大粒度构件的复用问题。当然，我相信普元的构件也是可以做小的，但是看上去构件似乎是一种重量对象，如果做成小粒度的，必然导致接口成本的大幅上升。这个矛盾目前看来是不可调和的。
回到XML的问题上来。我不想再说XML的性能问题，毕竟在复杂应用中，只要不滥用，这点性能损失通常还是可以接受的。我要谈的是“弱”约束的问题。
从目前已知的各方面来看，在EOS中XML似乎是被用作非强类型的数据接口定义，这就变得如令狐在他那个WebService实现中那样的做法了：客户端与服务端之间的调用约定是“弱”约束，双方必须自觉遵守，否则将在运行时出错。这也是小错指出的EOS的第三点别扭之处。
其实在令狐那个WebService中是可以用强类型数据的。只是麻烦：首先要为这些类型增加Serialize接口，然后在Web Service端要以wsdd形式配置并发布，客户端也要做一些处理……这一方面与DELPHI很类似，都是需要自己实现对非基本数据类型的序列化，然后注册，就可以在导出的WSDL中提供相应的约束（参见我的一篇关于用Delphi进行WebService开发的文章，其中用的还是默认的序列化方式，自定义序列化可以通过NativeToXS 和 XSToNative两个方法实现）。
但在普元EOS中，我没有看到这个方面。所以我认为，从这个角度上说，EOS甚至不如目前流行的SOA的概念。SOA作为一项基于WebService的技术，可以充分利用WebService提供的这一套标准的处理机制，并且它是以整合既有系统为目标设计的。就算普元EOS的开发成本很低，对于存在既有应用系统的情况，重新开发的成本总是会比整合既有系统要高的。当然，如果没有历史包袱的话，EOS也还是有优势的。
我之所以比较不喜欢这种“弱”约束，原因就在于前面所说的一点：它只会在运行时出错。而对应的强约束则可以在编译时得到检查。它等于在一个方面减少工作量的同时，在另一个方面增加了工作量——把本来应该由编辑器处理的问题交给程序员来做。至少需要增加不少本来不必要的单元测试工作。
不过这倒让我想到，如果是动态语言的话，可能会在粒度和接口复杂度之间取得比较好的平衡。
BTW：看到小错那篇后面又多了不少回复。牛者恒牛说：EOS降低了J2EE的门槛，提高了开发效率（大意）。这可能是事实，但是我不能同意这一句：我用你一半的时间完成你相同的工作，完成的系统更稳定更易维护。
稳定性我不好评价它，毕竟没有用过。但是从RAD这十多年来大大改进了开发效率，但是在易维护性上不但没有改进，反而有所退步这一方面来看，EOS的易维护性比较可疑。
降低技术门槛很容易诱使技术一般的开发人员使用最易开发的方式进行开发工作——比如在RAD里直接在事件响应里处理业务逻辑，这几乎是必然导致未来的维护工作大大增加——当然，EOS可能与此不同，不过它毕竟出来的时间不长，随着时间的推移，维护问题将逐渐显现。
而提高效率的同时，隐藏了过多的技术细节。如ARI所说：这是很危险的。任何事物都有两面性，构件带来方便的同时，必然带来局限。如果在未来维护时需要涉及细节上的变动，就可能受到很多的制约，增加维护成本。
当然，如令狐所说：一个产品被研发出来，总有它的市场和应用。但是普元目前的宣传方式并不能消除上述的这些疑虑。所以我还是认为，如果普元的EOS真是如他们所说的那么好，最好还是尽量多地发一些技术文章来证明，而不是扯淡。
好长…庆幸一下不用暂时去搞什么商务系统，商务软件…概念多的要死，“高来高去”的扯淡着。btw: MQ贴连接的习惯可能需要小修正一下，好像都是相对地址。
问一下猛禽，SAP的BAPI是什么咚咚？能否简单讲一下如何使用BAPI？
“也不要再想自己是一个JAVA高手，你一定会发现她美的地方。”———-这么说，难道EOS定位素那种JAVA高手看不上眼的东西？
无论产品如何，这个态度还是要得di,哪怕您肚子里把这几个家伙骂了多少遍，POST出来的东西还是满厚道，比当年csdn中文编程语言吵架的时候某些人强。哈哈，做生意，厚道换厚道呀。
还是猛爷总结的好！EOS在全国范围内接单做项目，大部分都是政府企业，我所指的社会资源浪费是怕今后这些单位企业几百万的投资只是昙花一现的政绩工程，而希望普元别总是这么高来高去的扯，而是揭开头盖让更多人看看是美是丑！
小错过奖了，我不过是闲扯一下而已。:P
这个，我知道了，是因为我用FCKeditor，它总喜欢自作主张-_-|||
BAPI我也不会，我只会一点ABAP-_-|||
顶一个
我是看了小错在大赛专区论坛里发的贴子才过来看的。小错说猛兄是很客观的，我就来看看。高来高去的扯淡性质的东西…把具体的技术细节拿出来接受检验——————这是分隔线————————非常欢迎你参加EOS大赛，免费注册为会员后就会获得产品的试用版，我们在程序员、CSDN、EOS在全国的路演、其他平面和网络媒体都有宣传，你拿去用，拿去研究，分析出有哪些确实的技术上的问题，你提出，我们改正。像小错上一篇文章所写–我个人的意见–那是观念的问题、习惯的问题，所以小错也只能说，觉得别扭，但却说不出太多实质性的技术弱点所谓构件的粒度过大，注定不会有好的可复用性——————这是分隔线————————我想EOS的构件颗粒度大小，小错就可以回答你，并非如你所想。如果做成小粒度的，必然导致接口成本的大幅上升——————这是分隔线————————如果我们在这一点上有问题，我们还讲什么XML数据总线，别人问我：你和以往的组件有什么区别？我还怎么回答？怎么还会出现北方电信的连续几期BOSS系统都基于EOS构建的案例稳定性我不好评价它，毕竟没有用过。但是从RAD这十多年来大大改进了开发效率，但是在易维护性上不但没有改进，反而有所退步这一方面来看，EOS的易维护性比较可疑——————这是分隔线————————如果RAD能很好的解决现有的问题？如果OO能很好的解决现有的问题？如果WSAD，如果WORKSHOP能很好的解决现有的问题？我们做EOS干什么？做一个没有市场的产品我们为了什么？新的技术或产品的产生大多有需求去推动。EOS就是。为什么易维护性无法改进，我想猛兄对程序员上的文章如果不是抱着不屑一顾的态度甚至是反感的态度去看，会明白个中原委。也会明白为什么很多其他的技术解决不了，而EOS却是一条很好的出路。再举北方电信的例子。实施方全公司全算上只有三十几个人（包括销售等非技术），可承担着四个省的系统支持任务，没有好的可维护性行吗？EOS可能与此不同，不过它毕竟出来的时间不长，随着时间的推移，维护问题将逐渐显现——————这是分隔线————————这句我本来不想批驳，因为很无聊，但看你这句话的推论与论点，请仔细分析，是不是有些逻辑漏洞？如果在未来维护时需要涉及细节上的变动，就可能受到很多的制约，增加维护成本。——————这是分隔线————————如果小错不是在一个月的学习时间里大都带着对EOS有色的眼镜，这个问题他原本可以代我很好的回答你，学学EOS的BIZLET吧，会找到答案。如果普元的EOS真是如他们所说的那么好，最好还是尽量多地发一些技术文章来证明，而不是扯淡。——————这是分隔线————————发什么文章？EOS的实现过程？EOS实现应用的过程？EOS的技术要点？这些问题我们在程序员上都有相关的文章阐述，请你认真的看一看吧。EOS在全国范围内接单做项目，大部分都是政府企业——————这是分隔线————————是哪一位公司成员讲我们做的项目大部分是电子政务？还是你对我们的项目情况本身就如此了解？我把我们的一部分签单列表出来,请大家审阅。BTW，这只是去年的，我想我没必要把我们签的单全列出来吧。如果有哪些人对“某”字不感冒的，请来我们公司核实。看看这些项目吧，你不会说这些是电子政务吧？与某电信行业集成公司的软件捆绑销售协议某航空局综合楼项目软件销售合同某省移动集团客户营销服务管理系统工程项目销售合同某省网通综合营帐系统项目销售合同某知名服务企业金融本部与普元捆绑销售协议某市联通ＣＲＭ应急系统项目销售合同某市电力行业捆绑协议某行总行客户信息综合管理系统项目合同某省通信电子商务平台项目与某公司的金融行业软件捆绑销售协议某证券公司客户分析系统项目销售合同希望普元别总是这么高来高去的扯，而是揭开头盖让更多人看看是美是丑！——————这是分隔线————————盖头早就揭开了，可你带着有色眼镜总觉得新娘长得丑，是不是试试看把你固有的JAVA观念转变一下，抛开一切个人的利益得失不谈，也不要再想自己是一个JAVA高手，你一定会发现她美的地方。
普元应该不只是做政府吧，我们公司是做电信的，在打单的时候老遇上普元，有好几个单都被他们拿走了。
牛兄太激动了，我只是认为EOS现在的宣传太过于空洞，缺乏令人信服的实际内容。比如像小错那篇那样的，如果普元能多发一些会更好一些。熊兄真是一针见血啊。^O^
有试用版可以下载吗？请问具体怎样可以得到？我倒有兴趣试用试用。BTW: 【不厚道】看了你们的网站，还真是不能令人放心啊……
说实话，VCBEAR、猛兄，小错，你们中任何一位的JAVA水平都在我百倍以上（用小错的形容方式应该是百*百了，呵呵），都是我的老师。所以我根本没有资格去对JAVA说什么。并不是说JAVA高手会看不上EOS，即使EOS达到全行业普及，JAVA高手依然是J2EE企业级应用中不可或缺的灵魂人物，然而他关注的领域不再是底层实现级别或其他最优化的BEAN与JAVA有关的技术设计，而是系统架构和模块划分和分析设计，说白了，与JAVA没关系，而与高手以往的项目经验有关系，这才是“也不要再想自己是一个JAVA高手”的真正含义。说的堂皇些，如果为了中国的软件产业，大家的思考和视角会有不同。
参加大赛，还可以拿奖。^o^
我还以为是eos300d-_-||
TO：牛兄等我忙完这阵，会考虑试试EOS，毕竟现在这样空谈的确没有说服力——所以我在题目上用了“闲扯”。TO：五十偶每次看到EOS也是想想到那方面去了。BTW：EOS 300D已经是过去时了，令狐都用350D乐^O^
言语中多有得罪，见谅。PS.EOS888是佳能的一个老牌子，我的哥们就有一个。吼吼。
令狐虫老兄在小错的博客上的留言中一句话我觉得很中肯：“一个产品被研发出来，总有它的市场和应用。假使没有的话，是这个公司的失误，损失的也是他自己。”普元花好几年做一个产品，现在仍然在不断投入，本身就存在一个至少他们看来存在的市场。当然，是产品就有弱点，就需要不断改进。从技术人员的敏感度来讲，在J2EE领域内，EOS绝对算得上是采用了一种好的思路的产品，当然，他还有很多完善的地方，也当然，他现在也已经发挥出相当的作用。从技术上评价他的优劣的时候，需要在一个相同的技术环境中进行比较，比较的范围也应该更广泛，或许这样得出的结论才更客观，才不算“扯淡”。在我看来，EOS正在做的和要做的，是要讲真正的设计师和开发者分化出来，让技术和业务分化出来，但还没完全做到！
中文编程语言，哈哈哈~~~~~~
看了一下，EOS 888还算是一款不错的机器呢。呵呵。
我对java 也不是很熟悉，因此无权对各位大侠做出评论。但从整体而言，EOS的出现，至少是市场的需要，如果没有需要，那也就没有出现的必要。现在很多朋友对EOS褒贬不一，这个至少在一定程度上说明了EOS受到了很多人的关注。我也觉得在技术功能以及耦合程度上，EOS有很多地方需要改进。但新生事物的发展，是一个过程，也许会失败，也许会涅槃（凤凰版本）。而我们也不要光在口头上说什么‘支持国产’，关键还是靠普元人对待该产品的态度和不断探索进取的精神。
任何一个新事物的发展，道路都是曲折的，愿普元走好，支持国内软件企业的发展！