EJB Enterprise JavaBean,企业级javabean,是J2EE的一部分，定义了一个用于 开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具(SDK)。 是Java的核心代码，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和消息驱动Bean（MessageDriven Bean）。会话Bean是为了完成业务逻辑, 实体Bean是为了完成数据/映射, 消息驱动Bean是为了完成消息发送. 有点像SSH.都是框架性的东西。
Enterprise JavaBean(EJB)是一种服务器端组件体系结构，它简化了Java开发企业级的分布式组件应用程序的过程。通过EJB，我们能写出可扩展的、健壮的和安全的应用程序，而不用自己去写复杂的分布式组件框架，EJB 开发服务器端应用程序，通过利用由业界提供的预先写好的分布式基础结构，我们可以快速而且轻松地利用Java构建服务器端组件
EJB是sun的服务器端组件模型，最大的用处是部署分布式应用程序，类似微软的.com技术。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。
EJB (Enterprise JavaBean)是J2EE的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具(SDK)。
在J2EE里，Enterprise Java Beans(EJB)称为Java 企业Bean，是Java的核心代码，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和消息驱动Bean（MessageDriven Bean）。
1.Session Bean用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当客户端请求时，容器就会选择一个Session Bean来为客户端服务。Session Bean可以直接访问数据库，但更多时候，它会通过Entity Bean实现数据访问。
2.Entity Bean是域模型对象，用于实现O/R映射，负责将数据库中的表记录映射为内存中的Entity对象，事实上，创建一个Entity Bean对象相当于新建一条记录，删除一个Entity Bean会同时从数据库中删除对应记录，修改一个Entity Bean时，容器会自动将Entity Bean的状态和数据库同步。
3.MessageDriven Bean是EJB2.0中引入的新的企业Bean，它基于JMS消息，只能接收客户端发送的JMS消息然后处理。MDB实际上是一个异步的无状态Session Bean，客户端调用MDB后无需等待，立刻返回，MDB将异步处理客户请求。这适合于需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个方法调用直到返回结果。
EJB实际上是SUN的J2EE中的一套规范,并且规定了一系列的API用来实现把EJB概念转换成EJB产品.EJB是BEANS,BEANS是什么概念,那就是得有一个容纳她,让她可劲造腾的地方,就是得有容器.EJB必须生存在EJB容器中.这个容器可是功能强大之极!她首先要包装你BEAN, EJB的客户程序实际上从来就不和你编写的EJB直接打交道,他们之间是通过HOME/REMOTE接口来发生关系的.它负责你的BEAN的所有的吃喝拉萨睡,比如BEAN的持续化,安全性,事务管理...
一.什么是 EJB?
一个技术规范：EJB 从技术上而言不是一种"产品"
EJB 是一种标准描述了构建应用组件要解决的:
可扩展 (Scalable)
分布式 (Distributed)
事务处理 (Transactional)
数据存储 (Persistent)
安全性 (Secure)
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就找到了。
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就找到了。