計算機專業(yè)外文翻譯--基于j2ee在分布式環(huán)境下的底層結構的自動動態(tài)配置的應用

1、<p>　　基于J2EE在分布式環(huán)境下的底層結構的自動動態(tài)配置的應用</p><p>　　Anatoly Akkerman, Alexander Totok, and Vijay Karamcheti</p><p>　　摘要：為了實現(xiàn)廣域網中符合工業(yè)標準基于組件的應用程序中動態(tài)的可適應性，我們需要一種框架來在這樣的環(huán)境里自動化地配置J2EE 應用程序。這種需要對于哪怕在單一的應

2、用程序服務器上嘗試部署J2EE應用的人來說也顯而易見，這種任務設計到大量的系統(tǒng)服務和應用組件的配置。</p><p>　　關鍵詞：j2ee；動態(tài)配置；分布式；組件；</p><p><b>　　1 前言</b></p><p>　　近幾年，我們已經看到基于組件的企業(yè)應用開發(fā)的顯著增加。這種應用程序通常被部署在公司的內部網或者是因特網上，以高事務

3、容量，大量的用戶和覆蓋范圍廣的訪問為特征，它通常會被部署在中央?yún)^(qū)域，采用服務器集群來均衡負載從而支持用戶下載。但是這種平均負荷的方法被證明只對減少應用轉發(fā)的用戶可以察覺的反應時間有效，而對于減少網絡方面的延遲作用不大，垂直分割（例如…運行網絡層和事務層在不同的虛擬機）被用于錯誤分離和均衡負荷，但是它是不符合實際的由于遠程調運的大量使用顯著地增加了運行時時間。最近的著作已經表明在廣域網中利用垂直負荷而不引起前面所述的超時問題的可行性。那非

4、研究的主要結論可以概括如下：</p><p>　　(1) 應用合適的應用程序，在廣域網中的垂直負荷可以察覺的延遲。</p><p>　　(2) 廣域垂直層需要復制應用層組件而且需要維持和原組件間的一致性。</p><p>　　(3) 新加的復制組件可以被動態(tài)配置以滿足新的需要。</p><p>　　(4) 事實上，不同的復制組件可能會根據(jù)應用

5、不同的方式實現(xiàn)相組件。</p><p>　　(5) 新的請求路徑可以復用先前的組件配置路徑。</p><p>　　應用智能監(jiān)視和人工智能規(guī)劃方法再結合那個研究得出的結論，我們看到通過動態(tài)布置基于動態(tài)監(jiān)視的額外的應用組件，在廣域網中符合工業(yè)標準基于組件的應用程序中動態(tài)的可適應性是可以實現(xiàn)的。然而，為了實現(xiàn)這種動態(tài)可適性，我們需要一種框架來在這樣的環(huán)境里自動化地配置J2EE 應用程序。這種需要

6、對于哪怕在單一的應用程序服務器上嘗試布置J2EE應用的人來說也顯而易見，這種任務設計到大量的系統(tǒng)服務和應用組件的配置。例如你必須在配置和部署應用組件前先建立JDBC數(shù)據(jù)源，設立消息目的地和資源適配器。在需要跨越多個節(jié)點服務器的廣域網配置中，這將更加復雜，因為更多的便利內部節(jié)點通信的系統(tǒng)服務需要配置和啟動，而且多種配置數(shù)據(jù)比如IP地址，端口號，JNDI名字和其他的數(shù)據(jù)在多個節(jié)點的配置文件中必須維持一致性。這種分布式配置框架必須滿足：<

7、;/p><p>　　(1) 聲明內部組件一致性規(guī)范和定義它對組件配置部署的影響。</p><p>　　(2) 聲明應用程序組件對應用服務器，以及它們的配置和部署的依賴性。</p><p>　　(3) 提供簡單但可表達的抽象方法去控制通過部署和拆卸組件獲得的適用性。</p><p>　　(4) 能夠復用服務和組件從而高效的利用網路節(jié)點資源。<

8、/p><p>　　(5) 提供上述便利而不會增加應用程序員的設計負擔。</p><p>　　在本論文中，我們提出自動動態(tài)部署J2EE應用程序的框架涉及了上面的所有問題，這種框架為組件定義了結構描述語言，鏈接說明和集合。這種組件說明語言用來描述應用程序組件和鏈接，它使得應用組件與系統(tǒng)組件中清晰的分開。一種靈活的系統(tǒng)類型用來定義組件接口和端口的兼容性。一種為配置組件屬性而開發(fā)的定義和表述語言允許內

9、部組件間獨立的規(guī)范和組件間屬性的繼承。組件集合語言允許先前定義的復制的組件通過連接合適的端口集合到應用路徑，連接時通過鏈接復制對象和具體把這些復制組件映射到目標應用服務器節(jié)點。組件配置過程評估了應用程序路徑的正確性，確認在系統(tǒng)組件上的應用組件的獨立性和完成復制組件的部署。根據(jù)這些配置使先前部署的復制組件在新的路徑中得以匹配和復用的努力正在做出。我們把這種架構作為JBoss開源java應用服務器的一部分加以實現(xiàn)，在幾個J2EE樣本程序比如

10、Java PetStore,，RUB和 TPC_W_NYU中進行測試。這種架構實現(xiàn)利用了JBoss的可擴展的微內核結構，基于JMX規(guī)范。JBoss的組件結構允許根據(jù)部署應用程序的需要增加服務配置。我們相信通過動態(tài)部署和拆卸系統(tǒng)服務來重構應用服務器對構建高效</p><p>　　2 J2EE背景知識</p><p><b>　　2.1 介紹</b></p>

11、;<p>　　組件框架。組件框架是一種中間件系統(tǒng)，它支持遵守一定標準的有不同組件構成的應用程序。應用組件被塞入這種確立它們運行環(huán)境和規(guī)定它們交互的框架中。這通常是通過容器，組件持有者來實現(xiàn)的。這種容器也提供通常需要的功能以實現(xiàn)命名，安全性，事務，和持久性！組件框架為組件的執(zhí)行提供了一個集成的環(huán)境，因此顯著的減少了在設計，實現(xiàn)，部署和維護應用程序時工作?，F(xiàn)在工業(yè)上的組件框架標準以對象管理組的CORBA組件模型， SUN 公司

12、的JAVA 2 Platform J企業(yè)版[J2EE]和微軟公司的.NET標準，其中在企業(yè)里應用最為廣泛的組件框架是2EEE。J2EE. J2EE是開發(fā)多層企業(yè)應用JAVA程序的綜合性的標準。J2EE規(guī)范定義如下：</p><p>　　(1) 組件編程模型。</p><p>　　(2) 組件和主服務器的鏈接。</p><p>　　(3) 服務器提供給組件的服務。&l

13、t;/p><p>　　(4) 各種各樣的人物角色。</p><p>　　(5) 兼容性檢驗裝置和編譯測試程序。</p><p>　　在眾多的服務列表中，消息通信，事務處理，命名機制和其它應用組件用到的服務是應用服務器必須提供的。用J2EE進行應用開發(fā)必須遵守經典的3層結構—表現(xiàn)層，業(yè)務層和企業(yè)信息系統(tǒng)層。屬于各層的J2EE組件在開發(fā)時遵守具體的J2EE標準。</p

14、><p>　　1、表現(xiàn)層或者網絡層</p><p>　　這一層實際上又被分為客戶端和服務器端。客戶端包括瀏覽器，applets，Java應用程序等和負責和服務器端的表現(xiàn)層或者業(yè)務層進行交互。服務器端包括servlet、jsp和靜態(tài)網頁內容。這些組件負責把業(yè)務數(shù)據(jù)傳遞給終端用戶。數(shù)據(jù)本身通常從業(yè)務層獲得有時也從企業(yè)信息系統(tǒng)層直接獲得。表現(xiàn)層的服務器端通常通過Http協(xié)議來進行訪問。</p&

15、gt;<p><b>　　業(yè)務層或者EJB層</b></p><p>　　這一層包含EJB，即企業(yè)應用的事務邏輯模型。這些組件提供了持久化機制和事務支持。EJB中的組件通過RMI被調用。在Java虛擬機調用或者異步的消息傳遞，取決與EJB組件的類型。EJB規(guī)范定義了很多種組件。它們在調用風格（同步和異步，本地和遠程）與狀態(tài)（完全狀態(tài)，不可持久狀態(tài)，可持久）方面不同。同步調用的E

16、JB組件通過特定的工廠代理對象來表現(xiàn)自己。這種工廠代理對象通常被EJB部署者綁定在JNDI中。EJB對象允許或者本地EJB對象是特定EJB實例的代理。</p><p>　　3、企業(yè)信息系統(tǒng)或者數(shù)據(jù)層</p><p>　　這一層指的就是企業(yè)信息系統(tǒng)，比如關系數(shù)據(jù)庫，ERP系統(tǒng)，消息系統(tǒng)等。業(yè)務層和持久層在資源適配器的幫助下與該層進行通信。資源適配器在Java連結結構中被定義。J2EE編程模型

17、一直被認為是分布式的編程模型，在該模型中應用組件在J2EE服務器上運行并且彼此可以相互交互。經過初始化說明和第一個服務實現(xiàn)后，該技術，更顯著的說EJB技術，已經明顯地從純粹的分布式計算模型轉向了本地交互。轉變的背后有合理的性能有關的原因，然而分布式的特征現(xiàn)在還存在。J2EE規(guī)范已經經過了好幾次修訂，現(xiàn)在最穩(wěn)定的版本是1.3，1.4版本正處于重審階段。我們應該把注意力放在1.3版本上，而實際上是在學習后者。適用與商業(yè)的J2EE實現(xiàn)可以大量

18、的從BEA系統(tǒng)，IBM，Oracle等贊助商得到。包括JBoss和JOnAS在內的開源實現(xiàn)據(jù)稱兼容性也不錯。最近名單上有多出了新的Apache project Geronimo。</p><p>　　2.2 J2EE組件編程模型</p><p>　　在我們基本的J2EE組件前，先讓我們強調一下什么是組件。軟件組件是有一系列的具體的接口和明確的上下文環(huán)境構成。它可以被獨立的部署而且易于被第

19、三方重構。根據(jù)以上的定義，如下的組成J2EE應用程序的實體可以看作是軟件組件：</p><p>　　(1) EJBS（會話，實體，消息驅動）。</p><p>　　(2) Web組件（Servlet、JSP）。.</p><p><b>　　(3) 消息目的。</b></p><p><b>　　(4) 數(shù)據(jù)源

20、。</b></p><p>　　EJB和Web組件被部署在由應用服務贊助商提供的容器中.它們有定義良好的容器規(guī)則來管理生命周期，線程，持久化和其他問題。EJB和Web組件都利用JNDI目錄機制去尋找資源和它們想要交互的其EJB組件。目錄被執(zhí)行的JNDI環(huán)境被獨立的由容器的每個組件加以維護。該種環(huán)境下的綁定機制通常由組件部署的解釋者加以配置。消息目的地，像對話和隊列，是由消息服務執(zhí)行所提供的資源。數(shù)據(jù)源

21、是提供給應用服務器的為事務組件進入到企業(yè)信息服務層提供數(shù)據(jù)接口，通常由被應用服務器管理的JDBC連接池實例化。一個J2EE編程者明確編寫的項目只有EJB和Web組件。這些用戶編寫的組件彼此交互而且系統(tǒng)服務可以是明顯的也可以是隱含的。例如，EJB開發(fā)者可以選擇明確的事務區(qū)分方式，這種方式意味著開發(fā)者假設通過定義良好接口的事務經理服務平臺來書寫明確的程序交互?；蛘撸_發(fā)者也可選擇容器管理事務區(qū)分的方式。這樣由于組件的事務行為通過他的描述者來

22、定義而且全部用EJB容器來處理，因此作為一個隱式獨立的EJB提供潛在的事務管理服務。</p><p>　　2.3 組件間的鏈接</p><p>　　2.3.1 遠程交互</p><p>　　J2EE僅定義了三種可以在不同應用服務器間傳遞的基本組件間連接類型。在這三種情況下，通信通過特定的Java對象來完成。</p><p>　　(1) 遠

23、程EJB調用：同步的EJB調用通過主EJB對象和EJB對象接口來實現(xiàn)。</p><p>　　(2) Java連結器的外部連接：同步消息接收，同步和異步消息發(fā)送，用連接工廠和連接接口進行數(shù)據(jù)庫查詢。</p><p>　　(3) Java連接器的內部連接：異步消息傳遞進入消息驅動Bean只能使用Activation Spec 對象。</p><p>　　在前兩個實例中，

24、應用組件的開發(fā)者不僅書寫執(zhí)行在組件的運行時JNDI環(huán)境中的對象目錄代碼，而且書寫發(fā)布方法調用，與遠程的組件相互發(fā)送和接受消息。組件的運行時JNDI環(huán)境為每一個組件部署所創(chuàng)建。環(huán)境中的綁定在組件部署時由部署者進行初始化。這些綁定被假設為是靜態(tài)的，因為規(guī)格中沒有提供任何的容器和組件間協(xié)議去提示綁定發(fā)生了變化。在 Java連接器的內部通信情景下，Activation Spec 對象查詢以及所有的相應的M容器隱式的完成。雖然查詢的協(xié)議還沒有被標

25、準化，但是假設一個基于JMX或者JNDI的查詢是合理的。 假設潛在的應用服務器提供了所有的設備去控制部署過程的每一步，那么在兩個J2EE組件間確立一個連接需要涉及：</p><p>　　(1) 部署目標組件類。</p><p>　　(2) 創(chuàng)建一個特定的Java對象用作目標組件代理。</p><p>　　(3) 用組件的命名服務去綁定目標。</p>&

26、lt;p>　　(4) 啟動目標組件。</p><p>　　(5) 部署指定的組件類。</p><p>　　(6) 在主機的命名服務中，創(chuàng)建和進行指定組件的運行環(huán)境。</p><p>　　(7) 啟動指定的組件。</p><p>　　然而，沒有一個現(xiàn)代的應用服務器允許詳細的控制所有組件類型的部署過程除了在它們的部署解釋器中的有限的選擇。因

27、此我們的架構將使用簡化的途徑，它所依賴的特征在現(xiàn)在的大多數(shù)的應用服務器上都可以得到。</p><p>　　(1) 動態(tài)部署消息目的和數(shù)據(jù)源的能力。</p><p>　　(2) 創(chuàng)建和綁定特定的JNDI目標去訪問消息目的和數(shù)據(jù)源的能力。</p><p>　　(3) 把初始綁定的EJB對象到EJB部署組件的能力。</p><p>　　(4) 用在

28、參考組件運行環(huán)境中的JNDI指引去指出綁定的參考EJB的能力。</p><p>　　在只有相同的應用服務器的架構中，上面的功能對通過簡單的部署控制解釋器方式來控件間的連接已經足夠了。然而，在不同應用服務器的環(huán)境下，由于跨服務器的類下載問題，這種簡單的控制解釋器的方式是不夠的。</p><p>　　2.3.2 本地交互</p><p>　　一些組件間的交互可以發(fā)生在

29、同一地點的相同應用服務器虛擬機的組件間，有時候甚至可以發(fā)生在只有相同容器的組件間。在Web層，這種交互的例子是 servlet到 servlet的請求轉發(fā)。在EJB層，這種交互的例子是CMP實體關系和通過EJB本地接口的調用。這種本地部署所關心的不是在分布式架構中去表現(xiàn)而是去增強一致性。因此，這種架構把所有的本地的組件請求當作一個單一的組件加以對待。</p><p>　　2.4 部署J2EE應用程序和系統(tǒng)服務&

30、lt;/p><p>　　2.4.1 部署應用程序組件</p><p>　　部署和拆卸標準的J2EE組件還沒有統(tǒng)一的標準，因此每個應用服務的提供商對組件的部署和拆卸提供了單獨的功能于J2EE規(guī)范中沒有定義標準組件的包，包的格式和包內的基于xml部署解釋器的位置，因此這種包對于沒有所屬權變化的應用服務器不需要部署。具體變化的例子有：</p><p>　　(1) 支持或者取

31、代標準所有者解釋器的新的所有者解釋器的產生。</p><p>　　(2) 具體服務應用程序類的代碼的更替。</p><p>　　為了著手構建一個能夠部署不可網絡的動態(tài)的分布式的架構，我們提出了一種普遍的部署單元即一個簡單的基于xml部署的解釋器或者是一組類似的綁定到文檔中的解釋器。文檔可能包含用于執(zhí)行組件的Java類或者任何其它的所需組件。相應地，部署解釋器也可以簡單地用URL來索引代碼。

32、我們假設這種動態(tài)的部署和拆卸服務存在于所有的兼容的J2EE服務器上而且在不理解類重載相關問題時一個健壯的類重載結結構的應用服務器就能夠重復的部署生命周期。大多數(shù)現(xiàn)代的應用服務器都提供這樣的功能。</p><p>　　2.4.2 部署系統(tǒng)組件</p><p>　　對應用組件來說，J2EE規(guī)范只是少了在部署和拆卸時的明確定義，而對系統(tǒng)服務來說，在這方面做的更糟。對系統(tǒng)服務來說不僅沒有具體的定

33、義一個標準化的部署，實際上，這個規(guī)格甚至連沒有強調在生命周期屬性方面的要求，更不用手強調依賴也潛在的系統(tǒng)服務的應用組件的明確規(guī)范了取而代之的是它定義了部署者的角色，這個角色負責確保像組件的本性和系統(tǒng)的解釋器所暗示的那樣，所需的服務是基于應用組件對系統(tǒng)服務依賴性的基礎之上。例如，假如有一個事務容器要至少用一種方法去開始一個新的事務，那么一個帶有這樣的事務容器的EJB就需要在應用層表示事務管理服務。與之相似的是，一個消息驅動的bean，也隱

34、式需要一種運行在網絡上消息服務實例。它為MDB管理消息目的以及基于查詢的Java連接器通過它的管理服務層去提供這種消息服務?？紤]到應用層可能通常只用到了應用服務器所提供的服務的一個子集，根據(jù)應用層的需要允許遞增的配置服務的組件應用服務器允許更高效的利用多種資源。包括，開源的應用服務器，JBoss和OnAS在內，已經有多種J2EE應用服務器已經全部或者部分的實現(xiàn)了組件化。我們感覺到通過動態(tài)的部署和拆卸系統(tǒng)服務，動態(tài)的配置應用服務器<

35、/p><p><b>　　參考文獻</b></p><p>　　[1] Matt Bishop. Computer Security: Art and Science. New York, 2002</p><p>　　[2] Matt Bishop. Vulnerabilities Analysis. Proceedings of the Sec

36、ond International Symposium on Recent Advances in Intrusion Detection. Los Angeles 2006</p><p>　　[3] Balasubra maniyan. Architecture for Intrusion Detection using Autonomous Agents[M]. Department of Computer

37、 Sciences, Purdue University, 1998.</p><p>　　Infrastructure for Automatic Dynamic Deployment</p><p>　　Of J2EE Application in Distributed Environments</p><p>　　Anatoly Akkerman, Alex

38、ander Totok, and Vijay Karamcheti</p><p>　　Abstract: in order to achieve such dynamic adaptation, we need an infrastructure for automating J2EE application deployment in such an environment. This need is qui

39、te 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 components

40、.</p><p>　　Key words: j2ee; component; Distributed; Dynamic Deployment; </p><p>　　1 Introduction</p><p>　　In recent years, we have seen a significant growth in component-based enter

41、prise application development. These applications are typically deployed on company Intranets or on the Internet and are characterized by high transaction volume, large numbers of users and wide area access. Traditionall

42、y they are deployed in a central location, using server clustering with load balancing (horizontal partitioning) to sustain user load. However, horizontal partitioning has been shown very efficient only in</p><

43、;p>　　? Using properly designed applications, vertical distribution across wide-area networks improves user-perceived latencies.</p><p>　　? Wide-area vertical layering requires replication of application c

44、omponents and maintaining consistency between replicas.</p><p>　　? Additional replicas may be deployed dynamically to handle new requests.</p><p>　　? Different replicas may, in fact, be differen

45、t implementations of the same component based on usage (read-only, read-write).</p><p>　　? New request paths may reuse components from previously deployed paths.</p><p>　　Applying intelligent mo

46、nitoring [6] and AI planning [2, 12] techniques in conjunction with the conclusions of that study, we see a potential for dynamic adaptation in industry-standard J2EE component-based applications in wide area networks<

47、;/p><p>　　Through deployment of additional application components dynamically based on active monitoring. However, in order to achieve such dynamic adaptation, we need an infrastructure for automating J2EE appl

48、ication 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 configura

49、tion of both the system services and application components. For example one has</p><p>　　This distributed deployment infrastructure must be able to:</p><p>　　? address inter-component connectiv

50、ity specification and define its effects on component configuration and deployment,</p><p>　　? address application component dependencies on application server services, their configuration and deployment,&l

51、t;/p><p>　　? provide simple but expressive abstractions to control adaptation through dynamic deployment and undeployment of components,</p><p>　　? enable reuse of services and components to mainta

52、in efficient use of network nodes’ resources,</p><p>　　? provide these facilities without incurring significant additional design effort on behalf of application programmers.</p><p>　　In this pa

53、per we propose the infrastructure for automatic dynamic deployment of J2EE applications, which addresses all of the aforementioned issues. The infrastructure defines architecture description languages (ADL) for component

54、 and link description and assembly. The Component Description Language is used to describe application components and links. It provides clear separation of application components from system components. A flexible type

55、system is used to define compatibility of componen</p><p>　　Connecting appropriate ports via link replicas and specifying the mapping of these component replicas onto target application server nodes. The Com

56、ponent Configuration Process evaluates an application path’s correctness, identifies the dependencies</p><p>　　of application components on system components, and configures component replicas for deployment

57、. An attempt is made to match and reuse any previously deployed replicas in the new path based on their configurations. We implement the infrastructure as a part of the JBoss open source Java application server [11] and

58、test it on several</p><p>　　Sample J2EE applications – Java Pets tore [23], Rubies [20] and TPC-W-NYU [32]. The infrastructure implementation utilizes the JBoss’s extendable micro-kernel architecture, based

59、on the JMX [27] specification. Componentized architecture of JBoss allows incremental service deployments depending on the needs of deployed applications. We believe that dynamic reconfiguration of application servers th

60、rough dynamic deployment and undeployment of system services is essential to building a resource-effi</p><p>　　2 J2EE Background</p><p>　　2.1 Introduction</p><p>　　Component framewo

61、rks. A component framework is a middleware system that supports applications consisting of components conforming to certain standards. Application components are “plugged” into the component framework, which establishes

62、their environmental conditions and regulates the interactions between them. This is usually done through containers, component holders, which also provide commonly required support for naming, security, transactions, and

63、 persistence. Component frameworks provide </p><p>　　J2EE. Java 2 Platform Enterprise Edition (J2EE) [25] is a comprehensive standard for developing multi-tier enterprise Java applications. The J2EE specific

64、ation among other things defines the following:</p><p>　　? Component programming model,</p><p>　　? Component contracts with the hosting server,</p><p>　　? Services that the platform

65、 provides to these components,</p><p>　　? Various human roles,</p><p>　　? Compatibility test suites and compliance testing procedures.</p><p>　　Among the list of services that a com

66、pliant application server must provide are messaging, transactions, naming and others that can be used by the application components. Application developed using J2EE adhere to the classical 3-Tier architectures – Presen

67、tation Tier, Business Tier, and Enterprise Information System (EIS) Tier (see Fig. 1). J2EE components belonging to each tier are developed adhering to the</p><p>　　Specific J2EE standards.</p><p&

68、gt;　　1. Presentation or Web tier.</p><p>　　This tier is actually subdivided into client and server sides. The client side hosts a web browser, applets and Java applications that communicate with the server s

69、ide of presentation tier or the business tier. The server side hosts Java Servlet components [30], Java Server Pages (JSPs) [29] and static web content. These components are responsible for presenting business data to th

70、e end users. The data itself is typically acquired from the business tier and sometimes directly from the Enterprise</p><p>　　2. Business or EJB tier.</p><p>　　This tier consists of Enterprise J

71、ava Beans (EJBs) [24] that model the business logic of the enterprise application. These components provide persistence mechanisms and transactional support. The components in the EJB tier are invoked through remote invo

72、cations (RMI), in-JVM invocations or asynchronous message delivery, depending on the type of EJB component. The EJB specification defines several types of components. They differ in invocation style (synchronous vs. asyn

73、chronous, local vs. remote</p><p>　　(e.g., Stateful Session Bean), stateful persistent (e.g., Entity Bean). Synchronously invocable EJB components expose themselves through a special factory proxy object (an

74、 EJB Home object, which is specific to a given EJB), which is typically bound in JNDI by the deployer of the EJB. The EJB Home object allows creation or location of an EJB</p><p>　　Object, which is a proxy t

75、o a particular instance of an EJB 1.</p><p>　　3. Enterprise Information System (EIS) or Data tier.</p><p>　　This tier refers to the enterprise information systems, like relational databases, ERP

76、 systems, messaging systems and the like. Business and presentation tier component communicate with this tier with the help of resource adapters as defined by the Java Connector Architecture [26].The J2EE programming mod

77、el has been conceived as a distributed programming model where application components would run in J2EE servers and communicate with each other. After the initial introduction and first server i</p><p>　　Dis

78、tributed features are still available. The J2EE specification has seen several revisions, the latest stable being version 1.3, while version 1.4 is going through last review phases 3. We shall focus our attention on the

79、former, while actually learning from the latter. Compliant commercial J2EE implementations are widely available from BEA Systems [4], IBM [9], Oracle [21] and other vendors. Several open source implementations, including

80、 JBoss [11] and JOnAS [19] claim compatibility as well. A</p><p>　　Recent addition to the list is a new Apache project Geronimo [1].</p><p>　　2.2 J2EE Component Programming Model</p><

81、p>　　Before we describe basic J2EE components, let’s first address the issue of defining what a component is a software component is a unit of composition with contractually specified interfaces and explicit context de

82、pendencies only. A software component can be deployed independently and is subject to composition by third parties [31].According to this definition the following entities which make up a typical J2EE application would b

83、e considered application components (some exceptions given below):</p><p>　　? EJBs (session, entity, message-driven),</p><p>　　? Web components (servlets, JSPs),</p><p>　　? messagin

84、g destinations,</p><p>　　? Data sources,</p><p>　　EJB and Web components are deployed into their corresponding containers provided by the application server vendor. They have well-defined contra

85、cts with their containers that govern lifecycle, threading, persistence and other concerns. Both Web and EJB components use JNDI lookups to locate resources or other EJB components they want to communicate with. The JNDI

86、 context in which these lookups are performed is maintained separately for each component by its container. Bindings messaging destinati</p><p>　　Server. A J2EE programmer explicitly programs only EJBs and W

87、eb components. These custom-written components interact with each other and system services both implicitly and explicitly. For example, an EJB developer may choose explicit transaction demarcation (i.e., Bean-Managed Tr

88、ansactions) which means that the developer assumes the burden of writing explicit programmatic interaction with the platform’s Transaction Manager Service through well-defined interfaces. Alternatively, the developer ma&

89、lt;/p><p>　　2.3 Links Between Components</p><p>　　2.3.1 Remote Interactions</p><p>　　J2EE defines only three basic inter-component connection types that can cross application server bo

90、undaries, in all three cases; communication is accomplished through special Java objects.</p><p>　　? Remote EJB invocation: synchronous EJB invocations through EJB Home and EJB Object interfaces.</p>

91、<p>　　? Java Connector outbound connection: synchronous message receipt, synchronous and asynchronous message sending,</p><p>　　Database query using Connection Factory and Connection interfaces.</p&g

92、t;<p>　　? Java Connector inbound connection: asynchronous message delivery into Message-Driven Beans (MDBs) only, utilizing Activation Spec objects. In the first two cases, an application component developer write

93、s the code that performs lookup of these objects in the component’s run-time JNDI context as well as code that issues method invocations or sends and receives messages to and from the remote component. The component’s ru

94、n-time JNDI context is created for each deployment of the component.</p><p>　　Bindings in the context are initialized at component deployment time by the deployed (usually by means of component’s deployment

95、descriptors). These bindings are assumed to be static, since the specification does not provide any contract between the container and the component to inform of any binding changes In the case of Java Connector inbound

96、communication, Activation Spec object lookup and all subsequent interactions with it are done implicitly by the MDB container. The protocol for lookup </p><p>　　? Deployment of target component classes (opti

97、onal for some components, like destinations),</p><p>　　? Creation of a special Java object to be used as a target component’s proxy,</p><p>　　? Binding of this object with component’s host namin

98、g service (JNDI or JMX),</p><p>　　? Start of the target component,</p><p>　　? Deployment of referencing component classes,</p><p>　　? Creation and population of referencing componen

99、t’s run-time context in its host naming service,</p><p>　　? start of the referencing component.</p><p>　　However, none of modern application servers allow detailed control of the deployment proc

100、ess for all component 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 ap

101、plication servers:</p><p>　　? Ability to deploy messaging destinations and data sources dynamically,</p><p>　　? Ability to create and bind into JNDI special objects to access messaging destinati