|
整理：mouri |
0==========
原文(proger于2001/05/28 23:10粘贴)
EJB的困惑
--------------------------------------------------------------------------------
EJB是一样号称开发周期短、运行性能高、结构合理、可维护性好、能减少开发成本的东东，可是最近做一个EJB实现的项目，却感到现实与理想似乎相距遥远：
各种运行EJB的应用服务器价格高得惊人，而且对硬件有惊人的需求。昂贵的软件，却没有友好的界面，光是配置就伤透了脑筋。应用服务器运行时需要占用大量的系统资源，对其图形界面进行操作时，感觉就好像回到了4兆内存跑WIN95的年代，DEPLOY时更是疯狂读盘，速度缓慢。（机器的CPU是不赖的，只是内存“小”了点，256兆，OS也不赖，是饱受好评的LINUX）
EJB的运行效率又有多神奇呢？我的朋友参加开发一个系统，在SUN服务器（e450？现在新买的SUN标准配置都是1G内存）上跑weblogic，当出现70个EJB实例时，服务器就顶不住了，而他们并没有什么海量数据要处理。那么这是什么优秀的性能？
说到减少开发成本，缩短开发周期，就更不敢恭维了。JAVA的开发工具都具有一个共同的特点，就是运行速度慢。仅此一点，每天浪费掉大量的时间来等待机器完成工作。在我们公司，JAVA组是机器配置最高，但计算机工作速度最慢的一组。JAVA语言的各种中文问题、NULL POINTER EXCEPTION、配置错误，再加上EJB开发过程的诸多步骤，常常让人忘记要开发的企业逻辑本身，而疲于奔命。
最后就是可维护性了。EJB的东西还没做出来，可维护性如何，不好说。但看看过去做的JAVA应用程序，有多少可维护性，SUN的JAVA 2和JAVA 1是不兼容的，这造成多少程序被迫重写，并且同时维护JAVA 2和JAVA 1两个版本（请看ORACLE JDBC的CLASSES11.ZIP和CLASSES12.ZIP）。从AWT到SWING的升级不知让多少JAVA程序员熬过无数不眠之夜，从com.sun.java.swing到javax.swing又让他们再次没法睡觉。JSP0.91到JSP1.0的升级，对已有的程序，也是致命的一击。
EJB的方案既然定了，就还是要做下去，如果不是定下这个方案，我甚至不会有现在的这份工作。然而这么些年来，尤其是最近与JAVA搏斗的经历，确实让我感到困惑，感到JAVA是一个笨重、昂贵而有吸引着无数英雄竞折腰的怪物，而我，也不得不为其折腰！
1==========
原文(tacone于2001/05/29 00:44粘贴)
回复: EJB的困惑
--------------------------------------------------------------------------------
我不是JAVA程序员
也许BORLAN的KYLIS是你的福音，基于LINUX下的RAD
如果在WINDOWS平台 转向C#吧
11==========
原文(nbmoon于2001/05/29 01:38粘贴)
what is KYLIS?
--------------------------------------------------------------------------------
111==========
原文(chenxu7103于2001/05/29 02:20粘贴)
回复: what is KYLIS?
--------------------------------------------------------------------------------
可以说是 Delphi for Linux。但对象模型不一样了。
2==========
原文(poorjim于2001/05/29 09:01粘贴)
回复: EJB的困惑
--------------------------------------------------------------------------------
JAVA 是这样的啦
不过还要多方面调试性能才行
我们前一段在AS400用WEBLOGIC开发的银行综合业务系统，用的是1。1。7
很低吧，开始的速度让人无法忍受，但多次调优后，现在还行。
还有一个用EJB的网上交易，在RS6000上的，速度也不错，
当然都在2G可4G内存
在并发上，要考虑的多些，
70个实例可能是代码与连接设计的不足。
21==========
原文(fancyh于2001/05/29 14:54粘贴)
请问 to proger
--------------------------------------------------------------------------------
客户端是应该直接调用Entity Bean的方法还是
应该建立一个session bean，通过session bean 来操作Entity Bean？
211==========
原文(proger于2001/05/29 15:55粘贴)
回复: 请问 to proger
--------------------------------------------------------------------------------
这个问题好像比较有争议,我倾向用stateful session bean调用entity bean,
但担心性能问题.现在是用stateless session bean 调用entity bean.
2111==========
原文(fancyh于2001/05/29 16:08粘贴)
回复: 请问 to proger
--------------------------------------------------------------------------------
那么对于采取了Ejb的系统的查询，你们怎么考虑？
我觉得一个一个地写findBy**是不行的，那样很难处理复杂的查询，比如
做报表，做统计。也想过findBySql来传入一个动态的sql语句，可是那样
等于客户端是直接知道数据库上的表结构了。好像看到金蝶的说他们可以（将来）
提供ejb sql，直接用这种类sql语言查询entity bean。在weblogic或websphere
有类似的功能提供吗？
21111==========
原文(caozq于2001/05/29 16:51粘贴)
回复: 请问 to proger
--------------------------------------------------------------------------------
我的做法是往往写一个Stateless Session Bean直接访问JDBC获取数据。
3==========
原文(evpu于2001/05/29 09:30粘贴)
It's too much to run concurrently 70 EJB objects on a j2ee server in only one machine.
--------------------------------------------------------------------------------
I think EJB take one of the most advantage that is distributed naturely.If you are sure to use only one machine as the application server maybe it is better to use jsp+servlet+javabean technology.
31==========
原文(proger于2001/05/29 14:38粘贴)
回复: It's too much to run concurrently 70 EJB objects on a j2ee server in only one machine.
--------------------------------------------------------------------------------
EJB=spend more money,do the same thing?! :((
311==========
原文(evpu于2001/05/29 15:28粘贴)
I think it is more applicable to a large-scale system.
--------------------------------------------------------------------------------
Maybe you just supplied an impropriate solution to an impropriate company.
I think you should differ the situation outback from oversea.
The software system is the most cost in a solution to the corporate but not like the opposite state considered by those ceos who you know are charge in the domestic companies.
32==========
原文(tianxiaoji于2001/05/29 17:06粘贴)
pattern is more important than performance
--------------------------------------------------------------------------------
ejb pattern provides us a premature way to use o-r mapping, distributed computing and components. it's easier than corba( based on corba ), more scarable than dcom. used it in a proper way, it will give you surprise.think more about applicative conditions, read more j2ee specification, ejb specification. keep in touch with ejb tech, it will be mature within a few days.
thinking in a way in which enterprise solution provider thinking.
sorry for writing in poor english, i am working on a english platform.
4==========
原文(caozq于2001/05/29 11:53粘贴)
回复: EJB的困惑
--------------------------------------------------------------------------------
对此我也深有同感。
但我觉得EJB不是万能的，它系统中有自己的职能。一般来说，在高强度的事务处理中使用EJB将是相当不错的。但如果仅仅开发一些门户网站之类的应用，那还不如用Servlet。
另外，EJB仅仅是一种工具，是实现某种设计理念的工具。这种理念就是Boundary/Controller/Entity模式。
关键是不能为EJB而EJB
41==========
原文(proger于2001/05/29 14:34粘贴)
回复: EJB的困惑
--------------------------------------------------------------------------------
:但我觉得EJB不是万能的，它系统中有自己的职能。一般来说，在高强度的事务
:处理中使用EJB将是相当不错的。但如果仅仅开发一些门户网站之类的应用，那
:还不如用Servlet。
我们正是要进行高强度处理.不知"一般来说"怎么讲?
:另外，EJB仅仅是一种工具，是实现某种设计理念的工具。这种理念就是
:Boundary/Controller/Entity模式。
:关键是不能为EJB而EJB
我的困惑就在于 Boundary+Controller+Entity?=更昂贵+更缓慢+更难配置?
411==========
原文(caozq于2001/05/29 16:45粘贴)
回复: EJB的困惑
--------------------------------------------------------------------------------
1）如果是这样，没有什么可犹豫的，用EJB吧；
2）J2EE框架肯定是面向高端的客户，肯定需要付出CPU、内存。。。。。。
如果觉得这些不太划算，可考虑Microsoft的DNA体系（ASP&COM+）,那也是不错的方案。
3）本人觉得，JAVA的最大好处在于它是最彻底的体现面向对象思想的语言。也就是说，它是最接近于问题领域。从计算机软件的发展来看，从机器语言，汇编语言，高级语言，4GL。。。直到面向对象的JAVA，其趋势是越来越接近问题领域。很难想象，现在还会为节省CPU、Memory资源而去使用汇编语言（当然特殊的如Embeded Software除外）。
5==========
原文(jiank于2001/05/29 12:03粘贴)
回复: EJB的困惑
--------------------------------------------------------------------------------
有优点就有缺点，要用一分为二的辨证方法看问题
6==========
原文(davidqql于2001/05/29 12:22粘贴)
SUN公司的东西从来就是这样
--------------------------------------------------------------------------------
最开始，我用Sun公司的工作站，同时还有其他公司如SGI,IBM，HP的工作站，从来只有SUN公司的机器死机。
JAVA是一个解释执行的程序，谁会相信它的性能会高，简直奇怪。原来我们准备采用JAVA进行系统开发的，后来发觉它的种种局限性，只好放弃了。
既然EJB这样糟糕，还不如更换它算了。
赶紧把JAVA扔到爪哇国去吧。
7==========
原文(tianxiaoji于2001/05/29 17:11粘贴)
回复: EJB的困惑
--------------------------------------------------------------------------------
ejb pattern provides us a premature way to use o-r mapping, distributed computing and components, middle tier enhancement. it's easier than corba( based on corba ), more scarable than dcom. used it in a proper way, it will give you surprise.think more about applicative conditions, read more j2ee specification, ejb specification. keep in touch with ejb tech, it will be mature within a few days.
you can search for o-r mapping solutions other than ejb , maybe toplink.
thinking in a way in which enterprise solution provider thinking.
sorry for writing in poor english, i am working on a english platform.