【導(dǎo)讀】來(lái)在這樣的環(huán)境里自動(dòng)化地配置J2EE應(yīng)用程序。這種需要對(duì)于哪怕在單一的應(yīng)用程序服務(wù)器上嘗。試部署J2EE應(yīng)用的人來(lái)說(shuō)也顯而易見(jiàn)，這種任務(wù)設(shè)計(jì)到大量的系統(tǒng)服務(wù)和應(yīng)用組件的配置。關(guān)鍵詞：j2ee；動(dòng)態(tài)配置；分布式；組件；近幾年，我們已經(jīng)看到基于組件的企業(yè)應(yīng)用開(kāi)發(fā)的顯著增加。為特征，它通常會(huì)被部署在中央?yún)^(qū)域，采用服務(wù)器集群來(lái)均衡負(fù)載從而支持用戶下載。對(duì)于減少網(wǎng)絡(luò)方面的延遲作用不大，垂直分割（例如…運(yùn)行網(wǎng)絡(luò)層和事務(wù)層在不同的虛。最近的著作已經(jīng)表明在廣域網(wǎng)中利用垂直負(fù)荷而不引起前面所。述的超時(shí)問(wèn)題的可行性。事實(shí)上，不同的復(fù)制組件可能會(huì)根據(jù)應(yīng)用不同的方式實(shí)現(xiàn)相組件。動(dòng)態(tài)的可適應(yīng)性是可以實(shí)現(xiàn)的。組件配置過(guò)程評(píng)估了應(yīng)用程序路徑的正確性，確認(rèn)在系統(tǒng)組。以理解和研究有關(guān)的J2EE組件技術(shù)規(guī)范。屬于各層的J2EE組件在開(kāi)發(fā)時(shí)遵守具體的J2EE標(biāo)準(zhǔn)。EJB規(guī)范定義了很多種組件。EJB對(duì)象允許或者本地EJB對(duì)象是特定EJB實(shí)例的代理。

　　

【正文】 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), 文獻(xiàn)翻譯 ? 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 will use a simplified approach that relies on features currently available on most application servers: ? Ability to deploy messaging destinations and data sources dynamically, ? Ability to create and bind into JNDI special objects to access messaging destinations and data sources, ? Ability to specify initial binding of EJB Home objects upon EJB ponent deployment, ? Ability to specify a JNDI reference 5 in the referencing ponent’s runtime context to point to the EJB Home binding of the referenced EJB ponent. In our infrastructure which is limited to homogeneous application servers, these options are sufficient to control interponent links through simple deployment descriptor manipulation. However, in context of heterogeneous application servers, simple JNDI references and thus simple descriptor manipulation are insufficient due to crossapplicationserver Classloading issues. Local Interactions Some interactions between ponents can occur only between ponents colocated in the same application server JVM and sometimes only in the same container. In the Web tier, examples of such interactions are servlettoservlet request forwarding. In the EJB tier, such interactions are CMP Entity relations and invocations via EJB local interfaces. Such local deployment concerns need not be exposed at the level of a distributed deployment infrastructure other than to ensure collocation. Therefore, the infrastructure treats all ponents requiring collocation as a single ponent. Deployment of J2EE Applications and System Services Deployment of Application Components 文獻(xiàn)翻譯 Deployment and undeployment of standard J2EE ponents has not yet been standardized (see JSR 88 [10] for standardization effort 6). Therefore, each application server vendor provides proprietary facilities for ponent deployment and undeployment. And while the J2EE specification does define packaging of standard ponents which includes format and location of XMLbased deployment descriptors within the package, this package is not required to be deployable by an application server without proprietary transformation. Examples of such transformation are ? Generation of additional proprietary descriptors that supplement or replace the standard ones, ? Code generation of application serverspecific classes. In order to proceed with building a dynamic distributed deployment infrastructure capable of deploying in heterogeneous works, we propose a universal unit of deployment to be a single XMLbased deployment descriptor or a set of such, Bundled into an archive. The archive may optionally include Java classes that implement the ponent and any other resources that the ponent may need. Alternatively, the deployment descriptors may simply have URL references to codebases. We assume presence of a dynamic deployment/undeployment service on all pliant J2EE servers and a robust application server classloading architecture capable of repeated deployment cycles without undesired classloadingrelated issues. Most modern application servers (., JBoss [11] and Geronimo [1]) do provide such facilities. Deployment of System Components (Services) While lacking only in the area of defining a clear specification of deployment and undeployment when it es to application ponents, the J2EE standard falls much shorter with respect to system services. Not only a standardized deployment facility for system services is not specified, the specification, in fact, places no requirements even on life cycle properties of these services, nor does it address the issue of explicit specification of application ponent dependencies on the underlying system services. Instead it defines a role of human deploy who is responsible for ensuring that the required services are running based on his/her understanding of dependencies of application ponents on system services as implied by the nature of ponents and their deployment descriptors. 文獻(xiàn)翻譯 References [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. An Architecture for Intrusion Detection using Autonomous Agents[M]. Department of Computer Sciences, Purdue University, 1998.