提纲:
　　一、基础知识
　　1.1 j2ee应用的构成
　　1.2 封装和部署操作的任务
　　1.3 不能封装到ear文件的组件
　　二、类装载模式
　　2.1 在ejb 2.0之前
　　2.2 在ejb 2.0之后
　　正文:
　　一、基础知识
　　1.1 j2ee应用的构成
　　j2ee应用由以下两种资源构成：
　　一个或者多个j2ee组件
　　一个j2ee应用部署描述器（deployment descriptor）
　　当多个异种的j2ee组件需要相互调用时，我们必须创建一个j2ee应用。在创建j2ee应用的过程中，有许多事情必须考虑，其中包括：
　　有哪些类型的组件可以封装到j2ee应用里？
　　创建j2ee应用的过程中，人们担负的各种职责。
　　当前j2ee封装技术的局限之处。
　　为满足j2ee组件交互的需要，不同的供应商所采取的类装载策略。
　　j2ee规范区分了两类资源：可以在容器之内运行的资源，可以封装到ear文件内的资源。ear是enterprise application archive的缩写，ear文件用来把一个或者多个j2ee组件封装到单个模块里面，以便一起部署并装入到服务器上。
　　j2ee规范阐明了运行时容器和部署模块之间的区别。运行时容器是请求级的截取机制，为系统内的组件提供一种基础服务。部署模块是一种为那些最终将在运行时容器内执行的组件提供的封装结构。下图描述了j2ee容器的结构：
　　　
　　其中：
　　ejb容器
　　ejb容器用来容纳业务逻辑，并为业务逻辑截取请求。ejb容器支持ejb访问jms、jaas、jta、javamail、jaxp、jdbc和连接器（connector）。
　　web容器
　　web容器截取通过http、ftp、smtp或其他协议发送的请求。web应用容器为servlet和jsp页面提供的资源与ejb容器提供的资源相同。
　　应用客户端容器
　　客户端应用是独立的java应用，它们在远程的独立jvm上运行（与web容器和ejb容器所运行的jvm不同）。应用客户端容器为这些应用截取请求。
　　运行在应用客户端容器上的程序非常类似于带有main()方法的java程序，不过，程序不再由jvm控制，而是由一个容器（也就是应用客户端容器）控制。
　　在应用客户端容器内运行的程序能够访问远程应用服务器上的jaxp、jdbc、jms和jaas资源。
　　applet容器
　　applet容器是一个特殊的容器，它为在浏览器内运行的java程序截取请求。applet容器不提供任何对其他资源（比如jdbc或jms）的访问。在applet容器内运行的applet必须自己直接向应用服务器请求资源（而不是把请求发送给容器，然后由容器发送请求给应用服务器）。
　　对于applet如何与ejb容器进行通信，ejb规范没有作出任何规定，但j2ee规范有这方面的规定。对于那些想要直接使用ejb的applet，j2ee规范要求它们使用http隧道。许多应用服务器提供某种形式的http隧道，支持applet直接使用ejb。
　　可以封装到j2ee ear文件里面的组件与包含容器的组件之间不存在直接的关联。j2ee没有规定ear文件至少必须包含哪些内容，ear文件可以由任意数量的以下组件构成：
　　
　　ejb应用jar文件
　　
　　ejb应用jar文件包含一个或者多个ejb组件。
　　
　　web应用war文件
　　
　　一个war文件包含一个web应用。ear文件可以包含多个web应用，ear文件中的每个web应用必须有一个唯一的部署上下文。ear文件的部署机制允许指定这类不同的上下文。
　　
　　应用客户端jar文件
　　
　　应用客户端jar文件包含一个准备在应用客户端容器内运行的独立java应用，还包含一个专用的部署描述器，其构成方式和ejb jar文件的构成方式相似。
　　
　　应用客户端jar文件除了包含运行独立客户程序所需要的类之外，还包含访问jdbc、jms、jaxp、jaas和ejb客户所需要的客户端库。
　　
　　资源适配器rar文件
　　
　　资源适配器rar文件包含了实现企业信息系统jca（java connector architecture）资源适配器所需要的java类和本地库。
　　
　　资源适配器不在容器内执行。相反，它们应该作为应用服务器和外部企业信息系统之间的桥接软件执行。
　　
　　这些组件都在j2ee ear文件之外分别地开发和打包，且分别拥有自己的部署描述器。然后，j2ee ear文件通过定制的部署描述器，把一个或者多个这种组件装配成一个统一的包。
　　
　　1.2 封装和部署操作的任务
　　
　　在ejb、web应用或其他组件的构造、部署和使用过程中，不同的人担负着不同的职责。j2ee规范为开发者在创建企业应用过程中的职责定义了范围广泛的平台角色（platform role）。尽管角色的数量众多，但它们不外乎是一种为了更好地规划和运行一个应用而设计的逻辑划分，单独的个人、小组或组织很可能扮演多个角色。在构造、部署使用ear文件的过程中，常见的角色包括：
　　
　　j2ee产品提供者
　　
　　负责实现j2ee平台，包括在规范中定义的所有j2ee api和其他功能。比如，j2ee应用服务器的供应商。
　　
　　应用组件提供者
　　
　　负责提供j2ee组件，例如ejb应用或web应用。j2ee规范中的许多角色都具有应用组件提供者的特征，比如文档编写者、jsp页面编写者、资源适配器开发者等。
　　
　　应用组装者
　　
　　负责把一个或者多个j2ee组件打包成ear文件，构造出j2ee应用。应用组装者还要负责创建j2ee应用部署描述器，说明应用依赖的各种外部资源，比如类库、安全角色等。通常，应用组装者要用到j2ee产品提供者和工具提供者提供的工具。
　　
　　工具提供者
　　
　　提供自动化j2ee应用创建、打包、部署过程的工具，例如为ear文件自动生成部署描述器的工具，自动创建ear文件的工具。
　　
　　部署者
　　
　　负责把web应用和ejb应用部署到服务器环境上。部署者不负责部署资源适配器包和应用客户端包，但可能要负责为这些组件进行额外的配置。这些组件虽然被打包成为j2ee ear文件的一部分，部署企业应用时却不必考虑。它们是j2ee应用的一部分，但不必象web应用和ejb容器那样经过一个“激活”过程。资源适配器包是置入合法jca实现的简单库，虽然它们被打包进j2ee ear文件，但它们不在j2ee容器环境下运行。因此，由于资源适配器包不包含j2ee容器，它们的激活不需要j2ee部署者的特别干预。应用客户端程序在j2ee容器的环境下运行，但它们不部署到应用服务器上。客户端程序独立运行，部署者不负责为这些程序配置容器环境。
　　
　　系统管理员
　　
　　负责为应用服务器和j2ee应用配置网络和运行环境，负责监视和维护j2ee应用的运行。
　　
　　在本文的讨论过程中，我们主要的角色是应用组装者和部署者。
　　
　　1.3 不能封装到ear文件的组件
　　
　　大多数基于web的j2ee应用只由web和ejb应用构成，ear文件能够满足封装应用的基本需求。然而，ear文件缺乏封装复杂j2ee应用的能力，比如，j2ee经常要用到下面这类组件，但它们无法在ear文件中声明：
　　jdbc datasource对象。
　　jms connectionfactory和destination对象。
　　jmx（java management extension）的mbean。
　　在应用服务器之内运行的一些jms消费者，例如作为serversession一部分运行的messageconsumer。
　　当应用被部署或卸载时触发运行的一些类（这些类是供应商提供的私有扩展，没有在j2ee规范中定义，但供应商一般都提供它们）。
　　当前，这些组件必须由系统管理员通过专用管理接口手工配置和部署。随着时间的推移，这些组件的应用也将日益增加，为了支持应用的整体移植性，让ear文件支持这些组件的封装也变得日益重要。
　　二、类装载模式
　　当一个类被引用时，java虚拟机（jvm）必须装入被引用的类。jvm利用一个标准的类装入机制把类装入内存，这个从源文件装入java类的机制称为类装载器。java类可以从磁盘、网络或其他媒体装入，它们可以驻留在任何地方。多个类装载器可以按照父-子关系链接在一起，形成一种层次结构。由子类装载器装入的类能够看到（能够使用）由任意父类装载器装入的类；由父类装载器装入的类不能看到由任意子类装载器装入的类。类装载器、ear文件与应用部署有着重要关系，因为应用服务器可能采用专用的类装载器部署应用模块。
　　如果在一个系统中，web应用需要访问某个ejb，它就必须能够装入它所需要的那些类。由于这意味着不同模块之间的依赖关系，为了解决依赖问题，应用服务器必须为ear类装载器考虑不同的结构方案。
　　独立的应用程序部署在它自己的类装载器中。这意味着，如果分别地部署一个web应用和一个ejb应用，每个应用的类将分别装入各自的、级别相同的类装入器，web应用内的类不能看到另一个类装载器装入的类。如果web应用想要使用那些分开部署的ejb，就会出现问题。
　　在ear文件出现之前，许多开发者先部署ejb，然后以web应用web-inf/lib目录一部分的形式，再次封装同一ejb jar文件。这样，同一类文件必须放入两个不同的地方，才能让应用正常地运行。显然，这是一种应当避免的情形。ear文件的引入就是为了解决这个问题。ear文件不仅是一种方便的封装格式，而且它还提供了一种特殊的类装载模式，允许ear文件内的应用访问其他应用的类。
　　j2ee 1.3规范没有具体规定ear类装载器应该如何运作。在决定类装入方式时，应用服务器供应商有着很大的自由。实现ear类装载器之前，供应商必须决定：
　　ear文件中所有应用的所有类由单一的类装载器装入，还是不同应用的文件由不同的类装载器装入？
　　在ear文件中的不同应用之间，是否存在类装载器的父-子关系？例如，如果两个ejb应用依赖于log4j.jar，那么，是否应该由父类装载器装入log4j.jar，由子类装载器装入两个ejb应用，从而维持适当的可见性关系？