算機科學與技術畢業論文中英文資料外文翻譯文獻-資料下載頁

【導讀】我們需要一種框架來在這樣的環境里自動化地配置J2EE應用程序。種任務設計到大量的系統服務和應用組件的配置。近幾年，我們已經看到基于組件的企業應用開發的顯著增加。從而支持用戶下載。以察覺的反應時間有效，而對于減少網絡方面的延遲作用不大，垂直分割（例如…符合實際的由于遠程調運的大量使用顯著地增加了運行時時間。表明在廣域網中利用垂直負荷而不引起前面所述的超時問題的可行性。廣域垂直層需要復制應用層組件而且需要維持和原組件間的一致性。新加的復制組件可以被動態配置以滿足新的需要。組件前先建立JDBC數據源，設立消息目的地和資源適配器。聲明內部組件一致性規范和定義它對組件配置部署的影響。部署的J2EE應用程序來說是非常必要的。這一層包含EJB，即企業應用的事務邏輯模型。息傳遞，取決與EJB組件的類型。理對象通常被EJB部署者綁定在JNDI中。

　　

【正文】 ce 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), ? 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, 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.