EJB与Java Bean的区别？

      Java Bean 是可复用的组件，对Java Bean并没有严格的规范，理论上讲，任何一个Java类都可以是一个Bean。但通常情况下，由于Java Bean是被容器所创建（如Tomcat)的，所以Java Bean应具有一个无参的构造器，另外，通常Java Bean还要实现Serializable接口用于实现Bean的持久性。Java Bean实际上相当于微软COM模型中的本地进程内COM组件，它是不能被跨进程访问的。Enterprise Java Bean 相当于DCOM，即分布式组件。它是基于Java的远程方法调用（RMI）技术的，所以EJB可以被远程访问（跨进程、跨计算机）。但EJB必须被布署在诸如Webspere、WebLogic这样的容器中，EJB客户从不直接访问真正的EJB组件，而是通过其容器访问。EJB容器是EJB组件的代理，EJB组件由容器所创建和管理。客户通过容器来访问真正的EJB组件。

EJB的英文全称是企业级的JavaBean
两者是完全不同的
JavaBean是一个组件，而EJB就是一个组建框架
JavaBean面向的是业务逻辑和表示层的显示，通过编写一个JavaBean，可以将业务逻辑的事件和事务都放在其中，然后通过它的变量属性将所需要的内容在表示层传递显示。
EJB是部署在服务器上的可执行组建或商业对象。EJB有一个部署描述符，通过这个部署描述符可以对EJB的属性进行描述。EJB不和表示层交互。
通常，对于简单的服务器端应用来说，使用JavaBean是很不错的选择。虽然对于复杂的服务器端应用来说，使用JavaBean同样可以达到相同的效果，但这么做，所有底层的实现都必须手工来重新编写。而EJB不必用户关心它的底层操作，而只要关心它的外部实现即可。
的确，利用JavaBean来与EJB共同完成实现，是十分常见的。
从概念层上理解就是：
首先，EJB是指运行在EJB容器中的JavaBean。Tomcat是Web容器的参考实现。一个完整的JavaEE服务器应该包括Web容器和EJB容器。
其次，Web容器中无法运行EJB，同时所有的JavaBean都是在服务器端运行的。如果有在客户端的话，就变成C/S结构了。
目前来说除非需要分布式处理，不然基本上不需要考虑EJB。Spring能帮你处理好除分布计算之外的一切。
用JavaScript来进行服务器调用的话，属于Ajax的范围了。
至于购物车。一般来说有几种方法，一种是EJB中的有状态SessionBean。一种是使用HttpSession保存。还有就是自己建设一个对象池来处理。
JavaBean是领域模型的具体化类，保存了信息和业务。只有set、get方法的JavaBean是失血模型。现在来说一般多少不太欢迎这种东西。把本属于领域对象的业务逻辑都丢掉了。
实际上现在的JavaEE系统分这么几个层。
表现层（Struts、JSF等）+应用层（处理业务，可以是JavaBean也可以是EJB）+持久层（JDBC、Hibernate）。
不要在Struts的Action类中写业务代码，那是反模式。不然日后需要修改的时候很麻烦的。Action中只有流程指向和对应用层的调用。
从服务其方面考虑就是：
JavaBean 和 Server Bean(通常称为 Enterprise JavaBean (EJB))有一些基本相同之处。它们都是用一组特性创建，以执行其特定任务的对象或组件。它们还有从当前所驻留服务器上的容器获得其它特性的能力。这使得 bean 的行为根据特定任务和所在环境的不同而有所不同。
这开辟了巨大商机。因为 JavaBean 是与平台无关的，所以对于将来的解决方案，供应商可以轻易向不同用户推出其客户机方的 JavaBean，而不必创建或维护不同的版本。
这些 JavaBean 可以与执行商业功能(例如订购、信用卡处理、电子汇款、存货分配、运输等)的 EJB 配合使用。这里有巨大潜力，而这正是组件代理(WebSphereApplication Server 企业版)设计提供的那种潜力。
JavaBean 是一种组件，它在内部有接口或有与其相关的属性，以便不同人在不同时间开发的 bean 可以询问和集成。可以构建一个 bean，而在以后构造时将其与其它 bean 绑定。
这种过程提供了先构建，然后重复使用的方法，这就是组件的概念。可以将这种单一应用程序部署成独立程序、ActiveX组件或在浏览器中。
JavaBean 因其外部接口(即属性接口)而与纯对象不同。这种接口允许工具读取组件要执行的功能，将其与其它 bean 挂钩，以及将其插入其它环境。
JavaBean 设计成对单一进程而言是本地的，它们在运行时通常可视。这种可视组件可能是按钮、列表框、图形或图表 - 但这不是必需的。
可执行组件
Server Bean 或 EJB 是部署在服务器上的可执行组件或商业对象。有一个协议允许对其进行远程访问或在特定服务器上安装或部署它们。有一系列机制允许它们将服务安全性、事务行为、并发性(由多个客户机同时访问的能力)和持久性(其状态可以保存多久)的主要方面授权给 EJB 服务器上其所在的容器。
当安装在容器中时，它们获得各自的行为，该行为提供不同质量的服务，因此，选择正确的 EJB 服务器至关重要。这正是 IBM WebSphere 企业版的优势所在

EJB的英文全称是企业级的JavaBean
两者是完全不同的
JavaBean是一个组件，而EJB就是一个组建框架
JavaBean面向的是业务逻辑和表示层的显示，通过编写一个JavaBean，可以将业务逻辑的事件和事务都放在其中，然后通过它的变量属性将所需要的内容在表示层传递显示。
EJB是部署在服务器上的可执行组建或商业对象。EJB有一个部署描述符，通过这个部署描述符可以对EJB的属性进行描述。EJB不和表示层交互。
通常，对于简单的服务器端应用来说，使用JavaBean是很不错的选择。虽然对于复杂的服务器端应用来说，使用JavaBean同样可以达到相同的效果，但这么做，所有底层的实现都必须手工来重新编写。而EJB不必用户关心它的底层操作，而只要关心它的外部实现即可。
的确，利用JavaBean来与EJB共同完成实现，是十分常见的。
从概念层上理解就是：
首先，EJB是指运行在EJB容器中的JavaBean。Tomcat是Web容器的参考实现。一个完整的JavaEE服务器应该包括Web容器和EJB容器。
其次，Web容器中无法运行EJB，同时所有的JavaBean都是在服务器端运行的。如果有在客户端的话，就变成C/S结构了。
目前来说除非需要分布式处理，不然基本上不需要考虑EJB。Spring能帮你处理好除分布计算之外的一切。
用JavaScript来进行服务器调用的话，属于Ajax的范围了。
至于购物车。一般来说有几种方法，一种是EJB中的有状态SessionBean。一种是使用HttpSession保存。还有就是自己建设一个对象池来处理。
JavaBean是领域模型的具体化类，保存了信息和业务。只有set、get方法的JavaBean是失血模型。现在来说一般多少不太欢迎这种东西。把本属于领域对象的业务逻辑都丢掉了。
实际上现在的JavaEE系统分这么几个层。
表现层（Struts、JSF等）+应用层（处理业务，可以是JavaBean也可以是EJB）+持久层（JDBC、Hibernate）。
不要在Struts的Action类中写业务代码，那是反模式。不然日后需要修改的时候很麻烦的。Action中只有流程指向和对应用层的调用。
从服务其方面考虑就是：
JavaBean 和 Server Bean(通常称为 Enterprise JavaBean (EJB))有一些基本相同之处。它们都是用一组特性创建，以执行其特定任务的对象或组件。它们还有从当前所驻留服务器上的容器获得其它特性的能力。这使得 bean 的行为根据特定任务和所在环境的不同而有所不同。
JavaBean 是一种组件，它在内部有接口或有与其相关的属性，以便不同人在不同时间开发的 bean 可以询问和集成。可以构建一个 bean，而在以后构造时将其与其它 bean 绑定。
这种过程提供了先构建，然后重复使用的方法，这就是组件的概念。可以将这种单一应用程序部署成独立程序、ActiveX组件或在浏览器中。
JavaBean 因其外部接口(即属性接口)而与纯对象不同。这种接口允许工具读取组件要执行的功能，将其与其它 bean 挂钩，以及将其插入其它环境。
JavaBean 设计成对单一进程而言是本地的，它们在运行时通常可视。这种可视组件可能是按钮、列表框、图形或图表 - 但这不是必需的。
可执行组件
Server Bean 或 EJB 是部署在服务器上的可执行组件或商业对象。有一个协议允许对其进行远程访问或在特定服务器上安装或部署它们。有一系列机制允许它们将服务安全性、事务行为、并发性(由多个客户机同时访问的能力)和持久性(其状态可以保存多久)的主要方面授权给 EJB 服务器上其所在的容器。