外文翻译---基于j2ee在分布式环境下的底层结构自动动态部署应用(编辑修改稿)

外文翻译---基于j2ee在分布式环境下的底层结构自动动态部署应用(编辑修改稿)内容摘要：

dependencies only. A software ponent can be deployed independently and is subject to position by third parties [31].According to this definition the following entities which make up a typical J2EE application would be considered application ponents (some exceptions given below): • EJBs (session, entity, messagedriven), • Web ponents (servlets, JSPs), • messaging destinations, • Data sources, EJB and Web ponents are deployed into their corresponding containers provided by the application server vendor. They have welldefined contracts with their containers that govern lifecycle, threading, persistence and other concerns. Both Web and EJB ponents use JNDI lookups to locate resources or other EJB ponents they want to municate with. The JNDI context in which these lookups are performed is maintained separately for each ponent by its container. Bindings messaging destinations, such as topics and queues, are resources provided by a messaging service implementation. Data sources are resources provided by the application server for data access by business ponents into the enterprise information services (data) tier, and most monly are exemplified by JDBC connection pools managed by the application Server. A J2EE programmer explicitly programs only EJBs and Web ponents. These customwritten ponents interact with each other and system services both implicitly and explicitly. For example, an EJB developer may choose explicit transaction demarcation (., BeanManaged Transactions) which means that the developer assumes the burden of writing explicit programmatic interaction with the platform’s Transaction Manager Service through welldefined interfaces. Alternatively, the developer may choose ContainerManaged transaction demarcation, where transactional behavior of a ponent is defined through its descriptors and handled pletely by the EJB container, thus acting as an implicit dependency of the EJB on the underlying Transaction Manager service. Links Between Components Remote Interactions J2EE defines only three basic interponent connection types that can cross application server boundaries, in all three cases。 munication is acplished through special Java objects. • Remote EJB invocation: synchronous EJB invocations through EJB Home and EJB Object interfaces. • Java Connector outbound connection: synchronous message receipt, synchronous and asynchronous message query using Connection Factory and Connection interfaces. • Java Connector inbound connection: asynchronous message delivery into MessageDriven Beans (MDBs) only, utilizing Activation Spec objects. In the first two cases, an application ponent developer writes the code that performs lookup of these objects in the ponent’s runtime JNDI context as well as code that issues method invocations or sends and receives messages to and from the remote ponent. The ponent’s runtime JNDI context is created for each deployment of the in the context are initialized at ponent deployment time by the deployed (usually by means of ponent’s deployment descriptors). These bindings are assumed to be static, since the specification does not provide any contract between the container and the ponent to inform of any binding changes In the case of Java Connector inbound munication, Activation Spec object lookup and all subsequent interactions with it are done implicitly by the MDB container. The protocol for lookup has not been standardized, though it is reasonable to assume a JMX or JNDIbased lookup assuming the underlying application server provides facilities to control each step of deployment process, establishment of a link between J2EE ponents would involve: • Deployment of target ponent classes (optional for some ponents, like destinations), • Creation of a special Java object to be used as a target ponent’s proxy, • Binding of this object with ponent’s host naming service (JNDI or JMX), • Start of the target ponent, • Deployment of referencing ponent classes, • Creation and population of referencing ponent’s runtime context in its host naming service, • start of the referencing ponent. However, none of modern application servers allow detailed control of the deployment process for all ponent types beyond what is possible by limited options in their deployment descriptors 4. Therefore our infrastructure will 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. Deploym。