ejb一直是一个让我很纠结的技术，虽然ejb作为sun推荐的最佳实践，在sun的J2EE教程中，推荐jsp和servlet作为view层，ejb作为业务逻辑层。
上述就是J2EE教程讲J2EE体系中J2EE的EJB示意图了，讲了EJB的位置，详情可以看:http://docs.oracle.com/javaee/1.4/tutorial/doc/
然而我所接触使用ejb开发的程序员(都是国内)，用了ejb，都没什么特别好感，甚至我以前的项目经理说，很多人被sun给欺骗了。
目前ejb已经出到了3.x了，然而国内已经几乎没有使用ejb3.x，有的也是ejb2.x，都是老系统遗留，有的是银行项目，有的是erp项目(都是大型项目)。
之前jboss出名就是因为它支持ejb，并且支持得最好，然而现在随着ejb的使用份额下降，这几年jboss在国内的使用份额也下降了，用tomcat和其他开源服务器多了很多。
我也很少用ejb，在开发中根本不用，除非是以前为了支持一些老系统，才会接触，而且为了应付ejb的，学了ejb3.0，但是遇到的项目全部是ejb2.x，ejb3.0相比ejb2.0，简单了很多，不想ejb2.0那么繁琐，为了一个业务逻辑类，要写业务接口类，home类啥啥的，我觉得进步很大，但是在国内依然没什么人使用。
这里就谈一下我对ejb的一些看法:
1.ejb是比较重量级:实现ejb是一件很复杂的事情，J2EE规范中ejb规范的实现是一块硬骨头，而ejb实在复杂，很多开发人员都喜欢简单的东西，复杂的东西，会带来未知风险。
2.ejb的移植性低:虽然ejb是遵循J2EE规范的，但是各个厂家在实现J2EE EJB的规范的同时，也会加入自己的一些实现，例如你要让一个EJB查找一个数据源，这个数据源如何配置，几乎所有的应用服务器厂商都不一样,weblogic，websphere，jboss，apusic都有自己的一套实现方式。我每次想到移植ejb的应用，最怕是去找这些不同点，然后一一修改相应配置。这无疑加大了开发人员的负担，java的东西，平台可移植性就是一大亮点。
3.ejb调用流程:ejb是支持远程调用，客户端值需要ejb的业务类接口，服务端值需要ejb的业务类实现，然后客户端只需要调用jndi(这个规范实现很复杂，使用比较简单,还是很多人用)的lookup方法，就可以使用业务类接口直接调用服务端实现类的方法了，这中间，应用服务器做了很多处理,基本流程都是:客户端通过jndi和业务类接口，调用对应ejb应用服务器厂商jndi的lookup服务端实现类方法，然后ejb应用服务器生成业务类的存根和代理，存根从服务端序列化到客户端，客户端调用的ejb业务接口就是调用这个存根，然后这个存根又通过rmi协议或者iiop协议发送命令到业务类的代理，代理再调用业务类实现，最终把执行结果返回到客户端。
3.ejb难以调试:看到ejb的调用流程，虽然看上去ejb让用户不用了解远程调用细节，使用简单，但是由于里面的调用过程复杂，一旦有一个环节错了，用户都难以调试，排错，开发过程中出现问题不可避免，而解决ejb的问题，解决周期要比较久。出错的时候，错误信息也千奇百怪。
4.ejb的性能问题:ejb的调用涉及太多类的序列化和反序列化，本来通过网络传输已经很慢了，还要传递对象，数据量又更大了，还要涉及了对象的序列化和反序列化，这中间有太多的开销了。
5.ejb的替换开源产品太多了:现在业务逻辑，在java上要用框架的有spring，远程调用，有webservice(apache cxf已经做得很好了，而且webservice又是通用标准)，mina(一个apache的NIO框架)，netty(现在性能最快的NIO框架，来自jboss).而且这些产品都是可移植，社区交流多，出了问题，google就找到了。
