J2EE又是一种框架和标准，框架类似API、库的概念，但是要超出它们。

J2EE是一个虚的大的概念，J2EE标准主要有三种子技术标准：WEB技术、EJB技术和JMS，谈到J2EE应该说最终要落实到这三个子概念上。

这三种技术的每个技术在应用时都涉及两个部分：容器部分和应用部分，Web容器也是指Jsp/Servlet容器，你如果要开发一个Web应用，无论是编译或运行，都必须要有Jsp/Servlet库或API支持（除了JDK/J2SE以外）。

Web技术中除了Jsp/Servlet技术外，还需要JavaBeans或Java Class实现一些功能或者包装携带数据，所以Web技术最初简称为Jsp/Servlet+JavaBeans系统。

谈到JavaBeans技术，就涉及到组件构件技术（component），这是Java的核心基础部分，很多软件设计概念（设计模式）都是通过JavaBeans实现的。

JavaBeans不属于J2EE概念范畴中，如果一个JavaBeans对象被Web技术（也就是Jsp/Servlet）调用，那么JavaBeans就运行在J2EE的Web容器中；如果它被EJB调用，它就运行在EJB容器中。

EJB（企业JavaBeans）是普通JavaBeans的一种提升和规范，因为企业信息系统开发中需要一个可伸缩的性能和事务、安全机制，这样能保证企业系统平滑发展，而不是发展到一种规模重新更换一套软件系统。

J2EE集群原理: http://www.jdon.com/jive/article.jsp?forum=121&thread=22282

至此，JavaBeans组件发展到EJB后，并不是说以前的那种JavaBeans形式就消失了，这就自然形成了两种JavaBeans技术：EJB和POJO，POJO完全不同于EJB概念，指的是普通JavaBeans，而且这个JavaBeans不依附某种框架，或者干脆可以说：这个JavaBeans是你为这个应用程序单独开发创建的。

J2EE应用系统开发工具有很多：如JBuilder、Eclipse等，这些IDE首先是Java开发工具，也就是说，它们首要基本功能是可以开发出JavaBeans或Java class，但是如果要开发出J2EE系统，就要落实到要么是Web技术或EJB技术，那么就有可能要一些专门模块功能，最重要的是，因为J2EE系统区分为容器和应用两个部分，所以，在任何开发工具中开发J2EE都需要指定J2EE容器。

J2EE容器分为WEB容器和EJB容器，Tomcat/Resin是Web容器；JBoss是EJB容器+Web容器等，其中Web容器直接使用Tomcat实现的。所以你开发的Web应用程序可以在上面两种容器运行，而你开发的Web+EJB应用则只可以在JBoss服务器上运行，商业产品Websphere/Weblogic等和JBoss属于同一种性质。

J2EE容器也称为J2EE服务器，大部分时它们概念是一致的。

如果你的J2EE应用系统的数据库连接是通过JNDI获得，也就是说是从容器中获得，那么你的J2EE应用系统基本与数据库无关，如果你在你的J2EE应用系统耦合了数据库JDBC驱动的配置，那么你的J2EE应用系统就有数据库概念色彩，作为一个成熟需要推广的J2EE应用系统，不推荐和具体数据库耦合，当然这其中如何保证J2EE应用系统运行性能又是体现你的设计水平了。

高质量的Java企业系统

衡量J2EE应用系统设计开发水平高低的标准就是：解耦性；你的应用系统各个功能是否能够彻底脱离？是否不相互依赖，也只有这样，才能体现可维护性、可拓展性的软件设计目标。

为了达到这个目的，诞生各种框架概念，J2EE框架标准将一个系统划分为WEB和EJB主要部分，当然我们有时不是以这个具体技术区分，而是从设计上抽象为表现层、服务层和持久层，这三个层次从一个高度将J2EE分离开来，实现解耦目的。

因此，我们实际编程中，也要将自己的功能向这三个层次上靠，做到大方向清楚，泾渭分明，但是没有技术上约束限制要做到这点是很不容易的，因此我们还是必须借助J2EE具体技术来实现，这时，你可以使用EJB规范实现服务层和持久层，Web技术实现表现层；

EJB为什么能将服务层从Jsp/Servlet手中分离出来，因为它对JavaBeans编码有强制的约束，现在有一种对JavaBeans弱约束，使用Ioc模式实现的（当然EJB 3.0也采取这种方式），在Ioc模式诞生前，一般都是通过工厂模式来对JavaBeans约束，形成一个服务层，这也是是Jive这样开源论坛设计原理之一。

由此，将服务层从表现层中分离出来目前有两种可选架构选择：管理普通JavaBeans（POJO）框架(如Spring、JdonFramework)以及管理EJB的EJB框架，因为EJB不只是框架，还是标准，而标准可以扩展发展，所以，这两种区别将来是可能模糊，被纳入同一个标准了。

但是，通常标准制定是为某个目的服务的，总要牺牲一些换取另外一些，所以，这两种架构会长时间并存。

前面谈了服务层框架，使用服务层框架可以将JavaBeans从Jsp/Servlet中分离出来，而使用表现层框架则可以将Jsp中剩余的JavaBeans完全分离，这部分JavaBeans主要负责显示相关，一般是通过标签库（taglib）实现，不同框架有不同自己的标签库，Struts是应用比较广泛的一种表现层框架。

这样，表现层和服务层的分离是通过两种框架达到目的，剩余的就是持久层框架了，通过持久层的框架将数据库存储从服务层中分离出来是其目的，持久层框架有两种方向：直接自己编写JDBC等SQL语句（如iBatis）；使用O/R Mapping技术实现的Hibernate和JDO技术；当然还有EJB中的实体Bean技术。

持久层框架目前呈现百花齐放，各有优缺点的现状，所以正如表现层框架一样，目前没有一个框架被指定为标准框架，当然，表现层框架现在又出来了一个JSF，它代表的页面组件概念是一个新的发展方向，但是复杂的实现让人有些忘而却步。

最后，你的J2EE应用系统如果采取上面提到的表现层、服务层和持久层的框架实现，基本可以在无需深刻掌握设计模式的情况下开发出一个高质量的应用系统了。

还要注意的是: 开发出一个高质量的J2EE系统还需要正确的业务需求理解，那么域建模提供了一种比较切实可行的正确理解业务需求的方法，相关详细知识可从UML角度结合理解。

当然，如果你想设计自己的行业框架，那么第一步从设计模式开始吧，因为设计模式提供你一个实现JavaBeans或类之间解耦参考实现方法，当你学会了系统基本单元JavaBeans或类之间解耦时，那么系统模块之间的解耦你就可能掌握，进而你就可以实现行业框架的提炼了，这又是另外一个发展方向了。

以上理念可以总结为一句话：

J2EE开发三件宝: Domain Model（域建模）、patterns（模式）和framework（框架）。

JAR 文件是什么？

JAR 文件格式以流行的 ZIP 文件格式为基础，用于将许多个文件聚集为一个文件。与 ZIP 文件不同的是，JAR 文件不仅用于压缩和发布，而且还用于部署和封装库、组件和插件程序，并可被像编译器和 JVM 这样的工具直接使用。在 JAR 中包含特殊的文件，如 manifests 和部署描述符，用来指示工具如何处理特定的 JAR。

一个 JAR 文件可以用于：

• 用于发布和使用类库
• 作为应用程序和扩展的构建单元
• 作为组件、applet 或者插件程序的部署单位
• 用于打包与组件相关联的辅助资源

JAR 文件格式提供了许多优势和功能，其中很多是传统的压缩格式如 ZIP 或者 TAR 所没有提供的。它们包括：

• 安全性。可以对 JAR 文件内容加上数字化签名。这样，能够识别签名的工具就可以有选择地为您授予软件安全特权，这是其他文件做不到的，它还可以检测代码是否被篡改过。
  
• 减少下载时间。 如果一个 applet 捆绑到一个 JAR 文件中，那么浏览器就可以在一个 HTTP 事务中下载这个 applet 的类文件和相关的资源，而不是对每一个文件打开一个新连接。
  
• 压缩。JAR 格式允许您压缩文件以提高存储效率。
  
• 传输平台扩展。 Java 扩展框架(Java Extensions Framework)提供了向 Java 核心平台添加功能的方法，这些扩展是用 JAR 文件打包的(Java 3D 和 JavaMail 就是由 Sun 开发的扩展例子)。
  
• 包密封。存储在 JAR 文件中的包可以选择进行 密封，以增强版本一致性和安全性。密封一个包意味着包中的所有类都必须在同一 JAR 文件中找到。
  
• 包版本控制。一个 JAR 文件可以包含有关它所包含的文件的数据，如厂商和版本信息。
  
• 可移植性。处理 JAR 文件的机制是 Java 平台核心 API 的标准部分。

压缩的和未压缩的 JAR

jar 工具(有关细节参阅 jar 工具 )在默认情况下压缩文件。未压缩的 JAR 文件一般可以比压缩过的 JAR 文件更快地装载，因为在装载过程中要解压缩文件，但是未压缩的文件在网络上的下载时间可能更长。

META-INF 目录

大多数 JAR 文件包含一个 META-INF 目录，它用于存储包和扩展的配置数据，如安全性和版本信息。Java 2 平台识别并解释 META-INF 目录中的下述文件和目录，以便配置应用程序、扩展和类装载器：

• MANIFEST.MF。这个 manifest 文件定义了与扩展和包相关的数据。
  
• INDEX.LIST。 这个文件由 jar 工具的新选项 -i 生成，它包含在应用程序或者扩展中定义的包的位置信息。它是 JarIndex 实现的一部分，并由类装载器用于加速类装载过程。
  
• xxx.SF。 这是 JAR 文件的签名文件。占位符 xxx标识了签名者。
  
• xxx.DSA。 与签名文件相关联的签名程序块文件，它存储了用于签名 JAR 文件的公共签名。

jar 工具

为了用 JAR 文件执行基本的任务，要使用作为Java Development Kit 的一部分提供的 Java Archive Tool ( jar 工具)。用 jar 命令调用 jar 工具。表 1 显示了一些常见的应用：

表 1. 常见的 jar 工具用法

功能	命令
用一个单独的文件创建一个 JAR 文件	jar cf jar-file input-file...
用一个目录创建一个 JAR 文件	jar cf jar-file dir-name
创建一个未压缩的 JAR 文件	jar cf0 jar-file dir-name
更新一个 JAR 文件	jar uf jar-file input-file...
查看一个 JAR 文件的内容	jar tf jar-file
提取一个 JAR 文件的内容	jar xf jar-file
从一个 JAR 文件中提取特定的文件	jar xf jar-file archived-file...
运行一个打包为可执行 JAR 文件的应用程序	java -jar app.jar

回页首

可执行的 JAR

一个 可执行的 jar 文件是一个自包含的 Java 应用程序，它存储在特别配置的JAR 文件中，可以由 JVM 直接执行它而无需事先提取文件或者设置类路径。要运行存储在非可执行的 JAR 中的应用程序，必须将它加入到您的类路径中，并用名字调用应用程序的主类。但是使用可执行的 JAR 文件，我们可以不用提取它或者知道主要入口点就可以运行一个应用程序。可执行 JAR 有助于方便发布和执行 Java 应用程序。

创建可执行 JAR

创建一个可执行 JAR 很容易。首先将所有应用程序代码放到一个目录中。假设应用程序中的主类是 com.mycompany.myapp.Sample 。您要创建一个包含应用程序代码的 JAR 文件并标识出主类。为此，在某个位置(不是在应用程序目录中)创建一个名为 manifest 的文件，并在其中加入以下一行：

Main-Class: com.mycompany.myapp.Sample
            

然后，像这样创建 JAR 文件：

jar cmf manifest ExecutableJar.jar application-dir
            

所要做的就是这些了 -- 现在可以用 java -jar 执行这个 JAR 文件 ExecutableJar.jar。

一个可执行的 JAR 必须通过 menifest 文件的头引用它所需要的所有其他从属 JAR。如果使用了 -jar 选项，那么环境变量 CLASSPATH 和在命令行中指定的所有类路径都被 JVM 所忽略。

启动可执行 JAR

既然我们已经将自己的应用程序打包到了一个名为 ExecutableJar.jar 的可执行 JAR 中了，那么我们就可以用下面的命令直接从文件启动这个应用程序：

java -jar ExecutableJar.jar
            

回页首

包密封

密封 JAR 文件中的一个包意味着在这个包中定义的所有类都必须在同一个 JAR 文件中找到。这使包的作者可以增强打包类之间的版本一致性。密封还提供了防止代码篡改的手段。

要密封包，需要在 JAR 的 manifest 文件中为包添加一个 Name 头，然后加上值为“true”的 Sealed 头。与可执行的 JAR 一样，可以在创建 JAR 时，通过指定一个具有适当头元素的 manifest 文件密封一个 JAR，如下所示：

Name: com/samplePackage/
            Sealed: true
            

Name 头标识出包的相对路径名。它以一个“/”结束以与文件名区别。在 Name 头后面第一个空行之前的所有头都作用于在 Name 头中指定的文件或者包。在上述例子中，因为 Sealed 头出现在 Name 头后并且中间没有空行，所以 Sealed 头将被解释为只应用到包 com/samplePackage 上。

如果试图从密封包所在的 JAR 文件以外的其他地方装载密封包中的一个类，那么 JVM 将抛出一个 SecurityException 。

扩展打包
扩展为 Java 平台增加了功能，在 JAR 文件格式中已经加入了扩展机制。扩展机制使得 JAR 文件可以通过 manifest 文件中的 Class-Path 头指定所需要的其他 JAR 文件。

假设 extension1.jar 和 extension2.jar 是同一个目录中的两个 JAR 文件，extension1.jar 的 manifest 文件包含以下头：

Class-Path: extension2.jar

这个头表明 extension2.jar 中的类是 extension1.jar 中的类的 扩展类。extension1.jar 中的类可以调用 extension2.jar 中的类，并且不要求 extension2.jar 处在类路径中。

在装载使用扩展机制的 JAR 时，JVM 会高效而自动地将在 Class-Path 头中引用的 JAR 添加到类路径中。不过，扩展 JAR 路径被解释为相对路径，所以一般来说，扩展 JAR 必须存储在引用它的 JAR 所在的同一目录中。

例如，假设类 ExtensionClient 引用了类 ExtensionDemo ,它捆绑在一个名为 ExtensionClient.jar 的 JAR 文件中，而类 ExtensionDemo 则捆绑在 ExtensionDemo.jar 中。为了使 ExtensionDemo.jar 可以成为扩展，必须将 ExtensionDemo.jar 列在 ExtensionClient.jar 的 manifest 的 Class-Path 头中，如下所示：

Manifest-Version: 1.0 Class-Path: ExtensionDemo.jar

在这个 manifest 中 Class-Path 头的值是没有指定路径的 ExtensionDemo.jar，表明 ExtensionDemo.jar 与 ExtensionClient JAR 文件处在同一目录中。

回页首

JAR 文件中的安全性

JAR 文件可以用 jarsigner 工具或者直接通过 java.security API 签名。一个签名的 JAR 文件与原来的 JAR 文件完全相同，只是更新了它的 manifest，并在 META-INF 目录中增加了两个文件，一个签名文件和一个签名块文件。

JAR 文件是用一个存储在 Keystore 数据库中的证书签名的。存储在 keystore 中的证书有密码保护，必须向 jarsigner 工具提供这个密码才能对 JAR 文件签名。

JAR 的每一位签名者都由在 JAR 文件的 META-INF 目录中的一个具有 .SF 扩展名的签名文件表示。这个文件的格式类似于 manifest 文件 -- 一组 RFC-822 头。如下所示，它的组成包括一个主要部分，它包括了由签名者提供的信息、但是不特别针对任何特定的 JAR 文件项，还有一系列的单独的项，这些项也必须包含在 menifest 文件中。在验证一个签名的 JAR 时，将签名文件的摘要值与对 JAR 文件中的相应项计算的摘要值进行比较。

Contents of signature file META-INF/MANIFEST.MF
            Manifest-Version: 1.0
            Created-By: 1.3.0 (Sun Microsystems Inc.)
            Name: Sample.java
            SHA1-Digest: 3+DdYW8INICtyG8ZarHlFxX0W6g=
            Name: Sample.class
            SHA1-Digest: YJ5yQHBZBJ3SsTNcHJFqUkfWEmI=
            Contents of signature file META-INF/JAMES.SF
            Signature-Version: 1.0
            SHA1-Digest-Manifest: HBstZOJBuuTJ6QMIdB90T8sjaOM=
            Created-By: 1.3.0 (Sun Microsystems Inc.)
            Name: Sample.java
            SHA1-Digest: qipMDrkurQcKwnyIlI3Jtrnia8Q=
            Name: Sample.class
            SHA1-Digest: pT2DYby8QXPcCzv2NwpLxd8p4G4=
            

数字签名

一个数字签名是.SF 签名文件的已签名版本。数字签名文件是二进制文件，并且与 .SF 文件有相同的文件名，但是扩展名不同。根据数字签名的类型 -- RSA、DSA 或者 PGP -- 以及用于签名 JAR 的证书类型而有不同的扩展名。

Keystore

要签名一个 JAR 文件，必须首先有一个私钥。私钥及其相关的公钥证书存储在名为 keystores 的、有密码保护的数据库中。JDK 包含创建和修改 keystores 的工具。keystore 中的每一个密钥都可以用一个别名标识，它通常是拥有这个密钥的签名者的名字。

所有 keystore 项(密钥和信任的证书项)都是用唯一别名访问的。别名是在用 keytool -genkey 命令生成密钥对(公钥和私钥)并在 keystore 中添加项时指定的。之后的 keytool 命令必须使用同样的别名引用这一项。

例如，要用别名“james”生成一个新的公钥/私钥对并将公钥包装到自签名的证书中，要使用下述命令：

keytool -genkey -alias james -keypass jamespass
            -validity 80 -keystore jamesKeyStore
            -storepass jamesKeyStorePass
            

这个命令序列指定了一个初始密码“jamespass”，后续的命令在访问 keystore “jamesKeyStore”中与别名“james”相关联的私钥时，就需要这个密码。如果 keystore“jamesKeyStore”不存在，则 keytool 会自动创建它。

jarsigner 工具

jarsigner 工具使用 keystore 生成或者验证 JAR 文件的数字签名。

假设像上述例子那样创建了 keystore “jamesKeyStore”，并且它包含一个别名为“james”的密钥，可以用下面的命令签名一个 JAR 文件：

jarsigner -keystore jamesKeyStore -storepass jamesKeyStorePass
            -keypass jamespass -signedjar SSample.jar Sample.jar james
            

这个命令用密码“jamesKeyStorePass”从名为“jamesKeyStore”的 keystore 中提出别名为“james”、密码为“jamespass”的密钥，并对 Sample.jar 文件签名、创建一个签名的 JAR -- SSample.jar。

jarsigner 工具还可以验证一个签名的 JAR 文件，这种操作比签名 JAR 文件要简单得多，只需执行以下命令：

jarsigner -verify SSample.jar
            

如果签名的 JAR 文件没有被篡改过，那么 jarsigner 工具就会告诉您 JAR 通过验证了。否则，它会抛出一个 SecurityException ， 表明哪些文件没有通过验证。

还可以用 java.util.jar 和 java.security API 以编程方式签名 JAR(有关细节参阅 参考资料)。也可以使用像 Netscape Object Signing Tool 这样的工具。

回页首

JAR 索引

如果一个应用程序或者 applet 捆绑到多个 JAR 文件中，那么类装载器就使用一个简单的线性搜索算法搜索类路径中的每一个元素，这使类装载器可能要下载并打开许多个 JAR 文件，直到找到所要的类或者资源。如果类装载器试图寻找一个不存在的资源，那么在应用程序或者 applet 中的所有 JAR 文件都会下载。对于大型的网络应用程序和 applet，这会导致启动缓慢、响应迟缓并浪费带宽。

从 JDK 1.3 以后，JAR 文件格式开始支持索引以优化网络应用程序中类的搜索过程，特别是 applet。JarIndex 机制收集在 applet 或者应用程序中定义的所有 JAR 文件的内容，并将这些信息存储到第一个 JAR 文件中的索引文件中。下载了第一个 JAR 文件后，applet 类装载器将使用收集的内容信息高效地装载 JAR 文件。这个目录信息存储在根 JAR 文件的 META-INF 目录中的一个名为 INDEX.LIST 的简单文本文件中。

创建一个 JarIndex
可以通过在 jar 命令中指定 -i 选项创建一个 JarIndex。假设我们的目录结构如下图所示：

您将使用下述命令为 JarIndex_Main.jar、JarIndex_test.jar 和 JarIndex_test1.jar 创建一个索引文件：

jar -i JarIndex_Main.jar JarIndex_test.jar SampleDir/JarIndex_test1.jar
            

INDEX.LIST 文件的格式很简单，包含每个已索引的 JAR 文件中包含的包或者类的名字，如清单 2 所示：

JarIndex-Version: 1.0
            JarIndex_Main.jar
            sp
            JarIndex_test.jar
            Sample
            SampleDir/JarIndex_test1.jar
            org
            org/apache
            org/apache/xerces
            org/apache/xerces/framework
            org/apache/xerces/framework/xml4j
            

回页首

结束语

JAR 格式远远超出了一种压缩格式，它有许多可以改进效率、安全性和组织 Java 应用程序的功能。因为这些功能已经建立在核心平台 -- 包括编译器和类装载器 -- 中了，所以开发人员可以利用 JAR 文件格式的能力简化和改进开发和部署过程。.

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 参阅 jar 实用程序的命令行选项的文档。
  
  
  
• Raffi Krikorian 在 ONJava 上发表的文章提供了有关 programmatically signing a JAR file的帮助。
  
  
  
• 这篇关于 Java Archive Tool的文档解释了创建和操作 JAR 文件可以使用的选项。
  
  
  
• 文章“ Java Web Start”( developerWorks，2001 年 9 月)描述了如何使用这种技术，以便允许应用程序可以指定所需的 JAR 文件并动态下载它们。
  
  
  
• 有关 J2EE 服务器（比如 IBM WebSphere Application Server）使用 JAR 文件格式的不同方式，请参阅“ What are Java Archive (JAR) files?”
  
  
  
• JAR 格式是 WAR (Web Archive) 格式的基础，WAR用于在 J2EE 容器中部署 Servlet 和 JSP 应用程序。更多内容请参阅“ What are WAR files?”。
  
  
  
• JAR 格式也是 EAR (Enterprise Archive) 格式的基础，EAR 用于在 J2EE 容器中部署 EJB。更多内容请参阅“ What are Enterprise Archive (EAR) files?”。
  
  
  
• 在 developerWorks Java 技术专区 上可以找到数百篇关于 Java 编程的各个方面的文章。
  
  

作者简介

		Pagadala J. Suresh 是 IBM Global Services India 的软件工程师。他擅长的领域包括 Java 技术、WebSphere Application Server 和 WebSphere Studio Application Developer (WSAD)、Ariba Buyer。他参与了 WebSphere 的 IBM Redbook 项目。可以通过 pjsuresh@in.ibm.com 与 Pagadala 联系。

		Palaniyappan Thiagarajan 是位于印度班加罗尔的 IBM Global Services India 的软件工程师。他是IBM 认证的 IBM WebSphere Application Server V3.5 和 IBM DB2 UDB V7.1 Family Fundamentals 专家。可以通过 tpalaniy@in.ibm.com 与 Palaniyappan 联系。

对于这两种应用，通常第一考虑是性能要最优，性能是我们选择IT技术的主要依据之一。

为达到最大化的性能，对于Java系统，以前通常的作法是使用对象池，这样节约对象生成时的性能开销，也就是说系统启动时，预先生成一定数目的对象实例在内存中，需要使用时，从对象池中取出实例，用完，归还对象池，对于有状态的应用，可以使用相关持久化（persistence）策略来保存状态。

下一步，如何并行访问对象池将是非常重要，java的多线程技术为我们提供了实现可能，线程的创建销毁也是可能非常耗时的，那么，无疑象使用对象池一样，我们必须使用线程池来实现多线程并行计算的最优化。

使用线程池和对象池，每次客户端请求发生一次就从线程池中借用一个线程，处理完这个请求就将线程返回线程池，同样，使用线程快速的访问对象，对象也是从对象池中借用，用完就还回对象池。 整个这样的架构设计在性能上是最优的。

有了性能保证，安全机制、事务机制、集群(cluster)技术也将是选择IT技术的主要依据。

J2EE就是这样一个实现上述多种考量的综合标准框架系统，在具体使用中，也许我们对所有这些考量的要求并不都一样重视，比如：如果纯粹追求性能是第一，可以忽视事务机制，那么，完整的J2EE技术也许就并不适合你。

那么我们先看看J2EE是如何从性能上保证我们的应用系统以最快速度运行的，也就是说J2EE中必然应该有上述线程池和对象池的实现技术，servlet实际是基于线程池的更好的线程容器；EJB是基于对象池的更好的对象容器。

看看Servler的架构图：

当client1发生请求时servlet容器会从线程池中分配一个线程给这个request.

再看看EJB的架构图：

instance Pool作为一个对象实例池，维持着EJB实例，当然这个对象池是用生命周期的，简单的说 EJB=对象池+远程对象池

但是，EJB还整合了相当的其它增强功能，如安全 事务机制等，这些对于一般应用都是必需的，当然你还必须根据你的需要来选择是否使用J2EE，如果你的应用对安全 事务机制没有要求，直接使用线程池和对象池技术肯定获得最好的性能。

所以，根据Servler和EJB的原理，我们已经可以规划我们的应用，什么可以放在servlet，或什么需要放在EJB中实现：

线程的本质决定了servlet只适合一些轻量的应用，如分析简单XML文档, 通过JDBC访问数据源，使用JMS或JavaMail处理简单的信息Message，或使用JTS/JTA处理简单的事务机制，注意这些用词都是"简单"的，一旦复杂了，就要使用EJB了。

下面从客户端和服务器端两个方面来具体考量这两个技术的使用，这里的客户端不一定是指最终客户端，因为J2EE是多层结构，中间层可能在多个服务器上实现，如果一个服务器上的服务是供另外一个服务器上的应用访问的，那么后者我们也称为客户端。

根据应用的复杂程度和要求不同，分下列情况：

1.在WEB层可以实现的一些应用

如果你的系统没有很复杂的事务处理，或访问很多企业原有的资源，那么可以借助javabean这样的一些Help性质的类来实现你的应用，但是，这样的方案不是最干净clean, 最有效efficient, 或最有扩展性的scalable。

否则，将所有核心计算放置入EJB中。

2.所有的复杂商务计算核心都在EJB中完成

如果你的客户端和服务器端之间有防火墙，那么目前能够无障碍通过防火墙的协议只有Http了(Web Service也是基于http就是这个道理)，既然使用http了，而Servlet是基于Http协议的，那么就需要通过servlet来访问EJB，这是我们最普遍的应用情况。

但是，如果你的客户端和服务器端可以放置在一个网络内，之间没有防火墙，那么就不必使用Servlet，直接使用Java调用RMI来访问EJB，这样性能是最好的，这时的Servlet大概只有用于控制Jsp的页面的输出了(MVC模式中的控制作用)。

如果是非java客户端，可以通过CORBA组件来访问EJB。

3.如果你的应用对速度要求很高，要求非常快，对于事务处理等方面几乎无要求

直接使用J2SE，加上线程池和对象池技术，将会使你的java系统性能发挥极致。Jakarta.Apache.org有这两种技术的源码，线程池可以从Servlet容器Tomcat的源码中发现。