什么是EJB

 转帖自  http://www.jspcn.net/htmlnews/11049291704061129.html

 

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
系统管理员: 监视运行时情况

***************
*您学到了哪些?*
***************
EJB 是构建健壮，可扩展并支持事务处理的分布式对象技术规范
有两种类型的 EJB: Session Bean 和 Entity Bean
一个 EJB 服务器使用 EJB 容器；容器来管理其所包容 bean 的生命周期
每个 bean 将有三个类: bean 类, home 接口和 remote 接口　

 

############################################

转帖自  http://www.jspcn.net/htmlnews/11049414546251367.html

 

Enterprise JavaBeans 入门

本章讲述内容

一个客户端应用的构成?
JNDI 是如何工作的
使用 home 接口
使用会话 bean
EJB 客户端
看起来很特殊的 EJB 客户端应用实质上一点也不特殊
可以是 applet, 应用程序, servlet, 或其它 bean
没有过高的 overhead
编程模式简单
JNDI
使用 JNDI (Java Naming and Directory Interface) 来查找一个 EJB home 接口
JNDI 是将名称与对象匹配的服务(类似电话黄页)
一个 "naming service"
一个服务器将对象添加到目录树上:Known as "binding" a name to an object
任何一种对象可以被加到目录树中
JNDI Context

一个 Context 是一个将名称与对象绑定好的对象
Context 可以是嵌套的 (构成一个目录结构):顶级的 context 对象是一个 InitialContext
Context 可以被 "列出" 来查看其中的内容
Binding

Context 接口定义了下列方法
void bind(String name, Object obj)
Object lookup(String name)
一个容器当 Bean 启动后自动将 Bean 的名称绑定到它的 home 对象上
一个客户端通过名称就可查找到 home 接口
为何使用 JNDI?

服务器和客户端需要知道:
如何定位名称服务器
在名称服务器上对象的正确名称
客户端不知道如何定位 EJB 服务器:客户端必需知道如何找到名称服务器
通过名称服务器存取的对象可以来自多方面:多个服务器可以构成命名空间
获得您的 Bean

一旦您获得一个 home 接口，您可以使用 create() 方法来获得一个 bean 的引用：一旦您获得对该 bean 的引用，您可以开始调用它的方法
不需要任何扫尾工作；只需简单地"停止引用" bean
try {
MyBean bean = findMyBeanHome().create();
bean.computeSomethingOrOther(42);
...
} catch (NamingException e) {
// Handle the naming exception
}



找到回 Home 的路

每个 EJB 都有一个 home 接口
客户端可从一个 JNDI context 获得 home 接口
使用一个 helper 类将它 "narrow" 成正确类型
public MyBeanHome findMyBeanHome()
throws NamingException {
Context context = getInitialContext();
Object object = context.lookup("MyBean");
context.close();
return (MyBeanHome)PortableRemoteObject
.narrow(object, MyBeanHome.class);
}



创建一个 InitialContext

INITIAL_CONTEXT_FACTORY
创建初始 context 的类
与各厂商的实现相关
PROVIDER_URL
名称服务器的位置 (URL 格式)
"IIOP://localhost:6543/" == 本地机器，端口 6543
public Context getInitialContext()
throws NamingException {
Hashtable properties = new Hashtable(2);
properties.put(Context.PROVIDER_URL, "iiop://localhost:6543/");
properties.put(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.ejs.ns.jndi.CNInitialContextFactory");
return new InitialContext(properties);
}



注意这些 "魔术" 值

这些 "常量" 不应该写死在您的方法中
应该从一个 properties 文件中获得，或为 servlet "init" 参数，...
public Context getInitialContext()
throws NamingException {
Hashtable properties = new Hashtable(2);
properties.put(Context.PROVIDER_URL, getNameServerURL());
properties.put(Context.INITIAL_CONTEXT_FACTORY,
getInitialContextFactoryClassName());
return new InitialContext(properties);
}



要及时关闭 Context

Context 不是线程安全的 (thread-safe)：当您要共享它们时要当心
一旦您获得了对象的引用，您不再需要 context； 可以关闭它
...
Context context = getInitialContext();
Information info = null;
try {
info = (Information)context.lookup("information");
} catch (NamingException e) {
throw e;
} finally {
context.close();
}
...



引用 Bean

您可以不确定地引用一个 home 或 bean 类
实际上，我们建议您保存 home 接口如果您还将使用它们时：JNDI 的查找是开销很大的
但要注意，home/bean 的引用不是 serializable 的
...
MyBean bean = findMyBeanHome().create();
bean.computeSomethingOrOther(42);
...



Servlet 示例

public void doGet(...) throws ... {
PrintWriter out = response.getWriter();
out.println("<HTML><HEAD>");
try {
BankAccount account = getBankAccountHome().findById(42);
double balance = account.getBalance();
out.print("Balance is: ");
out.println(balance);
} catch (Exception e) {
out.println("A problem has occurred with the server.");
}
out.println("</HEAD></HTML>");
}

public synchronized BankAccountHome getBankAccountHome()
throws NamingException{
if (bankAccountHome == null)
bankAccountHome = findBankAccountHome();
return bankAccountHome;
}



EJB 客户端开发流程总结

##########################################

转帖自 http://www.jspcn.net/htmlnews/11453845508281595.html

 

使用 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 中。你可以将克隆的模型配置成运行于组内的任何一台服务器上。另外，一个服务器的多个克隆模型也能运行与一台机子上，充分利用了多处理器的结构特点。同样，你也可以把所有克隆的模型作为一个组来管理。这就提高了可靠性，避免了个别地方故障时对应用服务器的破坏。
通过克隆可支持自动故障恢复。由于有几个克隆的服务器可以用来处理请求，故障不太可能破坏系统的吞吐量和可靠性。由于多个节点运行相同的服务，一台整机的故障就不会产生灾难性的后果。
所有这些特性都不需要对系统进行特殊的编程。利用这种可伸缩性也无需改动服务器端的代码。

WebSphere 支持其它服务器端 java 技术(如 java servlets，JSP文件)的发布、克隆和自动故障恢复。但是，这些更面向表示层的技术与其说是 EJB 组件的竞争对手，不如说是对其的补充。当总体时间和可伸缩性是问题的关键时，整体解决方案中应包括 EJB 组件。


关于两个方案的描述，或者说是关于正确使用 EJB 组件的描述
现在你已经了解了一些评估一个应用是否适合使用 EJB 技术的办法，下面我们来比较两个使用了 EJB 组件的应用，看看 EJB 技术究竟是帮助还是阻碍了开发者达到目标。在一个例子中 EJB 组件的正确使用使得代码更简洁、更易懂。在另一个例子中，使用 EJB 组件使得系统过于复杂，性能也不好。

这两个应用都是综合了多个其它应用的例子，而不是来自于某个单一的公司或方案小组。

一个使用 EJB 技术失败的例子
作为一个被授权评估新技术的高级技术小组的成员，某个方案小组最初设计了这个方案。该方案具有如下体系结构(每个方框代表运行于各自硬件上的不同程序)：

不可取的 EJB 体系结构


该体系结构的一些具体设计使得 EJB 组件的使用不如它初看起来那么有吸引力：

应用的主体部分是信息的显示，这部分由 java servlets 实现。EJB 组件只用来获取、更新数据。
方案小组在后台主机的事务处理中使用的数据连接不包括遵从扩充体系结构(XA)标准的数据源。事务不能被成批取消或提交，对每个主机的访问都是一个独立的请求。
由于不能区分用户是来自 web 还是来自后台主机，EJB 技术的安全特性在此没有得到利用。
servlet 对 EJB 组件的每一次访问都是一个网络请求。组件的探测方法和 ejbLoad() 方法的内部逻辑执行了真正的主机请求，但这之后 EJB 组件仅仅进行数据缓存，直到事务提交后才由 ejbStore() 方法将信息回传给主机。直到事务提交前的每一次数据访问和更新都导致了大量的网络开销。
该方案小组仅仅把 EJB 组件用作主机数据与 servlets 间的数据映射机制，这不是 EJB 技术的有效使用方法。本例中的应用没有利用以下一些特性：

EJB 组件的事务处理特性
EJB 组件的方法级安全性
EJB 组件的伸缩性与分布式特点(该方案小组仅使用了一个 EJB 服务器)
多种类型客户端间的商务逻辑共享
具备容器管理持久性(CMP)的 EJB 组件的自动数据映射功能

如果直接由和 java servlets 处于同一 JVM 中的 JavaBeans 组件来实现数据映射功能，系统的速度将比使用 EJB 组件快得多，同时避免了大量的网络开销。该系统还变得不必要的复杂(因为需要本地和远程接口，以及分布代码)。事实上，该方案后来被废弃并以不使用 EJB 组件的方式进行了重新设计，其中的数据映射由一套被 servlets 使用的标准 JavaBeans 组件实现。这使得最后的系统变得更简单、更快速。

一个成功使用EJB技术的例子
一个金融机构的方案小组设计了这套方案，最初使用了 java 和 RMI 技术。其系统体系结构如下：

RMI服务器体系结构


除了多种类型的客户端，方案小组还在系统内构建了以下两个框架单元，在本图中未画出来：

一个数据库映射层，通过 RMI 服务器上的 JDBC 将其 Oracle 数据表映射成 java 类，或者反过来。
一个用户安全框架单元，用于验证来自浏览器或应用客户端的用户，并进而决定用户是否有权进行 RMI 和数据库请求。
由于他们的应用需求与 EJB 技术的目标紧密相连，该方案小组得以很快将其设计方案转变为以下体系结构：


新的 EJB 体系结构


通过使用容器管理持久性(CMP)，EJB 组件使得方案小组可以抛弃数据库映射框架，转而利用 WebSphere 和 VisualAge for Java 中完整高效的实现机制。通过利用 EJB 技术的安全性，方案小组得以在应用中保留方法级安全性的同时，抛弃了他们的用户安全框架。结果，由于需要维护的代码量减少了，他们的应用变得更为简单。

简单地说，该应用的以下特点使得它适合使用 EJB 技术：

具有共享相同商务逻辑的多种类型客户端
使用了事务处理
需要通过 CMP 组件来实现与对象有关的映射
需要方法级的安全性

由于系统的设计目标是通过使用与实体同时发布的会话级 EJB 组件来实现最小的网络流量，该系统最终的体系结构很好地使用了 EJB 组件。对于前一种体系结构，由于客户端需要发出大量的请求，很可能会增加网络负担，另外由于要求客户端进行事务的启动、提交、取消，使得系统复杂化。

总结
构建一个可能使用 EJB 组件的新系统时，做出正确决定的第一步是要懂得如何确定 EJB 技术是否适合于该应用，包括选择 EJB 组件作为一种实现手段所带来的正面和负面影响。