虚拟天文台数据访问系统(VO-DAS)任务调度设计与实现*

田海俊，刘 超，高 丹，路 勇，杨 阳，崔辰州，赵永恒，郑小平

(1.华中师范大学物理学院，湖北 武汉 430079;2.中国科学院国家天文台，北京 100012)

1 概述

天文信息爆炸式增长不仅给天文学家的天文发现带来了巨大的机遇，同时也带来了数据存储、访问和处理等方面的巨大挑战。每天GB、甚至TB数量级的观测数据如何存储，各国的巡天数据如何共享，历史遗留的存储格式、管理模式等方面的差异性如何解决，天文学家如何从如此海量的天文数据中方便地提取自己需要的数据等等一系列问题不断地困扰着正为数据的“富裕”而喜悦的天文学家。

解决异地、异构、海量天文数据无缝透明地统一访问，是近年来国际虚拟天文台联盟(IVOA［1］)一直致力的问题。计算机科学技术的飞速发展，不断为这一难题带来新的希望。世界各国虚拟天文台项目、天文台数据中心以及大型巡天观测项目纷纷提出了自己的解决方案。比如美国国家虚拟天文台(NVO)先后提出的 Sky Query［2］原型和 Open Sky Query［3］原型;IVOA 制订的 Sky Node［4］数据访问模型;英国的 Astro Grid［5］项目; 法国的 Centre de Données astronomiques de Strasbourg(CDS)［6］采用自己设计的一系列协议以及Web服务实现了一个完整的天文资料(包括星表数据和文献等)访问系统;美国的大型巡天观测项目Sloan数字巡天(Sloan Digital Sky Survey，SDSS)［7］，基于Microsoft技术，开发了Sky Server数据访问系统。虽然已经有了上述若干数据访问方案的提出，但还没有一种方案完全满足天文学家的需求，它们要么因为所选择的网络技术限制了其功能，要么因为仅为专门的项目服务限制了应用范围和互操作性。

在这些研究、试验的基础上，IVOA正不断制订、完善各种相关标准协议。基于这些协议，China-VO研发小组自主设计了虚拟天文台数据访问服务(VO-DAS)。该系统利用OGSA-DAI(Open Grid Services Architecture-Data Access and Integration，开放网格服务体系结构——数据访问与集成)［8］中间件实现了异地异构的星表数据、图像数据和光谱数据的统一封装;利用ADQL(Astronomical Data Query Language，天文数据查询语言)［9］完成了对任务的统一描述;基于WSRF框架完善了对数据资源、计算资源以及存储资源任务的统一调度;借助国际通用Registry［10］(比如英国Astro Grid)服务，实现全球数据资源的统一描述和发现。这将使天文数据源的多波段交叉证认、海量数据分析及可视化等成为可能。支持国际虚拟天文台联盟(IVOA)的各项标准，使得VO-DAS具有良好的互操作性，它的对外接口简单实用，可以针对不同需求的天文数据用户开发出多种网格应用产品。

2 VO-DAS主要接口及框架设计

VO-DAS表现为一个基于Web服务资源框架(Web Services Resource Framework，WSRF)的网格服务，因此它的接口通过一个Web服务定义语言(Web Services Description Language，WSDL)文件就可以完全描述。将VO-DAS的接口分成5个类型:资源元数据接口(Resource Metadata Interface，RMI)、数据查询接口(Data Query Interface，DQI)、数据分析接口(Data Analysis Interface，DAI)、数据分发接口(Data Delivery Interface，DDI)和操作管理接口(Management Interface，MI)。5个接口的详细描述参见文［11］。

图1 VO-DAS的设计Fig.1 Out VO-DAS design

VO-DAS构建在Globus Toolkits 4(GT4)［12］之上，这一方面是因为GT4提供的带状态的Web服务(WS)完全满足需求，另一方面因为这样可以和OGSA-DAI中间件保持一致的架构平台。

总体设计如图1。全系统分成两个部分:VO-DAS和Data Node。图1的上部框图是VO-DAS部分的设计示意图。VO-DAS框图的最上方是面向客户端的WSRF服务接口。VO-DAS的核心是Task Queue和ADQL Parser。框架中各模块的描述以及用于任务描述的天文数据查询语言(ADQL)、数据格式、数据分发、Data Node等详细阐述请参见文［11］。

3 VO-DAS的任务调度方案设计

任务调度3种可选设计方案:

(1)基于Web服务(Web Service，WS)。Sky Node是基于WS设计的，支持异地异构的多波段天文数据的交叉证认。但是由于WS的限制，Sky Node仅仅能够用来对小数据集进行操作，无法完成大数据集的访问和交叉证认。同时WS是无状态的，只能借助其他方式，比如利用Tomcat容器来维护状态信息，所以WS无法满足异步查询的要求。

(2)基于网格服务基础结构(Open Grid Service Infrastructure，OGSI)［13］规范。该规范通过扩展Web服务定义语言(Web Services Description Language，WSDL)［14］和XML Schema的使用，封装资源的状态，将具有状态的资源建模为Web服务方式，来解决具有状态属性的Web服务的问题。但这方式有以下缺点:过分强调网格服务和Web服务的差别，导致了两者之间不能更好地融合在一起;Web服务和XML工具不能良好工作，可能会造成移植性差的问题;有些Web服务的实现不能适应网格服务的动态创建和销毁等等问题。如果VO-DAS基于OGSI会导致VO-DAS先天不足。

(3)基于Web服务资源框架(Web Services Resource Framework，WSRF)［15］。WSRF采用了与OGSI完全不同的定义:资源是有状态的，服务是无状态的，很好地解决OGSI和Web服务之间存在的矛盾。WSRF的规范是针对OGSI规范的主要接口和操作而定义的，它保留了OGSI中规定的所有基本功能，只是改变了某些语法，并且使用了不同的术语进行表达;同时，使用WSDL 1.1定义OGSI中的各项能力，充分兼容现有的 Web服务。基于 WSRF的 VO-DAS，同时融合 OGSA-DAI及 WS-Notification(Web Services Notification，Web服务的通知机制)，可以有效地完成对大数据量的操作、异步操作等。

3.1 VO-DAS的执行流程

在详细探讨VO-DAS的调度逻辑之前，明确VO-DAS的执行流程很有必要。VO-DAS的执行流程通常有3类场景:同步查询、异步查询、异地异构数据的联合查询。其中异地异构数据的联合查询最为典型，本文着重以该场景为例阐述VO-DAS的执行流程。

图2以3个节点为例，展示了VO-DAS执行异地异构数据的联合查询。该场景的执行流程概括如下:

A 搭建有效数据节点，并主动向VO-DAS的注册(Registry)模块注册。

B VO-DAS服务器自启动时刻起，间隔一定时间(默认1小时)从Registry模块读取有效数据节点信息，以确保数据节点的及时性和有效性。

C 用户从客户端提交ADQL查询语句。

D VO-DAS调用ADQL解析模块(ParseADQL)，检查ADQL中涉及的数据资源的DataNode的有效性，并按照传输数据最少的原则为所涉及的DataNode排序并生成每个DataNode的执行计划对象(ExecPlan)，然后进入排队列表中，等待有效执行线程，并将任务状态置为“WAITING”(等待中)。

E 当VO-DAS服务器发现有空闲线程时，首先将任务状态置为“PROCESSING”(处理中)，然后按照执行计划从第1个数据节点查询数据，将查询结果传送到第2个数据节点，并在第2个节点创建一个临时表存储查询结果，以便下一步的交叉证认。

图2 VO-DAS的执行流程示意图 (仅以三个DataNode的联合查询为例)Fig.2 The Workflow of our VO-DAS(in an example of associated query of three data nodes)

F VO-DAS向第2个数据节点查询数据，同时和上一步生成的临时表进行交叉证认(CrossMatch)，并将交叉证认结果传输到下一节点。

G 以同样的方式处理第3个节点(或者更多节点)，VO-DAS会将最终的处理结果保存在MySpace中，并将任务状态设置为“COMPLETED”(完成)。自此，VO-DAS服务器完成一次查询任务，并释放执行线程。

H 异步查询时，客户端从提交任务后，可以随时查看任务的处理状态，当发现任务状态为“COMPLETED”时，便可以到MySpace提取结果了。

在上述执行流程中，一旦出现错误，VO-DAS将立即将任务状态置为“ERROR”，并结束此次任务。相比而言，同步查询的执行流程和异步查询要简单的多，不用维护状态管理，用户提交数据后，直接等待结果的返回。所以，同步查询适合小数据量的简单任务查询，而异步查询适合大数据量的复杂任务查询。

3.2 VO-DAS的Session机制

Web服务(WS)不带状态的，WSRF主要描述了带状态的Web服务框架，即WS－R=Web Service+Resource。VO-DAS对外发布的各个接口都是以WS形式发布出来的，而各个操作的中间或最终状态信息，是通过Session来保存的，这里的Session对应于WSRF框架中Resource。Session与WS的搭配使用，如图3是一个Factory/Instance(工厂/实例)模式，Session Home专门用来管理所有Session的一个类，Client端通过 Factory Service类调用 Session Home类的 create()方法来创建 Session;DAS Service是VO-DAS通过WS接口对外提供远程操作的一个类，客户端(Client)可以远程调用DAS Service的相关方法，而每一次任务的操作状态都可以通过与之对应Session来保存。

3.3 VO-DAS的生命周期

VO-DAS的生命周期分为3类:全局对象的生命周期、非全局对象的生命周期和Session的生命周期。全局对象主要包括LoopThread、WorkThreadPool、 WaitingQueue、 Data-ResourceMap等;非全局对象主要包括WorkThread;Session主要包括ExecPlan、status、targetURL等。本文主要讨论异步操作的Session的生命周期的控制(因为对于同步操作的Session没有实际意义，本文不做详细讨论)。

像LoopThread这样的全局对象的生命周期是从VO-DAS启动到VODAS的结束，不需要过多考虑。

当LoopThead监控线程发现有排队的任务，同时检测到工作线程池(WorkThreadPool)中有可用的工作线程时，非全局对象工作线程WorkThread才能生效，一直到这个线程将任务完成，自动结束，并由系统自动收回。WorkThread的生命周期主要由系统控制，也不需要过多考虑。

当Client端对VO-DAS有新的操作任务时，VO-DAS将首先为这次操作生成一个Session，并分配一个SessionID，这意味着Session“生命”的开始，但是Session的结束情况就比较复杂了，主要分为以下几种情况:

(1)每一个Session都有一个预设生命期限TimeOut。它是由SessionHome在创建每一个Session的时候，VO-DAS给它预先设置了一个生命期限，比如不能超过6天(这个期限值可以在VO-DAS系统的配置文件中修改)。如果任务可以在预设生命期限内执行完成，那么用户必须要在预设期限内提取相关数据结果(以后VO-DAS支持用户注册时，可以将执行完后的状态信息永久保存在数据库中);如果失效的Session“尸体”没有及时处理，那么这种情况下，失效Session在到达预设生命期限时，自动由系统销毁。

(2)如果VO-DAS在执行某次任务的过程中，程序出错抛出异常，这就意味着该Session失效。在这种情况下，VO-DAS在异常处理时，首先将status置为ERROR。LoopThread线程一旦监控到状态(status)为ERROR的Session，就会调用立即销毁(Immediate Destruction)方法将该Session立即销毁。如果不及时处理这些Session“尸体”，VO-DAS可能会因资源耗尽而被“拖死”。

(3)执行任务尚未完成，Session已经达到了预设生命期限TimeOut时，VO-DAS需要利用调度销毁(Scheduled Destruction)方式管理生命周期。即通过周期性更新“租用时间”:如果TimeOut到期，发现状态 (status)尚未被置于“COMPLETED”状态，比如仍为“PROCESSING”状态时，那么VODAS将延长TimeOut值，一直到任务执行完成。

(4)客户端主动销毁某次执行任务。这种情况需要调用VO-DAS发布的destroy()方法接口。其实，这种情况同样是利用了Session的立即销毁(Immediate Destruction)方法。

3.4 VO-DAS的资源销毁

对于服务资源的销毁操作，VO-DAS主要提供了两种方式:一种是立即销毁(Immediate Destruction)，一种是调度销毁(Scheduled Destruction)。

图3 VO-DAS Session机制Fig.3 Mechanism of Session management in our VO-DAS

(1)立即销毁(Immediate Destruction)

当客户端主动发出一个立即销毁资源的请求，或异常出现时，服务器将会对不再使用的服务资源进行立即销毁处理，以便收回占用的系统资源。在VO-DAS调度中比较典型的场景:客户要删除某次任务操作，并向服务器发出请求时，或者是服务器端监控到某次任务在被执行过程中抛出异常，导致任务无法继续进行，即Status被置为“ERROR”时，系统会立即销毁这次任务，并收回该任务所占用的系统资源。

如果Web服务资源(WSRF)没有响应销毁请求，则必须将返回异常信息:

A ResourceUnknownFault(服务资源标识无法识别):在销毁请求文档中的服务资源标识不能被服务器端识别。

B ResourceDotDestroyedFault(服务资源不能被销毁):服务资源可能由于某种原因不能被销毁。

(2)调度销毁(Scheduled Destruction)

一种基于时间“租用”的方式来管理Web服务资源(WSRF)，在这种情况下，Web服务资源(WSRF)具有一个与之相关联的生命终止时间(TimeOut)，这个时间定义了该Web服务资源(WSRF)预期被销毁的时刻，这个时刻之前Web服务资源(WSRF)是有效的，超过这个时刻，系统将自动销毁该Web服务资源(WSRF)。Web服务资源(WSRF)生命终止时刻可以通过查看TerminationTime特征值来获取，也可以通过SetTerminationTime()方法还改变终止时刻。

在VO-DAS调度中比较典型的场景，每个Session被创建时，都设定了最大生命期，当系统发现在这个生命期内，相应的操作仍没有完成时，系统将通过SetTerminationTime()方法，延长Session的生命周期。Web服务资源(WSRF)为了支持调度销毁，Web服务资源(WSRF)必须包含如下的属性定义:

A CurrentTime(当前时刻)，表示当前时刻。

B TerminationTime(销毁时刻)，设定预期销毁时刻。

如果Web服务资源(WSRF)不能在预期时刻成功被销毁，则将返回异常信息:

A ResourceUnknownFault(服务资源标识无法识别):在销毁请求文档中的服务资源标识不能被服务器端识别。

B UnableToSetTermininationTimeFault(不能设置销毁时刻错误):服务资源可能由于某种原因不能设置销毁时刻。

C TerminationTimeChangeRejectedFault(更改销毁时刻被拒绝错误)。

3.5 VO-DAS的异常处理

VO-DAS是一个相当复杂的系统，系统的层次关系比较复杂，如果系统出现异常，但不抛出，用户根本不知道系统哪里出现了问题，也就无法“对症下药”，所以系统必须在任何可能出现异常的地方，从最低层逐级往上抛出异常，一直抛到最高一层。

程序处理异常通常有以下几种情况:

(1)捕获异常但不做相应处理，这种情况通常调用 printStackTrace()、getMessage()或者getStackTrace()等方法。这对程序员调试程序很有帮助，但是当程序调试结束后，这种处理方式往往不再使用。

(2)捕获异常但是不捕获具体异常，不管下级抛出多少异常、抛出什么样的异常，仅仅只用一个catch语句来捕获，最常见的情形是使用catch(Exception ex)。由于大多数异常都直接或者间接从java.lang.Exception派生，catch(Exception ex)就相当于想要捕获所有的异常，这种捕获异常的方式没有任何意义，等于没有捕获。所以这种情况一般也只在程序调试阶段，为了简单才采用。

(3)捕获到异常后不做相应处理，把异常处理重抛给上级处理。处理异常的代码在分析异常后，认为自己不能处理它，重新向上级抛出异常，这种方式在VO-DAS中是一种常用的处理方式。

表1 VO-DAS的主要异常列表Table 1 The key exceptions list

(4)捕获到异常并作相应处理。这种情况在VO-DAS的调度程序中非常重要，比如VO-DAS在执行任务的时候，不管哪个环节出现异常，必须要报告上级，上级捕获到异常后，第一件事就是要将任务状态(status)置为“ERROR”，然后再做其他的处理，比如销毁这次任务的Session，释放资源。资源不释放是影响系统性能的潜在杀手。

(5)捕获到异常后将异常转换成另一种异常。对于比较低级的异常，用户不容易理解，这时可以将异常转换成为应用级别的异常。

VO-DAS的部分异常列表见表1。

4 VO-DAS的任务调度方案的实现与测试

整个系统的调度大致如下:DataNode搭建成功时，首先要向Registry服务注册，注册的方法主要是将DataNode的描述文档(XML格式)以URL的方式告诉Registry服务，VO-DAS系统在启动时，首先要检测Registry服务，将Registry服务中所有DataNode装载于VO-DAS服务器中，并周期性地检查和更新，以确保所有DataNode的有效性。当客户端向VO-DAS Server提交任务时，Sever首先需要对提交的任务创建一个Session，然后由ADQL解析模块对任务进行解析，并生成执行计划(ExecPlan)，保存于Session中。后面的流程，主要由VO-DAS服务器按照该任务的执行计划(ExecPlan)逐一完成。以图2为例，它表示的是一次典型的异步查询的流程，在这次任务中，VO-DAS服务器需要分别从3个DataNode中查询相应的数据，然后完成两次交叉证认(CrossMatch)，并最终将结果保存在VOSpace或MySpace中，等待用户提取。

从上述描述的整个流程来看，异步查询并不需要用户始终将自己的电脑开着，用户只需要借助ADQL语言描述清楚自己的意图，提交给VO-DAS服务器，DAS会帮你完成剩下所有的操作，这种查询方式适合大数据量、多任务的耗时查询。对于另外一种简单的查询模式——同步查询，最终的查询结果需要直接反馈给用户，用户必须始终保持VO-DAS Client端的运行状态，不然VO-DAS Server最终将把结果丢失。所以，这种模式，适合小数据量、并不耗时的任务查询。

4.1 VO-DAS服务器的运行环境

DAS是一个独立的WSRF服务，和OGSA-DAI服务共同安装在GT4 Java WS Core或Tomcat容器之上。VO-DAS的所有开发都是基于Java，故VO-DAS可同时在Window和Linux平台下运行。VODAS的安装部署请参阅说明文档。

server.xml是VO-DAS的配置文件。该文件必须存放于容器(比如Tomcat或WS Core)根目录下，用于描述系统的全局变量和设置参数，主要包括:(1)ServerName:服务器名称;(2)ServerDescription:服务器的描述;(3)RegistryURL:注册服务器的URL;(4)WorkThreadNum:查询的最大工作线程;(5)JobValidPeriod:查询任务的 Session有效期，单位为 d(默认为5 d);(6)SessionIdlePeriod:Session的空闲时间，即从建立连接到提交任务的时间间隔的最大值，单位为ms(默认为120000ms);(7)DiscoverPeriod:服务器重新装载Registry的时间间隔，单位为ms(默认值3600000ms)。

4.2 VO-DAS服务器的性能

基于原型的反复试验，VO-DAS的性能概括如下:(1)查询:一次能够查询多于50万条数据;(2)分析:一次可以分析多于500万条数据;(3)交叉证认:一次可以做多于50万条的交叉证认;(4)Session的生命周期:最长可以容许多于168 h;(5)最少支持6个工作线程同时工作，其中至少预留2个线程用于同步查询，以确保同步查询的及时性。同时，应允许多于100个任务的等待;(6)Data Node数目允许大于5000;(7)Algorithm数目允许大于100;(8)数据传输率:接近网络最大值。

到目前为止，VO-DAS仅实现了最基本的功能，即同步查询、异步查询、异地异构数据的联合查询，以及数据传输、存储、格式转换等在内的辅助功能。但是，它的有效性已经充分体现出来，作为比较，VO-DAS可以同时支持数百万条数据的异步、同步、以及联合访问模式，而美国虚拟天文台(NVO)的OpenSkyQuery的实验原型仅支持最多5000条数据的同步查询，且不支持异步查询和联合查询模式。

5 基于科学范例的系统测试

基于VO-DAS，已经完成了数个科学范例，同时对VO-DAS的任务描述、数据访问等性能进行了实验。

范例1，利用星等、颜色等特性，从Sloan数字巡天的星系星表中，为LAMOST［16］巡天选择目标样本——亮红星系(LRGs)以及发射线星系 (ELGs)［17］。该范例的测试目标是检验ADQL描述、解析复杂任务的性能。客户端需要描述一个多达十几个条件语句，同时涉及多表的交叉证认的复杂任务，对应复杂表达式，VO-DAS仅视为多个条件语句的简单叠加，但目前VO-DAS仅支持简单的条件语句和多表的交叉认证，对复杂函数、各种数据挖掘的算法、可视化功能，比如给定红移直接求得共动距离、体积等尚不支持，需要在今后的开发中进一步完善。

范例2，采用Sloan数字巡天星表中的恒星星表作为数据源，通过研究这些恒星在空间分布密度的特点寻找银河系的卫星星系或球状星团［18］。该范例的目的是测试VO-DAS对于密集任务的承受能力。在范例中，客户端程序会向VO-DAS连续发出数百个空间位置查询，每得到一个空间位置的数以千计的查询结果就对这些恒星的空间密度、亮度、颜色特征等进行分析，给出可视化结果供人工判别。该范例验证了VO-DAS以及OGSA-DAI在较强的访问密度下进行查询的稳定性以及大量数据传输的可行性。但是当访问密度非常高(对同一个约7000万条数据的大表同时有3个客户端连续发出请求)的时候，可能会出现偶发性的错误。发生偶发错误的原因尚不能确认，可能是我们使用的MySQL数据库的问题也可能是OGSA-DAI的自身问题。

范例3，对Sloan数字巡天星表的星系红移做出估计［19］，并使用估计的结果完成星系大尺度结构的可视化。在此范例中，客户端需要向VO-DAS以及DataNode请求超过2 400万条星系位置和红移数据，并利用这些数据完成星系大尺度结构的绘图。实验发现，一次访问2 400万条数据会受到实验计算机的内存限制(使用1.5 GB内存的个人计算机进行实验)，适当降低一次访问数据的数量可以让查询稳定进行。在我们实验的环境下，我们一次访问最多达到500万条数据。在具体实践中，一次访问的允许最大访问数据量应该同服务器的内存大小以及每条数据的字节长度有关系。

科学范例表明，基于WSRF框架下的VO-DAS系统可以胜任各个模块的有效调度。在适当的硬件环境保证下，VO-DAS可以为天文学研究带来极大便利。

6 总结

本文第一节主要归纳了天文领域数据“雪崩”时代所面临的问题，为此中国虚拟天文台团队为解决这些问题，基于国际虚拟天文台联盟制定的各种协议标准，自主设计并开发了一套异地异构数据的统一访问平台 (VO-DAS)，第二节简单介绍该系统的框架和主要接口，但VO-DAS的任务调度设计与实现是整个VO-DAS的核心部分，由此本文在第三节、第四节着重从设计模式、Session机制、生命周期、资源销毁、异常处理等模块详细阐述了VO-DAS服务器端(Server)任务调度机制。

反复试验表明，ADQL可以有效地对复杂任务进行统一描述，OGSA-DAI可以有效封装异地异构数据，国际通用Registry(比如英国AstroGrid)服务，可以实现全球数据统一描述、自发现功能，同时OGSA-DAI的Activity插件使得我们可以随意扩展数据节点的功能(数据格式转换、传输、压缩、存储，给定红移求距离、体积等常用天文算法，可视化……)，而这一切模块都可以收拢于WSRF框架下有效地调控。随着VO-DAS数据节点的不断增多、功能日臻完善，越来越多的科学研究将基于VODAS来完成。比如在测量大尺度星系分布、探测重子声波震荡(BAO)，以及研究红移空间畸变对星系功率谱、相关函数的影响等科学研究中，科学工作者正尝试利用VO-DAS从SDSS的星系光谱星表中提取数据样本。随着科学工作者对VO-DAS的深入使用，VO-DAS也将不断面临新的需求和挑战，最终必将驱使它真正成为一款天文学界统一的数据访问和处理平台，这也将为中国已经投入使用的LAMOST［16］、以及正在建造的FAST［20］等大型天文望远镜的数据产出提供一种不错的数据发布平台。

［1］Quinn Peter J，Barnes David G，Csabai István，et al.The International Virtual Observatory Alliance:Recent Technical Developments and the Road Ahead ［J］.SPIE，2004，5493:137－145.

［2］Budavári T，Malik T，Szalay A S，et al.Sky Query-A Prototype Distributed Query Web Service for the Virtual Observatory ［J］.Astronomical Data Analysis Software and Systems XII ASP Conference Series，2003，295:31.

［3］O’Mullane W，Budavári T，Li N，et al.Open Sky Query and Open Sky Node-the VO Framework to Federate Astronomy Archives［J］.Astronomical Data Analysis Software and Systems XIV ASP Conference Series，2005，347:341.

［4］Wagner Richard P，Norman M L.Theory Sky Node ［J］.Bulletin of the American Astronomical Society，2007，38:1002.

［5］Page C.Astrogrid and Data Mining ［J］.SPIE，2001，4477:53－60.

［6］Cunto W，Mendoza C，Ochsenbein F，et al.Topbase at the CDS ［J］.A＆A，1993，275(1):L5.

［7］York Donald G，Adelman J，John E Anderson Jr，et al.The Sloan Digital Sky Survey:Technical Summary ［J］.AJ，2000，120(3):1579 －1587.

［8］OGSA-DAI.Open Grid Services Architecture-Data Access and Integration ［DB/OL］，http://WWW.ogsadai.org.uk.

［9］ADQL.Astronomical Data Query Language ［DB/OL］，http://www.ivoa.net/Documents/latest/ADQL.html.

［10］Registry［DB/OL］，http://www.ivoa.net/Documents/latest/RegistryInterface.html.

［11］刘超，田海俊，高丹，等.异地异构天文数据资源的统一访问 ［J］.天文研究与技术——国家天文台台刊，2008，5(2):145－155。Liu Chao，Tian Haijun，Gao Dan，et al.Integrated Access of Distributed and heterogeneous Astronomical Data Resources ［J］.Astronomical Research ＆ Technology——Publications of National Astronomical Observatories of China，2008，5(2):145－155.

［12］Globus Alliance［DB/OL］，http://www.globus.org.

［13］OGSI［DB/OL］，http://www.ggf.org/documents/GFD.15.pdf.

［14］WSDL［DB/OL］，http://www.w3.org/TR/wsdl.

［15］WSRF［DB/OL］，http://www.globus.org/wsrf/.

［16］LAMOST ［DB/OL］，http://www.lamost.org.

［20］FAST ［DB/OL］，http://159.226.88.6/bao/LT/.