【正文】 ocal interactions 2. There were very legitimate performancerelated reasons behind this shift, however the Distributed features are still available. The J2EE specification has seen several revisions, the latest stable being version , while version is going through last review phases 3. We shall focus our attention on the former, while actually learning from the latter. Compliant mercial J2EE implementations are widely available from BEA Systems [4], IBM [9], Oracle [21] and other vendors. Several open source implementations, including JBoss [11] and JOnAS [19] claim patibility as well. A Recent addition to the list is a new Apache project Geronimo [1]. J2EE Component Programming Model Before we describe basic J2EE ponents, let’s first address the issue of defining what a ponent is a software ponent is a unit of position with contractually specified interfaces and explicit context 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。 Distributed。附錄 1 翻譯原文 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 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. Key words: j2ee。 ponent。 Dynamic Deployment。 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 wi