原文地址: http://www.onjava.com/pub/a/onjava/2003/06/11/j2ee_deployment.html?page=1
1。介绍：
如今你和一些资历较高的J2EE开发人员交流的话，他们大部分都很乐意给你提供一些不同类型的EJB的细节问题，或者是怎么样来使用
JMS来发送和接受异步的消息。然而很难找到某个人能够描述一个能够确保可测试性，可靠性,和性能很好的系统构架部署。许多J2EE程序员缺少深入的理解部署。其中一个原因是J2EE specification中包含的应用程序的部署本来就甚少。把这个难题留给个人去考虑。所以这导致了许多困惑，比如每一个设计人员都有可能自己部署j2ee应用程序的方法。在此篇文章中，我们首先要介绍的是描述不同的J2EE模块和不同的打包结构。随后我们将来一起探讨一些可行的部署结构和一些在设计和执行J2EE应用程序中的部署技巧。
再此之前，你最好要了解一些J2EE核心技术，例如JSP，servlet，EJB，XML。
1.1J2EE Modules。
J2EE1.3支持把J2EE application打包成不同的可部署的模块.以下是2种J2EE modules
Application modules(enterprise application or web application)
Standalone modules(EJB or resource adapter)
基本上，一个WAR文件(Web Application Archive)是用来部署一个基于web的application。WAR文件中可以包含 servlets,HTML文件，JSPs
和一切和有关系的图或资源文件。另一方面,一个EAR文件（Enterprise Application Archice)是一个容器可以包含EJBs 资源适配器(resuorce adapters)，和一个或多个web application模块.当在打包enterprise application的时候部分需要考虑的是这个application需要用多少个EAR文件.是否要包含我的所有的EJBs到EAR文件中?这些决定将会直接影响到程序的运行稳定性，可维护性，和程序的执行。我们一会就来探讨这些，
1.2类加载器的关系（classLoader RelationShip)
经常在设计J2EE application时我们会忽略不同的模块类型间类加载之间的关系。Java虚拟机（JVM）用类加载器classloader来查找类和对象并把他们载如内存。在默认的情况下，系统的类加载器会根据在系统中的环境变量的Classpath的位置来加载类，当然也可以为自己的application提供别的加载的地方而不是默认的。
解释图1.应用程序端的server用SystemClassLoader加载,并且只能从通过系统的classpath才能看到资源。每一个EAR和RAR和WAR模块中中都有分离的单独的classloader。Classloaders加载器们的关系没有背很明确的确定，但是一般情况下在4种不同的类加载器中有一种关系就是父与子的关系，就像子类和父类的关系，当子类的classloader可以在在父类的classloader中定位class。但反之不行。在J2EE中systemloader就是所有的EARclassloader的父类classloader。然而EAR classloader是WAR和RAR的父类classloader。
图2
根据java规范，一个子类类加载器(classloader)在试图定位自己的了类之前必须先用其父类classloader定位这个类。这虽然听起来感觉没什么必要，但是这样是可以阻止当有多个类加载在同一个JVM里的多个类加载器（classloader）之间的含糊不清和之间的冲突。有个别的应用程序服务器允许你自己来选择性的查找EAR和WAR类加载器的加载行为。但是不推荐这样做，因为这样可能造成其他的麻烦，例如classcastException会在一下情况下发生：当在两个相同version的类但是在不同的类加载器中。
2部署结构 (Deployment Architecture)
一个典型的3层enterprise application由3个主要的层组成。
表达层：这个层的任务是负责处理与用户的交互。
商业逻辑层：这个层通常是扮演server的角色，负责响应来自用户的表达层的请求。
数据层：这个层包含数据库和其他连接数据库的组件。
一个大的商业系统的解决方案中，每一个层将被单独的部署在自己的域内，这样可以允许每个域来满足自己的商业需求。除此之外，负载平衡器将会在表达层之前背部署用来提高可靠性和支持更好的fail-over，商业逻辑层和数据层倾向与依赖聚合技术来预防fail-over，下图解释了典型的部署结构。
图3
根据现实的商业用例，上图也有一些变化。
对于一个J2EE－application，表达层通常通过使用servlet和JSP来解决实现，而这些servlet和JSPs可以打包成一个或多个WAR文件。商业层通常通过session beans来实现，而这些beans可以被打包为一个或多个EAR文件。数据层通常通过实体beans（entity beans）(通常用来和数据库的资源连接）或者是资源适配器（控制与lagacy和非JBDC资源的连接，同样的当然可以被打包为一个或多个EAR文件。下图给我们展示了在J2EE资源和模型中相同的部署结构。
如果按照上面的模型来部署一个J2EE application将会有很好的灵活性，但是这里还有一些别的需要在部署结构形成之前考虑到。
