数据库网格计算

数据库网格计算2023/6/101第一页，共五十九页，编辑于2023年，星期三第1章：网格概述网格的特征网格的最初定义及其他多种定义

与网格有关的标准及组织网格的体系结构2023/6/102第二页，共五十九页，编辑于2023年，星期三第2章OGSA和WSRF本章学习目的：OGSA是什么，在网格中它扮演什么角色；开放网格服务基础设施OGSI（OpenGridServicesInfrastructure）是什么；Web服务技术是什么；构成客户机/服务器应用的传统范例；WSRF是什么；WSRF对OGSA和OGSI有什么影响作用。2023/6/103第三页，共五十九页，编辑于2023年，星期三2.1引言本章内容的安排2.1引言2.2分布式计算的传统范例2.3Web服务2.4OGSA2.5Globus工具箱3（GT3）2.6OGSA-DAI2.7WSRF2.8本章小结2.9进一步的阅读和测试2023/6/104第四页，共五十九页，编辑于2023年，星期三2.2分布式计算的传统范例2023/6/105第五页，共五十九页，编辑于2023年，星期三套接字编程RPC图RPC应用中的数据流控制RPC实现和运行客户机/服务器应用的步骤是：用RPCIDL编写RPC接口程序；使用RPC编译器编译接口程序生成客户机端占位程序和服务器端骨架程序；实现服务器；实现客户机；调用RPC库编译所有代码；启动服务器；启动带有服务器IP地址的客户机。2023/6/106第六页，共五十九页，编辑于2023年，星期三JavaRMI图JavaRMI应用中的数据流控制实现和运行JavaRMI客户机/服务器应用的步骤是：编写RMI接口程序；编写去实现接口的RMI对象；用RMI编译器（rmic）编译RMI对象，生成客户机端占位程序和服务器端骨架程序；编写RMI服务器，用于注册RMI对象；编写RMI客户机；用Java编译器（Javac）去编译所有Java源代码；启动RMI名字服务器（rmiregistry）；启动RMI服务器；启动RMI客户机。2023/6/107第七页，共五十九页，编辑于2023年，星期三DCOM实现和运行DCOM客户/服务器应用的步骤是：编写MIDL接口程序；用接口编译器（Midl）编译接口程序，生成客户端占位程序和服务器端骨架程序；编写COM组件去实现接口；编写DCOM客户端；编译所有的代码；向DCOM服务器注册COM组件；启动DCOM服务器；启动DCOM客户机。2023/6/108第八页，共五十九页，编辑于2023年，星期三

CORBA运行CORBA客户机/服务器应用的步骤是：编写CORBAIDL接口程序；用IDL编译器编译接口程序，生成客户端占位程序和服务器骨架程序；编写CORBA对象去实现接口；编写CORBA服务器去注册CORBA对象；编写CORBA客户机；编译所有的源代码；启动CORBA名字服务器；启动CORBA服务器；启动CORBA客户机。2023/6/109第九页，共五十九页，编辑于2023年，星期三JavaRMI、DCOM和CORBA小结不同特点：在特定实现和特征方面有所不同公共特点：需要接口来唤醒远程对象或组件。对用户隐藏低级通信的复杂性，通过接口定义自动生成客户机端占位程序和服务器端骨架程序。它们使用专有的通信协议，例如，JavaRMI使用JRMP、DCOM使用ORPC、CORBA使用IIOP，去唤醒远程对象或组件。接口定义是二进制格式，这对在接口上产生询问的客户机应用是困难的，例如寻找定义过什么种类的方法、每一种方法的输入/输出、以及怎样更好的使用方法。客户和对象与它们的接口紧紧捆绑在一起，例如客户机部分的变化意味着其他部分也要变化，例如服务器也需要修改。2023/6/1010第十页，共五十九页，编辑于2023年，星期三2.3Web服务Web服务的定义：

本质上讲，Web服务是松散耦合的（客户机/服务器）、具有封装性、与平台和编程语言无关、提供能够在内部网络和Internet上被描述、发布、发现和唤醒的服务器端合成组件。松散耦合：Web服务的实现的改变是自由的，只要服务接口保持不变，不会过度影响该服务的客户端。封装性：Web服务的实现对该服务的客户端是完全不可见的。与平台和编程语言无关：Web服务可以用任何语言实现、可以在任一平台开发。合成：Web服务可以由一定数量的已部署的服务合成而成。服务器端组件：Web服务的安排范围可从一个完整的应用到运行在服务器上的子例程调用。描述：基于XML接口，用于描述一个Web服务能够提供的功能和能力。发布：Web服务可以用服务注册号注册，通过服务注册号可以在Intranet和Internet上存取访问。发现：Web服务客户可以通过检索服务注册和匹配它们的服务请求来发现服务。唤醒：客户可通过标准传输协议绑定一个Web服务，例如HTTP和FTP协议。内部网或Internet：一种Web服务可严格限制在一个单位组织内部可用，或者它能够提供穿过防火墙的访问，用于访问连接到Internet的任何用户。2023/6/1011第十一页，共五十九页，编辑于2023年，星期三2023/6/1012第十二页，共五十九页，编辑于2023年，星期三

SOAPSOAP是简单的、轻量级的通信协议，用于客户机和服务器之间以XML格式在传输层协议之上交换报文，通常是采用HTTP协议。

图2.7SOAP报文的结构2023/6/1013第十三页，共五十九页，编辑于2023年，星期三WSDL数据类型数据类型部分包括与报文交换有关的数据类型定义。<message><message>元素定义服务中可操作的数据元素。每一个报文可以包含一个和多个部分。这些部分类似于在传统编程语言中调用函数或方法的参数。<porttype><porttype>是WSDL文档的核心部分。类似于Java接口或C++类，它定义服务提供的抽象操作集合。每一个操作使用在<message>元素中定义的报文，去描述它的输入和输出。<binding><binding>标识由特定的<porttype>定义的报文和操作的具体协议和数据格式。对给定的<porttype>可以有一个任意的绑定号数字，也就是一个绑定可以是基于文档或使用RPC。在HTTP上的SOAP是最常用的在服务客户和服务本身之间传输报文的机制。<port><port>通过指定一个单个地址的绑定，定义一个惟一的服务端点。<service><service>是一个相关端口的集合。图2.8WSDL文档结构2023/6/1014第十四页，共五十九页，编辑于2023年，星期三UDDIUDDI是服务注册（发布）和发现的工业标准。

UDDI中的数据可以用下列方法组织：白页：包括有关服务提供者的一般信息，例如名字、联系信息和其他标识。黄页：这个信息使用分类（分类法）描述Web服务，并允许其他人基于分类（例如卡车制造厂或卡车销售商）去发现Web服务。绿页：绿页包含有关Web服务的技术信息，通常具有对外的WSDL服务文档说明书，使得客户知道如何与该服务交互。

2023/6/1015第十五页，共五十九页，编辑于2023年，星期三WS-Inspection2023/6/1016第十六页，共五十九页，编辑于2023年，星期三图2.10UDDI和WS-Inspection的服务发现WS-Inspection和UDDI2023/6/1017第十七页，共五十九页，编辑于2023年，星期三Web服务实现当使用Web服务时有三个方面需要考虑：编程模型规定如何编写访问Web服务的客户代码、如何编写服务实现、如何去处理SOAP规范的其他部分，例如头部和附加部分。开发模型是一个框架，用于部署一个服务并提供一个Web服务部署描述符（wsdd文件），来映射该服务的实现到SOAP报文。SOAP引擎接收SOAP报文并调用Web服务实现。实现Web服务应用的三个框架：J2EE、.Net和ApacheAxis。2023/6/1018第十八页，共五十九页，编辑于2023年，星期三J2EEJ2EE[21]是一个开发、建立和部署基于Java应用的标准。它能够用于建立一个传统的Web站点、软件组件，或者数据包应用。

J2EE为Web服务提供下列应用编程接口API：支持XML处理的JavaAPI（JAXP），使用不同的分析算法处理XML文档。支持XML绑定的Java体系结构，使用方案驱动的JavaBean组件类去处理XML文档。支持基于XMLRPC的JavaAPI（JAX-RPC），是RPC的标准。它提供XMLRPC调用API和使用基本级协议与SOAP/HTTP绑定，但是并不局限于HTTP。支持XML报文的JavaAPI（JAXM）和带有Java附加API的SOAP（ASSJ），用标准的方法在Web上发送SOAP报文。支持XML注册的JavaAPI，提供标准的方法与UDDI注册交互。

图2.11采用J2EEJAX-RPC调用Web服务的数据流控制2023/6/1019第十九页，共五十九页，编辑于2023年，星期三ApacheAxisApacheAxis[22]是SOAP引擎，能够用于在客户机和服务之间交换报文。采用Axis的Web服务应用可以按下列步骤实现和启动：编写Java接口；使用Java2WSDL去编译该接口，生成WSDL接口；使用WSDL2Java编译WSDL接口，生成客户端占位程序和服务器端骨架程序；编写一个实现WSDL接口的服务；编写客户机；用javac编译器编译所有代码；编写Web服务部署描述符（wsdd文件）在JakataTomcatWeb服务器中部署该服务；启动Tomcat；启动客户机去调用该服务。图2.12采用Axis调用Web服务的数据流控制2023/6/1020第二十页，共五十九页，编辑于2023年，星期三

Microsoft.Net

.Net是建立Web服务应用的Microsoft平台。

考虑到Web服务的引用，.Net提供三种选择：使用嵌入的.NetSOAP报文类；手工构造一个Web服务侦听者，例如使用MicrosoftXML分析器（MSXML），ASP或因特网服务器应用编程接口（ISAPI）；使用MicrosoftSOAP工具包2.0建立服务侦听，与采用COM实现的服务器进行通信。该工具包能够通过WSDL接口产生一个客户端占位程序，用于客户端与服务器进行通信。2023/6/1021第二十一页，共五十九页，编辑于2023年，星期三Web服务框架具下列优点，可以有助于网格建立：网格要求对在不同种类环境中的动态发现和网格服务的合成提供支持，这是对注册和发现接口定义和端点实现描述很有必要的机制；用于基于特殊（潜在的多重的）接口绑定来动态产生代理。WSDL通过提供一个标准机制支持这个要求，根据它们特定绑定（传输协议和数据编码格式）的具体情况来分别定义接口说明。Web服务技术基于国际公认标准。广泛采用意味着基于Web服务的框架将能够开发大量的工具和扩展服务，例如能够为不同环境产生绑定的WSDL处理程序，举例来说，Web服务引用框架WSIF（WebServicesInvocationFramework）[27]，使用WSDL工作流系统，用于Web服务的主机环境（例如Microsoft.Net和ApacheAxis）。图2.13Web服务核心技术首先服务提供者采用SOAP发布它的服务到UDDI注册中，然后服务请求者（客户）检索注册信息以寻找感兴趣的服务，最终客户通过绑定该服务来请求一个服务。2023/6/1022第二十二页，共五十九页，编辑于2023年，星期三2.4OGSAOGSA是用于建立面向服务的下一代网格系统的事实上的标准。目前，GGF正协调世界范围内的各种力量来完善OGSA规范。OGSA是基于Web服务技术，但又做了些扩展。OGSA通过引入接口和规则在三个领域对Web服务进行了扩展：第一，在网格环境中，服务的动态和潜在瞬时的特征，特定的服务实例会随着工作派遣、随着资源被配置和供应、随着系统状态变化而产生和离开。因此，网格服务需要一些接口去管理它们的创建、消失和生命周期管理。第二，服务的状态性。网格服务拥有属性和与属性联系的数据。在概念上来讲，这类似在面向对象程序设计中传统的对象结构，对象有属性和数据。同样的，Web服务需要扩展去支持与网格服务相联系的状态数据。第三，客户机可订阅它们感兴趣的服务。一旦一个服务发生任何变化，客户机会被通知。这就是从服务器到客户机的一个调用－返回（call-back）操作。2023/6/1023第二十三页，共五十九页，编辑于2023年，星期三图2.14用OGSI建立OGSA相容网格应用程序2023/6/1024第二十四页，共五十九页，编辑于2023年，星期三服务实例语义一个网格服务实例是一个可以动态地创建和明晰消失的网格服务的实例化。可以产生一个服务实例的网格服务被称为服务工厂，一个持续自身服务。客户可以请求一个工厂创建许多服务实例，并且多个客户可以访问同一个服务实例。

图2.15调用多网格服务实例的作业提交2023/6/1025第二十五页，共五十九页，编辑于2023年，星期三服务数据语义服务数据是封装为服务数据元素SDE（ServiceDataElements）的XML元素的集合。服务数据用于描述有关服务实例的信息和它们的运行时状态。服务工厂可以创建许多服务实例，每个服务实例有一个服务数据集。一个服务数据集可以包含零个或多个SDE。每一个SDE可以具有不同的数据类型。2023/6/1026第二十六页，共五十九页，编辑于2023年，星期三OGSA端口类型OGSA提供下列可扩展的WSDL端口类型的接口去定义网格服务。在OGSA中，GridService接口必须由所有的网格服务实现，而其他一些接口是可选的。OGSA支持下列接口。

GridService端口类型Factory端口类型HandleResolver端口类型注册（Registration）端口类型通知源（NotificationSource）/通知宿（NotificationSink）端口类型2023/6/1027第二十七页，共五十九页，编辑于2023年，星期三图2.17OGSA网格服务结构2023/6/1028第二十八页，共五十九页，编辑于2023年，星期三2.5GT3图2.18GT3结构2023/6/1029第二十九页，共五十九页，编辑于2023年，星期三宿主环境宿主环境是一个特定的执行环境，不仅阐述编程模型和语言，而且也说明能够用于实现网格服务的开发和调试工具。它也说明一个网格服务实现如何满足有关网格服务语义约束。GT3支持下列4个Java宿主环境。嵌入的：允许OGSI宿主环境嵌入到任何现有的J2SE应用中的库。独立的：轻量级J2SE服务器用于宿主网格服务。J2EEWeb容器：在一个Web服务器中的OGSI宿主环境，可以由任何JavaServlet兼容引擎构成，例如JakartaTomcat。J2EEEJB容器：代码产生器允许给出有状态的J2EE实体和作为OGSI兼容网格服务的会话JavaBean。2023/6/1030第三十页，共五十九页，编辑于2023年，星期三Web服务引擎

Web服务引擎负责在客户机和服务之间的SOAP报文交换。GT3目前使用ApacheAxis作为它的SOAP引擎，管理SOAP报文交换。2023/6/1031第三十一页，共五十九页，编辑于2023年，星期三网格服务容器网格服务容器运行在Web服务引擎的上面，为宿主的各种各样服务提供一个运行时环境。与Web服务比较，网格服务容器覆盖三个主要功能领域：轻量级服务，支持抽取和推送信息流两者的服务内省和发现。有状态的服务实例的动态部署和软状态管理，使用一个扩展的分析机制可以用于全局参考。传输独立于网格安全基础设施GSI（GridSecurityInfrastructure）[36]，支持信任授权、报文签名和加密；还有认证。2023/6/1032第三十二页，共五十九页，编辑于2023年，星期三GT3核心服务OGSI实现安全基础设施系统级服务2023/6/1033第三十三页，共五十九页，编辑于2023年，星期三GT3基本服务GT3中的资源管理GT3索引服务

GT3中可靠文件传输2023/6/1034第三十四页，共五十九页，编辑于2023年，星期三GT3中的资源管理GT3GRAM模型图2.19GT3中的MMJFS、LMJFS和MJS图2.20GT3中提交作业的数据流2023/6/1035第三十五页，共五十九页，编辑于2023年，星期三GT3GRAM模型的优势有效的资源使用：在GT3中，具有不同用户账户的使用者可以共享一个MMJFS服务或使用一个由MMJFS为作业提交唤醒的LMJFS。LMJFS仅在用户宿主环境生命期内是有效的。一旦用户完成对它的使用，它可以被释放。这有助于资源有效使用，从而导致在服务管理中性能的改进。非授权服务：由于网络服务接受和处理外部通信，因此网络服务可能受如逻辑错误、缓冲区溢出以及类似原因的连累。去掉这些服务的特权可以降低由于最小化特权获取而引起的连累影响。最小限度特权编码：特权编码限制到两个程序，GRIM和SetuidStarter。这些程序设计允许它们有效率地审计，并会减少不怀好意去得到特权授权使用它们的机会。客户端授权：GRIM允许客户机不仅验证资源（MJS在其上运行），而且可验证账户（MJS正在其中执行）。这样，一个客户机可以防止地址欺骗或社会工程哄骗（可能误导用户连接，更严重可能是分派证书给一个MJS，而此MJS并不是它们想要的）。2023/6/1036第三十六页，共五十九页，编辑于2023年，星期三GT3索引服务索引服务[46]使用一个扩展的框架去管理基于GT3网格系统的静态和动态数据。它提供下列功能：通过服务数据提供者组件实现动态服务数据创建和管理。从多个实例来的服务数据聚合。网格服务实例的注册。图2.21GT3索引服务结构2023/6/1037第三十七页，共五十九页，编辑于2023年，星期三GT3中可靠文件传输GT3可靠文件传输RFT（ReliableFileTransfer）[47]服务提供控制和监控使用GridFTP[48]的第三方文件传输。控制传输的客户机以宿主的形式放置在一个网格服务里面。GT3RFT担保文件传输是可靠的。例如，如果文件传输被中断（如由于网络故障），它可以在出现故障的瞬间重新启动文件传输，而不是重新开始所有文件传输。

2023/6/1038第三十八页，共五十九页，编辑于2023年，星期三GT3编程模型

GT3编程特点:GT3使用GWSDL去定义一个网格服务接口。一个GWSDL是一个具有所有OGSI定义类型、报文、端口类型和名字空间的WSDL。GWSDL使用<gwsdl:portType>标签替代在标准WSDL中的<portType>标签。Web服务部署描述符WSDD（WebServicesDeploymentDescriptor）包括与部署一个网格服务有关的信息，例如网格服务的名字、网格服务实例的名字，以及网格服务实例的基本类。GT3将所有的编译Java代码连同相关文件（如网格服务的WSDD文件）打包为一个GAR文件以方便服务的部署。GAR是一个特殊种类的JAR。网格服务可以是能动态的创建和明晰地撤消的瞬时服务。网格服务是与服务数据相联系的有状态服务。网格服务可以通知对感兴趣的事件有订阅的客户机。2023/6/1039第三十九页，共五十九页，编辑于2023年，星期三图2.22实现GT3应用中的数据流控制2023/6/1040第四十页，共五十九页，编辑于2023年，星期三GT3中的服务器端组件图2.23GT3的服务端组件2023/6/1041第四十一页，共五十九页，编辑于2023年，星期三GT3中的客户机端组件图2.24GT3的客户端组件2023/6/1042第四十二页，共五十九页，编辑于2023年，星期三2.6OGSA-DAI图2.25OGSA-DAI在OGSA中的位置2023/6/1043第四十三页，共五十九页，编辑于2023年，星期三OGSA-DAI端口类型GDSPortType端口类型GridDataPerform端口类型GridDataTransport端口类型GridDataServiceFactory端口类型DAIServiceGroupRegistry端口类型2023/6/1044第四十四页，共五十九页，编辑于2023年，星期三OGSA-DAI功能

GDS实例的生命期管理服务注册/取消注册服务发现服务通知通知的步骤：1、一个客户机使用NotificationSource::Subscribe()方法向DAISGR订阅以指定感兴趣事件通知。在订阅中，它指定实现NotificationSink接口的通知汇集点服务的位置.2、DAISGR创建一个通知订阅服务，实现NotificationSubscription接口去管理订阅。3、DAISGR告知客户机该通知订阅NotificationSubscription的标识。4、客户机通过GridService::FindServiceData()方法查询通知订阅服务，去管理它的订阅，例如它的生命周期管理。5、一旦DAISGR的状态中有一些变化，它将通过NotificationSink::DeliverNotification()方法告诉通知汇集点（sink）服务。6、通知汇集点服务将给客户机发送通知报文。图2.27OGSA-DAI中的服务通知2023/6/1045第四十五页，共五十九页，编辑于2023年，星期三在OGSA-DAI中的服务交互

图2.28OGSA-DAI服务间的交互2023/6/1046第四十六页，共五十九页，编辑于2023年，星期三1、启动一个网格服务容器，读一个serverconfig.wsdd文件。这个serverconfig.wsdd文件允许网格服务容器去访问已部署的服务的信息，以及在服务名和相联系的类之间的映射。2、网格服务容器基于在serviceconfig.wsdd文件中指定的GSH来创建一个持续的DAISGR。3、网格服务容器基于在serviceconfig.wsdd文件中指定的GSH来创建一个持续的GDSF。4、GDSF用ServiceGroupRegistration::Add()方法在DAISGR注册自己。5、客户机使用GridService::FindServiceData()方法查询DAISGR客户机选择一个已注册的GDSF。6、DAISGR返回所选择的GDSF的GSH。7、客户机可以查询GDSF的服务数据元素，去获得它的配置信息。8、客户机调用GDSFFactory::createService()方法，去创建一个GDS实例。9、GDSF创建GDS实例。10、GDSF向客户机返回GDS实例的GSH。11、客户机使用GridService::FindServiceData()方法查询新产生的GDS实例的服务数据元素，去建立它的配置和描述GDS-Perform文档的计划，该文档可以通过GridDataPerform::perform()方法提交。12、客户机向GDS实例提交GDS-Perform文档。13、GDS实例访问一个数据库去获得数据，并且产生一个GDS-Response文档。14、GDS实例向客户机返回GDS-Response文档。15、客户机通过GridService::Destroy()方法撤消GDS实例。2023/6/1047第四十七页，共五十九页，编辑于2023年，星期三OGSA-DAI和DAIS在GGF内的数据库访问和集成服务DAIS（DatabaseAccessandIntegrationServices）工作组[51]为网格数据库服务寻找促进OGSA的兼容标准，起初焦点在提供对现有的、自治管理数据库的一致性访问。它并没有追求去开发新的数据储存系统，而使这样的系统在网格框架内更容易个别地、全体地使用。OGSA-DAI是包括爱丁堡、曼切斯特和纽卡斯尔大学，以及由IBM和Oracle企业参与工作的协作编程。它的主要的目的是给出开放源代码数据库访问和集成中间件，以满足英国电子科学学会开发与网格有关应用的需要。它的研究领域包括一般网格数据服务定义和发展，提供对保存在关系数据库管理系统中的数据以及保存在XML仓库中的半结构化数据的访问和集成。OGSA-DAI代表英国电子科学学会核心计划对扩展包括数据库互操作性的网格模型也给出重要的贡献。OGSA-DAI与DAIS工作组紧密合作，并且打算把该软件用于DAIS标准的参考实现。2023/6/1048第四十八页，共五十九页，编辑于2023年，星期三2.7WSRFWSRF概述WSRF：Web服务资源框架（WebserviceResourceFramework），WSRF是一组WS规范。它引入WS-Resource来对Web服务上下文中的状态信息进行模型化和管理。

2023/6/1049第四十九页，共五十九页，编辑于2023年，星期三WS规范：WS-ResoucreLifetime（WS资源生命周期）WS-ResourceProperties（WS资源属性）WS-Notification（WS通知）WS-BaseFaultsWS-ServiceGroupWS-RenewableReferences2023/6/1050第五十页，共五十九页，编辑于2023年，星期三WS-Resource概念一个WS-Resource具有下列特点：它是一个有状态的资源，可以用于一个交换报文的Web服务的数据上下文。它可以被创建、标识和撤消。一个WS-Resource在同一个Web服务中或在不同的Web服务中可以有许多标识。有状态的WS-Resource类型可以与Web服务接口定义联系起来，允许通过它的服务接口对WS-Resource做好结构（well－formed）的查询，并且有状态WS-Resource的状态可以通过服务报文交换进行查询和修改。2023/6/1051第五十一页，共五十九页，编辑于2023年，星期三隐式的WS-Resource模式术语“隐式”意思指当客户机访问Web服务时，Web服务将返回一个WS-Addressing[60]端点参照，通常引用与Web服务相联系的WS-Resource。每一个WS-Resource有一个管理它的状态的标识（ID）。客户机访问的WS-Resource的ID将被自动的封装在端点参照中并返回给客户机。一个WS-ResourceID仅被Web服务用作一个隐含输入，去定位一个特定WS-Resource，它对客户机是不透明的。术语模式被用于指出Web服务和有状态的WS-Resource之间的关系根据一系列的约定加以整理，这些约定建在现存的Web服务技术之上，特别如XML、WSDL和WS-Addressing。2023/6/1052第五十二页，共五十九页，编辑于2023年，星期三图2.29通过Web服务访问有状态WS-Resource2023/6/1053第五十三页，共五十九页，编辑于2023年，星期三图2.30WS-Addressing端点参考例子图2.31绑定与WS-Resource相关Web服务的SOAP报文2023/6/1054第五十四页，共五十九页，编辑于2023年，星期三WSRF和OGSI/GT31.WSRF与OGSI的比较WSRF相对OGSI的优点WSRF的定义主要受一些想法的激励，想集成Web服务体系结构中的最新发展，特别如WS-Addressing，它的设计也解决了来自Web服务团体的对OGSI1.0版本的三个指责：OGSI是在一个规范中带有太多定义的重量级的规范。WSRF把OGSI功能划分成为一组规范。OGSI不能与现存的Web服务工具包一起很好的工作。OGSI使用XML规划扩展，例如，存在时常发生的xsd:any、属性使用。它也使用许多“面向文档”的WSDL操作。这些特征引发一些问题，例如，JAX-RPC。WSRF在某种程度上减少XML规划的使用。OGSI把一个有状态的资源刻画成为一个封装资源状态的Web服务，把服务的标识、生命周期和资源状态耦合在一起。WSRF重新清晰的说明基本的OGSI体系结构，给出在无状态Web服务和服务在其上运行的有状态资源之间的清晰的区别。OGSI相对WSRF的优点具有面向对象范例O