ejb开发什么是ejb?

为什么要使用EJB 使用EJB的理由

为什么使用EJB我原先认为这不是一个讨论的话题，因为EJB是J2EE重要的组成部分，可以说没有EJB的J2EE只是一种Web系统，这样的系统非常容易丧失了多层结构的大部分优点（仔细想想那些混合多种层次功能JavaBeans和传统两层结构有什么区别？）。

当然，可以人为地在Javabeans之间进行层次划分，例如Hibernate算数据持久层，某些JavaBeans是业务核心层，但是因为都是普通JavaBeans，这种划分没有一种强制性和明显标志性，这样的系统更换了主创人员或设计师，可能就会被新的程序员修改得非常混乱。

我们先看看一个包含EJB的J2EE系统是如何清晰地表达层次。

如下图： Web完全只是一个MVC模式的实现，关键业务核心是在EJB的服务层实现，这样做的优点是，Web只负责界面相关部分，因为，如果是一个智能客户端，如Swing或J2ME，在不需要修改任何业务核心的情况下能够方便地更换。

同样，提供Web Services功能，也只是在 Web层修改，不会涉及EJB方面的修改，同样保证了系统的稳定性，保证了系统升级和未来的扩展性。

如果不使用EJB，在EJB服务层实现的业务核心将由普通JavaBeans实现，使用何种架构或设计能够保证负责MVC的JavaBeans和负责业务核心的JavaBeans清晰地分开，又如何保证在新的程序员不会破坏和打乱你精心布局的JavaBeans架构？ EJB提供性能优化支持 最主要的是性能问题，由于以前国内中文Java网站有些人弯曲EJB，认为EJB性能低，其实这是一种非常肤浅错误的认识，我们首先看看在一般Java环境中是如何提高性能。

假定一个JavaBeans为A，那么一般使用这个JavaBeans命令如下： A a = new A(); 但是，在高访问量的环境中，new A()其实是很费时消耗系统性能的，因此，能不能在软件系统启动时候就预先建立一些对象，这样，系统运行时，从这些已经生成的对象池中借用一个，这样，就无需在使用时进行New，节约了开销，提高了性能，因此，真正成熟性能解决方案都是需要对象池等支持。

在一个纯Web结构的系统（也就是只能运行在Tomat环境中），例如Struts Hibernate等这样的系统，除非自己动手做，一般是没有对象池技术支持的，因此他们的性能只能算是Demo演示版本的性能，根本无法承受大容量并发访问，也无法称为一个成熟的系统，所以，我们研究成熟的开源Web系统，如Jive、OFBize，LifeRay等，他们都在Web层拥有自己的对象池和缓存池。

对象池和缓存机制是J2EE必须的吗？当然，是所有成熟系统必须的，Windows系统如果去掉缓存将会变得怎样？ 自己动手开发对象池和缓存机制并不是一件简单的事情，需要对多线程以及同步锁等底层原理有深层次的把握，这其实也是一门非常深入的Java研究分支，所以，你可以抛开你的客户焦急的催促，精心研究开发自己的对象池和缓存池。

但是，EJB容器（如JBoss）已经提供了对象池和缓存机制，所以，没有事务机制的无状态Session Bean的性能肯定要强于普通JavaBeans。

EJB容器不但在单机中提供了对象池和缓存，而且可以跨服务器实现动态负载平衡，这些都无需开发者自己开发任何软件代码，结构如下： EJB组件能提供真正的可重用框架 每一个jar包代表一个EJB组件，一个系统可以由多个可重用的EJB组件构成，例如：树形结构EJB组件；自增序号EJB组件；用户资料EJB组件等，这样的EJB组件可以象积木一样搭配在大部分应用系统中，提高了系统的开发效率，保证了开发质量。

下图是某个新的具体系统时应用到的EJB组件图，在这个新的应用中，由于使用了以前大量可重用的EJB组件，新的开发工作基本集中在界面设计和流程安排上： EJB提供了事务机制 事务机制对于一些关键事务是很重要的，例如ATM机提款，提款有多个动作：修改数据库以及数钱等，如果这其中有任何一个环节出错，那么其它已经实现的操作必须还原，否则，就会出现，提款人没有拿到钱，但是卡上已经扣款等不可思议的事情发生。

EJB提供的事务机制非常周全，但事务机制带来的缺点是性能的降低，因此，有些人认为EJB很重，因为在实际应用中，有的用户系统可能不需要事务机制，只是需要EJB提供的性能优化机制，这样，如果使用EJB，就象叫一个人来背东西，他除了背着我要的东西外，还背着我不要的东西。

除非你是一个完美主义，在一般企业应用或数据库系统应用中，EJB不会对你构成很重的包袱。

CMP独特的优点 开源以及一些数据库持久层技术崇拜者，一直抨击CMP，认为CMP慢无用，实际最大的问题是他们的设计和使用问题。

由于EJB容器（如JBoss）对CMP实现有事务机制的缓存优化，因此，CMP特别适合多个用户同时更新同一个数据源的情况，CMP这种严格的事务完整性保证多个用户同时操作一个数据记录时，能够保证性能优化和数据的完整性，如果这个数据记录是是软件系统的状态标志，它的状态会影响系统中很多的环节，那么状态更改的重要性不言而喻。

如果没有事务完整性支持，你的软件系统在用户访问量变大，就会变得发生各种不可能发生的逻辑错误，查看程序逻辑是正确的，那么问题出在哪里？出在数据完整性上。

由于每个CMP在内存中都有一个缓存，在实际应用中，如果使用CMP批量读数据库数据，几万条查询完毕，内存中充满了几万条CMP缓存，如果这时你的EJB容器设置不当（如使用JBoss缺省配置），那么JVM的垃圾回收机制就会频繁启动，导致你的系统变慢甚至死机，这也是一些人抨击CMP慢的原因所在，其实他们使用方法不当，或者没有正确配置EJB容器CMP缓存。

对于这种情况，根据J2EE核心模式，推荐使用DAO JDBC方式。

小结 除非你对设计模式非常精深，能够将自己系统中的JavaBeans使用模式或某种框架进行固定分层，同时，你孜孜不倦研发出对象池，又熟练于JTA等事务机制，你可以选择没有EJB的纯Web结构，就象Jive、OFBiz那样。

当然还有一个前提，老板不懂或者非常有挑战性（做与IBM SUN 微软齐名的公司和技术）。

不要再被TSS那些狂热的开源先生误导，他们有时间有保障可以做他们喜欢的事情，作为专业的J2EE程序员，按照J2EE标准去学习去行动，也不要认为，只要使用了J2EE其中某个技术如Jsp或JavaBeans就心安理得认为自己的系统是J2EE了。

当然，我并不是说纯Web系统不能实现多层结构，但是至少在很多方面没有Web EJB结构完善和清晰，所以，EJB不是J2EE可以忽视的部分，而是主要的重要的部分，重要业务功能核心都封装在EJB中，相反Web层是一种次要的、和界面相关的层次。

EJB是什么?

EJB (Enterprise JavaBean)是J2EE的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。

其特点包括网络服务支持和核心开发工具(SDK)。

在J2EE里，Enterprise Java Beans(EJB)称为Java 企业柄，是Java的核心代码，分为整体柄和片段柄和消息柄三个部分，其中的消息柄将在以后再作讨论。

现在我们来看看什么是整体柄和片段柄。

整体柄是一种对象: 标准Java对象由创建它的程序创建，当程序终止时，对象也随之丢失，这就意味着当再次运行些程序时，将无法找到先前创建的柄，而整体柄会一直存在着直到它被删除。

一个程序可以创建一个整体柄，并且这个程序可以在被保存后随时停止和重启。

整体柄将会依然存在。

重启后，程序可以找到与之相对应的整体柄，并且会继续使用这个整体柄。

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) 二.Sun 对 EJB 的期望 提供一个标准的分布的、基于 OO 的组件架构 屏蔽复杂的系统级功能需求 Write once, run anywhere 与非 Java 应用之间的互操作能力 兼容 CORBA 标准 三.为什么选择 EJB? EJB 服务器完成"繁杂"的工作：应用开发人员关注于业务逻辑的实现而不是底层的实现机制(类似于 4GL 语言设计的目标) 支持事务处理 多个业务操作同时成功，或全部失败 可以通过在代码外的描述来定义事务处理级别 可扩展性 EJB 可以根据您应用的增长而扩展 EJB 服务器往往还提供了负载均衡和 安全性：由 EJB 服务器提供资源的访问权限控制 四.EJB 架构 为了满足架构的目标，规范中描述了 服务器 (Server) 容器 (Container) 类 (Class) 和实例 (Instance) Home 和 Remote 接口 客户端 (Client) 五. 简化的编程模型 关注于业务逻辑实现：EJB 负责生命周期 (lifecycle), 数据存储 (persistence), 事务处理语义 (transactional semantic), 安全(security), ... 通用的编程模型：各种服务的高层 API Java 是其编程语言 1.EJB 特点 由一个 EJB 容器在运行时创建和管理 EJB 在部署 EJB 时定制其运行方式 由 EJB 容器和服务器来协调客户端的访问 可以部署到任何兼容的 EJB 容器中 客户端对 EJB 的视图是由 Bean 开发人员决定的

什么是ejb?

什么是EJB 1.什么是 EJB? 一个技术规范：EJB 从技术上而言不是一种"产品" EJB 是一种标准描述了构建应用组件要解决的: 可扩展 (Scalable) 分布式 (Distributed) 事务处理 (Transactional) 数据存储 (Persistent) 安全性 (Secure) 2.Sun 对 EJB 的期望 提供一个标准的分布的、基于 OO 的组件架构 屏蔽复杂的系统级功能需求 Write once, run anywhere 与非 Java 应用之间的互操作能力 兼容 CORBA 标准 3.为什么选择 EJB? EJB 服务器完成"繁杂"的工作：应用开发人员关注于业务逻辑的实现而不是底层的实现机制(类似于 4GL 语言设计的目标) 支持事务处理 多个业务操作同时成功，或全部失败 可以通过在代码外的描述来定义事务处理级别 可扩展性 EJB 可以根据您应用的增长而扩展 EJB 服务器往往还提供了负载均衡和 安全性：由 EJB 服务器提供资源的访问权限控制 4.EJB 架构 为了满足架构的目标，规范中描述了 服务器 (Server) 容器 (Container) 类 (Class) 和实例 (Instance) Home 和 Remote 接口 客户端 (Client) 5. 简化的编程模型 关注于业务逻辑实现：EJB 负责生命周期 (lifecycle), 数据存储 (persistence), 事务处理语义 (transactional semantic), 安全(security), ... 通用的编程模型：各种服务的高层 API Java 是其编程语言 1.EJB 特点 由一个 EJB 容器在运行时创建和管理 EJB 在部署 EJB 时定制其运行方式 由 EJB 容器和服务器来协调客户端的访问 可以部署到任何兼容的 EJB 容器中 客户端对 EJB 的视图是由 Bean 开发人员决定的 2.EJB 服务器 管理 EJB 容器 (它管理 Bean) 提供对操作系统服务的存取 提供 Java 相关的服务，尤其是 通过 JNDI 访问命名空间 基于 OTS 的事务处理服务 3.EJB 容器 管理 Bean 生命周期：将 EJB 服务器提供的服务传递给 Bean 生成代码来实现对 Bean 的存取访问 强制事务处理的限制 创建、初始化和回收 Bean 管理持久数据的存储 对客户端而言 EJB 容器是透明的 4.在一个 EJB 服务器中的容器 目前容器通常是由 EJB 服务器本身提供的 在 EJB 1.0 或 1.1 规范中没有定义容器-到-服务器的接口 各厂商可以根据他们的见解来实现服务器和容器的各自责任 5.容器提供服务: 数据存储 容器决定何时载入/储存状态 Container-Managed Persistence(容器管理存储/CMP) 容器负责存储您的 Bean 容器生成必要的类和代码 Bean-Managed Persistence(Bean 管理存储/BMP) Bean 开发人员提供存储代码 开发人员决定 如何存储, 容器仍然决定 何时进行 6.容器提供服务: 事务处理 可以由容器代理来实现 容器将得到业务逻辑方法的事务处理需求 容器提供事务控制代码 也可以由程序员通过代码实现 7.容器提供服务: 其它服务 其它服务包括 命名 (Naming) 安全 (Security) 线程管理 (Thread management) 这些服务由容器代理完成将减少应用开发人员的负担 8.分布式对象运算 远程对象被作为本地对象来处理：传递信息的方式不变，但开销更大 Enterprise JavaBeans 永远运行在服务器上：对 Bean 的访问永远是远程调用 9.Stub 和 Skeleton 由 EJB 生成: "Stub" 对要传递出去的信息编码 "Tie/Skel" 将接受到的信息解码并传递给目标对象 10.分类: Enterprise JavaBeans +---Entity Beans--CMP/BMP Ejb--| +---Session Beans--Stateful/Stateless 会话 Bean (Session Bean)：根据 EJB 规范，一个会话 Bean 是: 代表单个客户端来执行 可以参与到事务处理中 不直接代表共享于数据库中的数据，但它能访问和更新这些数据 相对而言是短暂存在的 当 EJB 容器失效后就不存在－－－客户端需要重新建立一个信新的会话对象来继续运算 实体 Bean (Entity Bean)：根据 EJB 规范，一个实体 Bean 是: 提供在数据库中数据的对象视图 允许被多个用户共享存取访问 可以是长期存在 (只要它存在于数据库中) 实体 Bean, 它的主键对象, 以及它的远程引用将能跨 EJB 容器的宕机而存在 11.EJB 类和实例 构建 EJB 应用包括来自三方的代码 开发人员编写的代码 由 EJB API 定义的类和接口 由容器自动生成的代码 开发人员编写的代码包括 Bean 类 (定义了业务逻辑) Home 接口 (如何查找或创建 bean) Remote 接口 (如何存取 bean) 其它组件，根据 bean 实际要求 12.EJB Home 接口 每个 bean 有一个 用于:创建新的 bean 实例、查找现存的 bean (只能是实体 bean) Remote 接口：定义 bean 的公共接口－－－只有在 Remote 接口中定义的方法才能被客户端访问 EJB 客户端 可以为 servlet, JSP, 应用程序或其它 bean 通过 JNDI 来查找 EJB home 接口，步骤为: 创建一个 JNDI Context (initial context) 使用 JNDI Context 来查找 bean home 接口 使用 bean home 接口来创建/查找 bean 实例 使用 bean 实例完成业务操作 实际的存取 (对 EJB) 是通过容器生成的类来完成 EJB 架构 客户端对 bean 访问永远不是直接的 EJBObject (tie) 是由容器自身提供的：用来帮助管理 bean 的生命周期 EJB 中的角色 EJB 服务器供应商: 开发并销售 EJB 服务器 EJB 容器供应商: 开发并销售 EJB 容器 Enterprise bean 开发人员: 开发并销售 EJB 应用组装人员: 将不同的 EJB 搭建成应用 部属人员: 使用相应工具在运行环境下配置 EJB 系统管理员: 监视运行时情况