外文翻譯---基于j2ee在分布式環(huán)境下的底層結(jié)構(gòu)自動(dòng)動(dòng)態(tài)部署應(yīng)用

1、<p><b>　　附錄1 翻譯原文</b></p><p>　　Infrastructure for Automatic Dynamic Deployment of J2EE Application in Distributed Environments</p><p>　　Anatoly Akkerman, Alexander Totok, and Vi

2、jay 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 quite evident to anyon

3、e 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.</p><p&

4、gt;　　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 enterprise application d

5、evelopment. 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. Traditionally they are deployed

6、 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><p>　　? Using pro

7、perly designed applications, vertical distribution across wide-area networks improves user-perceived latencies.</p><p>　　? Wide-area vertical layering requires replication of application components and maint

8、aining consistency between replicas.</p><p>　　? Additional replicas may be deployed dynamically to handle new requests.</p><p>　　? Different replicas may, in fact, be different implementations o

9、f 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 monitoring [6] and AI

10、 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 Through deployment of

11、 additional application components 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

12、. This need is qui</p><p>　　This distributed deployment infrastructure must be able to:</p><p>　　? address inter-component connectivity specification and define its effects on component configur

13、ation and deployment,</p><p>　　? address application component dependencies on application server services, their configuration and deployment,</p><p>　　? provide simple but expressive abstracti

14、ons to control adaptation through dynamic deployment and undeployment of components,</p><p>　　? enable reuse of services and components to maintain efficient use of network nodes’ resources,</p><p

15、>　　? provide these facilities without incurring significant additional design effort on behalf of application programmers.</p><p>　　In this paper we propose the infrastructure for automatic dynamic deploy

16、ment of J2EE applications, which addresses all of the aforementioned issues. The infrastructure defines architecture description languages (ADL) for component and link description and assembly. The Component Description

17、Language is used to describe application components and links. It provides clear separation of application components from system components. A flexible type system is used to define compatibility of componen</p>

18、<p>　　2 J2EE Background</p><p>　　2.1 Introduction</p><p>　　Component frameworks. A component framework is a middleware system that supports applications consisting of components conforming

19、to certain standards. Application components are “plugged” into the component framework, which establishes their environmental conditions and regulates the interactions between them. This is usually done through containe

20、rs, component holders, which also provide commonly required support for naming, security, transactions, and persistence.</p><p>　　Figure 1:J2EE 3-Tier architecture</p><p>　　Component frameworks

21、provide an integrated environment for component execution, as a result significantly reduce the effort .it takes to design, implement, deploy, and maintain applications. Current day industry component framework standards

22、 are represented by Object Management Group’s CORBA Component Model [18], Sun Microsystems’ Java 2 Platform Enterprise Edition (J2EE) [25] and Microsoft’s .NET [17], with J2EE being currently the most popular and widely

23、used component framework in the enterpr</p><p>　　J2EE. Java 2 Platform Enterprise Edition (J2EE) [25] is a comprehensive standard for developing multi-tier enterprise Java applications. The J2EE specificatio

24、n 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 pro

25、vides 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 complia

26、nt 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 – Presentati

27、on Tier, Business Tier, and Enterprise Information System (EIS) Tier (see Fig. 1). J2EE components belonging to each tier are developed adhering to the Specific J2EE standards.</p><p>　　1. Presentation or We

28、b 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 side of presentation tier o

29、r 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 the end users. The data itse

30、lf 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 Java Beans (EJBs) [24] that

31、 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 invocations (RMI), in-JVM invo

32、cations 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. asynchronous, local vs. remote

33、</p><p>　　3. Enterprise Information System (EIS) or Data tier.</p><p>　　This tier refers to the enterprise information systems, like relational databases, ERP systems, messaging systems and the

34、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 model has been conceived as a distribut

35、ed 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>　　2.2 J2EE Component Programming Model<

36、;/p><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 explic

37、it context dependencies 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 applic

38、ation would be considered application components (some exceptions given below):</p><p>　　? EJBs (session, entity, message-driven),</p><p>　　? Web components (servlets, JSPs),</p><p>

39、;　　? messaging 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-d

40、efined contracts 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 w

41、ith. The JNDI context in which these lookups are performed is maintained separately for each component by its container. Bindings messaging destinati</p><p>　　2.3 Links Between Components</p><p>

42、;　　2.3.1 Remote Interactions</p><p>　　J2EE defines only three basic inter-component connection types that can cross application server boundaries, in all three cases; communication is accomplished through sp

43、ecial Java objects.</p><p>　　? Remote EJB invocation: synchronous EJB invocations through EJB Home and EJB Object interfaces.</p><p>　　? Java Connector outbound connection: synchronous message r

44、eceipt, synchronous and asynchronous message sending.Database query using Connection Factory and Connection interfaces.</p><p>　　? Java Connector inbound connection: asynchronous message delivery into Messag

45、e-Driven Beans (MDBs) only, utilizing Activation Spec objects. </p><p>　　In the first two cases, an application component developer writes the code that performs lookup of these objects in the component’s ru

46、n-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 run-time JNDI context is created for each deployment of the component.Bi

47、ndings in the context are initialized at component deployment time by the deployed (usually by means of component’s deployment descriptors). These</p><p>　　? Deployment of target component classes (optional

48、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 naming ser

49、vice (JNDI or JMX),</p><p>　　? Start of the target component,</p><p>　　? Deployment of referencing component classes,</p><p>　　? Creation and population of referencing component’s r

50、un-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 process f

51、or 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 applica

52、tion 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 destinations a

53、nd data sources,</p><p>　　? Ability to specify initial binding of EJB Home objects upon EJB component deployment,</p><p>　　? Ability to specify a JNDI reference 5 in the referencing component’s

54、run-time context to point to the EJB Home binding of the referenced EJB component. In our infrastructure which is limited to homogeneous application servers, these options are sufficient to control intercomponent links t

55、hrough simple deployment descriptor manipulation. However, in context of heterogeneous application servers, simple JNDI references and thus simple descriptor manipulation are insufficient due to cross-applicat</p>

56、<p>　　2.3.2 Local Interactions</p><p>　　Some interactions between components can occur only between components co-located in the same application server JVM and sometimes only in the same container. In

57、 the Web tier, examples of such interactions are servlet-to-servlet request forwarding. In the EJB tier, such interactions are CMP Entity relations and invocations via EJB local interfaces. Such local deployment concerns

58、 need not be exposed at the level of a distributed deployment infrastructure other than to ensure collocation. Therefor</p><p>　　2.4 Deployment of J2EE Applications and System Services</p><p>　　

59、2.4.1 Deployment of Application Components</p><p>　　Deployment and undeployment of standard J2EE components has not yet been standardized (see JSR 88 [10] for standardization effort 6). Therefore, each appli

60、cation server vendor provides proprietary facilities for component deployment and undeployment. And while the J2EE specification does define packaging of standard components which includes format and location of XML-base

61、d deployment descriptors within the package, this package is not required to be deployable by an application server without p</p><p>　　? Generation of additional proprietary descriptors that supplement or re

62、place the standard ones,</p><p>　　? Code generation of application server-specific classes.</p><p>　　In order to proceed with building a dynamic distributed deployment infrastructure capable of

63、deploying in heterogeneous networks, we propose a universal unit of deployment to be a single XML-based deployment descriptor or a set of such,bundled into an archive. The archive may optionally include Java classes that

64、 implement the component and any other resources that the component may need. Alternatively, the deployment descriptors may simply have URL references to codebases. We assume presence of </p><p>　　2.4.2 Depl

65、oyment of System Components (Services)</p><p>　　While lacking only in the area of defining a clear specification of deployment and undeployment when it comes to application components, the J2EE standard fall

66、s 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

67、services, nor does it address the issue of explicit specification of application component dependencies on the underlying</p><p>　　For example, an EJB with container managed transactions that declares at lea

68、st one method that supports/requires/starts a new transaction would require presence of a TransactionManager service in the application server. Similarly, a messagedriven bean implicitly requires an instance of a messagi

69、ng service running somewhere in the network that hosts the messaging destination for the MDB and a Java Connector based hook-up from within its hosting application server to this messaging service.</p><p>　　

70、Given that applications would typically use only a subset of services provided by an application server, componentized application servers that allow incremental service deployments depending on the needs of the applicat

71、ion allow for most efficient utilization of server resources. There are several J2EE application servers that are already fully or partially componentized, including open source application servers JBoss [11] and JOnAS [

72、19]. We feel that dynamic reconfiguration of application ser</p><p>　　References</p><p>　　[1] Apache Software Foundation. Apache Geronimo Application Server. http://geronimo.apache.org/.</p&g

73、t;<p>　　[2] N. Arshad, D. Heimbigner, and A. L. Wolf. Deployment and dynamic reconfiguration planning for distributed software systems. In Proceedings of the 15th International Conference on Tools with Artificial

74、Intelligence (ICTAI’03), November 2003.</p><p>　　[3] T. Batista and N. Rodriguez. Dynamic reconfiguration of component-based applications. In Proceedings of the International Symposium on Software Engineerin

75、g for Parallel and Distributed Systems, June 2000.</p><p>　　[4] BEA Systems Inc. WebLogic Application Server. http://www.beasys.com/products/weblogic/.</p><p>　　[5] G. Candea, E. Kiciman, S. Zha

76、ng, P. Keyani, and A. Fox. JAGR: An autonomous self-recovering application server. In Proceedings of the 5th International Workshop on Active Middleware Services, June 2003.</p><p>　　[6] M. Chen, E. Kiciman,

77、 E. Fratkin, E. Brewer, and A. Fox. Pinpoint: Problem determination in large, dynamic, Internet services. In Proceedings of the International Conference on Dependable Systems and Networks, June 2002.</p><p>

78、　　[7] J. E. Cook and J. A. Dage. Highly reliable upgrading of components. In Proceedings of the 21st International Conference on Software Engineering (ICSE’99), May 1999.</p><p>　　[8] M. Fleury and F. Reverb

79、el. The JBoss extensible server. In Proceedings of the ACM/IFIP/USENIX International Middleware Conference (Middleware’2003), June 2003.</p><p>　　[9] IBM Corporation. WebSphere Application Server. http://www

80、.ibm.com/software/websphere/.</p><p>　　[10] Java Community Process. Java Specification Request 88 (JSR88). http://www.jcp.org/en/jsr/detail?id=88.</p><p>　　[11] JBoss Group. JBoss Application Se

81、rver. http://www.jboss.org.</p><p>　　[12] T. Kichkaylo, A. Ivan, and V. Karamcheti. Constrained component deployment in wide-area networks using AI planning techniques. In Proceedings of the International Pa

82、rallel and Distributed Processing Symposium (IPDPS), April 2003.</p><p>　　[13] F. Kon and R. H. Campbell. Dependence management in component-based distributed systems. IEEE Concurrency, 8(1):26–36, 2000.<

83、/p><p>　　[14] D. Llambiri, A. Totok, and V. Karamcheti. Efficiently distributing component-based applications across wide-area environments. In Proceedings of the International Conference on Distributed Computi

84、ng Systems (ICDCS), pages 412–421, May 2003.</p><p>　　[15] J.Magee, A. Tseng, and J. Kramer. Composing distributed objects in CORBA. In Proceedings of the Third International Symposium on Autonomous Decentra

85、lized Systems (ISADS’97), pages 257–263, 1997.</p><p>　　[16] V. Marangozova and D. Hagimont. An infrastructure for CORBA component replication. In Proceedings of the IFIP/ACM Working Conference on Component

86、Deployment, pages 257–263, 2002.</p><p>　　[17] Microsoft Corporation. Microsoft .NET. http://www.microsoft.com/net/.</p><p>　　[18] Object Management Group. CORBA Component Model (CCM) Specificat

87、ion. </p><p>　　http://www.omg.org/technology/documents/formal/components.htm.</p><p>　　[19] ObjectWeb Consortium. JOnAS Application Server. http://jonas.objectweb.org/.</p><p>　　[20

88、] ObjectWeb Consortium. RUBiS: Rice University Bidding System. http://rubis.objectweb.org/.</p><p>　　[21] Oracle Corporation. Oracle Application Server. http://www.oracle.com/appserver/.</p><p>

89、　　[22] M. Rutherford, K. Anderson, A. Carzaniga, D. Heimbigner, and A. L.Wolf. Reconfiguration in the Enterprise JavaBean component model. In Proceedings of the IFIP/ACM Working Conference on Component Deployment, pages

90、67–81, 2002.</p><p>　　[23] Sun Microsystems Inc. Java Pet Store Sample Application. http://java.sun.com/developer/releases/petstore/.</p><p>　　[24] Sun Microsystems Inc. Enterprise JavaBeans (EJ

91、B) Specification. http://java.sun.com/products/ejb/.</p><p>　　[25] Sun Microsystems Inc. Java 2 Enterprise Edition. http://java.sun.com/j2ee/.</p><p>　　[26] Sun Microsystems Inc. Java Connector

92、Architecture (JCA) Specification. http://java.sun.com/j2ee/connector/.</p><p>　　[27] Sun Microsystems Inc. Java Management Extensions (JMX) Specification. http://java.sun.com/products/JavaManagement/.</p&

93、gt;<p>　　[28] Sun Microsystems Inc. Java Naming and Directory Interface (JNDI) Specification. http://java.sun.com/ products/jndi/.</p><p>　　[29] Sun Microsystems Inc. Java Server Pages (JSP) Specifica

94、tion. http://java.sun.com/products/jsp/.</p><p>　　[30] Sun Microsystems Inc. Java Servlets Specification. http://java.sun.com/products/servlet/.</p><p>　　[31] C. Szyperski. Component Software. A

95、ddison-Wesley, November 2002.</p><p>　　[32] TPC-W-NYU. A J2EE implementation of the TPC-W benchmark. http://cs1.cs.nyu.edu/totok/professional/software/tpcw/tpcw.html.</p><p>　　[33] World Wide We

96、b Consortium. XML Path Language (XPath) Specification. http://www.w3.org/TR/xpath</p><p>　　[34] XmlBlaster Open Source Project. http://www.xmlblaster.org/.</p><p><b>　　附錄2 外文翻譯</b>&l

97、t;/p><p>　　基于J2EE在分布式環(huán)境下的底層結(jié)構(gòu)自動(dòng)動(dòng)態(tài)部署應(yīng)用</p><p>　　Anatoly Akkerman, Alexander Totok, and Vijay Karamcheti</p><p>　　摘要：為了實(shí)現(xiàn)其動(dòng)態(tài)的可適應(yīng)性，我們需要一種框架來在廣域網(wǎng)中符合工業(yè)標(biāo)準(zhǔn)基于組件的環(huán)境里自動(dòng)化地配置J2EE 應(yīng)用程序。這種需要對于哪怕在單一的

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

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

100、的可行性。其研究的主要結(jié)論可以概括如下：</p><p>　　(1) 如果應(yīng)用合適的應(yīng)用程序，則在廣域網(wǎng)中的垂直負(fù)荷可以察覺到延遲。</p><p>　　(2) 廣域垂直層需要復(fù)制應(yīng)用層組件而且需要維持和原組件間的一致性。</p><p>　　(3) 新加的復(fù)制組件可以動(dòng)態(tài)配置以滿足新的請求。</p><p>　　(4) 事實(shí)上，不同的復(fù)制組