谁偷走了我的ejb？

首先介绍一下，我所在公司的主要产品是中国移动的BOSS－－基础业务
支撑系统，用户总数大约3000人，同时在线1000人，也许这里有的道友
还是同行。

论坛里的帖子看了一些，让我很疑惑的是为什么EJB看来是如此的成功
但我却发现在公司和其它竞争对手中使用EJB的是少之又少

bea不断声称自己的weblogic是如此的出色，以至于weblogic 8出来后
我们这些日日夜夜的不停推磨的驴子简直都可以洗洗睡了。
但具有讽刺意味的，tuxedo可能是bea在中国的企业级应用中使用最受
认可的，稳定而又快速。
倘若bea问我们为什么也买了它的weblogic，我们只能告诉它因为sun的
iplanet不停的挂掉，我们终于受不了，也不敢再相信sun one server
选择weblogic实在只是我们需要一个支持jsp的可靠的web server罢了

我们公司boss系统的结构大约是weblogic(做web server)+tuxedo+存
储过程、事务基本都是放在存储过程中实现的，也许会有师兄说真傻，
好原始。确实，听起来好像就在原始社会，但真是不知道还有多少个公
司和我们做了一样的选择。尽管结构不清晰，代码可读性差，移植性
差，每换一次数据库就是一项浩大的工程，天数的存储过程要改写，
（经常有一些db厂商的好东东让你非常想用，可是等移植的时候就恨不
得全是sql92）。痛苦的就是这样做牺牲的情况下，系统速度还是不理
想，每月初是一个使用高峰，都要过一次小关，阵痛一把。如果用
ejb或者hibernate不知道能不能实现如此复杂的事务，实现了又是什么
样，个人估计就算不死成什么样，也不知道会慢成什么样。
另一公司因为使用jsp+javabeans 两层结构，使用jdbc直连数据库（相
同水平下，理论上速度应比使用ejb更快），慢的导致用户不满，已经
被中途踢掉了。

说到这里，或许有人会说那是因为你们设计不合理，管理不到位，试问
如果我们用c做的出来，用java做不出来，是不是充分证明我们java水
平很低。那其它的公司也做不到，又是什么原因，是不是充分证明我
们整个中国程序员的java水平都很低？倘若是，java门槛这么高，我们
岂不是永远要喝三块钱的稀饭，看着sun、ibm们来大鱼大肉

有人曾经说，为了系统的扩展性，我们应该牺牲一点性能。我不知道他
遇到的是什么样的用户，我们的用户要求是稳定第一、性能第二、扩展
性他们并不关注的，用户并不知道程序是什么的，他们只知道功能是什
么样，是否按照要求实现，扩展性根本不是他们所关心的。不要让我们
陷入程序的误区，因为写程序而写程序。一些工作都是要赚钱的，不正
视肯定要碰钉子，就象拍艺术电影的总看不起拍商业电影，实际上那一
样难度更大，不用说也明白的，如果商业电影容易拍，那帮人早溜光了
去挣大把rmb
//sorry 走题了，：）

也许，在电信这个领域比较特殊，不知道banq、bruce、robbin、icean
们经历过多大的项目，能否以下面的指标指点方向：多少人使用，什么
样的业务复杂度，最大并发数多少，最大并发时每笔事务平均耗时等
数据库表的多少能否表明业务复杂度？我们的表大约是一千多张。请不
要说他们数据库设计水平低，我对设计数据库的同事们有相当信心

其实很想用J2EE，java人不用J2EE就好比鸟儿被剪了一只翅膀，我在
学习hibernate中、希望不久的将来可以有所运用，说sun在搞JBOSS，
做的是同样的工作么？也许象大客户管理，网管，oa什么的可能早点
用上
应该承认java真是很慢，但情人眼里出西施，没办法，我就喜欢

如此之多的人认为EJB的性能存在严重的问题，以至于我想说说不同的意见。

首先我想声明，我并不是认为EJB模型没有任何问题，我本身也没有非常丰富的大工程的经验；之所以跳出来出话，可能是因为我的一点点哗众

取宠的心理，再加上一点点探索精神。

对于一个项目，我们首先明确目标是什么。如果是外包的项目，也不会涉及升级的问题，那么扩展性就完全可以抛到一边。如果是自己的项目

，可能就需要明确扩展能力了。我认为你提到的“扩展”是指接入新的应用的能力，与Scalability没有关系，Scalability是指能够应付不同

规模的客户端的能力。如果有误解，请纠正。
我们讨论性能。如果你认为EJB的性能有问题，请证明给我看，最好使用数据来说话。我不认为EJB有致命的性能问题，如果能够列举出数据来

，也算是为我解惑吧。楼上的在文中也说了jsp+javabean+jdbc都不行，就不能证明问题是在EJB模型中。

下面我做一个定性的分析，请有条件的网友能够做一个测试，得到其中的一个延迟的数据。
我们知道，对于一个典型的三层应用来说，大致过程是这样，客户端web browser<==>web server<==>EJB<==>DB，假设“<==>”是指代网络。

那么来分析一下中间大致有哪些过程消耗了大量的时间：
1、从browser到web server的网络传输延迟；如果是internet应用，这个延迟可能达到秒级；web browser处理的时间就忽略不计了。
2、web server除了处理客户的http请求，它还是一个EJB client。那么这里一般使用JSP/Servlet，在web server这一层的时间消耗到了哪里

？我想对于少量客户和大规模的客户群是有不同的情况的。少量客户的情况下，时间可能主要是消耗在了EJB client对请求进行

marshal/unmarshal中，如果有大量的请求到达，那么处理请求的时间就会变长，如果web server成了整个应用的瓶颈，可以考虑一下使用

cluster了（比如apache web server）。
3、从web server到ejb server的网络延迟，这部分的延迟应该是以毫秒来计的。这个网络延迟可能会成为瓶颈吗？我不知道。
4、EJB server的处理。EJB server对数据进行unmarshal/marshal，应该也消耗了不少的时间。java抛出异常、进行type cast等操作都是非常

耗时的操作。如果这部分成为瓶颈，可以考虑Session Bean cluster；
5、从EJB server到DB的网络延迟；
6、DB操作，这部分是耗时的，可以考虑不同数据库操作的频率，以便进行表格、查询的优化。

其中还有事务是比较耗时的。
总之，我认为EJB+三层结构，存在很多优化的空间，如果觉得性能有问题，就找出问题，然后试图去解决它；而不是凭直觉去做判断。
如果考虑成本，可以去评估一下开源的东西。

主要是EJB体系过于繁琐,导致了只有专家才能设计出真正高性能的应用,不过这也不矛盾,EJB本来就是"高端"架构,有哪个做高端应用的人不是专家呢?
不过enity bean的确应当是optional的,可能,MS的体系中就没有实体组件,也许它今后能变好.


用ejb开发的大部分项目都是为了用ejb而使用，如果不是基于分布，安全的原因，完全不必用ejb，否则只会带来麻烦和更多的花费。

可以考虑用c来开发部分模块，或者使用多个application server。 别用ejb了，ejb的会更消耗资源，更慢

我想说的是：使用EJB，一定要用好，一定要会用，根据自己的应用定制好自己的框架和参数，而且能够规范化，使更多程序员的开发能纳入EJB和自己的开发框架内，这样才能真正发挥EJB体系的优点。

我也想听听，就电信这个boss系统来说，用java有什么好的解决方案。我在电信业做过3年，当时一直都是用c,现在到金融公司了，用oracle,pl/sql,逐渐用了些java。

一般电信应用中，JMS框架使用比较普遍，而EJB的MDB使得JMS使用非常方便，有兴趣者可以多研究一下JMS。

ejb最大的问题不是如何使用，而是是否该使用。

这是tss的一次讨论，上边很多发言都有一定的启发性。
http://www.theserverside.com/home/thread.jsp?thread_id=8961

这篇文章也很有参考性。
http://www-900.ibm.com/developerWorks/cn/java/ibm-ejb/index.shtml

>ejb最大的问题不是如何使用，而是是否该使用。

是啊，原本是否该使用EJB不是一个首要问题，大家应该把精力放在如何使用上。

因为有开源代码的那些Web高手反对，他们以所谓轻量级的思想引导一批人向和EJB导向相反的方向走下去。

但是实践中，以一两个开发高手为主开源开发模式并不适合工程软件开发。

这是两种方向，所以有人说Java的危险失败是可能来自于Java社区阵营内部。

刚好一样咯，这里是电信boss，呵呵～

搂主说的还是现实问题，自然不是想怎么弄就怎么弄的，这个是团队，或者，经常是领导的问题

至于ejb，按照经验，包括bea的ps说的，只建议用stateless的和MDB
实际上，在听他说那句话以前，我们这都是这样做的

最后，handle你的很多想法，很多东西都是有历史原因的，改不了就算了
不过把存储过程干的事情移植到tuxedo上，还有比较有必要的，效率也不会低

我不觉得事务放存贮过程里有多傻~~ 在电信行业里，讲的就是垄断~~ 别想着兼容，能不兼容的，就不兼容，要是谁都可以做核心网，华为还吃什么?? ^_^

在电信，你用了一家的产品，最好配套的产品也用同一家的，要不然出问题你自己负责~~，反正羊毛出在羊身上，最后还不是用户在负担~~ 运营商犯不着去想什么迁移，兼容的问题，他们只要想着 money money 就可以了。

至于设备提供商，只要想着让自己的产品更多的装到运营商的机房里就可以了，谁装得最多，谁就是老大，别人自然想着与你兼容，你不用过多考虑兼容的问题了~~ 到时，这些用存贮过程写的逻辑，就是其它厂家的必备手册，嘿嘿~~

想想智能网业务生成系统，用 GUI 的方式像开发 Workflow 一样，在业务逻辑设计器里直接画个流程，然后在其中写些脚本，最后 deploy 到事务服务系统中，多好玩啊~~ 多有吸引力啊。 比现在的业务要强吧~~ 现在要开展一个业务都是提供商先做好，然后统一安装到运营商那的，运营商根本不可能定制，通过这个业务生成系统，你是不是觉得运营商以后就可以自己定制智能业务了呢?

我笑~~~ 我不是在嘲笑这种技术，这种想法很好，但是，在电信这个行业里，这样的东东如何能够生存。对于运营商来说，他们为什么要承担这样的东东带来的风险，要知道，如果是提供商提供的业务，出事了，提供商要出 money 的，但是如果是运营商去做，那出事了，就只有运营商自己去背了，何必呢~~ 对于提供商来说，为什么要多此一举去做这玩意？除非他们想自己用，希望自己以后能更快的生成业务，在行业里能取得更有利的地位~~


另，你说的 BOSS 指什么? 我反正是没搞清楚，也不知道有多少人搞得清楚，更不知道是不是搞清楚了的人脑子里的 blueprint 是不是一样的。

同道啊。个人认为：OSS上不宜使用EJB，BSS上还凑合。

missxkl说的不错。在中国的电信行业已实现的项目，真的没有一个使用EJB的解决方案，速度能达到甚至接近
使用事务中间件的解决方案。电信行业的JAVA程序开发水平低，也许是的。比中国的JAVA程序平均开发水平低，
恐怕不是。从WLS，WS在中国的销售情况，电信行业的JAVA程序开发投资情况看，事情远不是这样子的。

在OSS领域，也许永远都不合适使用EJB。在BSS领域，比如CRM，使用EJB是可能的（也许不是最合适的）。借助
工具，开发和改动EJB都比较简单，合适BSS中需求变化快的特征。就算这样，这个解决方案也不比使用事务中间
件的方案更好。

事实上，正在推动采用EJB的理由可能并不是EJB本身。而是EJB可以比较容易的与其他很有用的技术方案结合，
比如Portal，比如Workflow。这些东东，客户有实在的需求，并且没有其它的技术方案可以替代-暂时没有。

其实，面对了那么多legacy system

不可能有pure j2ee项目在boss中实施的

不过我们这里使用ejb作为中间层访问tuxedo corba，效果很好

下页