本文比较全面地介绍了与J2EE应用开发有关的各种基本概念，包括多层应用体系、容器、各种组件及其适用场合、J2EE基础服务、J2EE客户端类型等。
J2EE多层应用体系
J2EE可以理解为一个企业级的中间件体系或平台，它把多种分散到网络上的资源和应用连接起来，为构造和治理、运行可伸缩的企业级业务应用提供了一系列的应用组件和一个运行环境。从物理上看，J2EE环境可分布驻留到一个以上的服务器，单一的业务应用能够以一组分布式组件的形式部署到网络上的一个或者多个服务器。
要理解J2EE，就必须把握下面几个支撑起J2EE体系的核心概念：
· J2EE n-tier应用体系：或称为J2EE多层应用体系，J2EE平台提供的基本应用架构。
· J2EE应用组件：构造J2EE应用的基本软件单元。
· J2EE企业服务：可被J2EE应用组件调用的公共服务功能。
· J2EE容器：J2EE组件的运行环境。
J2EE中间件体系定义了四个独立的层，应用软件就构造在这个框架上，它们是：
· 客户层（Client tier）。
· 表现逻辑层（PResentation logic tier）。
· 业务逻辑层（Business logic tier）。
· 企业信息系统层（EIS，Enterprise information systems tier）。
如图一所示:
图一
表现逻辑层和业务逻辑层属于应用服务器领域。所谓应用服务器，也即J2EE平台的具体实现。这四层中的每一层都可以在物理上分布到多个机器，即使同属于应用服务器领域的表现逻辑层和业务逻辑层，也可以驻留在不同的应用服务器上。例如，在一个应用中，HTTP和表现逻辑的容器可以使用Sun公司的J2EE应用服务器iplanet，部署业务逻辑组件可以用BEA公司的J2EE应用服务器Weblogic。
按照习惯，表现逻辑层总是与jsp容器相关，业务逻辑层总是与EJB容器相关。为便于理解，可以把J2EE多层体系中的“层”理解为一种概念实体，引入“层”这个概念是为了简化设计；与此相对，把容器理解为一种物理性的软件实体，容器的目标是为应用组件提供运行环境。
不同层次的J2EE应用组件驻留在它们各自的运行环境中，这些运行环境就是J2EE术语所谓的容器。容器是遵从一定接口标准的产品，为J2EE组件提供了必需的底层基础功能。按照J2EE标准编写好应用组件之后，还要用厂商专有的部署工具把它们分别部署到各自的容器。J2EE标准定义了四种不同的容器：
· Applet容器：运行和治理Applet。
· 应用客户端容器：运行和治理标准java应用客户程序，包括Swing应用。
· Web容器：运行和治理表现逻辑层的Servlet和JSP组件。
· EJB容器：运行和治理业务逻辑层的EJB。
为了提供静态Html页面服务，随同Web容器提供一个HTTP Web服务器是很典型的做法，目前几乎所有流行的J2EE应用服务器都有内建的HTTP Web服务器。
一般地，容器提供的基础功能包括内存治理、线程/同步机制、垃圾收集、可用性、可伸缩性、负载平衡和故障转移等。容器必须实现的基本接口和功能由J2EE规范定义，但具体如何实现完全由容器厂商自己决定。因此，J2EE既确保了不同应用服务器之间的兼容性，又为各个厂商的专有代码留下了自由空间。实际上，在中间件产业，各路厂商之所以得以施展各自神通，容器功不可没。
J2EE多层体系的思想在很大程度上受到了MVC设计模式的启发和影响。所谓MVC，即Model-View-Controller，它是一种在复杂的应用系统中划分和界定各个组件的职能和作用范围的设计模式。在MVC设计模式中，Model即模型，是处理核心数据模型或实现核心应用功能的部分；View即视图，主要与用户界面有关，例如把处理结果提供给客户端或其他应用。MVC设计模式认为这些不同的部分应该尽可能地相互独立，它们之间的交互则由Controller（控制器）协调。
例如，考虑一个在Internet上传输银行帐户信息的过程。按照MVC的设计思想，这个过程可以分割成四个独立的任务：
· 任务1：从浏览器启动传输过程（View）。
· 任务2：发出对帐户传输操作的调用（Controller）。
· 任务3：实际完成帐户传输操作（业务过程或Model）。
· 任务4：把传输状态（成功或失败）显示给浏览器（View）。
MVC认为核心业务过程（任务3）不应该做任何有关客户端的假设，例如，它不能假定客户端是一个浏览器，因为除了浏览器之外，其他的应用程序也应当能够顺利地调用核心业务过程；所有与客户端直接相关的操作应当由View来完成。至于业务逻辑和表现逻辑的联系和协调，则专门由Controller部分负责。
J2EE体系建立在MVC设计思想的基础上。很自然地，J2EE体系也鼓励把业务逻辑从表现层分离出来，属于Controller性质的代码可以放在这两个层的任意一个（或全部）。依靠于这种设计思想，J2EE为重用业务逻辑组件打开了广阔的空间。
J2EE应用组件
J2EE标准定义了一个完善的应用组件框架，作为企业应用系统基本构造模块的组件就建立在这个框架之上。几乎所有的业务应用，从简单的Web门户到复杂的企业级分布式事务应用，都可以在此基础上构造。
J2EE组件框架只是一个以库、类和接口形式提供的基础架构，最终构成应用的业务逻辑和表现/控制逻辑要由建立在这个框架上的应用组件实现。以J2EE提供的标准应用组件Servlet为例，为具体的业务应用构造的Servlet总是建立在J2EE提供的基本Servlet接口之上，开发者可以调用各种Servlet包提供的基本库和服务。许多系统级的服务都已经在这些库中提供，例如操作HTTP输入流读取数据和写入数据，只需直接调用即可。因此，我们把J2EE提供的组件基础架构叫做应用框架（application Framework），把建立在应用框架之上的代码叫做J2EE应用组件（Application Component）。
如图一所示，无论是客户层、表现层还是业务逻辑层，都有相应的J2EE应用组件：
· 客户层：Applet，Javabean
· 表现逻辑层：Servlet，JSP，Javabean
· 业务逻辑层：EJB
必须指出的是，除了上述J2EE组件之外，标准的Java类和Jar包也可以在所有这些层上很好地运行。在许多场合，我们可以找到代码以普通Java类而不是J2EE组件状态存在的情形。EIS即Enterprise Information System，它包含所有的企业后端资源，例如数据库等。显然，对于EIS资源，我们要做的只是从组件访问它们，访问细节则由J2EE企业服务解决，所以在EIS层没有应用组件的位置。开发J2EE应用就是开发一种或者多种上述组件，然后把它们部署到各自的容器。
组件的接口确保组件遵从一定的标准并向外界提供公用功能，从而为具有良好互操作性的J2EE环境提供了基础。应用组件在各个层之间宽松结合，确保了组件互操作的灵活性和组件的可重用性。对于给定的业务情形，适当地选用和搭配各种应用组件是J2EE应用体系设计中一项富有艺术性的工作。由于组件的种类繁多，要想得到优质的代码和表现出色的应用，就要有丰富的知识和经验来确定组件的最佳搭配方案。对于每一种应用组件，J2EE明确定义了它在应用中应当担负的角色，从而为合理设计应用体系提供了坚实的基础。下面我们就来看看在应用服务器领域，各种组件的主要特点，请参见图二。
图二
注重以下几点：
· Web容器和EJB容器是不同的，两者相对独立，可以是来自不同厂商的产品。这两种容器都可以使用企业服务。也就是说，无论是Web容器的组件还是EJB，都可以访问数据库连接、email服务、目录服务和消息服务。组件只能通过一个或者多个以驱动程序或适配器形式实现的企业服务访问EIS资源。
· 最好把所有应用组件频繁调用的用户自定义服务和库集中到一个独立的层。在图二的J2EE模型中，用户自定义的服务和库被合并到“自定义组件库”。这些库由用户自己开发，不属于标准J2EE应用服务器的一部分，一般它们会随着软件项目的成熟而日渐丰富。例如，配置文件工具库就是一个很好的例子：它根据指定的配置文件名字，打开该文件，然后以整数或字符串的形式返回指定的配置选项。
· 另一种常见的现象是，开发者在J2EE提供的核心企业服务的基础上编写自定义的访问例程。把这些自定义的服务访问例程组织成一个单独的“服务访问库”层是值得的。例如，假设我们在一个项目中用IBM的MQ Series作为消息系统。通常，我们会编写一些在JMS基础上访问MQ Series服务的简单API，例如给所有外发的消息加上企业标准的消息头。这时，最好把这些服务整理成“服务访问库”层的公用API，并让它们可被企业平台的所有应用调用。简而言之，服务访问库提供了J2EE API上的一层抽象，它们总是与特定的企业应用平台密切相关。
如前所述，在复杂的企业计算环境中，不同的J2EE组件应当担负不同的角色。下面我们就来看看具体情况。
Web容器组件:
· Servlet
Servlet是服务器端面向表现逻辑的组件，驻留在Web容器内。正如Applet扩展了浏览器的功能，Servlet扩展了Web服务器的功能——除了提供静态HTML之外，Servlet还提供编程和生成动态内容的功能。
Servlet能够处理来自客户端浏览器的请求，处理输入参数，把处理结果以HTTP应答的形式发送到客户端浏览器上显示出来。例如，Servlet可用来开发基于Web的简单认证系统，从客户端浏览器接收用户名字和密码，处理请求，再发回认证通过或不通过的应答。
除了接受来自
