当前页面: 开发资料首页 → J2EE 专题 → 关于对J2EE几点误解和错误认识的澄清
关于对J2EE几点误解和错误认识的澄清
摘要: 关于对J2EE几点误解和错误认识的澄清
.Net和J2EE的争论一直没有停止，我也参加过“程序员”杂志主持的“.Net和Java之争”之类的讨论，本来这两种技术都是为用户提供了竞争性的选择，对于用户来说是一件好事，多种选择远胜于单一选择。
但是，一些个别人员或狂热者因为一些目的，故意扭曲J2EE，一叶遮目，因此必须针对这些谣言和误导澄清一些技术细节如下：
误导一：
Java阵营对EJB的看法
（1）J2EE项目中只有10%使用EJB
“EJB makes Java look bad. ”
（2）Sun’s Java PetStore:
“write your data persistence twice” . “bi-modal data access layer”
（3）IBM Redbook: 不要使用EJB, 用存储过程
（4）James Gosling, Borland Developer conference, May 2002
You have to manage it by ignoring it. The complexity of J2EE is pretty extereme…There’s a dirty little secret about J2EE; most people don’t need J2EE;
澄清一：
（1）“J2EE项目中只有10%使用EJB”
这是很早以前的过去式统计，过去有10%使用EJB，不代表将来就只有10%使用EJB。
对EJB反感主要来自于Java阵营中那些Web层所谓轻量级开源软件开发者，他们的理想是将所有业务（包括持久层）都包括在Web层中，用JavaBeans完成，自己实现缓存、对象池以及事务机制等等，这些底层技术很明显是发烧级别的技术，在一般商业应用中如果也要靠程序员自己完成这些低层机制，那么最后Java都没有人使用了。
EJB帮助一般商业应用实现了这些底层机制，无需开发者自己实现，所带来的条件是开发者必须按照EJB规定来开发程序，EJB使用的这些限定条件对于那些倡导自由的狂热发烧级别的开源开发者来说，简直是无法容忍的，我已经在很多英文媒体上看到这种不满和攻击。可笑的是，国内有些刚涉及Java的程序员为了显示自己是一个高手，进行项目咨询时，第一句就是：我不要EJB。
（2）Sun’s Java PetStore
SUN的Petstore只是J2EE设计思想的一个展示品，它离实践有一段距离，而且它没有加入一些优秀的开源软件开发框架，致使它的性能等指标都存在一点问题，这点问题就成为.Net攻击Java的口实，其实，这点在国外已经达成共识了，因为这种攻击如同指责时装模特的时装无法穿到大街上一样可笑。
（3） 不要使用EJB, 用存储过程
了解J2EE的人已经知道，EJB不只是操作数据库，因此这句话可以理解为，不要程序持久层，只用数据库的存储过程，如果真是这样，.Net也无需诞生，全世界软件业只有数据库，也没有cobol、java等其它可操作数据库的语言了。
数据库存储过程是提升数据库性能的一个方向，是一种“向下思维”，把活向细处做，说句开玩笑的话，大概直接用汇编语言将数据库和数据操作一起实现性能是最快了。“向下思维”的一个缺点是会过分依赖数据库厂商，通用性不强，同时业务逻辑也可能混淆在存储过程中，很多存储过程的复杂语句包含了非常多的业务逻辑在里面，大概只有编制者才了解这样的奥妙，这种情况不是软件工程中愿意看到的。
还有一种思维是“向上思维”，通过层、架构来提升数据库系统的性能，设立专门的持久层负责数据库操作，使用缓存Cache以及多台分布式Cache将是一个新的方向，将数据库数据放在内存中，既做到程序的数据库操作通用性，不依赖具体数据库产品，又具有可拓展性和伸缩性。。
（4）James Gosling也不喜欢J2EE
这位号称Java之父的程序员也不喜欢J2EE，我想其中一个很大原因大概是Java的发展已经出乎他的意料 之外，而且不为他控制的超前发展了，幸亏他不是J2EE之父，否则，我倒是也要放弃J2EE了。
（5）小结
有人说过，Java的毁灭可能来源Java社区本身，在这个充满活力和创新的社区中，有多种先进的J2EE开源软件支持着更广阔的商业应用，当然也难免有争议和指责声，后者容易被对手利用，但是我们已经知道，最可怕的还是，永远只有一家公司的一种声音。
误导二：
有各种统计数据如Web测试、分布式测试或性能测试等对比显示，J2EE明显不如.Net
澄清二：
独立的middleware-company.com公司在其首页明确指出：
According the Gartner Group, 70% of Java projects fail due to lack of skills
上述测试数据来源于如何正确使用J2EE，如何使用J2EE是一个很大的学问，如果没有使用正确，那么就会导致上述测试结果。
误导三：
.Net与J2EE是企业应用解决方案的技术
.Net与J2EE在体系结构和主要技术上有明显的对应性
.Net与J2EE的差别主要体现在开发效率, 性能, 成本和可靠性上
独立的MiddleWare测试表明, .Net在开发效率, 性能, 成本和可靠性上明显优于J2EE
澄清三：
前面三句是正确的，最后一句是偏颇的，这句混杂在三条正确语句后面，就具有误导之嫌！
开发效率：
如果将.Net的强大开发工具和环境和J2EE的ant以及EditPlus编写J2EE这样开发方式相比，当然是前者给初级用户带来很大的开发效率和方便，但这种类比是不公平的。
使用Borland JBuilder 8.0以后的开发工具，在J2EE开发效率上根本丝毫不逊色于.Net，J道提供这样的开发教程，非常方便。
性能：
性能永远是使用者的问题，如果把Java的性能归结于解释型语言等错误原因上，那还需要你多补一些Java的课程。
如果需要开发出一个优异的性能系统，无论是.Net或J2EE，程序员和设计师都需要有专门的培训和咨询指导。
成本：
J2EE有那么多免费的开源软件支持，成本就几乎为零，J2EE服务器使用JBoss，使用Struts+EJB，JBuilder X将提供这种优美框架的可视化开发工具，多美好。
当然，.Net在中国使用也是“免费”的，因为几乎都是盗版，他也懒得管。
可靠性：
有多年成熟应用的J2EE技术带来的最大优点就是可靠性，每个技术细节直至底层，都可能是开源的，基于Linux的运行可靠性已经为更多实践证明，曾经收购易趣30%股份的eBay，全世界最大的网络拍卖系统，就是使用J2EE建立的，每天有多少关键业务在这个系统上运行？《J2EE核心模式》一书有很多模式来自他们的实践总结。J2EE在银行、保险等领域成熟应用的事例比比皆是，他们的多年运行经验都用事实证明了J2EE的可靠性。
相反，饱受病毒大幅度侵蚀的Windows系统才会给人带来可靠性的疑问，它的成熟应用也许刚刚开始。
误导四
.NET的性能明显优于 J2EE ：
Web应用服务
事务性能
XML Web 服务性能
澄清四
是否对Web服务（Web Services）优于支持，主要取决于支持这类标准的API是否丰富方便，作为Java的发明者Sun公司现在已经成为一个Java标准指定者，他的Java/J2EE产品实用性其实不强，Web Services作为最近由微软和IBM等倡导提出的标准，要落后于J2SE 1.3 API版本的推出，Sun不可能在短时间内将这些应用加入标准的JDK库，而且没有必要，有很多开源软件支持Web Service就非常优秀，如 Apache的Axis。
Web Services的概念其实是Java语言概念的Copy，如果你的系统都是使用Java建立，那么，Java提供的支持，无论性能还是拓展性等方面远远超过Web Services。
因为更多人知道Windows，因此更多人知道了Web Services，并为此激动，而忽视了几年前Java提出了同样思想，只因为不知道，但是他们是客户，这好像类似政治了吧，这里避开。
在我的书籍《Java实用系统开发指南》中，关于肥客户端.服务器模式下，我就推荐直接使用Http+EJB实现远程调用，省却Web Services中的XML转换带来的性能消耗。
Web Services的最大问题还是安全，这正如Windows的最大问题一样，如果他们认为这是他们的一贯产品特点，那么我们还在这里实现什么比较呢？
澄清误导五
主要一个误导言论是：来自TSS（著名Java社区theServerSide.com）的母公司middleware-company(TMC)向Java社区提交了一份J2EE和微软.Net应用架构的评测报告，Java开源精神领袖Rickard Oberg在第一时间分析了用于评测的源代码，以压倒性的证据推翻了TMC的结论。
但是，middlerware-company这份报告还被别有用心的少数人作为诋毁J2EE的证据。