【正文】 的請(qǐng)求轉(zhuǎn)發(fā)。在 EJB 層，這種交互的例子是 CMP 實(shí)體關(guān)系和通過(guò) EJB 本地接口的調(diào)用。這種本地部署所關(guān)心的不是在分布式架構(gòu)中去表現(xiàn)而是去增強(qiáng)一致性。因此，這種架構(gòu)把所有的本地的組件請(qǐng)求 當(dāng)作一個(gè)單一的組件加以對(duì)待。 部署 J2EE 應(yīng)用程序和系統(tǒng)服務(wù) 部署應(yīng)用程序組件 部署和拆卸標(biāo)準(zhǔn)的 J2EE 組件還沒(méi)有統(tǒng)一的標(biāo)準(zhǔn)，因此每個(gè)應(yīng)用服務(wù)的提供商對(duì)組件的部署和拆卸提供了單獨(dú)的功能于 J2EE 規(guī)范中沒(méi)有定義標(biāo)準(zhǔn)組件的包，包的格式和包內(nèi)的基于 xml 部署解釋器的位置，因此這種包對(duì)于沒(méi)有所屬權(quán)變化的應(yīng)用服務(wù)器不需要部署。具體變化的例子有： (1) 支持或者取代標(biāo)準(zhǔn)所有者解釋器的新的所有者解釋器的產(chǎn)生 。 (2) 具體服務(wù)應(yīng)用程序類的代碼的更替 。 為了著手構(gòu)建一個(gè)能夠部署不可網(wǎng)絡(luò)的動(dòng)態(tài)的分布 式的架構(gòu)，我們提出了一種普遍的部署單元即一個(gè)簡(jiǎn)單的基于 xml 部署的解釋器或者是一組類似的綁定到文檔中的解釋器。文檔可能包含用于執(zhí)行組件的 Java 類或者任何其它的所需組件。相應(yīng)地，部署解釋器也可以簡(jiǎn)單地用 URL 來(lái)索引代碼。我們假設(shè)這種動(dòng)態(tài)的部署和拆卸服務(wù)存在于所有的兼容的 J2EE 服務(wù)器上而且在不理解類重載相關(guān)問(wèn)題時(shí)一個(gè)健壯的類重載結(jié)結(jié)構(gòu)的應(yīng)用服務(wù)器就能夠重復(fù)的部署生命周期。大多數(shù)現(xiàn)代的應(yīng)用服務(wù)器都提供這樣的功能。 部署系統(tǒng)組件 對(duì)應(yīng)用組件來(lái)說(shuō)， J2EE 規(guī)范只是少了在部署和拆卸時(shí)的明確定義，而對(duì)系統(tǒng)服務(wù)來(lái)說(shuō)，在這方面做的更糟。對(duì)系統(tǒng)服務(wù)來(lái)說(shuō)不僅沒(méi)有具體的定義一個(gè)標(biāo)準(zhǔn)化的部署，實(shí)際上，這個(gè)規(guī)格甚至連沒(méi)有強(qiáng)調(diào)在生命周期屬性方面的要求，更不用手強(qiáng)調(diào)依賴也潛在的系統(tǒng)服務(wù)的應(yīng)用組件的明確規(guī)范了取而代之的是它定義了部署者的角色，這個(gè)角色負(fù)責(zé)確保像組件的本性和系統(tǒng)的解釋器所暗示的那樣，所需的服務(wù)是基于應(yīng)用組件對(duì)系統(tǒng)服務(wù)依賴性的基礎(chǔ)之上。例如，假如有一個(gè)事務(wù)容器要至少用一種方法去開(kāi)始一個(gè)新的事務(wù)，那么一個(gè)帶有這樣的事務(wù)容器的 EJB 就需要在應(yīng)用層表示事務(wù)管理服務(wù)。與之相似的是，一個(gè)消息驅(qū)動(dòng)的bean，也隱式需要一種運(yùn) 行在網(wǎng)絡(luò)上消息服務(wù)實(shí)例。它為 MDB 管理消息目的以及基于查詢的 Java 連接器通過(guò)它的管理服務(wù)層去提供這種消息服務(wù)?？紤]到應(yīng)用層可能通常只用到了應(yīng)用服務(wù)器所提供的服務(wù)的一個(gè)子集，根據(jù)應(yīng)用層的需要允許遞增的配置服務(wù)的組件應(yīng)用服務(wù)器允許更高效的利用多種資源。包括，開(kāi)源的應(yīng)用服務(wù)器， JBoss 和 OnAS 在內(nèi)，已經(jīng)有多種 J2EE 應(yīng)用服務(wù)器已經(jīng)全部或者部分的實(shí)現(xiàn)了組件化。我們感覺(jué)到通過(guò)動(dòng)態(tài)的部署和拆卸系統(tǒng)服務(wù)，動(dòng)態(tài)的配置應(yīng)用服務(wù)器對(duì)動(dòng)態(tài)分布的部署 J2EE 應(yīng)用程序是一種十分重要的構(gòu)建資源有效型框架的方法。因此我們提倡并將把 用 JBoss 應(yīng)用服務(wù)器設(shè)計(jì)的微內(nèi)核的應(yīng)用服務(wù)器用作一個(gè)模型。在該模型中，一個(gè)微型的服務(wù)包括了系統(tǒng)調(diào)用總線，一個(gè)穩(wěn)健的類下載子系統(tǒng)，一些命名子系統(tǒng)和一個(gè)動(dòng)態(tài)配置子系統(tǒng)。所有其它的服務(wù)是熱部署并且通過(guò)一個(gè)普通的調(diào)用總線來(lái)進(jìn)行通信。例如， JBoss 利用 Java 管理擴(kuò)展服務(wù)器來(lái)實(shí)現(xiàn)基本的命名和調(diào)用功能。除此之外， JBoss 實(shí)現(xiàn)了一個(gè)先進(jìn)的類下載子系統(tǒng)和部署服務(wù)。所有其它的 JBoss 是動(dòng)態(tài)配置的，并外在的表現(xiàn)為具有良好機(jī)制和生命周期的 JMX 利用應(yīng)用組件去設(shè)計(jì)相關(guān)功能 ，并且只有需要的系統(tǒng)服務(wù)才會(huì)得到合理配置和部署！ 參考文獻(xiàn) [1] Matt Bishop. Computer Security: Art and Science. New York, 2020 [2] Matt Bishop. Vulnerabilities Analysis. Proceedings of the Second International Symposium on Recent Advances in Intrusion Detection. Los Angeles 2020 [3] Balasubra maniyan. Architecture for Intrusion Detection using Autonomous Agents[M]. Department of Computer Sciences, Purdue University, 1998. 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。 Distributed。 Dynamic Deployment。 1 Introduction In recent years, we have seen a significant growth in ponentbased enterprise application development. These applications are typically deployed on pany Intras or on the Inter and are characterized by high transaction volume, large numbers of users and wide area access. Traditionally 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 reducing applicationrelated overheads of userperceived response times, without having much effect on workinduced latencies. Vertical partitioning (., running web tier and business tier in separate VMs) has been used for fault isolation and load balancing but it is sometimes impractical due to significant runtime overheads (even if one would keep the tiers on a fast localarea work) related to heavy use of remote invocations. Recent work [14] in the context of J2EE ponent based applications has shown viability of vertical partitioning in widearea works without incurring the aforementioned overheads. The key conclusions from that study can be summarized as follows: ? Using properly designed applications, vertical distribution across widearea works improves userperceived latencies. ? Widearea vertical layering requires replication of application ponents and maintaining consistency between replicas. ? Additional replicas may be deployed dynamically to handle new requests. ? Different replicas may, in fact, be different implementations of the same ponent based on usage (readonly, readwrite). ? New request paths may reuse ponents from previously deployed paths. Applying intelligent monitoring [6] and AI planning [2, 12] techniques in conjunction with the conclusions of that study, we see a potential for dynamic adaptation in industrystandard J2EE ponentbased applications in wide area works Through deployment of additional application ponents dynamically based on active monitoring. However, 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. For example one has to set up JDBC data sources, messaging destinations and other resource adapters before application ponents can be configured and deployed. In a wide area deployment that spans multiple server nodes, this proves even more plex, since more system services that facilitate internode munications need to be configured and started and a variety of configuration data, like IP addresses, port numbers, JNDI names and others have to be consistently maintained in various configuration files on multiple nodes. This distributed deployment infrastructure must be able to: ? address interponent connectivity specification and define its effects on ponent configuration and deployment, ? a