【正文】 ll use a simplified approach that relies on features currently available on most application servers: ? Ability to deploy messaging destinations and data sources dynamically, ? Ability to create and bind into JNDI special objects to access messaging destinations and data sources, ? Ability to specify initial binding of EJB Home objects upon EJB ponent deployment, ? Ability to specify a JNDI reference 5 in the referencing ponent’s runtime context to point to the EJB Home binding of the referenced EJB ponent. In our infrastructure which is limited to homogeneous application servers, these options are sufficient to control interponent links through simple deployment descriptor manipulation. However, in context of heterogeneous application servers, simple JNDI references and thus simple descriptor manipulation are insufficient due to crossapplicationserver classloading issues. Local Interactions Some interactions between ponents can occur only between ponents colocated in the same application server JVM and sometimes only in the same container. In the Web tier, examples of such interactions are servlettoservlet request forwarding. In the EJB tier, such interactions are CMP Entity relations and invocations via EJB local interfaces. Such local deployment concerns need not be exposed at the level of a distributed deployment infrastructure other than to ensure collocation. Therefore, the infrastructure treats all ponents requiring collocation as a single ponent. Deployment of J2EE Applications and System Services Deployment of Application Components Deployment and undeployment of standard J2EE ponents has not yet been standardized (see JSR 88 [10] for standardization effort 6). Therefore, each application server vendor provides proprietary facilities for ponent deployment and undeployment. And while the J2EE specification does define packaging of standard ponents which includes format and location of XMLbased deployment descriptors within the package, this package is not required to be deployable by an application server without proprietary transformation. Examples of such transformation are ? Generation of additional proprietary descriptors that supplement or replace the standard ones, ? Code generation of application serverspecific classes. In order to proceed with building a dynamic distributed deployment infrastructure capable of deploying in heterogeneous works, we propose a universal unit of deployment to be a single XMLbased deployment descriptor or a set of such,bundled into an archive. The archive may optionally include Java classes that implement the ponent and any other resources that the ponent may need. Alternatively, the deployment descriptors may simply have URL references to codebases. We assume presence of a dynamic deployment/undeployment service on all pliant J2EE servers and a robust application server classloading architecture capable of repeated deployment cycles without undesired classloadingrelated issues. Most modern application servers (., JBoss [11] and Geronimo [1]) do provide such facilities. Deployment of System Components (Services) While lacking only in the area of defining a clear specification of deployment and undeployment when it es to application ponents, the J2EE standard falls much shorter with respect to system services. Not only a standardized deployment facility for system services is not specified, the specification, in fact, places no requirements even on life cycle properties of these services, nor does it address the issue of explicit specification of application ponent dependencies on the underlying system services. Instead it defines a role of human deploy who is responsible for ensuring that the required services are running based on his/her understanding of dependencies of application ponents on system services as implied by the nature of ponents and their deployment descriptors. For example, an EJB with container managed transactions that declares at least one method that supports/requires/starts a new transaction would require presence of a TransactionManager service in the application server. Similarly, a messagedriven bean implicitly requires an instance of a messaging service running somewhere in the work that hosts the messaging destination for the MDB and a Java Connector based hookup from within its hosting application server to this messaging service. Given that applications would typically use only a subset of services provided by an application server, ponentized application servers that allow incremental service deployments depending on the needs of the application allow for most efficient utilization of server resources. There are several J2EE application servers that are already fully or partially ponentized, including open source application servers JBoss [11] and JOnAS [19]. We feel 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. Therefore we advocate and will use as a model a microkernel application server design used by the JBoss application server [8]. In this model a minimal server consists of a service invocation bus, a robust classloading subsystem, some naming subsystem and a dynamic deployment subsystem. All other services are hotdeployable and municate through a mon invocation bus. For example, JBoss utilizes a Java Management Extensions (JMX) [27] server that provides basic naming and invocation facilities. In addition JBoss implements an advanced classloading subsystem and a deployment service. All other JBoss services are dynamically deployable and expose themselves as JMX MBeans with well defined (un)deployment mechanism and lifecycle. Such an application serv