JClarens:基于Java框架开发和部署网络服务的网格计算外文翻译资料

 2022-08-07 03:08

英语原文共 8 页,剩余内容已隐藏,支付完成后下载完整资料


JClarens:基于Java框架开发和部署网络服务的网格计算

概要

高能物理(HEP)和其他科学界已经采用了面向服务的架构[1][2],作为更大的网格计算工作的一部分。这项工作包括将许多遗留应用程序和编程库集成到一个SOA框架中。网格分析环境(GAE) [3]是这样一个基于克拉伦斯网格服务框架[4][5]的面向服务的体系结构,目前正在欧洲粒子物理实验室(CERN) [8]的大型强子对撞机(LHC) [7]上作为紧凑型mu;子螺线管(CMS) [6]实验的一部分进行开发。Clarens提供了一组授权、访问控制和发现服务,以及对所有已部署服务的XMLRPC和SOAP访问。克莱伦斯网络服务框架的两种实现(Python和Java)为各种编程语言提供了集成的可能性。本文描述了名为“JClarens”的Clarens网络服务框架的Java实现。和网格社区感兴趣的几个网络服务,这些服务已经使用JClarens进行了部署。

1.正式介绍

如今,科学合作需要的计算(cpu、存储、网络等)资源比任何一个机构都要多。此外,这些合作由许多地理上分散的研究人员组成。例如,两个高能物理实验CMS [6]和ATLAS [9]将产生千兆字节到千兆字节的数据,来自30多个国家150个参与机构的2000多名物理学家必须能够访问这些数据。

网格计算有望将地理上分散的机构的计算资源整合到一个更大的分布式系统中,供整个协作使用。

由于任何网站的责任之一是对本地用户负责,管理这些网站的机构通常对他们网站的资源有很大的控制权。每个站点的本地需求导致对操作系统、软件工具包和使用策略的不同决定。这些不同的需求会导致一些网格环境的异构性。

面向服务的体系结构非常适合解决这种异构、本地控制但全球共享的系统中出现的一些问题。SOA的三个特性使其成为网格计算环境中的合适候选:

标准接口定义——对资源使用通用接口定义允许它们以相同的方式使用。

实现独立性——任何操作系统上的任何编程语言都可以用来实现服务。当实现或选择它们的服务实现时,本地站点不需要运行特定的操作系统或使用特定的编程语言。标准基础服务–这些服务为定位和访问远程服务提供基本的安全性、发现和访问控制功能。

SOA的一个例子是网格分析环境(GAE) [3],它使用了克莱伦斯网格服务框架。GAE的目标是为成千上万的物理学家提供一个连贯的环境,利用地理上分散的计算资源进行数据分析。GAE SOA是超轻[10]项目的一部分,该项目侧重于将网络集成为全球数据密集型网格系统中的端到端托管资源。在其他项目中,Clarens也被用作网格服务框架,例如Lambda站[11],证明使能分析中心(PEAC) [12],和Physh [13]。

在本文中,我们讨论了第二个名为“JClarens”的Clarens实现的设计、实现和各种服务。JClarens架构基于Java Servlet技术和XMLRPC/SOAP。JClarens可以部署在任何配置了servlet引擎的web服务器上。JClarens和PClarens(基于Python)都旨在作为一组对等服务器进行部署,并具有一组互补的部署服务。

  1. 软件体系结构

Clarens框架的核心为授权、访问控制、服务发现提供了一套标准的基础服务,并为托管额外的网格服务提供了一个框架。这些附加服务提供了一些功能,如远程作业提交、作业调度、数据发现和访问。标准技术,如用于安全的公钥基础设施(PKI),以及用于调用远程服务的SOAP/XMLRPC,都在Clarens框架内使用,以提供安全和无处不在的访问。Clarens的两个实现(Python和Java)都共享一套通用的标准基础服务。PClarens,基于带有mod_python模块的Apache Web服务器。在这个实现中,服务是使用Python编程语言编写的。

JClarens是作为一个单一的J2EE网络应用程序开发的,它托管在Tomcat servlet容器中[14]。Tomcat为发送和接收SOAP和XMLRPC消息提供了基本的HTTP和HTTPS传输。但是,Tomcat的内置HTTPS连接器无法使用,因为它不支持使用代理证书的客户端身份验证。gLite [15]项目提供的库为此客户端代理身份验证提供了支持。基于HTTP的身份验证也可以使用下面描述的“系统”服务来执行。

JClarens网络应用程序使用单个servlet来处理SOAP和XMLRPC消息,如图1所示。该servlet包含一个Axis SOAP引擎和一个Apache XML-RPC引擎的实例。检查每个传入的请求,以确定它是SOAP请求还是XMLRPC请求。然后,请求被传递到适当的引擎(Axis或XML-RPC)进行处理。对两种类型的请求使用单一的网址简化了客户端应用程序的配置。

使用两个传输编码引擎需要两种配置。一个Java属性文件用于配置主JClarens web应用程序,以及XMLRPC引擎。web服务的接口是使用一个配置属性指定的,另一个属性用于定义该服务的实现类。这使得安装多个服务实现变得非常容易,并在启动时在多个实现之间进行选择。标准的SOAP web服务部署描述符文件用于配置SOAP引擎。

  1. 服务

在动态网格环境中,对于所有授权和访问控制查询,没有可以信任的中央权威。网格服务的每个本地提供者负责为他们的本地服务集提供这些特性。Clarens框架提供了几个核心服务[16],其中包括一个提供授权和访问控制管理功能的系统服务。群组服务通过允许将用户组作为单个实体进行管理来增强访问控制能力。文件服务为在远程系统上浏览、上传和下载文件提供了一种有限的机制。代理服务有助于管理客户端代理凭据,这些凭据在执行外壳命令(参见下面的外壳服务第3.4部分)以及从一个服务向另一个服务进行委托服务调用时使用。

上一段中描述的核心服务是Clarens标准安装的一部分。随着Clarens在项目中的不断开发和使用,新的功能和服务也在不断产生。站点管理员可以决定安装附加服务,而不是创建包含所有可能服务的大型包。

额外的服务为在网格环境中操作增加了有用的功能,以及一些特定于域的服务,用于非常特殊的环境,如内容管理系统。接下来的几节讨论了为JClarens编写的一些附加服务

3.1作业调度

网格调度器的工作是在许多网格站点上实现资源的有效利用。调度器考虑数据位置、中央处理器可用性和资源策略,在用户请求和网格资源之间执行匹配过程。SPHINX[17][18]是一种在动态变化和异构网格环境中的新型调度中间件,在其体系结构中提供了若干关键功能,用于在动态网格环境中进行高效和容错调度。

模块化系统:调度系统可以很容易地修改或扩展。对单个调度模块的更改不会影响其他模块的逻辑结构。健壮且可恢复的系统:SPHINX服务器使用关系数据库来管理调度过程。数据库还通过使系统易于从内部组件故障中恢复来提供一定程度的容错。

平台无关的可互操作系统:JClarens服务框架由SPHINX用来提供平台和语言中立的基于XML的通信协议。

SPHINX由两个组件组成:一个客户端和一个服务器。这种分离有利于系统的可访问性和可移植性。客户端是一个轻量级、可移植的调度代理,它向服务器提供调度请求。客户端还与向客户端提交调度请求的用户进行交互。因此,它为调度服务提供了一个抽象层,同时公开了一个定制的接口来适应用户特定的功能。

狮身人面像使用基于有限状态机的系统处理有向无环图。每个DAG工作流(和相应的作业集)可以处于几种状态之一。这些状态允许有效的控制流以及在机器故障情况下的正常恢复。每个状态都有一个模块来处理控制流和机器故障。数据管理组件与监控接口和副本位置服务(RLS)通信,用于管理存储在许多站点的数据副本。

图2展示了狮身人面像的架构。斯芬克斯客户端将奇美拉[19]生成的作业转发给服务器,以供执行站点推荐。狮身人面像服务器利用监控信息和副本定位服务将作业调度到一个站点。然后,客户端可以将它提交到该站点,跟踪者可以将作业状态信息发送回服务器。所有组件之间的通信使用GSI支持的XMLRPC服务。

3.2服务发现

在全球分布式服务环境中,服务将以不可预测和动态的方式出现、消失和移动。科学家和应用程序几乎不可能跟踪这些变化。服务发现为科学家和应用程序提供了在动态环境中查询服务和检索服务的位置和接口的最新信息的能力。尽管发现服务在概念上类似于UDDI注册中心,但它提供了更简单的服务界面和更动态的内容。必须定期向发现服务注册,以证明服务仍然可用。如果服务未能在特定时间段内通知服务发现,它将自动从注册表中删除。服务发现提供四种方法:(1)注册用于向注册中心添加新服务;(2) find_server用于定位符合特定搜索标准的服务主机;(3) find用于定位匹配特定搜索标准的服务实例;(4)取消注册用于从注册中心删除服务(但是很少使用,因为一旦注册中心无法重新注册,它将自动删除服务)。

服务发现接口的两个实现目前正在使用。第一个是基于Jini和MonALISA [20]网格监控系统的对等实现,如图3所示.MonALISA是一个基于Jini的监控系统,它使用站服务器收集本地监控数据,并使用Jini对等网络与其他站服务器或其他感兴趣的客户端共享选定的监控数据。任意监控数据都可以使用ApMon发布到MonALISA站服务器,APmon是一个使用简单的XDR编码UDP包的库。

服务发现的第一个实现使用ApMon库向MonALISA Jini网络发布服务注册。每个发现服务都包含一个客户端,该客户端监听MonALISA Jini网络上的这些服务发布,并将它们存储在内存缓存中。发现服务定期从内存缓存中清除过期条目。因为服务注册表存储在内存中,所以它在服务器重新启动时不会持久,这不是问题,因为一旦注册表再次启动,它将很快被新信息填充。

服务发现的第二个实现根本没有使用MonALISA Jini网络。相反,它使用UDDI存储库来存储服务发布。UDDI实现在简单的JClarens服务注册中心和功能更全面、更通用的UDDI注册中心之间起到了重要的桥梁作用。这个实现的注册方法进行适当的UDDI服务调用,将网络服务插入一个已知的UDDI注册中心。find和find_server方法对UDDI注册表执行查询,并重新格式化结果以匹配发现服务接口。这种UDDI实现允许JClarens在一个更加静态的环境中使用,并且已经使用了现有的UDDI存储库。

3.3数据定位服务

网格将有许多计算元素,这些元素可能属于分布在不同地理位置的多个组织。这些站点通过许多不同的广域网链路连接在一起。由于各种原因,例如站点的相对位置、本地电信提供商的能力等,这些链路将具有不同的带宽和延迟。与可用的网络带宽和延迟相比,某些可执行文件和数据项会很大。在网格范围的调度决策中,可执行文件和数据的相对位置、消耗的网络带宽、数据传输的大小和时间非常重要,因为这些参数可能会对计算成本产生重大影响。

为了实现上述目标,必须将网格分析环境中的文件访问和优化副本位置服务结合起来,以便用户或用户代理可以指定单个逻辑文件名并返回该文件的最佳物理路径。本文概述的数据定位服务(DLS)侧重于选择所选逻辑文件的最佳副本,同时考虑计算资源的位置以及网络和存储访问延迟。它必须是一个轻量级的网络服务,从网格的网络监控服务中收集信息,并基于这些信息执行访问优化计算。

该服务基于更快的访问和更好的性能特征提供最佳的副本信息。数据定位过程允许应用程序根据其性能和数据访问功能从各种副本目录中选择一个副本。一旦用户请求了一个逻辑文件,DLS就使用副本目录来定位包含该逻辑文件的物理文件实例的所有副本位置,并从中选择一个最佳实例进行检索。这些决策基于网络速度、数据位置、文件大小、数据传输时间和其他相关参数等标准。它应该是分散的(不依赖于某个中央存储系统)和容错的,以便当一个实例脱机时,用户(或客户端服务)仍然能够通过使用服务的其他实例来工作。

图4显示了DLS架构。DLS是一个分散的服务,它考虑了基于客户端和文件位置以及各自网络参数的选择过程,同时利用发现服务来定位可用的数据集目录服务。DLS查询每个目录,以找到所请求文件可用的所有位置。该服务向调用者返回一个分页的文件位置列表。此外,DLS监控数据访问模式,跟踪经常使用和经常不可用的文件。

对该服务的调用结果是根据文件的可靠性或由网络ping时间或MonALISA的其他网络测量结果确定的“接近度”来排序的。DLS还评估了访问副本的网络成本。为此,它必须使用基于网络监控统计的文件传输时间估计等信息。DLS根据给定的参数选择“最佳”物理文件。在选

剩余内容已隐藏,支付完成后下载完整资料


资料编号:[259402],资料为PDF文档或Word文档,PDF文档可免费转换为Word

原文和译文剩余内容已隐藏,您需要先支付 30元 才能查看原文和译文全部内容!立即支付

以上是毕业论文外文翻译,课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。