EJB实质问题

为什么要使用EJB?
　　================
　　
　　EJB最大的诱人之处是她把应用程序和服务器分开了,我们再也不用和那些服务器上的复杂的资源打交道了,什么数据库,什么进程,线程,什么安全权限,什么套接字,都见鬼去吧,我们只需要专著于我们的商业逻辑的实现了.
　　
　　==========
　　EJB的实质?
　　==========
　　
　　EJB实际上是SUN的J2EE中的一套规范,并且规定了一系列的API用来实现把EJB概念转换成EJB产品.EJB是BEANS,BEANS是什么概念,那就是得有一个容纳她,让她可劲造腾的地方,就是得有容器.EJB必须生存在EJB容器中.这个容器可是功能强大之极!她首先要包装你BEAN,EJB的客户程序实际上从来就不和你编写的EJB直接打交道,他们之间是通过HOME/REMOTE接口来发生关系的.它负责你的BEAN的所有的吃喝拉萨睡,比如BEAN的持续化,安全性,事务管理...
　　
　　=============
　　EJB服务器产品
　　=============
　　
　　各个WEB服务器开发商基本上都在他们WEB服务器中新捆绑了EJB容器,或者叫EJB服务器.其中最简单也是最根本的是J2EE开发环境带的J2EE的EJB容器,它很好的和J2EE的HTTP服务器和Servlet引擎一起构筑了一个很好的运行环境,由于配置简单,功能强大,因此成为我的最爱.另外象BEA的Weblogical是值得推荐的一个产品,它的WEB服务器功能相当强大,是当今很多网站构筑的理想WEB服务器,它也已经加入了EJB的行列,在EJB方面有着不俗的表现.Inprise的IAS更是一个功能强大的WEB服务器,同样,也嵌入了EJB容器,加之与本公司的JBuilder的无接缝结合,更使它人气攀升.
　　还有象IBM的WebSphere也不错,不过Apache是否已经搭载了EJB容器,我不太清楚.
　　另外,推荐一个EJBoss,是一个完全免费的EJB服务器,而且是原代码公开的.
　　
　　========================
　　EJB容器如何包装你的BEAN.
　　========================
　　
　　这年头没有天上掉馅饼的好事情,EJB也不例外,你想让EJB容器替你管理你编写的EJB的吃喝拉萨睡,凭什么?!凭XML描述子,你通过一个XML文件告诉EJB容器BEAN的相关配置信息,比如我的EJB的HOME接口和REMOTE接口是哪一个类,比如我的EJB的别名(实际上是JNDI名称)叫什么,比如我的EJB是否是实体类型的EJB还是对话类型的EJB,比如告诉容器替我管理我的实体EJB中哪些自段,......总之,你得跟咱们的EJB大总管----EJB容器把所有都交代清楚.这样,剩下的,就看EJB容器的了!!!
　　你是不是总共写过3个文件,BEAN定义,HOME接口定义,ROMOTE接口定义,
　　当你DEPLOY他们时,容器会
　　(1).首先根据HOME和REMOTE接口生成他们的实现代码,我们不妨叫做HOME_IMPL和REMOTE_IMPL,
　　(2).然后,利用RMIC产生HOME_IMPL和REMOTE_IMPL的STUB和SKELETON文件,2X2一共生成4个文件.
　　(STUB和SKELETON请参见RMI的相关概念)
　　如此这般,最后,在服务器上,一共有
　　BEAN
　　HOME_IMPL
　　REMOTE_IMPL
　　HOME_STUB
　　HOME_SKELETON
　　REMOTE_STUB
　　REMOTE_SKELETON
　　7文件,才能让EJB工作起来.
　　(3).生成实体EJB对应的数据库的库表
　　(4).注册你的EJB到JNDI服务
　　
　　===============================================================
　　为什么除了写BEAN,还得写接口文件,而且干嘛要HOME和REMOTE两个接口.
　　===============================================================
　　
　　我搅着吧,这两个接口完全是可以合并成一个接口的,其实他们的作用都只是一个接口,为了让那人家SUN干吗还拆成两个呢?我想,正如SUN所说的,为了将一些容器相关操作和客户商业方法分开,什么意思?说开了吧,HOME用来规范容器相关的操作方法,REMOTE负责专心致志的定制商业方法,而我们的BEAN才是最终的逻辑实现者.
　　还是不明白?没关系,我在说的细些,
　　举例说明:
　　把我想象成一个BEAN,HOME接口就是我们家人的命令,REMOTE接口就是我们单位的领导的命令,我们家人的命令决定了我如何吃喝拉萨睡,领导的命令决定了我如何做一些真正的工作,请注意这里我使用了"决定"这个字眼,
　　我并没有说我们家人,而是说了我们家人的命令,这个命令的含义就是接口,不是类,而我这个BEAN却是个类!还有,BEAN类不实现REMOTE和HOME接口,记住!记住!
　　
　　=========
　　EJB的分类
　　=========
　　
　　EJB分为实体(Entity)EJB和对话(Session)EJB,
　　
　　>>>>>>实体EJB:>>>>>>对话EJB<<<<<<< 　　 　　对话EJB根本根本不和数据库打交道,为什么,因为他根本不用序列化!他只负责来完成一些逻辑操作,比如算个帐什么的. 　　为了和实体EJB较劲,他也一口气生了两个儿子, 　　a.有状态(sessionful)对话EJB 　　他就跟servlet中的session对象似的,可以保存用户的session相关信息,而且他仅仅被一个用户的一次session所使用,不和别人共享,我管他叫对话,不过这"对话"翻出来这是够难听的,还不如就叫他session呢! 　　b.无状态(sessionless)对话EJB 　　这个东东是最简单的EJB,他是可以被多个用户共享,注意!我所说的共享是指实例的共享! 　　 　　 　　====================================== 　　一个BEAN管理持续化的实体EJB(BMP)小例子 　　====================================== 　　 　　说了半天了,大家珍贵的脑资源恐怕被我消耗的差不多了,好,让我们来剖析一个BEAN管理持续化的实体EJB(BMP)吧.

　　
　　-----------------------看看REMOTE接口------------------------------
　　public interface Account extends EJBObject {//必须从EJBObject继承
　　//这些都是商业方法,而且这里写了的,必须在BEAN中都实现
　　public void deposit(double amt) throws RemoteException;
　　public double withdraw(double amt) throws AccountException, RemoteException;
　　public double getBalance() throws RemoteException;
　　public String getOwnerName() throws RemoteException;
　　public void setOwnerName(String name)throws RemoteException;
　　}
　　
　　-------------------------看看HOME接口---------------------------------
　　public interface AccountHome extends EJBHome {
　　//这声明了create函数,由于是BMP,所以必须在BEAN中实现一个叫ejbCreate的对应函数
　　Account create(String accountID, String ownerName) throws CreateException, RemoteException;
　　
　　//按主键查询
　　//由于是BMP,所以必须在BEAN中实现一个叫ejbFindByPrimaryKey的对应函数
　　public Account findByPrimaryKey(AccountPK key) throws FinderException, RemoteException;
　　
　　//按其中的Name字段查询
　　//由于是BMP,所以必须在BEAN中实现一个叫ejbFindByOwnerName的对应函数
　　public Account findByOwnerName(String name) throws FinderException, RemoteException;
　　}
　　
　　---------------------------看看BEAN-----------------------------------
　　public class AccountBean implements EntityBean {
　　//三个PUBLIC字段,他们将来对应库表的三个字段
　　public String accountID
　　public String ownerName;
　　public double balance;
　　
　　//----HOME中声明的create方法的影射实现
　　//由于是BMP,所以必须自己来负责实例创建时实例到数据库的影射
　　public AccountPK ejbCreate(String accountID, String ownerName) throws CreateException, RemoteException {
　　PreparedStatement pstmt = null;
　　Connection conn = null;
　　try {
　　this.ownerName = ownerName;
　　this.balance = 0;
　　conn = getConnection();
　　pstmt = conn.prepareStatement("insert into accounts (id, ownerName, balance) values (?, ?, ?)");
　　pstmt.setString(1, accountID);
　　pstmt.setString(2, ownerName);
　　pstmt.setDouble(3, balance);
　　//看这里,看这里!插进去了...
　　pstmt.executeUpdate();
　　return new AccountPK(accountID);
　　}catch (Exception e) {
　　throw new CreateException(e.toString());
　　}finally {
　　try {
　　pstmt.close();
　　conn.close();
　　}catch (Exception e) { }
　　}
　　}
　　
　　//----HOME中声明的findByOwnerName方法的影射实现
　　//由于是BMP,所以必须自己来完成按照Name字段查找的工作
　　public AccountPK ejbFindByOwnerName(String name) throws FinderException, RemoteException {
　　PreparedStatement pstmt = null;
　　Connection conn = null;
　　try {
　　conn = getConnection();
　　pstmt = conn.prepareStatement("select id from accounts where ownerName = ?");
　　pstmt.setString(1, name);
　　//看看看!找上了,根据名称...
　　ResultSet rs = pstmt.executeQuery();
　　rs.next();
　　String id = rs.getString("id");
　　pstmt.close();
　　conn.close();
　　return new AccountPK(id);
　　}catch (Exception e) {
　　throw new FinderException(e.toString());
　　}finally {
　　try {
　　pstmt.close();
　　conn.close();
　　}catch (Exception e) { }
　　}

JavaBean与EJB有何不同

您现在可能已在使用 JavaBean，但还不了解它。如果有支持 Java 的浏览器，那么，在桌面上使用 JavaBean 就没有限制。使用的 Web 页面可以将 bean 作为小应用程序的一部分。您很快就会和作为浏览器可视部分的 JavaBean 交互，然后，那些 JavaBean 将与服务器上的 EJB 接口。这种能力也可以扩展到因特网和内部网。
　　JavaBean 和 Server Bean（通常称为 Enterprise JavaBean (EJB)）有一些基本相同之处。它们都是用一组特性创建，以执行其特定任务的对象或组件。它们还有从当前所驻留服务器上的容器获得其它特性的能力。这使得 bean 的行为根据特定任务和所在环境的不同而有所不同。
　　这开辟了巨大商机。因为 JavaBean 是与平台无关的，所以对于将来的解决方案，供应商可以轻易向不同用户推出其客户机方的 JavaBean，而不必创建或维护不同的版本。这些 JavaBean 可以与执行商业功能（例如订购、信用卡处理、电子汇款、存货分配、运输等）的 EJB 配合使用。这里有巨大潜力，而这正是组件代理（WebSphere Application Server 企业版）设计提供的那种潜力。
　　JavaBean 是一种组件，它在内部有接口或有与其相关的属性，以便不同人在不同时间开发的 bean 可以询问和集成。可以构建一个 bean，而在以后构造时将其与其它 bean 绑定。这种过程提供了先构建，然后重复使用的方法，这就是组件的概念。可以将这种单一应用程序部署成独立程序、ActiveX 组件或在浏览器中。
　　JavaBean 因其外部接口（即属性接口）而与纯对象不同。这种接口允许工具读取组件要执行的功能，将其与其它 bean 挂钩，以及将其插入其它环境。JavaBean 设计成对单一进程而言是本地的，它们在运行时通常可视。这种可视组件可能是按钮、列表框、图形或图表 - 但这不是必需的。
　　可执行组件
　　Server Bean 或 EJB 是部署在服务器上的可执行组件或商业对象。有一个协议允许对其进行远程访问或在特定服务器上安装或部署它们。有一系列机制允许它们将服务安全性、事务行为、并发性（由多个客户机同时访问的能力）和持久性（其状态可以保存多久）的主要方面授权给 EJB 服务器上其所在的容器。当安装在容器中时，它们获得各自的行为，该行为提供不同质量的服务，因此，选择正确的 EJB 服务器至关重要。这正是 IBM WebSphere 企业版的优势所在。
　　EJB 是设计成运行在服务器上，并由客户机调用的非可视远程对象。可通过多个非可视 JavaBean 构建 EJB。它们有一个部署描述符，其目的与 JavaBean 属性相同：它是以后可由工具读取的 bean 的描述。EJB 还独立于平台，一旦编写好，还可以在任何支持 Java 的平台（包括客户机和服务器）上使用。
　　因为 EJB 由诸如 IBM VisualAge for Java 这样的工具集生成，所以，它是基于服务器的对象，并用于远程调用。它们安装在 EJB 服务器上，并象调用其它 CORBA 远程对象那样获得进行调用的远程接口。
　　ActiveX 对象
　　可以将 JavaBean 部署成 ActiveX 对象，虽然 EJB 的代理也可以这样做，但是，因为 ActiveX 运行在桌面上，所以，EJB 本身不能成为 ActiveX 对象。要在与平台相关的、仅 Windows 平台上做到这一点，开发人员可以将 JavaBean 变换成 ActiveX 组件。
　　好处
　　EJB 的主要好处在于：构建 bean 时，bean 开发人员可以规定需要什么类型的行为，而不必规定如何去做。开发分为两部分：程序员开发 bean，然后验证：它可与构建工具一起工作，并包括标识所需服务质量行为种类的部署描述符。下一步，另一个程序员可以采用这个 bean，并使用读取 EJB 部署描述符的部署工具，然后将该 bean 安装到 Enterprise Java Server 上的容器中。在第二步中，部署工具采取一些操作 - 这可能意味着生成如状态保存代码，放入事务挂钩，或执行安全性检查这样的代码。所有这些操作由部署工具生成，bean 开发人员和部署人员可以是不同的人。
　　可以通过使用部署工具，将任何独立于平台的 JavaBean 改写成具有可靠服务质量、特定于平台的 EJB，以满足现有商业系统和应用程序的特定需求。这就是 EJB 服务器对集成系统、网络和体系结构如此重要的原因所在。
　　EJB 与 IBM WebSphere 企业版
　　在 IBM WebSphere 企业版中使用时，可以将 EJB 配置成被管理的商业对象。接受它们授权服务的容器是其安装到的容器。将 EJB 的持久性部分映射在数据或状态对象中。EJB 服务器为 EJB 提供不同的服务质量，选择正确的 EJB 服务器可能对满足完整的商业需求至关重要。“组件代理”功能极其健壮，该功能提供如负载均衡和支持服务器组中多台机器的高级功能。它还有大大超出 Enterprise Java Server (EJS) 规范所倡导的系统管理功能。因此，按照基本标准编写的 JavaBean 或 EJB 可以运行在使用“组件代理”功能的 WebSphere 企业版上，并获得那些所有的附加功能。
　　EJB 服务器还提供独特的特性和服务质量，而且不完全相同。IBM“组件代理”有一些强大特性 - 例如，可伸缩性，它允许开发人员将 EJB 部署到从小型系统到大型网络的不同类型服务器。开发人员可以从小处入手，例如，在一个部门中，首先在 LAN 的 Java 服务器上部署，一旦准备好，就知道可以将在那里创建的 JavaBean 和 EJB 部署到全球网络。然后，开发人员可以测试并熟悉这些 bean，试运行，制作样本等等。满意之后，开发人员可以通过将其移至高性能服务器，来大幅度扩大其规模。JavaBean 和 EJB 不受任何计算机体系结构边界的限制。它们用 Java 编写，可以运行在任何具有 Java 虚拟机的系统上，并可以使用任何 Enterprise Java Server (EJS) 来部署对象。因此，开发人员现在可以在方便的系统上构建，以后在方便的系统上部署，而不必是同一台或同样类型的机器。
　　IBM WebSphere 企业版支持将商业对象部署到多台服务器。EJB 作为商业对象集成到“组件代理”功能，并作为任何其它商业对象处理。因此，EJB 可以连接到所选的后端系统，并执行任何所需操作，以满足其商业需求。这就成为“组件代理”为 EJB 提供的基础设施。通过将“组件代理”用作 EJB 服务器，开发人员将能够继续使用当前旧有系统，并将其与电子商务接口一起提供。
　　为使 EJB 能在 WebSphere“组件代理”环境中工作，可以使用“组件代理”部署工具将其安装在一台或多台服务器上，然后将其添加到命名服务器，以便可以全局查找到它。任何可以访问公共命名服务器的人都可以找到它，找到其宿主，并可以在宿主上执行方法，同时创建 EJB。这就是“代理组件”要做的事。
　　示例
　　让我们举一个在 Web 购物站点上可以看到的电子购物车的例子。用户的购物车是一个 JavaBean。用户将货架上的商品放入购物车，这些商品本身是 JavaBean。它们全部可视，并且面向用户。结帐时，将用户购物车中的商品发送到服务器上的 EJB，该 EJB 执行一些必要的操作，如检查信用卡授权和可用额度，生成封条，或生成给发货部门的有关提什么货和发货地点的特殊指示 - 这就是商业程序已在进行的活动。
　　结束语
　　Bean 的全部意义不只是其现有能力，更在于其可以为商业提供的有竞争力的潜在能力。IT 设计师和应用开发人员现在可以将精力完全集中在商业逻辑，而将如事务、持久性和安全性的底层工作留给服务器。WebSphere 的“组件代理”功能将提供所有这些（还有后端访问）和对象事务管理器。
　　
　　

使用EJB组件你需要了解些什么呢？

　　什么是 EJB 组件？EJB 组件是为企业级应用设计的 java 组件模型
　　EJB 组件是基于标准分布式对象技术、CORBA 和 RMI 的服务器端 java 组件。EJB 组件总是分布式的，这是它们与标准 JavaBeans 组件最根本的区别。
　　EJB 组件提供了应用的商务逻辑部分。由于它们不涉及表示层的问题，因此必须与其它的显示技术(如 servlets)，服务于 HTML 客户端的 JSP 技术，或者使用了诸如 AWT、Swing 技术的 java 应用一起使用。
　　实现了 EJB 规范的应用服务器提供了可以解决安全性、资源共享、持续运行、并行处理、事务完整性等复杂问题的服务，从而简化了商业应用系统。
　　Sun 公司制定的 EJB 组件模型要求 EJB 组件运行于 EJB 服务器(通常称为应用服务器)的环境下。我们的示例中使用了高级版 WebSphere 应用服务器，但所讨论的功能适用于大多数 EJB 服务器。
　　
　　需要考虑的技术问题
　　当你在决定 EJB 组件是否为适合你的实际情况的合适技术时，不妨先考虑几个问题。如果你对所有这些问题的回答都是肯定的话，那么 EJB 组件就是你可以采用的合适技术。反之的话，别的技术可能更适合。
　　
　　你需要将商务逻辑组件与面向外界的 Internet 隔离开吗？
　　许多公司认为他们的应用软件，特别是构成商务逻辑的一些标准和数据结构，是极为重要的公司财产(例如，公司所拥有的分析应用工具构成了股票交易网站的一部分)。允许外人访问这些属于公司资产的原码和目标码将对公司产生极大的危害。因此，这些公司十分需要将商务逻辑置于一套安全防火墙后面(通常称为无戒备区，也称 DMZ)。
　　
　　在这种情况下，分布式对象组件体系结构(例如 EJB 技术)允许你将有价值的公司资产隔离到 DMZ 以内，同时表示层代码可以访问 DMZ 内的 EJB 服务器。下图描述了这种分布式解决方案：
　　
　　防火墙内部的 EJB
　　这里我们假设表示层逻辑不如后台的商务逻辑重要。如果不是这样，那么这种方案的安全性就要下降，整个系统可能都需要置于 DMZ 之内。如果整个应用必须(或者能够)置于第二层防火墙后面，那么选择其它技术(如通过 Java Servlets 发出 JDBC 请求来直接访问数据库)就显得更合理。
　　
　　这种解决方案也有一些效率方面的缺陷。例如在安装 WebSphere 时，如果你将客户端(servlets 与 JSP文件)与图示的位于另一个 java 虚拟机(JVM)中的 EJB 组件分隔开，这种选择将降低整体性能。与客户端和 EJB 组件位于同一个 JVM 中的情况相比，这种方式下每一个需要经过防火墙的请求都将增加20%的耗时。
　　
　　你需要不止一种类型的客户端访问共享数据吗？
　　通常，一个应用会有多种类型、需要访问相同信息的客户端。例如，一个应用可能会有供外部客户访问的基于 web 的 HTML 前端，以及供内部人员使用的更完整的应用前端。通常，这个问题是通过为同一应用编写两个共享相同数据源(数据库表)的版本来解决的。但是，这种方法效率不高，无论是从编程时间还是从同时发生多个数据库锁定时数据库的利用率来说。
　　
　　EJB 技术的解决方案是将共享数据和商务逻辑集成到一套 EJB 组件中，以供不同类型的客户端(如 servlet/HTML 和 application)访问。EJB 组件控制着对后台数据的访问，并管理着当前事务以及数据库的内部锁定。通过去除应用中的重复代码，减少编写数据库控制逻辑的工作，这种方案降低了总的编程量。
　　
　　在这个领域还有其它一些解决方案--比如，java 应用可以通过 HTTP 访问 java servlets，同时浏览器也可以通过 HTTP 访问 java servlets。这些解决方案的问题在于：如果 servlet 是用来在浏览器中显示信息的，它就必须包含一些表示层逻辑，这些表示层逻辑对于向另一个程序传递信息来说是多余的。因此，你最终不得不采用两套部分重复的 servlets 来处理两种情况。此外，HTTP 不是程序间通讯的效率最高的协议。你必须设计能通过 HTTP 管道进行程序间信息传递的数据格式--这通常或者是基于文本的格式，比如 XML（由接收端进行解析，由发送端生成），或者是基于对象的格式，比如 java 序列化。两种格式都需要大量的编程工作，它们都不如本地的 IIOP 速度快。
　　
　　你是否需要对共享数据同时进行读和写操作？
　　通常，"胖客户端"解决方案要求应用在数据库级别上管理对共享数据的访问。其结果是：处理数据库锁定与同步的方案非常复杂，若不考虑数据库锁定与同步问题又会失去数据的完整性。
　　
　　EJB 技术能自动处理这些复杂的共享数据同步问题。正如前面提到的那样，EJB 组件控制着对后台数据的访问，并管理着当前事务和数据库的内部锁定。这不仅省去了编写数据库控制逻辑的工作量，同时也保证了数据的一致性与正确性，从而降低了总的编程量。
　　
　　你需要访问具备事务处理功能的多个异构数据源吗？
　　许多应用需要访问多个数据源。例如，一个应用程序可能既要访问来自中间层的 Oracle 数据库，又要通过中间件(如 MQSeries)访问 CICS、IMS 等大型主机系统。问题的关键是一些应用要求这种访问是完全事务化的，并且数据完整性在不同数据源间也能得到保证。例如，某个应用可能要求在处理用户的订购信息时，既要在 Oracle 数据库中存储详细的订购信息，同时又通过 MQSeries 在 CICS 系统中存储一份出货订单。无论是数据库更新或是 MQ 队列产生错误，整个事务都应被取消。
　　
　　过去，构建这样的系统的唯一选择是采用事务监视器，例如 Encina、CICS、Tuxedo，它们使用非标准接口并需要用 COBOL、C、C++ 等语言进行开发。例如，高级版 WebSphere 中的 EJB 容器支持多个并发的事务，具备在多个 DB2 数据源间进行完整的事务提交及事务取消的能力，这些都是在一个完全支持二状态事务提交的环境中进行的。目前，WebSphere 对其它数据源(如 Oracle, MQSeries 和 CICS)只支持单状态的事务提交。企业版 WebSphere 中的 EJB 容器能对更多的数据源支持二状态的事务提交。
　　
　　大多数容器正在支持各种数据源下的二状态事务提交方面不断完善。随着时间的推移，我们将在这一领域看到不断的进步。
　　
　　你需要能与 HTML 文档、servlets、JSP 文件、客户端登录安全性无缝集成的方法级对象安全性吗？
　　某些类型的应用由于其安全性限制，使得以前它们很难通过 java 应用来实现。例如，某些保险业的应用程序为了满足管理规定的要求，必须限制对客户数据的访问。直到 EJB 技术出现后，才能够限制特定用户访问某个对象或方法。在这之前，可实施的办法只有：在数据库级别上限制访问，并捕获在 JDBC 层次上抛出的错误；或者通过客户安全密码在应用层上限制访问。
　　
　　EJB 技术可以在任何 EJB 组件或方法上实施方法级的安全策略。创建的用户和用户组可以被授予或禁止对任何 EJB 组件或方法的操作权。在 WebSphere 中，用户组可以被授予或禁止对 web 资源(servlets, JSP 文件和 HTML 页面)的访问权，用户的 ID 可以通过底层的安全机制被安全地从 web 资源传递到 EJB 组件。
　　
　　体系结构是否有标准化、轻量化、组件化的需要呢？
　　对于许多有远见的公司来说，关键问题是要实现平台、销售商和应用服务器设备间的相互独立。符合工业标准的 EJB 组件体系结构有助于实现这些目标。为 WebSphere 开发的 EJB 组件通常可以发布到其它类型的应用服务器上使用，反之亦然。尽管这一目标尚未完全实现，但它已成为许多客户选择的战略发展方向。从短期看，利用一些可能优于标准化的特性会更方便、更迅速，但从长远看标准化具有最大的好处。
　　
　　你也应当考虑到越来越多的可选工具和 EJB 标准的优化实现手段，这些都是你无法从本地管理对象框架中获得的。由于大多数公司并不从事中间件业务，将注意力集中在与你的业务更直接相关的活动上会更有效。
　　
　　你需要多个服务器来满足系统的吞吐量和有效性需要吗？
　　胖客户端系统显然不能适应 web 系统可能拥有的成千上万个用户。软件发布方面的问题也要求给胖客户端减肥。Web 站点的24小时不间断运行特点也使得时间成为关键问题。但并不是每个人都需要24小时不间断运行，并能同时处理上万个用户的系统。你应当能设计这样的系统：在不增加开发和标准化难度的前提下，实现系统的伸缩性。
　　
　　因此，你要设法使得编写的商务逻辑可以进行伸缩来满足这些需要。EJB 技术为构建这种具有高伸缩性、高利用率的系统提供了骨架。例如，WebSphere 通过以下一些特性帮助开发者构建这类系统。这些特性也适用于其它的 EJB 服务器：
　　
　　对象缓存与共享。WebSphere 自动在服务器层面上共享无状态会话 EJB 组件，从而减少了用于创建对象和回收碎片的时间。这将使得更多的处理时间周期可以分配给真正的实际工作。
　　服务器端的工作量优化。WebSphere 还使得 EJB 服务器具备群管理的特点。在 WebSphere 应用服务器上，你可以创建跨越多个节点的服务器组。除此之外，你可以创建模型(服务器的抽象表述)，并把它们克隆到多个 JVM 中。你可以将克隆的模型配置成运行于组内的任何一台服务器上。另外，一个服务器的多个克隆模型也能运行与一台机子上，充分利用了多处理器的结构特点。同样，你也可以把所有克隆的模型作为一个组来管理。这就提高了可靠性，避免了个别地方故障时对应用服务器的破坏。
　　通过克隆可支持自动故障恢复。由于有几个克隆的服务器可以用来处理请求，故障不太可能破坏系统的吞吐量和可靠性。由于多个节点运行相同的服务，一台整机的故障就不会产生灾难性的后果。
　　所有这些特性都不需要对系统进行特殊的编程。利用这种可伸缩性也无需改动服务器端的代码。
如果直接由和 java servlets 处于同一 JVM 中的 JavaBeans 组件来实现数据映射功能，系统的速度将比使用 EJB 组件快得多，同时避免了大量的网络开销。该系统还变得不必要的复杂(因为需要本地和远程接口，以及分布代码)。事实上，该方案后来被废弃并以不使用 EJB 组件的方式进行了重新设计，其中的数据映射由一套被 servlets 使用的标准 JavaBeans 组件实现。这使得最后的系统变得更简单、更快速.
　　
　　简单地说，该应用的以下特点使得它适合使用 EJB 技术：
　　具有共享相同商务逻辑的多种类型客户端
　　使用了事务处理
　　需要通过 CMP 组件来实现与对象有关的映射
　　需要方法级的安全性