070112005的文献翻译

《070112005的文献翻译》由会员分享，可在线阅读，更多相关《070112005的文献翻译（19页珍藏版）》请在金锄头文库上搜索。

1、单位代码 01 学号 070112005 分 类 号 TP393 密 级 文 献 翻 译基于 J2EE 在分布式环境下的底层结构的自动动态配置的应用院 （ 系 ） 名 称 信 息 工 程 学 院专 业 名 称 软 件 工 程学 生 姓 名指 导 教 师2011 年 3 月 29 日黄 河 科 技 学 院 毕 业 设 计 (文 献 翻 译 ) 第 1 页 英文译文基于 J2EE 在分布式环境下的底层结构的自动动态配置的应用Anatoly Akkerman, Alexander Totok, and Vijay Karamcheti摘要：为了实现广域网中符合工业标准基于组件的应用程序中动态的可适应

2、性，我们需要一种框架来在这样的环境里自动化地配置 J2EE 应用程序。这种需要对于哪怕在单一的应用程序服务器上尝试部署 J2EE 应用的人来说也显而易见，这种任务设计到大量的系统服务和应用组件的配置。关键词：j2ee；动态配置；分布式；组件；1 前言近几年，我们已经看到基于组件的企业应用开发的显著增加。这种应用程序通常被部署在公司的内部网或者是因特网上，以高事务容量，大量的用户和覆盖范围广的访问为特征，它通常会被部署在中央区域，采用服务器集群来均衡负载从而支持用户下载。但是这种平均负荷的方法被证明只对减少应用转发的用户可以察觉的反应时间有效，而对于减少网络方面的延迟作用不大，垂直分割（例如运行

3、网络层和事务层在不同的虚拟机）被用于错误分离和均衡负荷，但是它是不符合实际的由于远程调运的大量使用显著地增加了运行时时间。最近的著作已经表明在广域网中利用垂直负荷而不引起前面所述的超时问题的可行性。那非研究的主要结论可以概括如下：(1) 应用合适的应用程序，在广域网中的垂直负荷可以察觉的延迟。(2) 广域垂直层需要复制应用层组件而且需要维持和原组件间的一致性。(3) 新加的复制组件可以被动态配置以满足新的需要。(4) 事实上，不同的复制组件可能会根据应用不同的方式实现相组件。(5) 新的请求路径可以复用先前的组件配置路径。应用智能监视和人工智能规划方法再结合那个研究得出的结论，我们看到通过动态

4、布置基于动态监视的额外的应用组件，在广域网中符合工业标准基于组件的应用程黄 河 科 技 学 院 毕 业 设 计 (文 献 翻 译 ) 第 2 页 序中动态的可适应性是可以实现的。然而，为了实现这种动态可适性，我们需要一种框架来在这样的环境里自动化地配置 J2EE 应用程序。这种需要对于哪怕在单一的应用程序服务器上尝试布置 J2EE 应用的人来说也显而易见，这种任务设计到大量的系统服务和应用组件的配置。例如你必须在配置和部署应用组件前先建立 JDBC 数据源，设立消息目的地和资源适配器。在需要跨越多个节点服务器的广域网配置中，这将更加复杂，因为更多的便利内部节点通信的系统服务需要配置和启动，而且

5、多种配置数据比如 IP 地址，端口号，JNDI 名字和其他的数据在多个节点的配置文件中必须维持一致性。这种分布式配置框架必须满足：(1) 声明内部组件一致性规范和定义它对组件配置部署的影响。(2) 声明应用程序组件对应用服务器，以及它们的配置和部署的依赖性。(3) 提供简单但可表达的抽象方法去控制通过部署和拆卸组件获得的适用性。(4) 能够复用服务和组件从而高效的利用网路节点资源。(5) 提供上述便利而不会增加应用程序员的设计负担。在本论文中，我们提出自动动态部署 J2EE 应用程序的框架涉及了上面的所有问题，这种框架为组件定义了结构描述语言，链接说明和集合。这种组件说明语言用来描述应用程序组

6、件和链接，它使得应用组件与系统组件中清晰的分开。一种灵活的系统类型用来定义组件接口和端口的兼容性。一种为配置组件属性而开发的定义和表述语言允许内部组件间独立的规范和组件间属性的继承。组件集合语言允许先前定义的复制的组件通过连接合适的端口集合到应用路径，连接时通过链接复制对象和具体把这些复制组件映射到目标应用服务器节点。组件配置过程评估了应用程序路径的正确性，确认在系统组件上的应用组件的独立性和完成复制组件的部署。根据这些配置使先前部署的复制组件在新的路径中得以匹配和复用的努力正在做出。我们把这种架构作为JBoss 开源 java 应用服务器的一部分加以实现，在几个 J2EE 样本程序比如 Ja

7、va PetStore,，RUB 和 TPC_W_NYU 中进行测试。这种架构实现利用了 JBoss 的可扩展的微内核结构，基于 JMX 规范。JBoss 的组件结构允许根据部署应用程序的需要增加服务配置。我们相信通过动态部署和拆卸系统服务来重构应用服务器对构建高效资源框架的动态分布部署的 J2EE 应用程序来说是非常必要的。本文如下部分是这样组织的。第 2 部分提供了必要的背景以理解和研究有关的 J2EE 组件技术规范。第 3 部分对这种架构给出了一般性的描述。第 4 部分更深入的描述了有关这种架构特别重要的和有趣黄 河 科 技 学 院 毕 业 设 计 (文 献 翻 译 ) 第 3 页 的内

8、部机制。第五部分描述了如何实现这种架构，相关联的工作将在第六部分介绍。2 J2EE 背景知识2.1 介绍组件框架。组件框架是一种中间件系统，它支持遵守一定标准的有不同组件构成的应用程序。应用组件被塞入这种确立它们运行环境和规定它们交互的框架中。这通常是通过容器，组件持有者来实现的。这种容器也提供通常需要的功能以实现命名，安全性，事务，和持久性！组件框架为组件的执行提供了一个集成的环境，因此显著的减少了在设计，实现，部署和维护应用程序时工作。现在工业上的组件框架标准以对象管理组的 CORBA 组件模型， SUN 公司的 JAVA 2 Platform J 企业版J2EE 和微软公司的.NET 标

9、准，其中在企业里应用最为广泛的组件框架是 2EEE。J2EE. J2EE 是开发多层企业应用 JAVA 程序的综合性的标准。J2EE 规范定义如下：(1) 组件编程模型。(2) 组件和主服务器的链接。(3) 服务器提供给组件的服务。(4) 各种各样的人物角色。(5) 兼容性检验装置和编译测试程序。在众多的服务列表中，消息通信，事务处理，命名机制和其它应用组件用到的服务是应用服务器必须提供的。用 J2EE 进行应用开发必须遵守经典的 3 层结构表现层，业务层和企业信息系统层。属于各层的 J2EE 组件在开发时遵守具体的 J2EE 标准。1、表现层或者网络层这一层实际上又被分为客户端和服务器端。客

10、户端包括浏览器，applets，Java 应用程序等和负责和服务器端的表现层或者业务层进行交互。服务器端包括 servlet、jsp和静态网页内容。这些组件负责把业务数据传递给终端用户。数据本身通常从业务层获得有时也从企业信息系统层直接获得。表现层的服务器端通常通过 Http 协议来进行访问。2、业务层或者 EJB 层黄 河 科 技 学 院 毕 业 设 计 (文 献 翻 译 ) 第 4 页 这一层包含 EJB，即企业应用的事务逻辑模型。这些组件提供了持久化机制和事务支持。EJB 中的组件通过 RMI 被调用。在 Java 虚拟机调用或者异步的消息传递，取决与 EJB 组件的类型。EJB 规范定

11、义了很多种组件。它们在调用风格（同步和异步，本地和远程）与状态（完全状态，不可持久状态，可持久）方面不同。同步调用的EJB 组件通过特定的工厂代理对象来表现自己。这种工厂代理对象通常被 EJB 部署者绑定在 JNDI 中。EJB 对象允许或者本地 EJB 对象是特定 EJB 实例的代理。3、企业信息系统或者数据层这一层指的就是企业信息系统，比如关系数据库，ERP 系统，消息系统等。业务层和持久层在资源适配器的帮助下与该层进行通信。资源适配器在 Java 连结结构中被定义。J2EE 编程模型一直被认为是分布式的编程模型，在该模型中应用组件在 J2EE 服务器上运行并且彼此可以相互交互。经过初始化

12、说明和第一个服务实现后，该技术，更显著的说 EJB 技术，已经明显地从纯粹的分布式计算模型转向了本地交互。转变的背后有合理的性能有关的原因，然而分布式的特征现在还存在。J2EE 规范已经经过了好几次修订，现在最稳定的版本是 1.3，1.4 版本正处于重审阶段。我们应该把注意力放在 1.3 版本上，而实际上是在学习后者。适用与商业的 J2EE 实现可以大量的从 BEA系统，IBM，Oracle 等赞助商得到。包括 JBoss 和 JOnAS 在内的开源实现据称兼容性也不错。最近名单上有多出了新的 Apache project Geronimo。2.2 J2EE 组件编程模型在我们基本的 J2EE

13、 组件前，先让我们强调一下什么是组件。软件组件是有一系列的具体的接口和明确的上下文环境构成。它可以被独立的部署而且易于被第三方重构。根据以上的定义，如下的组成 J2EE 应用程序的实体可以看作是软件组件：(1) EJBS（会话，实体，消息驱动）。(2) Web 组件（Servle t、JSP ）。.(3) 消息目的。(4) 数据源。EJB 和 Web 组件被部署在由应用服务赞助商提供的容器中.它们有定义良好的容器规则来管理生命周期，线程，持久化和其他问题。EJB 和 Web 组件都利用 JNDI 目录机制去寻找资源和它们想要交互的其 EJB 组件。目录被执行的 JNDI 环境被独立的由容器黄

14、河 科 技 学 院 毕 业 设 计 (文 献 翻 译 ) 第 5 页 的每个组件加以维护。该种环境下的绑定机制通常由组件部署的解释者加以配置。消息目的地，像对话和队列，是由消息服务执行所提供的资源。数据源是提供给应用服务器的为事务组件进入到企业信息服务层提供数据接口，通常由被应用服务器管理的JDBC 连接池实例化。一个 J2EE 编程者明确编写的项目只有 EJB 和 Web 组件。这些用户编写的组件彼此交互而且系统服务可以是明显的也可以是隐含的。例如，EJB 开发者可以选择明确的事务区分方式，这种方式意味着开发者假设通过定义良好接口的事务经理服务平台来书写明确的程序交互。或者，开发者也可选择容

15、器管理事务区分的方式。这样由于组件的事务行为通过他的描述者来定义而且全部用 EJB 容器来处理，因此作为一个隐式独立的 EJB 提供潜在的事务管理服务。2.3 组件间的链接2.3.1 远程交互J2EE 仅定义了三种可以在不同应用服务器间传递的基本组件间连接类型。在这三种情况下，通信通过特定的 Java 对象来完成。(1) 远程 EJB 调用：同步的 EJB 调用通过主 EJB 对象和 EJB 对象接口来实现。(2) Java 连结器的外部连接：同步消息接收，同步和异步消息发送，用连接工厂和连接接口进行数据库查询。(3) Java 连接器的内部连接：异步消息传递进入消息驱动 Bean 只能使用

16、Activation Spec 对象。在前两个实例中，应用组件的开发者不仅书写执行在组件的运行时 JNDI 环境中的对象目录代码，而且书写发布方法调用，与远程的组件相互发送和接受消息。组件的运行时 JNDI 环境为每一个组件部署所创建。环境中的绑定在组件部署时由部署者进行初始化。这些绑定被假设为是静态的，因为规格中没有提供任何的容器和组件间协议去提示绑定发生了变化。在 Java 连接器的内部通信情景下，Activation Spec 对象查询以及所有的相应的 M 容器隐式的完成。虽然查询的协议还没有被标准化，但是假设一个基于 JMX 或者 JNDI 的查询是合理的。 假设潜在的应用服务器提供了所有的设备去控制部署过程的每一步，那么在两个 J2EE 组件间确立一个连接需要涉及：(1) 部署目标组件类。(2) 创建一个特