1、“.....大量的用户和覆盖范围广的访问为特征，它通常会被部署在中央区域，采用服务器集群来均衡负载从而支持用户下载。但是这种平均负荷的方法被证明只对减少应用转发的用户可以察觉的反应时间有效，而对于减少网络方面的延迟作用不大，垂直分割例如运行网络层和事务层在不同的虚拟机被用于分离和均衡负荷，但是它是不符合实际的由于远程调运的大量使用显著地增加了运行时时间。最近的著作已经表明在广域网中利用垂直负荷而不引起前面所述的超时问题的可行性。那非研究的主要结论可以概括如下应用合适的应用程序，在广域网中的垂直负荷可以察觉的延迟。广域垂直层需要复制应用层组件而且需要维持和原组件间的致性。新加的复制组件可以被动态配置以满足新的需要。事实上......”。

2、“.....新的请求路径可以复用先前的组件配置路径。应用智能监视和人工智能规划方法再结合那个研究得出的结论，我们看到通过动态布置基于动态监视的额外的应用组件，在广域网中符合工业标准基于组件的应用程序中动态的可适应性是可以实现的。然而，为了实现这种动态可适性，我们需要种框架来在这样的环境里自动化地配置应用程序。这种需要对于哪怕在单的应用程序服务器上尝试布置应用的人来说也显而易见，这种任务设计到大量的系统服务和应用组件的配置。例如你必须在配置和部署应用组件前先建立数据源，设立消息目的地和资源适配器。在需要跨越多个节点服务器的广域网配置中，这将更加复杂，因为更多的便利内部节点通信的系统服务需要配置和启动，而且多种配置数据比如地址......”。

3、“.....名字和其他的数据在多个节点的配置文件中必须维持致性。这种分布式配置框架必须满足声明内部组件致性规范和定义它对组件配置部署的影响。声明应用程序组件对应用服务器，以及它们的配置和部署的依赖性。提供简单但可表达的抽象方法去控制通过部署和拆卸组件获得的适用性。能够复用服务和组件从而高效的利用网路节点资源。提供上述便利而不会增加应用程序员的设计负担。在本论文中，我们提出自动动态部署应用程序的框架涉及了上面的所有问题，这种框架为组件定义了结构描述语言，链接说明和集合。这种组件说明语言用来描述应用程序组件和链接，它使得应用组件与系统组件中清晰的分开。种灵活的系统类型用来定义组件接口和端口的兼容性......”。

4、“.....组件集合语言允许先前定义的复制的组件通过连接合适的端口集合到应用路径，连接时通过链接复制对象和具体把这些复制组件映射到目标应用服务器节点。组件配置过程评估了应用程序路径的正确性，确认在系统组件上的应用组件的独立性和完成复制组件的部署。根据这些配置使先前部署的复制组件在新的路径中得以匹配和复用的努力正在做出。我们把这种架构作为开源应用服务器的部分加以实现，在几个样本程序比如和所有的相应的容器隐式的完成。虽然查询的协议还没有被标准化，但是假设个基于或者的查询是合理的。假设潜在的应用服务器提供了所有的设备去控制部署过程的每步，那么在两个组件间确立个连接需要涉及部署目标组件类。创建个特定的对象用作目标组件代理......”。

5、“.....启动目标组件。部署指定的组件类。在主机的命名服务中，创建和进行指定组件的运行环境。启动指定的组件。然而，没有个现代的应用服务器允许详细的控制所有组件类型的部署过程除了在它们的部署解释器中的有限的选择。因此我们的架构将使用简化的途径，它所依赖的特征在现在的大多数的应用服务器上都可以得到。动态部署消息目的和数据源的能力。创建和绑定特定的目标去访问消息目的和数据源的能力。把初始绑定的对象到部署组件的能力。用在参考组件运行环境中的指引去指出绑定的参考的能力。在只有相同的应用服务器的架构中，上面的功能对通过简单的部署控制解释器方式来控件间的连接已经足够了。然而，在不同应用服务器的环境下，由于跨服务器的类下载问题......”。

6、“.....本地交互些组件间的交互可以发生在同地点的相同应用服务器虚拟机的组件间，有时候甚至可以发生在只有相同容器的组件间。在层，这种交互的例子是到的请求转发。在层，这种交互的例子是实体关系和通过本地接口的调用。这种本地部署所关心的不是在分布式架构中去表现而是去增强致性。因此，这种架构把所有的本地的组件请求当作个单的组件加以对待。部署应用程序和系统服务部署应用程序组件部署和拆卸标准的组件还没有统的标准，因此每个应用服务的提供商对组件的部署和拆卸提供了单独的功能于规范中没有定义标准组件的包，包的格式和包内的基于部署解释器的位置，因此这种包对于没有所属权变化的应用服务器不需要部署......”。

7、“.....具体服务应用程序类的代码的更替。为了着手构建个能够部署不可网络的动态的分布式的架构，我们提出了种普遍的部署单元即个简单的基于部署的解释器或者是组类似的绑定到文档中的解释器。文档可能包含用于执行组件的类或者任何其它的所需组件。相应地，部署解释器也可以简单地用来索引代码。我们假设这种动态的部署和拆卸服务存在于所有的兼容的服务器上而且在不理解类重载相关问题时个健壮的类重载结结构的应用服务器就能够重复的部署生命周期。大多数现代的应用服务器都提供这样的功能。部署系统组件对应用组件来说，规范只是少了在部署和拆卸时的明确定义，而对系统服务来说，在这方面做的更糟。对系统服务来说不仅没有具体的定义个标准化的部署，实际上......”。

8、“.....更不用手强调依赖也潜在的系统服务的应用组件的明确规范了取而代之的是它定义了部署者的角色，这个角色负责确保像组件的本性和系统的解释器所暗示的那样，所需的服务是基于应用组件对系统服务依赖性的基础之上。例如，假如有个事务容器要至少用种方法去开始个新的事务，那么个带有这样的事务容器的就需要在应用层表示事务管理服务。与之相似的是，个消息驱动的，也隐式需要种运行在网络上消息服务实例。它为管理消息目的以及基于查询的连接器通过它的管理服务层去提供这种消息服务。考虑到应用层可能通常只用到了应用服务器所提供的服务的个子集，根据应用层的需要允许递增的配置服务的组件应用服务器允许更高效的利用多种资源。包括，开源的应用服务器，和在内......”。

9、“.....我们感觉到通过动态的部署和拆卸系统服务，动态的配置应用服务器对动态分布的部署应用程序是种十分重要的构建资源有效型框架的方法。因此我们提倡并将把用应用服务器设计的微内核的应用服务器用作个模型。在该模型中，个微型的服务包括了系统调用总线，个稳健的类下载子系统，些命名子系统和个动态配置子系统。所有其它的服务是热部署并且通过个普通的调用总线来进行通信。例如，利用管理扩展服务器来实现基本的命名和调用功能。除此之外，实现了个先进的类下载子系统和部署服务。所有其它的是动态配置的，并外在的表现为具有良好机制和生命周期的这样的种应用服务器根据系统服务外在利用应用组件去设计相关功能，并且只有需要的系统服务才会得到合理配置和部署......”。