【導(dǎo)讀】我們需要一種框架來在這樣的環(huán)境里自動(dòng)化地配置J2EE應(yīng)用程序。種任務(wù)設(shè)計(jì)到大量的系統(tǒng)服務(wù)和應(yīng)用組件的配置。近幾年，我們已經(jīng)看到基于組件的企業(yè)應(yīng)用開發(fā)的顯著增加。從而支持用戶下載。但是這種平均負(fù)荷的方法被證明只對(duì)減少應(yīng)用轉(zhuǎn)發(fā)的用戶可。以察覺的反應(yīng)時(shí)間有效，而對(duì)于減少網(wǎng)絡(luò)方面的延遲作用不大，垂直分割（例如…符合實(shí)際的由于遠(yuǎn)程調(diào)運(yùn)的大量使用顯著地增加了運(yùn)行時(shí)時(shí)間。表明在廣域網(wǎng)中利用垂直負(fù)荷而不引起前面所述的超時(shí)問題的可行性。事實(shí)上，不同的復(fù)制組件可能會(huì)根據(jù)應(yīng)用不同的方式實(shí)現(xiàn)相組件。組件前先建立JDBC數(shù)據(jù)源，設(shè)立消息目的地和資源適配器。部署的J2EE應(yīng)用程序來說是非常必要的。息傳遞，取決與EJB組件的類型。理對(duì)象通常被EJB部署者綁定在JNDI中。這一層指的就是企業(yè)信息系統(tǒng)，比如關(guān)系數(shù)據(jù)庫，ERP系統(tǒng)，消息系統(tǒng)等。

　　

【正文】 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), ? 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 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. References [1] Matt Bishop. Computer Security: Art and Science. New York, 2021 [2] Matt Bishop. Vulnerabilities Analysis. Proceedings of the Second International Symposium on Recent Advances in Intrusion Detection. Los Angeles 2021 [3] Balasubra maniyan. An Architecture for Intrusion Detection using Autonomous Agents[M]. Department of Computer Sciences, Purdue University, 1998.