J2EE without EJB

第一，所谓企业应用，除了联机事务处理之外，还包括联机分析处理。

第二，联机事务处理不等于EJB，就好象J2EE不等于EJB一样。J2EE提供了企业应用所必须的基础设施服务，例如事务管理、资源池缓存、分布、远程。EJB为使用这些服务提供了一种统一的途径。但以现在的角度来看，EJB这种途径既不简单，也不实用，因为我们很多时候并不需要all in one的solution。不会变的是企业级中间件的思想，即以分层的方式提供infrastructures的思想，这可不是什么“EJB的思想”。

gigix 说得也是我想说的，其实要说 OLTP 我们做得确实也不少了，非常复杂的事务控制我们都做过，OLAP 我们也做了不少了。现在突然有个人指教我道：“告诉你，企业级应用其实就是 OLTP”，真是有点哭笑不得的感觉。

曹晓钢总不该还没看Rod Johnson那本书吧？第一章就说得清清楚楚了。没错EJB仍然有它的位置，比如对于真正需要业务对象分布的应用，EJB就是不可替代的最佳选择。对于大量使用异步消息的应用，MDB也很有帮助。但这里的关键是，EJB必须走下神坛。EJB不是J2EE的核心，它只是一种在某些时候适用、很多时候不适用的解决方案。这样一来，也没有说“EJB和without EJB谁更好”的说法了，因为比较的双方都是可选的J2EE方案，都有各自适合的场景。

其实要说oltp我们做的非常少，多少年了，我们的核心系统除了交易还是交易！
非常复杂的事务控制还真没有遇到过！
olap真的没有做过！

那你更加没道理推崇EJB了。你看，需求不是那么复杂，EJB提供的好处你基本上没有品尝到，EJB带来的麻烦你倒是不可避免地全都承担了。难道你不应该找一种更合适你的需求的技术架构吗？如果没有别的选择，如果EJB就是使用J2EE infrastructures的唯一途径，那你没办法；但现在的情况是你有选择，那为什么还要抱残守缺呢？

看了dlee的发言，有一种这样的感觉：终于有人说出我想说的话，赶紧添油加醋，一棒子打死EJB。

就我个人而言，我也不喜欢EJB的繁琐，写一个Hello World就可以让人吐血。号称可以让程序员不了解细节，简化开发，如果真的不去了解，结果常常是死得很难看。

当年EJB出现是为了解决当时遇到的企业开发中问题，而现在Spring、Hibernate之类框架的出现又是为了解决现在遇到的问题，但这并不代表就可以完全否定EJB。如果没有EJB作先驱，那有后来者的精彩。恐怕少有人会只懂EJB的技术，会随着EJB生存毁灭。就我个人而言，我愿意承认自己是个Java程序员，却不会说自己是个EJB程序员、Spring程序员。把自己绑死在一项技术上的人，根本就难以长久，即便是像Unix生命力这样长久的东西，它留下更多的是思想。

如果我现在说Spring也会过时，那是不是我们现在连学习Spring的必要都没有了呢？显然不是。只有有了积累，后面的学习之路才会变得顺畅，当然，我并非鼓励大家都从DOS练起。也许dlee已经对EJB有了深入的研究，才会做出自己的判断，很多初学者面对EJB这样花哨的名词，多半会心向往之。怎么办？学吧！

以我的学习观来看，我会关注“新”东西，也许我会写个小例子，只有当我真正使用的时候，我才会去深入的了解。我们无法以这项技术即将过时为理由拒绝老板吧？除非你有决定权。

不过，以吸引眼球的观点来看，dlee的做法不错，让大家热火朝天的争论起来。^_^

我不推崇EJB，我认为EJB的应用范围很小，可能很多人一辈子也用不到他。
我的意思是：EJB技术自有它应用的范围，怎么可以一棍子打死他呢？凡事不要走极端。

关于选择吗，在有些领域，你是没有办法选择的，比如工行的mova系统，航空公司的售票系统，都可以去咨询一下，问问他们的系统可以选择吗？或许有，或许极少。

现在象集群和分布式处理还没有专门的独立产品，但基础构架上已经有了足够的准备。例如用于支持集群处理的Group communication，在Tomcat3的时候，web层的集群可都是自己用Jgroup写的，而在分布式事务方面，现在用JOTM为TOmcat应用程序提供分布式事务处理已经成为非常流行的做法。

分布式应用方面，象JBoss Remoting这样的产品完全可以发展为单独提供分布式服务的产品，还有很多，不象Jboss有名，但提供透明的remote支持也是由来已久，在我的收藏夹里面至少有3个这样的软件


所以选择还是有的，但这些服务分开提供的能力还没有得到足够实践的考验，如果每个服务的提供者都达到Tyrex和JOTM的水平，那么完全替代EJB体系的时机就会到来

JBoss的发展策略已经初露端倪，我相信JBoss的各个aspect终有一天发展到可以完全脱离整个JBoss核心构架，然后被其他微核心框架所用。还会产生XXXRemoting,XXXJTS,XXXTP Monitor,也会产生Spring,PICO,JBossKernal,XXXMicroKernal，到那个时候，选择一个应用体系就应该选择核心和Aspect，然后把他们组装起来，可以根据不同的应用选择弱于或强于EJB规范规定的所有服务。

奇怪，我看了半天，好像没发现我说错了什么？

EJB是几年前的体系结构了，除了提供一个大而全的解决方案之外，还是一个“商业标准”的解决方案。是的，this is business. 为什么JBOSS要辛辛苦苦花费几十万美元去拿到J2EE Certificate?

EJB做得这么复杂的原因，也就是为了要实现集群/集群transaction,以至于对很多应用来说，成了牛刀。

EJB只不过是一项技术，Jboss的眼光非常不错，他们十分了解目前的技术状况，把几个著名的项目收罗旗下，然后用这些项目去冲击标准本身，JDO未果，EJB3有些成效，既然J2EE都在改变，在EJB3 final spec出来之前，又何必讨论A 和B好的问题？Jboss的这种眼光才是具有战略意义的，一个项目的得失，可能不足以影响产业的格局，如果能够从标准上突入，开放源代码的产品却很有可能成为下一个十年的主流。

集群，假若现在要实现一个真正的高端系统（考虑一下，比如说现在的网游，拿传奇的例子来说，是delphi写的集群核心），那么目前最成熟的，还是用EJB,拿集群来堆出一个高在线的系统出来。

tomcat的集群，Jboss正在做一个group communicate,用于给tomcat加上session复制等基础的集群特性。

这些都会作为JBOSS的下一个版本的标准特性。我觉得Jboss可以代表下一个十年的技术基础。

在这个thread 里面，除了potian的这个帖子，其他所有的帖子，对我来说都喝白开水一样，没有什么营养。

我赞同potian的看法。面向aspect，我认为其实还是面向组件的开发，只不过经过这些年的发展，微内核等架构的发展已经渐入人心，而且我们又有了支持这样架构的开源工具。其实spring如此流行也是因为它核心框架能够较好的支持组件的开发。至于像ejb这样的技术，我们也可以完全看作是系统服务组件，在一定的技术保证下，需要时能够透明的为我们的业务提供服务。我有过这样简单的尝试，组件运行可以自由在ejb和非ejb的环境之间切换。这样，开发人员就不必在意。

我也不认为ejb会就此淡出，地位削弱倒是很有可能。

potian兄对微内核的研究已经有好久一段时间了吧，我最早也是在你的影响下找到了pico这样的微内核框架。自己写了点玩具，在项目中自娱自乐一番。