【正文】 us 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。 Dynamic Deployment。最近的著作已經(jīng)表明在廣域網(wǎng)中利用垂直負(fù)荷而不引起前面所述的超時(shí)問(wèn)題的可行性。這種需要對(duì)于哪怕在單一的應(yīng)用程序服務(wù)器上嘗試布置 J2EE應(yīng)用，涉及到大量的系統(tǒng)服務(wù)和應(yīng)用組件的配置的人來(lái)說(shuō)也顯而易見(jiàn)的。 在本論文中，我們提出自動(dòng)動(dòng)態(tài)部署 J2EE應(yīng)用程序的框架涉及了上述所有問(wèn)題。系統(tǒng)會(huì)試圖根據(jù)這些配置通過(guò)復(fù)制 先前部署的組件配置新的路徑。第五部分描述了如何實(shí)現(xiàn)這種架構(gòu)，相關(guān)聯(lián)的工作將在第六部分介紹。 J2EE 規(guī)范定義如下： (1) 組件編程模型。 表現(xiàn)層或者網(wǎng)絡(luò)層 這一層實(shí)際上又被分為客戶端和服務(wù)器端。 EJB 中的組件通過(guò)遠(yuǎn)程調(diào)用方法（ RMI）被調(diào)用，并根據(jù) EJB 組件的類型在 Java 虛擬機(jī)調(diào)用或者異步的消息傳遞。經(jīng)過(guò)初始化說(shuō)明和第一個(gè)服務(wù)實(shí)現(xiàn)后， EJB 技術(shù)已經(jīng)明顯地從純粹的分布式計(jì)算模型轉(zhuǎn)向了本地交互。 EJB 主對(duì)象允許或者本地 EJB 對(duì)象是特定 EJB 實(shí)例的代理。數(shù)據(jù)本身通常從業(yè)務(wù)層獲得有時(shí)也從企業(yè)信息系統(tǒng)層直接獲得。 (5) 兼容性測(cè)試裝置和編譯測(cè)試程序。這通常是通過(guò)一個(gè)可以提供通常需要的功能以實(shí)現(xiàn)命名，安全性，事務(wù)，和持久性的容器，組件持有者來(lái)實(shí)現(xiàn)的。我們相信通過(guò)動(dòng)態(tài)部署和拆卸系統(tǒng)服務(wù)來(lái)重構(gòu)應(yīng)用服務(wù)器對(duì)構(gòu)建高效資源框架的動(dòng)態(tài)分布部署的 J2EE應(yīng)用程序來(lái)說(shuō)是非常必要的。一種靈活的系統(tǒng)類型用于定義組件接口和端口的兼容性。 (2) 聲明應(yīng)用程序組件對(duì)應(yīng)用服務(wù)器，以及它們的配置和部署的依賴性。 (4) 事實(shí)上，不同的復(fù)制組件可能會(huì)根據(jù)應(yīng)用不同的方式實(shí)現(xiàn)相組件（只讀，讀寫(xiě)）。 關(guān)鍵詞： j2ee；動(dòng)態(tài)配置；分布式；動(dòng)態(tài)部署； 1 前言 近年來(lái)，我們已經(jīng)看到基于組件的企業(yè)應(yīng)用開(kāi)發(fā)的顯著增加 。附錄 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。這種應(yīng)用程序通常被部署在公司的內(nèi)部網(wǎng)或者是因特網(wǎng)上，以高事務(wù)容量，大量的用戶和覆蓋范圍廣的訪問(wèn)為特征，它通常會(huì)被部署在中央?yún)^(qū)域，采用服務(wù)器集群來(lái)均衡負(fù)載（平均分配）支持用戶下載。 (5) 新的請(qǐng)求路徑可以復(fù)用先前的組件配置路徑。 (3) 提供簡(jiǎn)單但可表達(dá)的抽象方法去控制通過(guò)部署和拆卸組件獲得的適用性。一種為配置組件屬性而開(kāi)發(fā)的定義和其表述性語(yǔ)言允許內(nèi)部組件間獨(dú)立的規(guī)范和組件間屬性的繼承。本文剩余部分結(jié)構(gòu)如下：第二部分提供了必要的背景以理解和研究有關(guān)的 J2EE組件 技術(shù)規(guī)范。 圖 1 J2EE的三層結(jié)構(gòu) 組件框架為組件的執(zhí)行提供了一個(gè)集成的環(huán)境，從而顯著的減少了在設(shè)計(jì)，實(shí)現(xiàn)，部署和維護(hù)應(yīng)用程序時(shí)工作。 在眾多的服務(wù)列表中，應(yīng)用服務(wù)器必須提供消息通信，事務(wù)處理，命名機(jī)制和其它應(yīng)用組件用到的服務(wù)。表現(xiàn)層的服務(wù)器端通常通過(guò) Http（ s）協(xié)議來(lái)進(jìn)行訪問(wèn)。 企業(yè)信息系統(tǒng)（ EIS）或數(shù)據(jù)層 這一層指的就是企業(yè)信息系統(tǒng)，比如關(guān)系數(shù)據(jù)庫(kù)， ERP 系統(tǒng)，消息系統(tǒng)等。 J2EE編程模型一直被認(rèn)為是分布式的編程模型，在該模型中應(yīng)用組件在 J2EE 服務(wù)器上運(yùn)行并且彼此可以相互交互。這些組件提供了持久化機(jī)制和事務(wù)支持。屬于各層的 J2EE 組件在開(kāi)發(fā)時(shí)遵守具體的 J2EE 標(biāo)準(zhǔn)。 J2EE 是開(kāi)發(fā)多層企業(yè)應(yīng)用 JAVA程序的綜合性的標(biāo)準(zhǔn)。第四部分更深入的描述了有關(guān)這種架構(gòu)特別重要的和有趣的內(nèi)部機(jī)制。組件配置過(guò)程評(píng)估了應(yīng)用程序路徑的正確性，確認(rèn)在系統(tǒng)組件上的應(yīng)用組件的獨(dú)立性和完成復(fù)制組件的部署。 (5) 提供上述便利而不會(huì)增加應(yīng)用程序員的設(shè)計(jì)負(fù)擔(dān)。然而，為了實(shí)現(xiàn)這種動(dòng)態(tài)可適性，我們需要一種框架來(lái)在這樣的環(huán)境里自動(dòng)化地配置 J2EE 應(yīng)用程序。垂直分割（例如運(yùn)行網(wǎng)絡(luò)層和事務(wù)層在不同的虛擬機(jī)）被用于錯(cuò)誤分離和均衡負(fù)荷，但是由于它遠(yuǎn)程調(diào)運(yùn)的大量使用顯著地增加了運(yùn)行時(shí)時(shí)間導(dǎo)致其實(shí)現(xiàn)很不實(shí)際。 Distributed。 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 de