【正文】 pecification 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。這種應(yīng)用程序通常被部署在公司的內(nèi)部網(wǎng)或者是因特網(wǎng)上，以高事務(wù)容量，大量的用戶和覆蓋范圍廣的訪問為特征，它通常會被部署在中央?yún)^(qū)域，采用服務(wù)器集群來均衡負(fù)載（平均分配）支持用戶下載。其研 究的主要結(jié)論可以概括如下： (1) 如果應(yīng)用合適的應(yīng)用程序，則在廣域網(wǎng)中的垂直負(fù)荷可以察覺到延遲。 (5) 新的請求路徑可以復(fù)用先前的組件配置路徑。例如你必須在配置和部署應(yīng)用組件前先建立JDBC數(shù)據(jù)源、設(shè)立消息目的地及資源適配器。 (3) 提供簡單但可表達(dá)的抽象方法去控制通過部署和拆卸組件獲得的適用性。這種框架為組件定義了結(jié)構(gòu)描述語言（ ADL），鏈接說明和集合。一種為配置組件屬性而開發(fā)的定義和其表述性語言允許內(nèi)部組件間獨立的規(guī)范和組件間屬性的繼承。我們把這種架構(gòu)作為 JBoss開源 java應(yīng)用服務(wù)器的一部分加以實現(xiàn)，在幾個 J2EE樣本程序比如 Java PetStore,， RUB和 TPC_W_NYU中進(jìn)行測試。本文剩余部分結(jié)構(gòu)如下：第二部分提供了必要的背景以理解和研究有關(guān)的 J2EE組件 技術(shù)規(guī)范。 2 J2EE背景知識 介紹 組件框架。 圖 1 J2EE的三層結(jié)構(gòu) 組件框架為組件的執(zhí)行提供了一個集成的環(huán)境，從而顯著的減少了在設(shè)計，實現(xiàn)，部署和維護(hù)應(yīng)用程序時工作。 (2) 組件和主服務(wù)器的鏈接。 在眾多的服務(wù)列表中，應(yīng)用服務(wù)器必須提供消息通信，事務(wù)處理，命名機制和其它應(yīng)用組件用到的服務(wù)。客戶端包括瀏覽器， applets， Java 應(yīng)用程序等和負(fù)責(zé)與服務(wù)器端的表現(xiàn)層或者業(yè)務(wù)層進(jìn)行交互。表現(xiàn)層的服務(wù)器端通常通過 Http（ s）協(xié)議來進(jìn)行訪問。 EJB 規(guī)范定義了幾種類型的組件。 企業(yè)信息系統(tǒng)（ EIS）或數(shù)據(jù)層 這一層指的就是企業(yè)信息系統(tǒng)，比如關(guān)系數(shù)據(jù)庫， ERP 系統(tǒng)，消息系統(tǒng)等。轉(zhuǎn)變的背。 J2EE編程模型一直被認(rèn)為是分布式的編程模型，在該模型中應(yīng)用組件在 J2EE 服務(wù)器上運行并且彼此可以相互交互。同步調(diào)用的 EJB 組件通過通常被 EJB 部署者綁定在 JNDI中的工廠代理對象來表現(xiàn)自己。這些組件提供了持久化機制和事務(wù)支持。 這些組件負(fù)責(zé)把業(yè)務(wù)數(shù)據(jù)傳遞給終端用戶。屬于各層的 J2EE 組件在開發(fā)時遵守具體的 J2EE 標(biāo)準(zhǔn)。 (4) 各種各樣的人物角色。 J2EE 是開發(fā)多層企業(yè)應(yīng)用 JAVA程序的綜合性的標(biāo)準(zhǔn)。應(yīng)用組件“插入” 確立它們運行環(huán)境和規(guī)定它們交互的組件框架中。第四部分更深入的描述了有關(guān)這種架構(gòu)特別重要的和有趣的內(nèi)部機制。 JBoss的組件結(jié)構(gòu)允許根據(jù)部署應(yīng)用程序的需要增加服務(wù)配置。組件配置過程評估了應(yīng)用程序路徑的正確性，確認(rèn)在系統(tǒng)組件上的應(yīng)用組件的獨立性和完成復(fù)制組件的部署。它使得應(yīng)用組件與系統(tǒng)組件中清晰的分開。 (5) 提供上述便利而不會增加應(yīng)用程序員的設(shè)計負(fù)擔(dān)。 這種分布 式配置框架必須滿足： (1) 聲明內(nèi)部組件的一致性規(guī)范和定義其對組件配置部署的影響。然而，為了實現(xiàn)這種動態(tài)可適性，我們需要一種框架來在這樣的環(huán)境里自動化地配置 J2EE 應(yīng)用程序。 (3) 新加的復(fù)制組件可以動態(tài)配置以滿足新的請求。垂直分割（例如運行網(wǎng)絡(luò)層和事務(wù)層在不同的虛擬機）被用于錯誤分離和均衡負(fù)荷，但是由于它遠(yuǎn)程調(diào)運的大量使用顯著地增加了運行時時間導(dǎo)致其實現(xiàn)很不實際。這種需要對于哪怕在單一的應(yīng)用程序服務(wù)器上嘗試部署 J2EE應(yīng)用的人來說也很明顯，這種任務(wù)涉及到大量的系統(tǒng)服務(wù)和應(yīng)用組件的配置。 Distributed。 ponent。 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 ste