Ian Foster是网格计算界的首席牛人,
他和南加州大学的Carl Kesselman首先提出了网格计算的概念,定义了协议规范.
他所领导的Globus计划(
http://www.globus.org)是网格计算界最有影响的项目，是网格的
标准的制定者。
从去年的OGSA架构和OGSI1.0规范的提出，网格计算与Web Services走到了一起。
今年年初，Globus计划和IBM、HP、FUJISTU等共同提出了WS-Resource Framework and WS
-Notification的概念，把网格计算与Web Services，当前最热门的两项技术更紧密地捆绑
起来。
但是也有许多网格界的人对于这些变化没有准备，有许多疑惑。
转自一塌糊涂 网格论坛的这篇文章是Ian Foster教授与一位网格爱好者的问答录,希望能
够诠释大家的困惑。
发信人: lhztop (hell第一鬼(远离HT真心戒网)), 信区: GridForum
标 题: Ian Foster：最近网格界的变化(中文)
发信站: 一塌糊涂 BBS (Mon Mar 29 18:25:49 2004), 本站(ytht.net)
Ian Foster：最近网格界的变化
记者：Mark Baker
译者：lhztop@ytht.org
Ian Foster是Argonne国家实验室首席科学家，其分布式系统实验室负责人。他也是芝加哥
大家计算机系Arthur Holly Compton教授。他出名的原因可能是和Carl Kesselman、Stev
e Tuecke一起作为Globus Toolkit的发起人。这个软件是开源的，对广域的分布式计算提
供了一个统一的框架，由以下几个组件构成：安全、资源管理、通讯、数据管理等。在19
99年出版的《the Gird（网格）》一书中，他和Kesslman首次提到了构成网格的几个主要
要素。从此之后，Globus Toolkit已经成为众多网格软件基础件实现中的先锋，网格真正
达到可用性的一个关键组件。
从第一版开始，globus Toolkit做了几次大的变化，相当重要的一个变化就是基于服务的
（service-based）实现。在2003年7月Globus Toolkit3.0的发布中，它就实现了OGSI标准
（译者注：OGSI是一个网格服务的规范）。但是令网格界惊奇的是，在2004年1月20日的G
lobusWorld会议上，Foster和他的同事提出把OGSI的概念向网络服务资源框架（WSRF， w
eb service resource Framework）演化。
在Foster提出了WSRF的声明之后，IEEE分布式系统的在线编辑Mark Baker联系了他，探讨
了近来的变化及其对网格界的影响。
Mark Baker：基于OGSI的网格服务与以前的网格建构（Grid Architecture）有很大的跳跃
。把网格搭建在WSRF之上，是另一个具有重要意义的转变。现在的网格服务与网络服务有
趋同的趋势，除此之外，什么人，什么事情有这么大的影响力，以至于要采用WSRF？
Ian Foster：WSRF的提出，重新组织了OGSI的概念，这样做的目的是更好地与网络服务一
致。网络服务标准制定者承认OGSI概念很重要，但他们并不打算采用目前OGSI所定义的这
些概念，在这种情况下，有必要重新组织OGSI，因为不这样，就威胁到那些符合OGSI规范
的网格基础件的统一支持。Globus联盟对重新设计OGSI不感兴趣（我们更愿意开发高级服
务，而不是基础件）。我们认为如果重新组织OGSI能对网格服务和网络服务的合并产生影
响，这种重组就是有意义的、正确的。我们成立了一个网络服务建构小组，专门研究这个
问题，其研究成果就是WSRF。
OGSI到WSRF，其中的主要变化是在句法上的，也有一些有用的进展。把OGSI在功能上分成
了六个独立的部分，用WS-Addressing是一种进步，更多地运用标准的XML Schema和WSDL2
.0，我们就可以用很多现成的工具。对OGSI的分割，以及对网格基础件规范的修订与获得
的好处相比，这样做是正确的么？从纯技术角度讲，这是有争议的。但是事实上，网格基
础件是一个很大的成就，我们在网络服务界获得了强有力的支持：我们能从核心的网络服
务产品中看到WSRF支持，这对网格界来说，真是一个好消息。而且，我们不应该过分夸大
变化的范围：当然，从OGSI到WSRF，还是有一定的工作要做，但并不是每一件都是必须的
，我们正在试图使这样的转化更少。
问：显然，WSRF的计划和设计已经有一段时间了。现在网格界很多人关心进度如何、有多
少参与者，直到2004年1月的GlobusWorld上宣布WSRF，这个计划一直没有被透露。为什么
要秘密进行？以前这些进程都是公开的，怎么现在好象和一些商业界的东西一样呢？
答：WSRF的工作在2003年夏末开始，在收到网络服务界对OGSI的反馈之后。幸运的是，我
们在这样工作中成功纳入了高级网络服务建构。不幸的是，他们仅仅想把我们放到到一个
闭集中。幸运的，通过大量的艰苦工作，我们很快就结束了这个过程，迅速地提出这个规
范供大家评论。
我并不会说这个过程是理想的。然而，我们应该从这个过程的结果来看待它。在几个月的
封闭讨论之后，我们提出了一系列的规范供大家探讨。这些规范已经被OGSI的作者们接受
，许多网络服务界的人也接受了它们。我能想象更好的过程，我也能想象更坏的结果。
问：WSRF的动机，至少部分的，是因为使网格服务更容易让网络服务界接受。这样做，似
乎网格服务这一概念也消失了。这样说对么？为什么二年前我们需要网格服务，而现在不
需要了？
答：不。风格服务这一概念并没有消失。OGSI和WSRF的精华就是，网络服务所缺少的关键
功能：能够创建、使用、探察、发现和管理有状态资源。在OGSI里，有状态资源叫做网格
服务；在WSRF里，叫做WS-资源。每一个网格服务都有一个ID、服务数据（service data）
和生命期管理机制。术语变了，但需要、概念和机制并没有变。OGSI和WSRF都定义了规范
所要求的机制，这些都是建立在OGSA（open grid services architecture）之上。这些变
化对OGSA的影响很小。
问：OGSI第一次提出时，其基本特征已经被相当秘密地制定了，Globus项目已经沿着OGSI
走了很长的时间了。网格界中大部分人都原谅了你，投入了很大的精力来理解OGSI，修订
了他们的项目计划。他们还会再次这样做么？
答：你刚开始说的不对。OGSI并不是在秘密中进行的。从2000年开始，我们就发现在网格
界有人把网络服务作为网格的一种实现技术。因此，Globus联盟中的一个小组，与IBM合作
，在2002年2月制定了一个OGSI规范的草案。一年半以后，在GGF的一个工作组细致审查之
后，最终在2003年6月形成了最终版本。我认为这是一个极好的例子，Globus联盟看到了大
家新的要求，而预先研发，并制定了开放的标准。
WSRF的初始动机也是一样，按照同样的进度安排。网格的成功需要广泛地采用标准化的基
础件来创建、使用、探察、发现和管理有状态资源。OGSI定义了需要的机制，WSRF采用了
能易于使用商业的网格服务工具的陈述（术语）。确实，路中央突起了一块，但并不是一
大块，所取得的利益也是很重大的。
问：许多项目都向OGSI靠拢了一段时间了，有些已经在开发网格服务，这些工作是浪费么
？另外一些坚持网络服务，希望一旦OGSI基础件到位时，转向网格服务是没有痛苦的、很
快乐的一件事情。似乎后者等待WSRF是更明智的，但是对许多项目来说，他们的生命期太
短了。而且还有很多坚持用GT2，现在好象可以直接用GT4，而不必理会GT3了。一些人正在
考虑是否使用Globus。你怎么能说服大家，与转向所经历的痛苦相比，长期的利益会更大
呢？我们是不是阻碍网格的一个大的障碍呢？是不是就象AI的冬天一样，现在也是 网格的
冬天了呢？
答：电子科学和电子商务仍在持续增长，最近Oracle、IBM、Sun还有其它一些公司最近都
宣布支持它们；美国的Cyberinfrastructure项目和新的EU项目也在进行中。因此，要认识
到中间件扮演了一个极重的角色：保证了安全性、可靠性、互操作的资源共享与管理。因
此，我并不认为（大家是）一个障碍，网格已经来了，不管我们在构建它时经历多大的痛
苦，我们也要接受它。
我没想把你所说的“剧变”降到很小，不过我想，很多情况下大家把它想得太严重了。Gl
obus Toolkit、OGSI和WSRF，他们都有各自的适用范围，并不是适合每一种情况。然而，
我们也尽量使跳跃不会很大，以免大家都“我的问题与别的问题不同，我还是自己开发自
己的中间件吧”。分布式计算在多个层面上都是很复杂的，从安全性、可靠性到可信度管
理；互操作性总是具有挑战性的。在标准框架下工作有很多优势，能解决一些很紧迫的问
题：一次登录，多次使用；远程布署；计算管理、数据移动等。采用GT的用户能得到这方
面的帮助，还能在一个开发者和用户所组成的全球范围的社区内讨论。
问：提议中的WSRF标准什么时候能被通过？你有信心么？GGF能做为一个独立的标准化组织
存在么？
答：GGF的OGSI工作组对WSRF标准的讨论仍然有很多争议。这个规范可能不久就要提交给O
asis（Organization for the Advancement of Structured Information Standards），
这是GGF为了保证网格要求能被处理而与Oasis做的正式联系。这么做的原因很简单：WSRF
并不是一个排外的网格标准，而是一系列的与网格相关的网络服务标准中的一个，而以往
的网络服务标准是由Oasis和W3C制定的。提交之后，什么时间能完成这个标准的制定还是
未知的，不过GGF的OGSI小组付出了巨大努力之后，这个进程会更快进行。
有人认为把WSRF提交给Oasis说明GGF并不是一个独立的标准化组织。我不这么想。GGF已经
提出了许多正在应用的网格标准，比如GridFTP和GSI。其它的一些规范还在制定中，比如
DAIS。很自然地，网格也建立在其它组织（如IETF、W3C和Oasis）的标准之上。一些GGF的
合作伙伴也参与了这些组织。OGSI的作者是W3C的WSDL工作组的特邀专家。GGF的CMM和Oas
is的WSDM WG也存在交集。我们期望看到更多的这种情况，这些进展都能使GGF不仅仅作为
网格标准的制定者，而且也是网格要求能集成进其它标准化组织的工作中去的推进者。
问：除了Globus之外，OGSI规范还有其它的实现。一旦Globus跳票，转向了WSRF，OGSI还
会拥有这么多追随者么？
答：如前所说，Globus致力于用WSRF开发Globus Toolkit。据我所知，其它的OGSI的实现
，如pyGlobus、OGSI.NET、OGSI::Lite和Unicore也有同样的趋势，就如OGSA相关规范的主
要设计者，象WSDM（管理）、DAI（数据访问和集成）和WS-Agreement所做的一样。因此，
虽然没有理由不继续在OGSI框架下工作（我们将继续支持GT 3.x的基于网络服务组件一段
时间，具体依赖于我们的人力和用户的需要），但应该准备明年向WSRF转化。
问：许多科学家仍然用库风格的API，并不理解网络服务或者网格服务。GT2那样的风格还
会继续支持么？
答：我当然期望科学问题的解决环境是面向服务的，我们说服专家不是通过共享程序或者
数据，而是创建服务来开发程序，这个概念有国际虚拟天文台的核心里最有体现。稍小一
些的美国Fusion Collaboratory项目也取得了很大的成功，通过远程访问相同的代码，不
需要远程用户下载并安装这么复杂的程序。更一般的，网络服务是一个建立大规模分布式
系统的强有力的框架，通过一个严格的接口，可以不受约束地进行开发。
然而，许多项目和个人仍然需要特殊的功能（比如，访问远程计算机或数据），这是GT2函
数库的实现，创建和管理远程计算，交换数据等等。这就是为什么客户端的API仍然在GT3
和GT4中保留了这些功能，并且它们仍将会继续获得支持，只要还有类似的需要。确实，我
们希望GT以及基于GT的工具中这样的API会更多，这样，更多的高层次的、面向应用的网格
工具就会被开发出来。
问：OGSI规范的一个缺点就是对两个独立但兼容的实现的互操作说的很少。例如，GT3的安
全模型是GSI和WS-Security的一个不标准的混合体。WS-Addressing应该有助于避免这种应
付问题的方法。Globus联盟是不是采取了措施，不会重复这些有害于互操作的事情？
答：OGSI规范主要是网格服务的WSDL接口。互操作性更关心其它问题，如安全、可靠消息
等。我们和其它的OGSI/WSRF实现的开发者组成了一个封闭的小组，可能不久就会测试互操
作性。这个工作应该能构画出OGSI/WSRF实现的互操作性的轮廓。
最终，互操作性需要一个更大范围的网络服务标准和网格标准的标准化。Grid以网络服务
为基础，这样做的价值只有当这些标准正式制定出来，并且适合网格的要求时才会体现出
来。因此，我们更大范围参与到网络服务界，还有一些制定这些标准的组织，如WS-Inter
operability论坛。这样我们就能提供更好的互操作性，只要是符合WSRF的服务，不管它是
网格的，还是其它网络服务中间件。
问：怎样从WSRF网格上构建信息服务？有指定的机制（如监视和发现服务）么？或者说，
会用现有的注册技术么？
答：OGSI/WSRF中令人振奋的一个新特征就是信息服务机制的高度集成。任何网格服务（在
WSRF中叫WSRF资源）都可以声明服务数据（WSRF中的资源属性），这些服务数据都可以用
标准的机制发现、取出、放入。WSRF的WS-Notification规范使我们迈了重要的一步，更广
泛地使用基于消息的中间件建立可以探知的接口，就可以提供更健壮的、内容更丰富的信
息服务。打个比方，一个程序员开发了一个文件传输服务，它只需要定义一些服务数据（
资源属性），这个服务就对别人可见，并可以被监视。在此基础之上，就有可能定义一个
更大范围的信息服务组件，来发现、监视、得到它们，对出现的错误也可以捕获到，等等
。Globus联盟正在开发这些组件的雏形，包括一个存档服务和注册服务，状态提供者可以
更快地更新状态信息。第一版将出现在GT3.2，更完善的将在GT4.0。
问：在可靠的WSRF实现之前，你对开发者有什么建议？我们什么时候能够看到多语言的WS
RF组件，而不仅仅是JAVA？
答：先谈一下Globus Toolkit。GT3是GT的pre-WS组件的可靠实现，基于网络服务组件的早
期实现。就要发布的GT3.2，对基于网络服务的组件做了重大改进，在继续支持pre-WS组件
的同时，更强调了网络服务的可用性、健壮性和性能。GT4.0，可能会在2004年第三季度发
布，在继续支持pre-WS组件和网络服务组件的同时，还会支持WSRF。
其它的OGSI实现也计划向WSRF转向，不过我并不知道具体的时间表。Stephen Pickles最近
在OGSI WG的邮件列表上宣布他将OGSI::Lite转向WSRF。
下面是我对你所谈及的开发者的建议：
如果你用pre-WS工作得很好，就象很多产品化的网格一样，那么继续。它们仍将在GT3和G
T4中得到支持。只要还有需要，我们会继续支持pre-WS组件，我们有人力支持到2005年。
如果你正在用GT3.0的基于网络服务的GT组件，为了得到更好的性能，在GT3.2可用时，转
向它。进一步的，如果WSRF对你有意义，转向它。我们会继续支持GT3.x组件，我们有人力
支持到2005年。
如果你刚刚开始熟悉网络服务和网格，先用GT3.2，然后到明年的某个时间转向GT4.x。
问：最后，我从英国来，知道英国2002年开始的电子科学项目，在它的基础件里用了很多
Globus技术。事后来看，英国的电子科学项目是不是起动的太早了？
答：不是。英国的电子科学项目的起动时机选择得很好，使英国在开发网格是扮演了一个
重要的角色。如果没有英国的电子科学资助，OGSA-DAI起动得更晚，或者根本就不能起动
，英国就不会在数据服务起先导作用。Globus联盟也不会把Edinburgh大学加入进来。
对这个问题，我更想说与之相关的一个误解。电子科学就是建立21世纪科学的环境。与建
筑类似，我们愿意简单地搬到一间已经盖完的房子，很多用户就把Globus看过这个完工的
房子。然而，就如它的名字所说，Globus Toolkit仅仅是一系列的工具，并不是一个完整
的解决方案。对熟练的开发者来说，只要适当地运用，就能解决认证、发现、远程访问等
分布式计算中的许多挑战性课题，产生很好的效果。但是成功并不是仅仅在有了科学家和
Globus Toolkit之后，就自然而然地完成了。它需要在科学家和网格技术的合作，可用的
高层面上的面向特定应用的解决工具，就象GriPhyN/PPDG的虚拟数据工具包，Access网格
和一些portal工具。
所以，从总体上讲，网格的发展需要创造性和理解性。随着各种试验的进行，我们提高了
我们的理解，知道怎么更好地建立一个健壮的、可靠的全球的网格。作为一个多少合作才
能工作很好的例子，我们看一下今年就要完成的地震模拟网格所组成的网络（Network fo
r Earthquake Engineering Simulation Grid）。Neesgrid用GT3的OGSI软件建立了一个成
熟的、分布式的实验控制和协作系统。其中的一些工作需要把OGSI软件转向GT4，不过Nee
sgrid设计者认为变化的代价与现在已经布署在各个Neesgrid节点上的集成的协作工具取得
的巨大进展和对大家的培训相比，仍然很小。去年7月，Neesgrid完成了一个多站点结构的
地震试验，试验设备在Colorado和Illinois，模拟系统在Illinois，数据文件和人力参与
达12个站点之多。如果没有Neesgrid，这种新的科学就不会完成。
我举的第二个例子是美国的Grid3系统。从2003年11月开始，已经用GT的pre-WS组件，在美
国和韩国的27个网格子节点上持续运行了500到2000个数据分析任务，涵盖物理、生物和计
算机科学。通过最终用户和GriPhyN/PPDG虚拟数据工具的开发者之间的合作，程序的结果
传递过来。GriPhyN/PPDG运用GT提供的机制，来调度多节点上的数据密集的工作流。此外
，正在做着的更多的试验，如何建立、运行一个可操作的网格。
后记：
感谢Ian抽出宝贵的时间，回答我提出的这些问题。无疑Ian将会考虑这次会谈中所提出的
问题，他也会考虑将在2004年3月在德国柏林召开的GGF10中提出的问题。
Mark Baker是英国Portsmouth大学计算机学院分布式系统的高级讲师，Westminster大学C
avendish计算机学院的计算机科学访问教授。联系方式：mark.baker@computer.org.
Acronyms
CMM: Common Management Model
DAIS: Data Acquisition for Industrial Systems
GGF: Global Grid Forum
GSI: Grid Security Infrastructure
IETF: Internet Engineering Task Force
MDS: Monitoring and Discovery Service
Neesgrid: Network for Earthquake Engineering Simulation Grid
Oasis: Organization for the Advancement of Structured Information Standards
OGSA: Open Grid Services Architecture
OGSI: Open Grid Service Infrastructure
W3C: World Wide Web Consortium
WG: Working group
WS: Web services
WSDL: Web Services Description Language
WSDM: Web Services Distributed Management
WSRF: Web Services Resource Framework
--
FROM 162.105.80.*