Ian Foster：最近网格界的变化

记者：Mark Baker

译者：lhztop@ytht.org, ancry@ytht.org 

任何转载,都必须争得译者同意,并标注译者!!!

 

 

Ian Foster是Argonne国家实验室资深科学家，分布式系统实验室负责人。同时，他也是芝加哥大家计算机系Arthur Holly Compton教授。

他为大家所知的原因可能就是和Carl Kesselman、Steve Tuecke一起作为Globus Toolkit的发起人。这个软件是开源的，对广域的分布式计算提供了一个统一的框架，由以下几个组件构成：安全、资源管理、通讯、数据管理等。在1999年出版的《the Gird（网格）》一书中，他和Kesslman首次提到了构成网格的几个主要要素。从此之后，Globus Toolkit已经成为众多网格软件基础件实现中的先锋，网格真正达到可用性的一个关键组件。

从第一版开始，globus Toolkit经历了几次大的变化，但其中最大的一个变化就是转向基于服务的（service-based）实现。在2003年7月Globus Toolkit3.0的发布中，它就实现了OGSI标准（译者注：OGSI是一个网格服务的规范）。但是令网格界惊奇的是，在2004年1月20日的GlobusWorld会议上，Foster和他的同事提出把OGSI的概念向网络服务资源框架（WSRF， web service resource Framework）演化。

在Foster提出了WSRF的声明之后，IEEE分布式系统的在线编辑Mark Baker联系了他，探讨了近来的变化及其对网格界的影响。

 

 

 

 

问题1：基于OGSI的网格服务与以前的网格建构（Grid Architecture）有很大的跳跃。把网格搭建在WSRF之上，是另一个具有重要意义的转变。现在的网格服务与Web服务有趋同的趋势，除此之外，什么人，什么事情有这么大的影响力，以至于要采用WSRF？

WSRF框架实际上重新分解了OGSI的概念，从而更好地符合Web Services标准。为什么需要对网格计算的标准和实现一再修改？按照Foster的解释，尽管Web Services的厂商（vendors）认识到了OGSI思想的重要性，但是他们不打算采纳OGSI 1.0发布时的定义。这样就威胁影响到了对OGSI规范的网格基础设施的广泛支持。而获得广泛的基础设施的支持是最初制定OGSI的主要目的。所以，在这种情况下，有必要重新组织OGSI。而Globus联盟不想重新设计OGSI（他们更乐于开发高层的服务，而不是纠缠于基础设施），所以Globus的结论是，对OGSI做一些重新分解如果能够促进网格服务和Web服务的聚合的话，那么这样就是正确的、值得的和有意义的。于是，Globus与Web服务架构师组成了一个小组来研究这个问题，成果就是WSRF。

尽管从OGSI到WSRF的演化主要是句法上的，但是也代表了一些有益的进展。把OGSI的功能分割成6个独立的规范，简化了别人的采用过程，而使用了WS-Adressing是一个进步，弱化对XML Schema和WSDL2.0的过分使用将会更加便于使用目前已有的工具。但是这些好处足以抵消对网格基础设施规范的修订带来的破坏么？站在纯技术的角度来看是很有争议的。但是事实上，我们已经获得了Web服务社区对网格基础设施强大支持，这对于网格社区来说是一个很大的成就－－这意味着我们将会在核心的Web服务产品里看到对WSRF的支持，这对于网格社区来说更是一个美妙的消息。但我们不应过分强调这个变化的影响范围：尽管这里有需要一些从OGSI到WSRF的转换工作，但是这个工作量看起来并不是非常大，而且我们正试图减轻这个过渡工作。

 

 

问题2：显然，WSRF的计划和设计工作在一段时间前就已开始了，网格社区的很多人都很关心这一进展为什么要保密，而且有多少参与者，直到2004年1月的GlobusWorld上宣布WSRF，这个计划一直没有被透露。为什么要秘密进行？以前这些进程都是公开的，怎么现在好象和一些商业界的做法一样呢？

WSRF的研究工作始于2003年夏末，在收到网络服务界对OGSI的反馈之后。幸运的是，我们在这个工作中成功得到了高级Web服务架构师的参与。不幸的是，他们希望与我们的合作方式在封闭的情况下进行。幸运的，通过大量的艰苦工作，我们很快就结束了这个过程，迅速地提出这个规范供大家评论。

我并不会说这个过程是理想的。然而，我们应该从这个过程的结果来评价它。在几个月的闭门讨论之后，我们提出了一系列的规范供大家探讨。这些规范已经被OGSI的作者们接受，许多网络服务界的人也接受了它们。我能想象更好的过程，我也能想象更坏的结果。

 

 

问题3：制定WSRF至少的一大动因就是为了使得网格服务更合Web服务社区的胃口。而这样做的结果就是，网格服务的概念好像完全消失了。这样说对么？所以为什么我们两年前需要网格服务，而现在不需要呢？

不，网格服务的概念没有消失。OGSI和WSRF所致力于解决的本质问题――也就是从一个网格的观点来看，Web服务所缺少的关键功能就是能够创建、定址、检查、发现和管理有状态的资源。在OGSI里面，这些有状态的资源被称作网格服务；而在WSRF里，他们被称为WS-Resources。一个网格服务拥有一个身份id、服务数据（Service data）、生命期管理机制；一个WS-Resource拥有一个名称、资源属性和生命期管理机制。术语变了，但需要、概念和机制并没有变。OGSI和WSRF都定义了这些确实很重要的规范所需的机制，这些规范都是用来定义构建上层的OGSA的。OGSA工作将会继续向前，这些变化对OGSA的影响很小。

 

 

问题4：OGSI第一次提出时，其基本特征已经被相当秘密地制定了，Globus项目已经沿着OGSI走了很长的时间了。网格界中大部分人都原谅了你，投入了很大的精力来理解OGSI，修订了他们的项目计划。他们还会再次这样做么？

你开始说的不对：OGSI不是在秘密中制定的。从2000年起，我们就发现网格社区越来越多的人愿意采用Web服务作为网格的实现技术。与此相回应的，Globus联盟和IBM组成了一个小组在2002年2月提出了一个OGSI规范的草案。随后，在GGF的一个工作组内经过一年半的全面细致的检查审阅后，于2003年6月才形成了最终的OGSI规范。我认为这是一个极好的例子，Globus联盟看到了大家新的要求，而预先研发，并制定了开放的标准。

WSRF的初始动机也是为着相同的目标，并且沿着同样的进程进行的。网格的成功需要采用已经被广泛地采纳应用的标准化了的基础设施来创建、定址、检查、发现和管理有状态的资源。OGSI定义了需要的机制。WSRF稍微改编了其中的陈述来便于在商业的Web服务工具里的应用。它是前进路上的一次颠簸，但不是非常严重，而获得的好处是巨大的。

 

 

问题5：许多项目都向OGSI靠拢了一段时间了，有些已经在开发网格服务，这些工作是浪费么？另外一些坚持使用Web服务，希望一旦一个广泛部署的OGSI基础件到位时，转向网格服务是没有痛苦的、很快乐的一件事情。似乎后者等待WSRF是更明智的，但是对许多项目来说，他们的生命期太短了。而且还有很多坚持用GT2，现在好象可以直接用GT4，而不必理会GT3了。一些人正在考虑是否使用Globus，而使用Globus的替代品。你怎么能说服牢骚满腹的大家，与转向所经历的痛苦相比，长期的利益会更大呢？我们是不是也遭遇了阻碍网格发展的一个激烈反应呢？就象AI的冬天一样，现在也是网格的冬天了呢？

e-science和e-business仍在持续增长：例如最近Oracle、IBM、Sun还有其它一些公司最近都宣布支持它们；美国的Cyberinfrastructure项目和新的EU项目也在进行中。同样地，人们也认识到了中间件扮演了一个极重的角色：保证了安全性、可靠性、互操作的资源共享与管理。因此，我不关心会有激烈的反对反应：网格已经到来了，不管我们在构建它时经历多大的痛苦，我们也要接受它。

我不想低估你谈到的“剧变”，但是我想，大家经常把它的想得过于严重了。当Globus联盟最初在GT3.0里包括对OGSI支持的时候，我们承诺支持GT的pre-Web服务部件，许多用户继续使用它们。确实我们继续推荐他们用于实际的产品级服务，因为目前基于Web服务（WS-based）的部件还没有达到产品级的水平。WSRF是从OGSI的一个渐增的变化，我们在将来一段时间内将继续支持OGSI。

分布式系统的开发者必须仔细地审视可用的技术，然后决定那一种最适合需要。Globus Toolkit，OGSI和WSRF都不是适用于所有的情况的。但是，我们也不要不加考虑就忙下结论“我的问题是不同的或者很简单，所以我还是开发自己的中间件把”。分布式计算在多个层面上都是很复杂的，从安全性、可靠性到可信度管理；互操作性总是具有挑战性的。在标准框架下工作有很多优势，能解决一些很紧迫的问题：一次登录，多次使用；远程布署；计算管理、数据移动等。采用GT的用户能得到这方面的帮助，还能在一个开发者和用户所组成的全球范围的社区内讨论。

 

 

问题6：你对提议的WSRF标准获得认同的时间表是什么？ 你认为GGF作为一个标准组织存在可行么？

WSRF已经被列入了GGF的OGSI工作组的讨论日程，将会对其进行大量的讨论。这些规范很有可能很快被提交到OASIS（Organization for the Advancement of Structured Information Standards），为了保证网格的需求能够得到满足，OASIS与GGF启动了一个正式的联络进程。这么做的原因很简单：WSRF不是一组纯粹的网格标准，而是碰巧却是一组与网格非常相关的WS标准，WS标准通常情况下是由Oasis或者W3C处理。提交之后，什么时间能完成这个标准的制定还是未知的，不过GGF的OGSI小组付出了巨大努力之后，这个进程会更快进行。

有人认为把WSRF提交给Oasis说明GGF并不是一个独立的标准化组织。我不这么想。GGF已经提出了许多正在应用的网格标准，比如GridFTP和GSI。其它的一些规范还在制定中，比如DAIS。很自然地，网格也建立在其它组织（如IETF、W3C和Oasis）的标准之上。一些GGF的参与者也参与了其他的这样的组织，例如，OGSI的作者作为了W3C的WSDL工作组的特邀专家。GGF的CMM和Oasis的WSDM WG也存在交集。我们期望看到更多的这种情况，这些进展都能使GGF不仅仅作为网格标准的制定者，而且也是网格要求能集成进其它标准化组织的工作中去的推进者。

 

 

问题7：OGSI规范除了GlobusToolkit实现之外，还有一些其他的实现。可是一旦Globus弃船逃跑，转向了WSRF，OGSI还会拥有这么多追随者么？

由于我刚才提到的原因，Globus联盟致力于把Globus Toolkit升级成WSRF。据我所知，其它的OGSI实现，如pyGlobus、OGSI.NET、OGSI::Lite和Unicore也有同样的趋势，就如OGSA相关规范的主要设计者，象WSDM（管理）、DAI（数据访问和集成）和WS-Agreement所做的一样。因此，虽然没有理由不继续在OGSI框架下工作（我们将继续支持GT 3.x的基于WS组件一段时间，具体依赖于我们的人力和用户的需要），但应该准备明年向演进到WSRF。

 

 

问题8：许多科学家仍然使用库风格的API，并不理解Web服务或者网格服务。而对GT2那样的风格库包还会继续支持么？

当前各种社区正在努力学习通过创建服务而不是共享程序或者数据来提供汇聚专门技能知识，我完全期望科学计算的问题解决环境（PSE，problem-solving environment）越来越转向面向服务。例如，这个概念就是国际虚拟天文台启动计划（international Virtual Observatory initiative）的核心思想。稍小规模的美国的Fusion Collaboratory项目通过远程访问仿真代码，就免除了远程用户需要下载和安装复杂的应用的麻烦。更一般的，网络服务是一个建立大规模分布式系统的强有力的框架，通过一个严格的接口，可以不受约束地进行开发。

然而，许多社区和用户仍然需要特殊的功能（例如，访问远处的计算机或数据）这是通过GT2风格库创建和管理远程的计算、传递数据等实现的。这就是GT3和GT4提供这些功能的客户端API的原因。只要有类似的重要的需要，这些API就会继续被支持。确实，我们希望GT以及基于GT的工具中这样的API会更多，这样，更多的高层次的、面向应用的网格工具就会被开发出来。

 

 

问题9：OGSI规范的一个缺点就是对于某些焦点问题说得很少，例如如何支持两个独立的但是兼容的实现进行互操作。例如，GT3中的安全模型就是GSI和WS-Security的一个非标准的混合体。WS-Adreessing应该会有助于避免重复解析句柄的难题。Globus联盟是否也采取了措施来避免重蹈覆辙，例如互操作性？

OGSI规范集中于网格服务的WSDL接口。互操作涉及到了许多其他的问题，如安全和可靠的通信。我们与其他的OGSI/WSRF的实现研究人员保持紧密的联络，希望能够尽快进行互操作测试。这个工作应该能有助于构画出OGSI/WSRF实现的互操作性的轮廓。

最终地，互操作需要一个广泛的WS和网格标准的标准化。只有在这些标准都到位了并且满足了网格需要的时候，才能完全达到采用WS作为网格的基础的价值。因此，我们就很有必要参与到更广泛的Web服务社区和象WS_I论坛那样的组织中去才能确保我们的符合WSRF标准的服务具有完全的互操作性，不管是由网格提供的还是由Web服务中间件提供的。

 

 

问题10：怎样从WSRF网格上构建信息服务？有指定的机制（如监视和发现服务）么？或者说，会用现有的注册技术么？

 

 

OGSI/WSRF中令人振奋的一个新特征就是信息服务机制的高度集成。任何网格服务（在WSRF中叫WSRF资源）都可以声明服务数据（WSRF中的资源属性），这些服务数据都可以用标准的机制发现、取出、放入。WSRF的WS-Notification规范使我们迈出了重要的一步，通过建立一些接口使用已被广泛采用的基于消息的中间件，就可以提供更健壮的、内容更丰富的信息服务。打个比方，一个程序员开发了一个文件传输服务，只需要定义一些适当的服务数据（资源属性），然后服务马上就可以被发现和监控了。在此基础之上，就有可能定义一个更大范围的信息服务组件，来发现、监视、得到它们，对出现的错误也可以捕获到，等等。Globus联盟正在开发这些组件的雏形，包括一个存档服务和注册服务，状态提供者可以更快地更新状态信息。第一版将出现在GT3.2，更完善的将在GT4.0。

OGSI/WSRF中令人振奋的一个新特征就是信息服务机制的高度集成。任何网格服务（在WSRF中叫WSRF资源）都可以声明服务数据（WSRF中的资源属性），这些服务数据都可以用标准的机制发现、取出、放入。WSRF的WS-Notification规范使我们迈了重要的一步，更广泛地使用基于消息的中间件建立可以探知的接口，就可以提供更健壮的、内容更丰富的信息服务。打个比方，一个程序员开发了一个文件传输服务，它只需要定义一些服务数据（资源属性），这个服务就对别人可见，并可以被监视。在此基础之上，就有可能定义一个更大范围的信息服务组件，来发现、监视、得到它们，对出现的错误也可以捕获到，等等。Globus联盟正在开发这些组件的雏形，包括一个存档服务和注册服务，状态提供者可以更快地更新状态信息。第一版将出现在GT3.2，更完善的将在GT4.0。

 

 

问题11：在WSRF的可靠实现可用之前，你对开发者有什么建议？我们什么时候能够看到其他语言的WSRF组件，而不仅仅是JAVA？

先谈一下Globus Toolkit。GT3包括了GT的pre-WS组件的可靠实现和基于WS组件的早期实现。即将发布的GT3.2，对基于WS组件做了重大改进，在继续支持pre-WS组件的同时，更强调了网络服务的可用性、健壮性和性能。GT4.0，可能会在2004年第三季度发布，将引进对WSRF的支持，同时会继续改进GT的基于WS组件的可用性、健壮性和性能，支持pre-WS组件。

其它的OGSI实现也计划向WSRF演进，不过我并不知道具体的时间表。Stephen Pickles最近在OGSI WG的邮件列表上宣布他已经几乎完成了OGSI::Lite向WSRF的转变。

借助这个场合，我提出几点建议：

如果你用pre-WS工作得很好，就象很多产品化的网格一样，那么继续。它们仍将在GT3和GT4中得到支持。只要还有需要，我们会继续支持pre-WS组件，我们有人力支持到2005年。

如果你正在用GT3.0的基于网络服务的GT组件，为了得到更好的性能，在GT3.2发布时，转向它。进一步的，如果WSRF对你有意义，转向它。我们会继续支持GT3.x组件，我们有人力支持到2005年。

如果你刚刚开始熟悉网络服务和网格，先用GT3.2，然后到明年的某个时间转向GT4.x。

 

 

问题12：最后一个问题来自英国，我知道英国的e-Science项目从2002年就开始了，而它的基础设施里面许多都是与Globus技术紧密相关的。事后看来，英国的e-Science项目是不是开始的过早？

不是的。英国的e-Science项目启动的时机非常好，使得英国在开发网格上起到了一个清楚的作用。例如，如果没有英国的e-Science项目的资助，OGSA-DAI的工作就会启动的更晚或者根本就不能起动，英国就不会在数据服务起先导作用。Globus联盟也不会把Edinburgh大学加入进来。

对于这个问题，我想澄清一个与之相关的误解。e-science方面的工作就是关于创建21世纪的科学所需要的环境。很自然地，类似于建筑，我们更愿意直接搬入一个已建好的房子，而一些用户好像就是希望Globus是一个这样的房子。但是，正如它的名字所说，Globus Toolkit仅仅是一系列的工具，并不是一个完整的解决方案。对于熟练的开发者来说，只要适当地运用这些工具来解决认证、发现、远程访问和其他的分布式计算的挑战，就能开发出很好的成果。但是成功并不是仅仅在有了科学家和Globus Toolkit之后，就自然而然地完成了。它需要在科学家和网格技术的合作，和／或可用的高层面向特定应用的解决工具，就象GriPhyN/PPDG的虚拟数据工具包，Access网格和一些portal工具。

所以从整体上来讲，网格的发展需要创造性和理解。随着经验的积累，我们也在不断深化我们的认识，知道怎么更好地建立一个健壮的、可靠的全球的网格。作为合作的很好的例子，我们看一下今年就要完成的地震模拟网格所组成的网络（Network for Earthquake Engineering Simulation Grid）。Neesgrid用GT3的OGSI软件建立了一个成熟的、分布式的实验控制和协作系统。其中的一些工作需要把OGSI软件转向GT4，不过Neesgrid设计者认为变化的代价与现在已经布署在各个Neesgrid节点上的集成的协作工具取得的巨大进展和对大家的培训相比，仍然很小。去年7月，Neesgrid完成了一个多站点结构的地震试验，试验设备在Colorado和Illinois，模拟系统在Illinois，数据文件和人力参与达12个站点之多。如果没有Neesgrid，这种新的科学就不会完成。

我举的第二个例子是美国的Grid3系统。从2003年11月开始，已经用GT的pre-WS组件，在美国和韩国的27个网格子节点上持续运行了500到2000个数据分析任务，涵盖一系列物理、生物和计算机科学项目。最终用户和GriPhyN/PPDG虚拟数据工具箱（Virtual Data Toolkit）的开发者之间展开合作，使用GT机制来协同在多个站点上的数据密集的工作流的调度，目前这个计划已经取得了很大的应用成果。此外，对于创建和运行一个可操作的网格需要什么，还积累了许多经验。

 

 

后记：

感谢Ian抽出宝贵的时间，回答我提出的这些问题。无疑Ian将会考虑这次会谈中所提出的问题，他也会考虑将在2004年3月在德国柏林召开的GGF10中提出的问题。

Mark Baker是英国Portsmouth大学计算机学院分布式系统的高级讲师，Westminster大学Cavendish计算机学院的计算机科学访问教授。联系方式：mark.baker@computer.org.