部署和拆卸标准的J2EE组件还没有统一的标准，因此每个应用服务的提供商对组件的部署和拆卸提供了单独的功能于J2EE规范中没有定义标准组件的包，包的格式和包内的基于xml部署解释器的位置，因此这种包对于没有所属权变化的应用服务器不需要部署。具体变化的例子有：
(1) 支持或者取代标准所有者解释器的新的所有者解释器的产生。 (2) 具体服务应用程序类的代码的更替。
为了着手构建一个能够部署不可网络的动态的分布式的架构，我们提出了一种普遍的部署单元即一个简单的基于xml部署的解释器或者是一组类似的绑定到文档中的解释器。文档可能包含用于执行组件的Java类或者任何其它的所需组件。相应地，部署解释器也可以简单地用URL来索引代码。我们假设这种动态的部署和拆卸服务存在于所有的兼容的J2EE服务器上而且在不理解类重载相关问题时一个健壮的类重载结结构的应用服务器就能够重复的部署生命周期。大多数现代的应用服务器都提供这样的功能。 2.4.2 部署系统组件
对应用组件来说，J2EE规范只是少了在部署和拆卸时的明确定义，而对系统服务来说，在这方面做的更糟。对系统服务来说不仅没有具体的定义一个标准化的部署，实际上，这个规格甚至连没有强调在生命周期属性方面的要求，更不用手强调依赖也潜在的系统服务的应用组件的明确规范了取而代之的是它定义了部署者的角色，这个角色负责确保像组件的本性和系统的解释器所暗示的那样，所需的服务是基于应用组件对系统服务依赖性的基础之上。例如，假如有一个事务容器要至少用一种方法去开始一个新的事务，那么一个带有这样的事务容器的EJB就需要在应用层表示事务管理服务。与之相似的是，一个消息驱动的bean，也隐式需要一种运
行在网络上消息服务实例。它为MDB管理消息目的以及基于查询的Java连接器通过它的管理服务层去提供这种消息服务。考虑到应用层可能通常只用到了应用服务器所提供的服务的一个子集，根据应用层的需要允许递增的配置服务的组件应用服务器允许更高效的利用多种资源。包括，开源的应用服务器，JBoss和OnAS在内，已经有多种J2EE应用服务器已经全部或者部分的实现了组件化。我们感觉到通过动态的部署和拆卸系统服务，动态的配置应用服务器对动态分布的部署J2EE应用程序是一种十分重要的构建资源有效型框架的方法。因此我们提倡并将把用JBoss应用服务器设计的微内核的应用服务器用作一个模型。在该模型中，一个微型的服务包括了系统调用总线，一个稳健的类下载子系统，一些命名子系统和一个动态配置子系统。所有其它的服务是热部署并且通过一个普通的调用总线来进行通信。例如，JBoss利用Java管理扩展服务器来实现基本的命名和调用功能。除此之外，JBoss实现了一个先进的类下载子系统和部署服务。所有其它的JBoss是动态配置的，并外在的表现为具有良好机制和生命周期的JMX MBeans.这样的一种应用服务器根据系统服务外在利用应用组件去设计相关功能，并且只有需要的系统服务才会得到合理配置和部署！
参考文献
[1] Matt Bishop. Computer Security: Art and Science. New York, 2002 [2] Matt Bishop. Vulnerabilities Analysis. Proceedings of the Second International Symposium on Recent Advances in Intrusion Detection. Los Angeles 2006
[3] Balasubra maniyan. Architecture for Intrusion Detection using Autonomous Agents[M]. Department of Computer Sciences, Purdue
University, 1998.
Infrastructure for Automatic Dynamic Deployment Of J2EE Application in Distributed Environments
Anatoly Akkerman, Alexander Totok, and Vijay Karamcheti
Abstract: in order to achieve such dynamic adaptation, we need an infrastructure for automating J2EE application deployment in such an environment. This need is quite evident to anyone who even on a single application server, which is a task that involves a great deal of configuration of both the system services and application components. Key words: j2ee; component; Distributed; Dynamic Deployment; 1 Introduction
In recent years, we a significant growth in component-based enterprise application development. These applications are typically deployed on company Intranets or on the Internet and are characterized by volume, large numbers of users and wide area access. Traditionally they are deployed in a central location, using server clustering with load balancing ( user load. However, shown very efficient only in reducing application-related overheads of user-perceived response times, without network-induced latencies. Vertical partitioning (e.g., running web tier and business tier in separate VMs) used for fault isolation and load balancing but it is sometimes impractical due to significant run-time overheads (even if one would keep the tiers on a fast local-area network) related to the context of J2EE component based applications viability of vertical partitioning in wide-area networks without incurring the aforementioned
overheads. The key conclusions from that study can be summarized as follows:
? Using properly designed applications, vertical distribution across wide-area networks improves user-perceived latencies.
? Wide-area vertical layering requires replication of application components and maintaining consistency between replicas.
? Additional replicas may be deployed dynamically to fact, be different implementations of the same component based on usage (read-only, read-write).
? New request paths may reuse components from previously deployed paths.
Applying intelligent monitoring [6] and AI planning [2, 12] techniques in conjunction with the conclusions of that study, we see a potential for dynamic adaptation in industry-standard J2EE component-based applications in wide area networks
Through deployment of additional application components dynamically based on active monitoring. However, in order to achieve such dynamic adaptation, we need an infrastructure for automating J2EE application deployment in such an environment. This need is quite evident to anyone who even on a single application server, which is a task that involves a great deal of configuration of both the system services and application components. For example one components can be configured and deployed. In a wide area deployment that spans multiple server nodes, this proves even more complex, since more system services that facilitate