级别： 初级 Joshy Joseph (joshy@us.ibm.com), 软件工程师
2003 年 5 月 01 日 本文介绍了开放网格服务基础结构（Open Grid Service Infrastructure，OGSI）规范，包括命名和引用网格服务、使用常见于所有网格服务的接口和行为，以及指定其它接口、行为和扩展。文中提供的示例实现了一个简单的服务 — AcmeSearchEngine 服务。
简介
随着随需应变（on-demand）计算和自主计算的发展，网格计算已经吸引了技术社区的注意力。正如
The Anatomy of the Grid（请参阅
参考资料）一书所介绍的那样，网格计算是动态多机构虚拟组织中的一个协调的共享资源和解决问题的过程。在随需应变和自主（自我调节的）计算环境中，网格计算特别有趣。
使用较少的集中控制，同时又要用最高质量的服务来实现跨众多虚拟组织共享的资源之间的高度交互，这是一项技术挑战。全球网格论坛（Global Grid Forum，GGF）必须设法通过一组软件体系结构标准和其它框架倡议（请参阅参考资料）来使这一资源共享的过程标准化。GGF 已经着手进行一些体系结构标准化工作，以便提供更佳的软件互操作性、高级别的安全性、资源定义和发现、策略和可管理性。开放网格服务体系结构（Open Grid Service Architecture，OGSA）就是这样一个体系结构标准化过程。
该体系结构的基本组件是开放网格服务基础结构（OGSI）。这是一项基于新兴的 Web 服务标准的网格软件基础结构标准化工作，用于为 OGSA 软件组件提供最大的互操作性。
网格服务
网格服务实例基于 OGSI 规范（请参阅
参考资料），它是一个 Web 服务，符合用 Web 服务描述语言（WSDL）表达为服务接口、扩展和行为的一组约定。该规范定义了下列内容：
 |
OGSI 规范版本
本讨论以 GGF OGSI WG 于 2003 年 3 月 13 日发布的建议最终草案为基础。由于这是一个工作草案，因此当 OGSI 规范到达最终接受阶段时，可能会对它进行更改。
|
|
- 如何命名和引用网格服务实例
- 常见于所有网格服务的接口和行为有哪些
- 如何指定其它接口、行为及其扩展
下图显示了 AcmeSearchEngine 服务的一个简单服务实现。请注意，现实世界中的网格服务实际上在资源共享、提供和管理等方面更为复杂。AcmeSearchEngine 服务是一个有状态的 Web 服务，其网格服务行为如图 1 所示。
图 1 中的对象图引入了下列网格服务概念：
- 为有状态的 Web 服务实现提供 AcmeSearchEngine 公共接口，以访问服务和它的状态
- 支持接口继承。AcmeSearchEngine 服务实现 AcmeSearchEngine 接口，后者则又继承 GridService 接口和 AbstractSearchEngine 接口。
- 通过在 OGSI（GridService 接口）中定义的接口，指定常见的网格服务行为（状态数据和操作）
- 通过 GridService 接口的 findServiceData 将状态信息发布到客户机
- 通过 GridService 接口的 findServiceData 查看服务的状态和元数据
由 OGSI 定义的服务需求之一就是能够使用 OGSI 描述模型（它是 Web 服务 WSDL 和 OGSI GWSDL 的组合）描述上述概念。
本文讨论了 OGSI 规范的核心概念，并演示了如何使用这些概念来描述和实现带有所需网格服务行为的网格服务。但是，具体的实现将留待将来的文章去介绍。
OGSI 及其 WSDL 使用
OGSI 创建了一个新的 WSDL 扩展模型，名为 GWSDL。描述基于 OGSI 的 Web 服务有两项核心需求：
- 描述接口继承的能力，这是大多数分布式对象系统的核心概念。
- 利用接口定义描述其它信息元素的能力。这样的一种信息元素称为
服务数据，将在稍后讨论。
|
合并 GWSDL 和 WSDL 1.2
OGSI 工作组（OGSI Work Group）成员有一个共识，即在所有方面都要遵从 WSDL 1.2 规范。这一共识可能会在 WSDL 1.2 到达建议书阶段时排除掉由 OGSI 引入的新模式和名称空间（GWSDL）。因此，为了当前使用以及向后兼容的目的，工具和应用程序的开发人员可能希望使用 GWSDL 扩展。除了 WSDL 1.2 建议书以外，您还应当熟悉用于互操作 Web 服务和网格服务的 Web 服务-互操作性（Web Services-Interoperability，WS-I）基本概要最佳实践指南（请参阅
参考资料）。
|
|
跟大多数 Web 服务一样，OGSI 服务使用 WSDL 作为服务描述机制，但是当前的 WSDL 1.1 规范在其 portType 定义中缺乏这两种能力。WSDL 1.2 工作组同意通过 portType 继承和用于 portType 的开放内容模型来支持这些功能。作为一个临时决定，OGSI 在新的名称空间定义下开发了新的用于 portType 定义（从普通的 WSDL 1.1 模式 portType 类型扩展）的模式 — GWSDL。
OGSI 的另一个重要方面是为 portType 操作采用的命名约定，以及缺乏对运算符重载的支持。在这些情形中，OGSI 遵从的约定与建议的 WSDL 1.2 规范中描述的约定相同。请参阅 OGSI 规范和 WSDL 1.2 规范，以获取有关扩展支持及操作命名的详细信息。
服务数据
服务数据声明是一种通过已知模式公开表达服务的可用状态信息的机制。这一概念并不仅限于网格服务。任何有状态的 Web 服务都可以通过服务数据概念声明其公共可用的状态信息。
服务数据结构
清单 1 表明
服务数据元素（SDE）是作为 WSDL portType 可扩展性模型的一部分声明的。
<wsdl:definitions xmlns:tns="abc" targetNamespace="mynamespace">
<gwsdl:portType name="AbstractSearchEngine">
<wsdl:operation name="search" />
--------------------
<sd:serviceData name="cachedURL" type="tns: cachedURLType"
mutability="mutable" nilable="true", maxOccurs="1" minOccurs="0"
modifiable="true"/>
</gwsdl:portType>
</wsdl:definitions>
|
表 1 显示了一组为该服务数据元素定义的属性。
表 1：有关服务数据元素属性的详细信息
|
SDE 属性
|
描述和缺省值
| | name | 这是目标名称空间中一个必需的属性，它带有唯一的可标识名称。 | | type | 定义了服务数据值的 XML 模式类型。 | | maxOccurs | 该属性表明可以出现在服务实例的 SDE 值或 portType staticServiceDataValues 中的 SDE 值的最大数。缺省值 = 1。 | | minOccurs | 该属性表明可以出现在服务实例的 SDE 值或 portType staticServiceDataValues 中的 SDE 值的最小数。如果 minOccurs = 0，那么该 SDE 就是可选的。缺省值 = 1。 | | nilable | 表明 SD 值是否可以包含空（nil）值。可以将这个 SDE 值声明为 <sd:cachedURL xsd:nil="true"。缺省值 = false。 | | modifiable | 这是一种指定只读或只写服务数据元素的机制。如果是可写的，那么您可以使用 setServiceData 根据 mutability、最小和最大约束来更改其 SDE 值。缺省值 = false（缺省情况下，所有 SDE 都是“read only”）。 | | mutability | 表明是否以及如何更改 serviceData 元素的值。可能的值有“static”|“constant”|“extendable”|“mutable”（请参阅表 4 以获取详细信息）。缺省值 = “extendable”。 |
该属性集是可扩展的（通过模式的 SDE 的开放属性声明）。因此，服务可以通过属性可扩展性添加更多有关服务数据的语义信息。稍后在介绍生命周期属性时将提供该扩展性的一个示例。目前，记住这些属性的缺省值将有助于您理解网格服务的良好状态管理框架，并有助于您定义这样一个框架。表 1 表明 SDE 唯一必需的属性是“name”属性。
|
xsd:element 和服务数据元素之间的比较
SDE 声明类似于 xsd:element 声明，但是 SDE 声明是对 xml 模式 xsd:element 的一个限制，该限制规定只使用 xsd:element 声明的六个特性（annotation、name、type、出现次数（minOccurs 和 maxOccurs）、nillable 和开放属性模型），并且使用开放属性模型添加了两个新属性“mutability”和“modifiable”。
|
|
服务数据的类型
有两种类型的服务数据元素：
-
静态：
这种元素作为服务的接口定义（GWSDL portType 定义）的一部分进行声明
-
动态：
这类元素被动态地添加到服务实例。该行为是特定于实现的。客户机可能知道服务数据的语义（类型和含义），或者您可以从某个地方获取信息。例如，为了处理动态 SDE 值，您可能需要从远程位置获取 SDE 的模式。
为了支持这两种服务数据，客户机必须在运行时期间获取某个服务中服务数据元素的完整列表。客户机可以使用网格服务（该服务将静态和动态 SDE 元素的列表保存在其 serviceData SDE 中）的 findServiceData 方法查询服务，以获取服务数据元素的当前列表。
服务数据和 WSDL portType 继承
网格服务可以支持按照 WSDL 1.2 所定义的 portType 继承模型，但是该继承模型会影响与继承链中每个 portType 相关的服务数据声明。清单 2 显示了 portType 层次结构图和 WSDL 声明的工作原理。
<gwsdl:portType name="BasePT">
<sd:serviceData name="baseSD" type="xsd:string" minOccurs="1"
maxOccurs="1" mutability="static" />
<sd:serviceData name="myServiceData" type="xsd:string" minOccurs="1"
maxOccurs="1" mutability="static" />
<sd:staticServiceDataValues>
<baseSD>base</baseSD>
</sd:staticServiceDataValues>
</gwsdl:portType>
<gwsdl:portType name="DerivedPT1" extends="BasePT">
<sd:serviceData name="derivedSD1" type="xsd:string" minOccurs="1"
maxOccurs="1" mutability="static" />
<sd:staticServiceDataValues>
<derivedSD1>derived 1</ derivedSD1>
</sd:staticServiceDataValues>
</gwsdl:portType>
<gwsdl:portType name="DerivedPT2" extends="BasePT">
<sd:serviceData name="derivedSD2" type="xsd:string" minOccurs="1"
maxOccurs="1" mutability="static" />
<sd:staticServiceDataValues>
<derivedSD2> derived 2</ derivedSD2>
</sd:staticServiceDataValues>
</gwsdl:portType>
<gwsdl:portType name="MostDerivedPT" extends=" DerivedPT1 DerivedPT2">
<sd:serviceData name="mostDerivedSD" type="xsd:string" minOccurs="1"
maxOccurs="1" mutability="static" />
<sd:serviceData name="myServiceData" type="xsd:string" minOccurs="1"
maxOccurs="1" mutability="static" />
<sd:staticServiceDataValues>
<derivedSD>base</ derivedSD>
</sd:staticServiceDataValues>
</gwsdl:portType>
|
下面是根据清单 2 中的 portType 和服务数据的示例继承定义得出的一组指南：
- 该服务包含了在由该服务实现的 portType 中定义的所有服务数据的联合。表 2 显示了服务数据聚集是如何在继承中发生的。
表 2：有关服务数据元素属性的详细信息
|
如果服务实现：
|
那么其服务数据集包含：
| | BasePT | BaseSD 和 myServiceData | | DerivedPT1 | derivedSD1 和 myServiceData | | DerivedPT2 | derivedSD2 和 myServiceData | | MostDerivedPT | MostDerivedSD、myServiceData、derivedSD2、derivedSD1 和 baseSD |
- 该聚集基于服务数据元素的名称（QName），因此只有一个具有相同 QName 的服务数据元素出现在服务中。清单 2 在 MostDerivePT 中只使用了一个 myServiceData 元素，因为 BasePT 的 myServiceData 和 MostDerivedPT 的 myServiceData 具有相同的本地名称，并且属于同一个目标名称空间。
- 必须保存服务数据元素上的基数需求（minOccurs 和 maxOccurs）。
请参阅 OGSI 规范，以获取有关这些基数约束的更多示例和最佳实践指南。您还可以查看有关如何定义 SDE 的抽象 portType，以及实现和工具应该如何检查基数违例等问题的信息。
服务数据元素和 mutability 属性
服务数据元素的最复杂概念之一就是其 mutability 属性。表 3 显示了可能的 mutability 属性，以及由这些属性而产生的 SDE 值。它还显示了如何定义和初始化这些值。
表 3：有关服务数据元素 mutability 属性的详细信息
|
SDE mutability 属性值
|
SDE 值描述
|
如何定义和初始化这个 SDE 值
| | static | 类似于语言类成员变量。所有 portType 声明都带有该服务数据值。 | 在 WSDL portType 中使用 staticServiceDataValues 来定义和初始化。 | | constant | 该 SDE 值是常量，一定不能更改。 | 该 SDE 值是在网格服务创建时分配的（这是一种运行时行为）。 | | extendable | 类似于追加值的概念。一旦添加，这些值就归 SDE 所有，并且追加新值。 | 通过编程的方式追加新的 SDE 值。在保持旧值的同时追加新值。 | | mutable | 可以除去这类 SDE 值，并添加其它值。 | 通过编程的方式（setServiceData）可以更改 SDE 值，以及添加新值。 |
服务数据元素和生命期属性
除了以上讨论的明确的服务数据特性外，在规范中还有一个“隐藏”的概念，它是关于与服务数据元素相关联的生命期特性的。该概念是隐藏的，因为它只是一个您可能会忽略的建议。但是，优秀的设计、程序和工具应当注意到该特性。
服务数据元素代表了对服务实例动态状态的实时观测。这种实时观测迫使客户机理解状态表示的有效性和可用性（某些服务数据元素，特别是动态 SDE，它们的生命期可能是有限的）。如果有与 SDE 相关联的生命期信息，那么它可以帮助客户机确定 SDE 是否可用和有效，并且可以帮助确定何时重新验证 SDE（客户机端服务数据高速缓存重新验证）。
根据上述需求，该规范提供了三种生命期特性：
- 该元素内容有效的起始时间（ogsi:goodFrom）
- 该元素内容有效的截止时间（ogsi:goodUntil）
- 该元素本身可用的截止时间（ogsi:availableUntil）
前两个是与内容的生命期有关的特性，而 availableUntil 属性定义了元素本身的可用性。
根据规范，这些值是 SDE 元素和 SDE 值的可选属性，但是推荐将它们包含在用于服务数据声明的类型设计 XML 模式中。清单 3 包含了服务数据声明（myPortType）、它的类型（myType），以及通过开放内容 XML 模式类型属性声明（##any）包含的这些生命期属性。
清单 3
<wsdl:types>
<xsd:complexType name="myType">
<xsd:sequence>
<xsd:element name="myElem" type="xsd:string"/>
</xsd: sequence >
<anyAttribute namespace="##any" />
</xsd:complexType>
</wsdl:types>
<gwsdl:portType name ="myPortType">
<sd:serviceData name="mySDE" type="myType" />
.........
</gwsdl:portType>
|
清单 3 中的服务数据声明可以包含下列值：
<sd:serviceDataValues>
<mySDE goodFrom="2003-04-01-27T10:20:00.000-06:00"
goodUntil="2003-05-20-27T10:20:00.000-06:00"
availableUntil="2004-05-01-27T10:20:00.000-06:00">
<myElem goodUntil="2003-04-20-27T10:20:00.000-06:00" >
test
</ myElem>
</ mySDE>
</sd:serviceDataValues>
|
在清单 3 中，SDE 值中的子元素（myElem）可以覆盖 goodUntil 生命期特性，以获得一个早于其父元素（mySDE）的生命期时间的新时间。SDE 元素模式的属性扩展（anyAttribute）和 SDE 值的 XML 类型模式使得覆盖特性成为可能。请参阅 OGSI 规范，以了解更详细的讨论。
下面是使用该编程模型的几点好处：
- 提供了服务状态的聚集视图，而不是单独的状态值或特性
- 提供了数据的以文档为中心的视图（XML 文档），因此避免了用于状态访问的特定方法
- 显示了在支持动态状态信息和服务状态内省（introspection）方面的灵活性
- 提供了有关状态特性的生命期和订阅支持
- 支持状态数据信息元素和值的动态构造
网格服务实例句柄、引用和使用模型
使用 OGSI 规范实现的所有网格服务都包含下列内容：
- 一个或多个网格服务实例句柄（Grid service instance handle，GSH）。这些句柄唯一地标识网格服务实例，该实例在服务的整个生命过程中都是有效的。但是句柄所携带的信息不足以使客户机与服务实例直接通信。服务 GSH 基于 URI 方案（例如 http://）和特定的信息（例如 abc.com/myInstance）。
- 客户机必须以下述三种方法之一将 GSH 信息解析成特定于服务的网格服务引用（Grid Service Reference，GSR）（将在下一节讨论该服务引用）：通过自身、通过使用由服务提供程序（一个实现 HandleResolver portType 的 HandleResolver 服务）提供的机制，或者通过委派给第三方解析器。
- 一个或多个网格服务引用（GSR）。客户机可以通过使用 GSR 访问网格服务，GSR 可被当成是指向特定网格服务实例的指针。GSR 的格式特定于客户机用来与服务通信的绑定机制。这些绑定格式的示例有，针对使用远程方法调用／因特网 ORB 间协议（Remote Method Invocation/Internet Inter-ORB Protocol，RMI/IIOP）的客户机的可互操作对象引用（Interoperable Object Reference，IOR），以及针对使用 SOAP 协议的客户机的 WSDL。
- 网格服务实例可能拥有一个或多个可用的 GSR。这些 GSR 与不同于服务生命周期的生命周期相关联。当 GSR 不再有效时，客户机应当使用可用的 GSH 获取到服务的引用。请注意，规范推荐为服务使用 GSR 的 WSDL 编码。该引用包含 WSDL 定义元素（带有一个服务）作为子元素。
作为网格服务的开发人员，您应当知道由规范定义的名为服务定位器（service locator）的另一个有用构造。这是一个定位器类，带有由服务实现的 0 个或多个 GSH、0 个或多个 GSR 以及 0 个或多个 portType（由 portType QName 标识）。
|
服务生命周期和软状态（soft-state）方法
软状态方法与网格服务生命周期管理有关。每个网格服务都有一个由服务创建程序或工厂设置的终止时间。具有适当权限的客户机可以使用该终止时间信息来检查服务的可用性（租用期），并且可以通过将带有新终止时间的持活（keep-alive）消息发送给服务来请求延长当前的租用时间。如果服务接受该请求，就会把租用时间延长为由客户机请求的新终止时间。这个软状态生命周期是由服务相应的安全性和策略决策控制的，并且服务具有控制该行为的权限（例如，某个服务可以任意终止一个服务，或者可以延长它的终止时间，即使客户机保持着服务引用）。还有一点需要牢记，无论是真正破坏一个服务还是只是使其不可用，都是由服务托管环境来决定的。
|
|
托管环境管理网格服务的生命周期（如何及何时创建服务、如何及何时破坏服务）。OGSI 规范并不规定该行为。例如，一个基于 Enterprise Java Bean（EJB）的基本网格服务与 EJB 规范定义的服务具有相同的生命周期特性、可管理性接口和策略。下面是几个由 OGSI 定义的生命周期事件和服务创建模式，来为网格服务的客户机提供帮助：
- 常用的网格服务创建模式是通过网格服务工厂接口（将在下面讨论）及其 createService 操作定义的。服务可以决定是否依据为服务定义的策略来支持这种行为。
- 定义了两种析构（destruction）机制：
- 调用显式的析构操作（对 GridService portType 执行破坏操作）。
- 使用服务支持的软状态机制（基于服务的终止时间属性）。
网格服务接口
网格服务接口是由 OGSI 规范描述的。本文介绍了基本的和重要的信息：服务接口行为、消息交换和接口描述。
按它们的功能分，有三组接口。表 4、5 和 6 显示了接口名称、描述、为这些接口定义的服务数据，以及预定义的静态服务数据元素。
表 4：支持网格服务行为、服务数据元素和静态服务数据值的 portType
|
PortType 名称
|
接口描述和操作
|
由该 portType 定义的服务数据元素
|
缺省的服务数据（静态）值
| | GridService（必需） | 所有网格服务都实现该接口，并提供下面这些操作和行为。
操作
findServiceData
setServiceData
requestTerminationTimeAfter
requestTerminationTimeBefore
destroy
| 接口
serviceDataName
factoryLocator
GridServiceHandle
GridServiceRefrence
findServiceDataExtensibility
setServiceDataExtensibility
terminationTime
| <ogsi: findServiceDataExtensibility inputElement="queryByServiceDataNames" />
<ogsi: setServiceDataExtensibility
inputElement="deleteByServiceDataNames" />
| | Factory（可选） | 用于创建新的网格服务。
操作
1.createService
| 1.createServiceExtensibility | 无 | | HandleResolver（可选） | 提供将 GSH 解析成 GSR 的机制的服务
操作
1.FindByHandle
| handleResolverScheme | 无 |
在表 4 的接口中，所有网格服务都必须实现 GridService portType 及其行为。该接口及其相关的服务数据集提供了特定于服务的元数据信息，您可以将该信息用于动态服务内省。
第二组 portType 为网格服务创建了通知框架。
表 5：支持网格服务通知框架、服务数据元素和静态服务数据值的 portType
|
PortType 名称
|
接口描述和操作
|
由该 portType 定义的服务数据元素
|
缺省的服务数据（静态）值
| | NotificationSource（可选） | 该接口使客户机能够订阅基于服务数据值变化的通知。
操作
1.subscribe
| notifiableServiceDataName
subscribeExtensibility
| <ogsi: subscribeExtensibility
inputElement="subscribeByServiceDataNames" /> | | NotificationSink（可选）
| 实现该接口使网格服务实例能够接收基于订阅的通知消息。
操作
1.deliverNotification
| 无 | 无 | | NotificationSubscription（可选） | 调用 NotificationSource 的订阅，从而创建订阅网格服务。
操作
未定义
| subscriptionExpression
sinkLocator
| 无 |
关于通知过程，需要记住以下这些概念：
- 实现 NotificationSink portType 的服务和客户机并不一定要是网格服务（无需实现 GridService portType）。
- 订阅网格服务是在运行时创建的。客户机使用订阅网格服务来管理通知进程的生命周期。
第三组 portType 提供了网格服务的分组概念。网格服务可以根据某些分类方案来分组，它们也可以使用简单的聚集机制。请注意，表 5 中的 MembershipContentRule 服务数据可用于分类机制。这个“规则”服务数据用于限制组中网格服务的成员资格。该规则指定下列内容：
- 成员网格服务必须实现的接口列表
- 0 个或多个可通过 QName 标识的内容，这些内容是成为该组成员所必需的。（QName 的内容是使用 ServiceGroupEntry 列出的；请参阅表 6）。
该服务数据的 mutability 值为“constant”，因此这些规则是在 ServiceGroup 服务启动时由运行时创建的（在大多数情况下）。
表 6：支持网格服务分组行为、其服务数据元素和静态服务数据值的 PortType
|
PortType 名称
|
接口描述和操作
|
由该 portType 定义的服务数据元素
|
缺省的服务数据（静态）值
| | ServiceGroup（可选） | 这是一个抽象接口，用于表示 0 个或多个服务的分组。该接口继承 GridService portType。
操作
未定义，但是可以使用 GridService portType 中定义的操作。
| MembershipContentRule
entry
| 无 | | ServiceGroupRegistration（可选）
| 该接口继承 ServiceGroup 接口，并提供了管理 ServiceGroup 的操作，包括将服务添加到组，以及从组删除服务。
操作
add
remove
| addExtensibility
removeExtensibility
| <ogsi: removeExtensibility
inputElement=
"matchByLocatorEquivalence" />
| | ServiceGroupEntry（可选）
| 这是 ServiceGroup 单个项的表示，它是通过 ServiceGroupRegistration 的“add”操作创建的。每项都包含到成员网格服务的服务定位器，以及有关由服务组成员规则（content）定义的成员服务的信息。
操作
未定义
| memberServiceLocator
content
| |
网格服务接口和操作可扩展性
由该规范引入的另一个有趣特性是可扩展操作的概念，该操作是通过使用 XML 模式
xsd:any构造来使用无类型的参数引入的。通过允许网格服务操作使用“any”参数，该特性允许网格服务操作拥有最大的灵活性。但是，该特性会导致客户机端就其可以传递给服务什么种类的参数产生混淆。为了避免这种混淆，该规范为客户机提供了一种机制（查询能力），以询问服务有关受支持的可扩展参数及其类型（XML 模式）的信息。
只要举一个示例就可使上述想法更为清晰。我们已经知道了可以使用 GridService 的 findServiceData 来查询服务实例的服务数据。服务可以支持不同类型的查询，包括通过服务数据名称进行查询，以及通过 XPath 进行查询。规范使用 ogsi:ExtensibilityType 将 findServiceData 的输入参数定义为可扩展的。现在，您可以根据服务的 findserviceDataExtensibility 的 SDE 值检索服务实例支持的所有可能的查询。缺省情况下，服务提供一个名为 queryByServiceDataNames 的静态查询类型（使用 staticServiceDataValue 定义）。
对 OGSI 规范的评价
该规范成功地解决了一些与分布式系统相关的问题（生命周期、命名、引用和状态管理）。同时，当该规范采用某些 Web 服务概念，特别是实例寻址、有状态服务的概念（引用和状态表示）和 Web 服务最佳实践指南（以文档为中心的视图）时，会存在一些松散性。随着有状态 Web 服务和相关性的出现，以及 WS-Addressing 和相关规范的成熟，最终可解决这些问题。不久的将来也会制定网格服务的最佳实践指南。
结束语
OGSI 规范处理网格服务必需的行为，该规范是可扩展的，并可达到各种服务实现之间最大互操作性。目前可用的几种软件框架都基于 OGSI 规范。Globus GT3 是该规范最重要且最实用的实现。接下来有关 OGSI 的系列文章将详细讨论 Globus 如何实现该规范，并将提供一些样本。
参考资料
关于作者 | | | Joshy Joseph 是一位为 IBM OGSA 开发团队效力的软件工程师。他的主要编程兴趣在于使用新兴技术，包括 Web 服务、语义 Web、REST 和网格计算，他还对使用基于 UML、MDA、AOP 和 XP 的编程模型感兴趣。可以通过
joshy@us.ibm.com与他联系。
|
对本文的评价
| 
