课选的统筹与线性规划毕业设计(本科论文).doc

大连交通大学信息工程学院2012届本科生毕业设计（论文）外文翻译

大连交通大学信息工程学院
毕业设计(论文)任务书

题 目 Useful课选的统筹与线性规划
任务及要求：
1.设计（研究）内容和要求
任务：
1、 调查基于Useful课选的统筹与线性规划系统，完成实习报告，字数不少于3000，第三周交给指导老师。
2、 结合自己实习情况安排进度，填写进度计划表，第二周完成后交给指导老师签字，并严格执行。
3、 按照软件工程思想，独立完成系统的设计和程序开发，完成代码估计2000行左右。
4、 用JSP实现Useful课选的统筹与线性规划系统。
5 程序简洁，算法可行，运行情况良好。

要求：
1、 每周和指导老师至少见面沟通一次，回报课题进展情况，接受老师询问。
2、 接到任务书后，查阅与题目及专业相关的外文资料进行翻译，要求不少于10000个外文字符，译出汉字不得少于3000，于第四周交给指导老师审阅。
3、 毕业设计第13周完成毕业论文的装订，并由指导老师评阅。论文要求12000字以上，包括综述、系统总体设计、系统实现、性能分析、结论等。
4、 教学第13周通过中软及教研室组织进行软件验收，验收时要提供软件使用说明书。
5、 于第13周提出毕业答辩申请并签字。
6、 第14 周答辩，要求制作PPT

2.原始依据
通过大学几年的学习，已经学习了诸如软件工程、数据库原理及应用、数据结构、C++、Visual Basic、JAVA等多门程序设计语言和网络等基础知识和专业知识，学生有能力而且可以独立完成小中型项目的设计与开发。学校现有设备和环境可以提供给学生实习和上机，而且具有专业老师可以指导学生。

3.参考文献
[1] 张跃平.JSP实用教程[M].北京清华大学出版社.2003
[2] SunMicrosystems.Database Programming With Java Technology[M].2001
[3] Java Servlet & JSP Cookbook[M].O'Reilly Press.2004
[4] 万峰科技编著.JSP 网站开发四酷全书[M].电子工业出版社.2005
[5] 武卫华.计算机专业英语[M].科学出版社.2004
[6] 王国辉.李文立.杨亮.JSP数据库系统开发完全手册[M].北京人民邮电出版社.2006.3
[7] 吴斌.赵有珍等.SQL Server应用与提高[M].科学出版社.2002.7
[8] Bruce Eckel 著.Java编程思想.北京机械工业出版社.2004.01
[9] Kevin duffey.Vikram goyal.Ted husted著.JSP站点设计编程指南[M].电子工业出版社.2002.6
[10] 汪孝宜.刘中兵.徐佳晶等著.JSP数据库开发实例精粹[M].电子工业出版社.
2005.1
[11] Elliote Rusty Harold,DavidFlanagan 著. Java Network Programming. O'Reilly.1997.06
[12] Harvey M.Deitel.Paul J.Deitel 著.Java How to Program.北京机械工业出版社.2002.01

指导教师签字：
教研室主任签字：
　　　　　　　　　　　　　　　　　　　　　　 2012年3月26日

大连交通大学信息工程学院
毕业设计(论文)进度计划与考核表
学生姓名
滕晓汝
专业班级
计算机科学与技术08-2班
指导教师
袁振海 宋丽芳
本课题其他人员
无
题　目
Useful课选的统筹与线性规划

日　期
计划完成内容
完成情况
指导老师检查签字
第1周
拟订《毕业论文进度计划与考核表》

第2周
完成实习或调研报告

第3周
提交外文文献翻译资料

第4周
系统概要设计阶段

第5周
系统详细设计阶段

第6周
系统编码实施、完成论文初稿

第7周
完成系统编码实施

第8周
系统编码调试、提交论文初稿

第9周
完成系统编码调试、完善毕业论文

第10周
完成撰写毕业设计论文编写及代码测试

第11周
完成论文终稿、准备毕业论文打印、装订

第12周
提交毕业论文终稿及代码

第13周
完成毕业论文

第14周
毕业论文答辩

指导教师签字：　　　　　　　　　　　 2012年3月30日

大连交通大学信息工程学院
毕业设计(论文)外文翻译

学生姓名 滕晓汝 专业班级 计算机082班
指导教师 袁振海 宋丽芳 职 称 高工　副教授
所在单位 　信息科学系计算机教研室
教研室主任 　 宋丽芳

完成日期 2012 年 4 月 13 日
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 components.
Key words: j2ee; component; Distributed; Dynamic Deployment;
1 Introduction
In recent years, we have seen a significant growth in component-based enterprise application development. 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 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 application-related overheads of user-perceived response times, without having much effect on network-induced latencies. Vertical partitioning (e.g., 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 run-time overheads (even if one would keep the tiers on a fast local-area network) related to heavy use of remote invocations. Recent work [14] in the context of J2EE component based applications has shown viability of vertical partitioning in wide-area networks without incurring the aforementioned overheads. The key conclusions from that study can be summarized as follows:
• Using properly designed applications, vertical distribution across wide-area networks improves user-perceived latencies.
• Wide-area vertical layering requires replication of application components 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 component based on usage (read-only, read-write).
• New request paths may reuse components 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 industry-standard J2EE component-based applications in wide area networks
Through deployment of 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. 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 components. For example one has to set up JDBC data sources, messaging destinations and other resource adapters before application components can be configured and deployed. In a wide area deployment that spans multiple server nodes, this proves even more complex, since more system services that facilitate inter-node communications 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 inter-component connectivity specification and define its effects on component configuration and deployment,
• address application component dependencies on application server services, their configuration and deployment,
• provide simple but expressive abstractions to control adaptation through dynamic deployment and undeployment of components,
• enable reuse of services and components to maintain efficient use of network nodes’ resources,
• provide these facilities without incurring significant additional design effort on behalf of application programmers.
In this paper we propose the infrastructure for automatic dynamic deployment 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 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 component ports and links. A declaration and expression language for configurable component properties allows for specification of inter-component dependencies and propagation of properties between components. The Component (Replica) Assembly Language allows for assembly of replicas of previously defined components into application paths by
Connecting appropriate ports via link replicas and specifying the mapping of these component replicas onto target application server nodes. The Component Configuration Process evaluates an application path’s correctness, identifies the dependencies
of application components on system components, and configures component replicas for deployment. An attempt is made to match and reuse any previously deployed replicas in the new path based on their configurations. We implement the infrastructure as a part of the JBoss open source Java application server [11] and test it on several
Sample J2EE applications – Java Pets tore [23], Rubies [20] and TPC-W-NYU [32]. The infrastructure implementation utilizes the JBoss’s extendable micro-kernel architecture, based on the JMX [27] specification. Componentized architecture of JBoss allows incremental service deployments depending on the needs of deployed applications. We believe that dynamic reconfiguration of application servers through dynamic deployment and undeployment of system services is essential to building a resource-efficient framework for dynamic distributed deployment of J2EE applications. The rest of the paper is organized as follows. Section 2 provides necessary background for understanding the specifics of the J2EE component technology which are relevant to this study. Section 3 gives a general description of the infrastructure architecture, while section 4 goes deeper in describing particularly important and interesting internal mechanisms of the infrastructure. Section 5 describes the implementation of the framework, and related work is discussed in section 6.
2 J2EE Background
2.1 Introduction
Component frameworks. A component framework is a middleware system that supports applications consisting of components conforming 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 containers, component holders, which also provide commonly required support for naming, security, transactions, and persistence. Component frameworks 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 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 used component framework in the enterprise arena.
J2EE. Java 2 Platform Enterprise Edition (J2EE) [25] is a comprehensive standard for developing multi-tier enterprise Java applications. The J2EE specification among other things defines the following:
• Component programming model,
• Component contracts with the hosting server,
• Services that the platform provides to these components,
• Various human roles,
• Compatibility test suites and compliance testing procedures.
Among the list of services that a compliant 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 – Presentation 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.
1. Presentation or Web tier.
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 or 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 itself is typically acquired from the business tier and sometimes directly from the Enterprise Information System tier. The server side of the presentation tier is typically accessed through HTTP(S) protocol.
2. Business or EJB tier.
This tier consists of Enterprise Java Beans (EJBs) [24] that 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 invocations 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)and statefulness: completely stateless (e.g., Message-Driven Bean), stateful non-persistent(e.g., Stateful Session Bean), stateful persistent (e.g., Entity Bean). Synchronously invocable EJB components expose themselves through a special factory proxy object (an EJB Home object, which is specific to a given EJB), which is typically bound in JNDI by the deployer of the EJB. The EJB Home object allows creation or location of an EJB，Object, which is a proxy to a particular instance of an EJB 1.
3. Enterprise Information System (EIS) or Data tier.
This tier refers to the enterprise information systems, like relational databases, ERP systems, messaging systems and the 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 distributed programming model where application components would run in J2EE servers and communicate with each other. After the initial introduction and first server implementations, the technology, most notably, the EJB technology has seen some a significant shift away from purely distributed computing model towards local interactions 2. There were very legitimate performance-related reasons behind this shift, however the
Distributed features are still available. The J2EE specification has seen several revisions, the latest stable being version 1.3, while version 1.4 is going through last review phases 3. We shall focus our attention on the former, while actually learning from the latter. Compliant commercial J2EE implementations are widely available from BEA Systems [4], IBM [9], Oracle [21] and other vendors. Several open source implementations, including JBoss [11] and JOnAS [19] claim compatibility as well. A
Recent addition to the list is a new Apache project Geronimo [1].
2.2 J2EE Component Programming Model
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 explicit 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 application would be considered application components (some exceptions given below):
• EJBs (session, entity, message-driven),
• Web components (servlets, JSPs),
• messaging destinations,
• Data sources,
EJB and Web components are deployed into their corresponding containers provided by the application server vendor. They have well-defined 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 with. The JNDI cont