【正文】 1 Introduction In recent years, we have seen a significant growth in ponentbased enterprise application development. These applications are typically deployed on pany Intras or on the Inter and are characterized by high transaction volume, large numbers of users and wide area access. Traditionally they are deployed in a central location, using server clustering with load balancing (horizontal partitioning) to sustain user load. However, horizontal partitioning has been shown very efficient only in reducing applicationrelated overheads of userperceived response times, without having much effect on workinduced latencies. Vertical partitioning (., running web tier and business tier in separate VMs) has been used for fault isolation and load balancing but it is sometimes impractical due to significant runtime overheads (even if one would keep the tiers on a fast localarea work) related to heavy use of remote invocations. Recent work [14] in the context of J2EE ponent based applications has shown viability of vertical partitioning in widearea works without incurring the aforementioned overheads. The key conclusions from that study can be summarized as follows: ? Using properly designed applications, vertical distribution across widearea works improves userperceived latencies. ? Widearea vertical layering requires replication of application ponents and maintaining consistency between replicas. ? Additional replicas may be deployed dynamically to handle new requests. ? Different replicas may, in fact, be different implementations of the same ponent based on usage (readonly, readwrite). ? New request paths may reuse ponents 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 industrystandard J2EE ponentbased applications in wide area works Through deployment of additional application ponents 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 has ever tried deploying a J2EE application even on a single application server, which is a task that involves a great deal of configuration of both the system services and application ponents. For example one has to set up JDBC data sources, messaging destinations and other resource adapters before application ponents can be configured and deployed. In a wide area deployment that spans multiple server nodes, this proves even more plex, since more system services that facilitate internode munications need to be configured and started and a variety of configuration data, like IP addresses, port numbers, JNDI names and others have to be consistently maintained in various configuration files on multiple nodes. This distributed deployment infrastructure must be able to: ? address interponent connectivity specification and define its effects on ponent configuration and deployment, ? address application ponent dependencies on application server services, their configuration and deployment, ? provide simple but expressive abstractions to control adaptation through dynamic deployment and undeployment of ponents, ? enable reuse of services and ponents to maintain efficient use of work nodes’ resources, ? provide these facilities without incurring significant additional design effort on behalf of application programmers. In this paper we propose the infrastructure for automatic dynamic deployment of J2EE applications, which addresses all of the aforementioned issues. The infrastructure defines architecture description languages (ADL) for ponent and link description and assembly. The Component Description Language is used to describe application ponents and links. It provides clear separation of application ponents from system ponents. A flexible type system is used to define patibility of ponent ports and links. A declaration and expression language for configurable ponent properties allows for specification of interponent dependencies and propagation of properties between ponents. The Component (Replica) Assembly Language allows for assembly of replicas of previously defined ponents into application paths by Connecting appropriate ports via link replicas and specifying the mapping of these ponent replicas onto target application server nodes. The Component Configuration Process evaluates an application path’s correctness, identifies the dependencies of application ponents on system ponents, and configures ponent replicas for deployment. An attempt is made to match and reuse any previously deployed replicas in the new path based on their configurations. We implement the infrastructure as a part of the JBoss open source Java application server [11] and test it on several Sample J2EE applications – Java Pets tore [23], Rubies [20] and TPCWNYU [32]. The infrastructure implementation utilizes the JBoss’s extendable microkernel architecture, based on the JMX [27] specification. Componentized architecture of JBoss allows incremental service deployments depending on the needs of deployed applications. We believe that dynamic reconfiguration of application servers through dynamic deployment and undeployment of system services is essential to building a resourceefficient framework for dynamic distributed deployment of J2EE applications. The rest of the paper