[URL=http://www-900.ibm.com/developerWorks/cn/grid/gr-visual/index_eng.shtml]
英文原文[/URL]
相关内容： [URL=http://www-900.ibm.com/developerWorks/cn/grid/gr-ogsi/index.shtml]开发人员对于 OGSI 和基于 OGSI 的网格计算的概述[/URL]
[URL=http://www-900.ibm.com/developerWorks/cn/grid/gr-gt3/index.shtml]Globus Toolkit 3.0 和 OGSI 体系结构 — 概述[/URL]
剖析 OGSA 的组件结构
级别：入门
[URL=http://www-900.ibm.com/developerWorks/cn/grid/gr-visual/index.shtml#author1]Jay Unger[/URL] ([URL=mailto:unger@us.ibm.com?cc=&subject=A visual tour of Open Grid Services Architecture]unger@us.ibm.com[/URL])，IBM 高级技术人员, IBM
[URL=http://www-900.ibm.com/developerWorks/cn/grid/gr-visual/index.shtml#author2]Matt Haynos[/URL] ([URL=mailto:mph@us.ibm.com?cc=&subject=A visual tour of Open Grid Services Architecture]mph@us.ibm.com[/URL])，程序主管，IBM
2003 年 12 月
网格计算是一门前景光明的新兴技术，业内人士对它的关注程度与日俱增，而它与行业的关系更是越来越密切。学术与商业组织都正在开发利用网格技术的应用程序。网格计算的定义有很多种（参阅 [URL=http://www-900.ibm.com/developerWorks/cn/grid/gr-visual/index.shtml#resources]参考资料[/URL]），但网格的本质是计算资源的联合加上这些资源的虚拟化，从而达到加速应用程序处理的目的。网格的全部核心就是分布式计算与资源管理。
一大批异构的资源组成了一个网格，重要的是，这些资源以众所周知并且一致的方式进行交互和运转。正是这种交互以及不同资源所提供的组件之间的互操作性，才是开放标准的需要，并因此促进了开放网格服务架构（Open Grid Services Architecture，OGSA）的出现。OGSA 是由 Global Grid Forum（GGF）的 Open Grid Services Infrastructure（OGSI）工作小组于 2002 年 6 月制定的。在本文中，我们全面介绍了 OGSA 的组件，并解释了它们的重要性。Global Toolkit 3（GT3）是 OGSA 标准的第一个主要实现；而其他实现还处于开发阶段。(参阅 [URL=http://www-900.ibm.com/developerWorks/cn/grid/gr-visual/index.shtml#resources]参考资料[/URL])。
OGSA 的目标
OGSA 具有下列目标：
跨分布式异构平台管理资源。
交付无缝的服务质量（Quality of Service，OoS）。网格的拓扑结构通常十分复杂，而且网格资源的交互往往是动态的。有一点很重要，即网格可以提供健壮的后台服务，比如授权、访问控制和委托。
为自治管理解决方案提供公共基础。网格可以包含许多资源，还有大量的配置组合、交互以及状态与故障模式的改变。对于这些资源来说，一些智能自动调节与自治管理方式是必不可少的。
定义开放的、已公布的接口。OGSA 是一种由 GGF 标准团体进行管理的开放式标准。为了不同资源的互操作性，网格必须构建在标准接口及协议之上。
利用行业标准的集成技术。OGSA 的创始者很有远见地利用了现有解决方案。OGSA 的基础是 Web 服务。
OGSA 架构
图 1. OGSA 的主要架构
OGSA 架构由四个主要的层构成：参见图 1。从下到上依次为：
资源 -- 物理资源和逻辑资源。
Web 服务，以及定义网格服务的 OGSI 扩展。
基于 OGSA 架构的服务。
网格应用程序。
让我们来逐一考察这些层。
物理和逻辑资源层
资源的概念是 OGSA 以及通常意义上的网格计算的中心部分。构成网格能力的资源并不仅限于处理器。
物理 资源包括服务器、存储器和网络。
物理资源之上是逻辑资源。它们通过虚拟化和聚合物理层的资源来提供额外的功能。通用的中间件，比如文件系统、数据库管理员、目录和工作流管理人员，在物理网格之上提供这些抽象服务。
Web 服务层
OGSA 架构中的第二层是 Web 服务。
这里有一条重要的 OGSA 原则：所有网格资源（逻辑的与物理的）都被建模为服务。OGSI 规范定义了网格服务并建立在标准 Web 服务技术之上。OGSI 利用诸如 XML 与 Web 服务描述语言（Web Services Description Language，WSDL）这样的 Web 服务机制，为所有网格资源指定标准的接口、行为与交互。OGSI进一步扩展了 Web 服务的定义，提供了动态的、有状态的和可管理的 Web 服务的能力，这在对网格资源进行建模时都是必需的。本文稍后将讨论这些扩展。
基于 OGSA 架构的网格服务层
Web服务层及其 OGSI 扩展为下一层提供了基础设施：基于架构的网格服务。GGF 目前正在致力于在诸如程序执行、数据服务和核心服务等领域中定义基于网格架构的服务。随着这些新架构的服务开始出现，OGSA 将变成更加有用的面向服务的架构（SOA）。
网格应用程序层
随着时间的推移，一组丰富的基于网格架构的服务不断被开发出来，使用一个或多个基于网格架构的服务的新网格应用程序亦将出现。这些应用程序构成了 OGSA 架构的第四个主要的层。
扩展网格的 Web 服务
图 2. OGSA 的结构
让我们仔细考察 OGSA 的两个主要逻辑组件：Web 服务加 OGSI 层和基于 OGSA 架构的服务层。参见图 2 。为什么它们看起来像是相互独立的呢？因为 GGF OGSA 工作小组相信，通过增加核心Web服务功能来满足网格服务需求是非常必要的。OGSI 通过在以下两个领域引入接口和约定来扩展 Web 服务。
第一，网格中服务具有动态及可能瞬变的特性。在网格中，特殊的服务实例会随着工作的分派、资源的配置与供给以及系统状态的变化而不断地产生和销毁。因此，网格服务需要接口来管理它们的创建、销毁以及生命周期管理。
第二，就是状态。网格服务可以拥有与自身相关的属性和数据。这在概念上类似于面向对象编程中对象的传统结构。对象有其行为和数据。同样地，Web 服务需要得到扩展，从而支持与网格服务相关的状态数据。
Web 服务的交互模型
图 3. OGSI 组件
OGSI 引入了一种网格服务的交互模型。通过提供发现、生命周期、状态管理、创建与销毁、事件通知以及引用管理的接口，OGSI 为软件开发人员提供了一种统一的建模和与网格服务进行交互的方式。图 3 描述了这些接口。不论开发人员正在开发的是网格服务还是应用程序，OGSI 编程模型都会为网格软件提供一种一致的交互方式。
让我们来进一步考察 OGSI 引入的接口和约定。
工厂。实现此接口的网格服务提供了一种创建新网格服务的方式。工厂可以创建有限功能的临时实例，比如创建服务以表示执行特殊任务的调度程序，或者它们可能创建生存时间更长的服务，比如一个常用数据集的本地拷贝。并不是所有网格服务都是动态创建的。其中有些可能是作为网格中物理资源的实例被创建的，比如处理器、存储器或者网络设备。
生命周期。 因为网格服务可能是瞬变的，所以网格服务实例是使用指定的生命周期来创建的。您可以根据依赖或管理该服务的组件的需要，确定和扩展任何特殊服务实例的生命周期。生命周期机制是以这样一种方式构架的，即在不需要大规模分布式垃圾收集清理程序的情况下，防止网格服务无限地消耗资源。
状态管理。网格服务可以具有状态。OGSI 规定了一个用于表示这种状态的名为 Service Data 的框架，以及一个用于检查或修改该状态的名为 Find/SetServiceData 机制。此外，OGSI 要求每个网格服务都必须支持的Service Data Elements中要有最低数量的状态，并要求所有服务都要实现 Find/SetServiceData portType。
服务组。服务组是网格服务的集合，它们使用 Service Data 来建立索引以用于特定目的。例如，您可能使用它们来收集所有这样的服务，它们在网格内特定群集节点中代表资源。
通知。被建模用于网格服务的状态信息（Service Data）会随着系统的运行而变化。网格服务之间的许多交互要求动态地监控状态变化。通知把一种传统的发布和订阅范式应用于这种监控。网格服务支持一个接口（NotificationSource），以允许其他网格服务（NotificationSink）订阅进行变更。
HandleMap. 当工厂创建网格服务的一个新实例时，工厂会返回新实例化的服务标识。这个标识由两部分组成：一个网格服务句柄（Grid Service Handle，GSH）和一个网格服务引用（Grid Service Reference，GSR）。GSH 保证无限期地引用该网格服务，而 GSR 可以在该网格服务的生命周期内发生改变。HandleMap 接口提供一种在给定GSH的情况下获得 GSR 的途径。这可能看起来很简单，但有许多与请求相关的错综复杂的事情夹杂其中，这在论文“The Physiology of the Grid”(参阅 [URL=http://www-900.ibm.com/developerWorks/cn/grid/gr-visual/index.shtml#resources]参考资料[/URL])中有详细描述。
关于 OGSI 和 Web 服务的更多信息
图 4. OGSI 和 Web 服务
我们已经看到，OGSA 架构增强了 Web 服务以适应网格的需求。在 OGSI 中已规定了这些增强。随着 OGSI 规范的定稿，以及相关实现的开始出现，一些标准组织开始对如下事情感兴趣：在相应的 Web 服务标准中整合 OGSA 拟定的大多数功能。这样做是很有意义的。从某些方面看，OGSI 处理的大量内容不是网格计算所特有的，但是是构建面向服务的健壮架构所必需的。随着时间的推移，许多 OGSI 功能或许会整合进 Web 服务标准中。[URL=http://www-900.ibm.com/developerWorks/cn/grid/gr-visual/index.shtml#figure4]图 4[/URL] 列出了几种可能整合 OGSI 的新兴 Web 服务标准。在图 4 中，我们将这些增强的 Web 服务叫做 扩展的 Web 服务。
OGSI 的实现
图 5. OGSI 和 Web 服务宿主
GT3 是 OGSI 标准的第一个完整实现版本。这个工具包由 Globus Project 开发，Globus Project 是一个研究开发项目，致力于支持网格概念的应用，以及科学、工程和商务计算。这个工具包是利用 Java 2 Platform, Enterprise Edition（J2EE）以 Java 语言编写的。OGSI 是网格服务架构的核心，您需要在一个支持Web服务的交付平台上宿主它。尽管 OGSI 最初使用 Java 来创建并宿主在 J2EE 运行库环境中，但是没有谁会阻止您用其他语言来实现 OGSI 并将它宿主在其他环境中。事实上，为了让 OGSA 得到更多人接受，需要在多种宿主平台中启用 OGSI。
采用哪种平台？在图 5 中，我们可以看到，OGSI 的 Java 实现可由多种 J2EE 环境中的任何一种来宿主，比如 JBOSS、WebSphere 或者 BEA Weblogic，这是用 Java 技术实现 OGSI 或者任何软件的突出优点之一。然而，另一些可选平台也是 OGSI 的可行宿主环境，比如传统的 C 或者 C++ 环境，或者 C# 和 Microsoft .Net 环境。已经有了运行在其他环境中的 OGSI 初始实现，包括 C#/.Net 和 Python。
许多 OGSI 实现或许会通过开放源代码开发模型来交付，而现有参考实现（GT3）将不加修改地在合适的宿主环境中使用。在理想的情况下，OGSI 核心实现（每种宿主平台有一个实现）的一小部分将由业界联合开发并在许多产品中使用。虽然 OGSI 在扩展 Web 服务方面颇为新颖，但是软件供应商将不能根据他们的 OGSI 实现的质量来区分他们自己。因而，OGSI 的共同开发和广泛使用将是直观和可取的。
基于 OGSA 架构的服务
图 6. 基于 OGSA 架构的服务的结构
OGSI 是在为网格开发面向服务的架构方面迈出的重要一步。然而要开发有用的应用程序，像 Globus 项目这样的开放源代码努力和那些中间件软件公司，将需要实现并交付网格服务的丰富集合——基于 OGSA 架构的服务。在某种意义上，OGSI 和它为 Web 服务提供的扩展是必不可少的，但是对于面向服务的架构的成熟来说还不够。
在图 6 中，我们进一步将网格架构的服务分为四个类别：
网格核心服务。
网格程序执行服务。
网格数据服务。
特定于领域的服务。
前三个类别代表 GGF 研究或工作小组的当前工作领域。随着时间的推移，当这些服务成熟时，就可以规定特定于领域的服务，让它们利用这些服务所提供的功能。GGF 工作小组当前正在集中精力制定有用网格服务的广泛集合，而软件供应商和开发人员现在就可以开始实现这些服务。
下面我们来进一步考察这些服务。
网格核心服务
图 7. 网格核心服务
图 7 表明，网格核心服务由四种主要的服务类型组成：
服务管理。
服务通信。
策略管理。
安全。
与已经实现为基本 Web 服务协议扩展和交互模型的 OGSI 功能不同，这些核心服务实际上被实现为网格服务（建立在 OGSI 基础上）。这些服务被认为是核心，主要是因为它们最有可能得到大多数（如果不是全部的话）高级服务的利用，实现这些高级服务或者是为了支持程序执行，或者是支持数据访问，又或者是将它们实现为特定于领域的服务。
服务管理。提供相关功能来管理分布式网格中部署的服务。服务管理自动化和帮助网格系统中各种各样的安装、维护、监控和诊断任务。它还包括相关的功能，用于收集和交换关于网格操作的数据。这些数据同时用于在线和离线管理操作，并包括关于错误、事件、问题确定、审核、测量、会计和账务的信息。
服务通信。包括一系列的功能，这些功能支持网格服务用来与其它网格服务通信的基本方法。它们支持多种通信模型，这些模型能够允许进行有效的服务间通信，包括消息排队、发布-订阅事件通知，以及可靠的分布式日志记录。
策略服务。提供一个用于创建、执行和管理系统操作策略和协议的一般框架。这包括控制安全、资源分配和性能的策略，以及一个用于策略敏感的服务的基础结构，以便使用策略来控制它们的操作。策略和协议文档提供一种机制，用于表示和谈判服务提供商和客户之间的条款。这些条款包括功能规范、性能，以及供应商和客户交换的质量需求和目标，这些质量需求和目标可用于影响他们的互动。
安全服务。以一种使得不同操作系统能够安全地互操作的方式，支持、集成和统一流行的安全模型、机制、协议和技术。这些安全服务启用并扩展了核心 Web 服务安全协议和绑定，同时提供面向服务的身份验证、授权、信任策略强制、证书转换等机制。
网格执行和数据服务
图 8. 网格程序执行服务和网格数据服务
图 8 描述了两类网格服务：
网格程序执行服务。
网格数据服务。
网格程序执行服务。 虽然 OGSI 和网格核心服务一般适用于任何分布式计算系统，但是网格程序执行类别是支持高性能计算、并行计算和分布式协作的分布式任务执行网格模型所特有的。被实现为这类服务的一部分的作业调度和工作负载管理原则，是网格计算和虚拟化处理资源的能力的中心。我们已经看到了这个类别中接口的早期规范，比如 Community Scheduling Framework（CSF），该规范于 2003 年 6 月在西雅图举行的有关 GGF 8 的会议上发布。
网格数据服务。 对程序执行服务所规定的计算虚拟化约定形成补充的，是构成网格数据服务的服务。这些接口支持数据虚拟化的概念，并提供与多种类型的信息的分布式访问相关的机制，包括数据库、文件、文档、内容库和应用程序生成的流。网格数据服务使用诸如复制、缓存和高性能数据移动布局方法来利用和虚拟化数据，以便赋予应用程序必需的跨分布式网格 Qos 访问。用于联合多个相异的分布式数据源的方法可能还提供存储在不同模式下的数据的集成，比如文件和关系数据库。
在本分类中，OGSA 同等地看待数据资源和计算资源是显而易见的。
网格程序执行和数据服务宿主
图 9. 网格程序执行和数据服务宿主
供应商或许不会通过提供广泛的 OGSI 实现来展开竞争。相反，作为 Web 服务实现结构的一部分，提供 OGSI 实现的供应商可能会直接使用诸如 Globus 等组织提供的现有开放源代码实现，或者他们会把 OGSI 实现与诸如 WebSphere、WebLogic、Apache 或者.Net 等宿主平台集成在一起。
然而，对于彼此竞争而区分开来的供应商和组织来说，基于网格架构的服务提供了自然的成熟机会。这种竞争将创造一种网格软件供应商“经济”，这些供应商的创新将有助于推动诸如 OGSI/OGSA 等标准得以接受，而这将允许客户抛弃互操作组件来构建系统。此外，网格程序执行和数据服务中的功能领域将需要创新的方法，以加快市场对网格解决方案的接受进度，为供应商提供市场机会。在图 9 中，我们看到，网格核心服务很可能会成为开放源代码参考实现和供应商提供的“增值”实现的混合体。这个领域的许多技术可能会变得非常普及，但是诸如策略和安全等领域将为供应商提供各自的市场表现机会。
网格程序执行和数据服务的实现，预期将主要由诸如 IBM、Avaki、DataSynapse、Platform Computing 和 United Devices等公司的增值实现组成。这些领域代表了供应商在 OGSA 框架内集成领先的中间件产品的重要机会，并将允许一个丰饶的网格解决方案生态系统成长壮大。
结束语
本文描述了 OGSA 的组件结构。随着最初的 OGSI 实现的交付，OGSA 正准备加速进入主流商业计算环境。不管最初的设想是称作有机计算、按需计算，还是称作自适应计算，像 OGSA 这样建立在标准技术基础上的开放而全面的标准，对于在商业世界中实现分布式异构计算来说是必不可少的。
参考资料
要了解网格计算的不同定义，请参阅以下资源：
“[URL=http://www-fp.mcs.anl.gov/~foster/Articles/WhatIsTheGrid.pdf]What is the Grid[/URL]”，作者：Ian Foster。
“[URL=http://www.gridtoday.com/02/0819/100249.html]How Does One Really Characterize Grid Computing[/URL]”，作者：Richard Freund。
“[URL=http://www.sun.com/software/grid/SunGridComputingBrief.pdf]An Overview of Grid Computing from Sun[/URL]”。
“[URL=http://www-1.ibm.com/grid/about_grid/what_is.shtml]What is Grid computing?[/URL]”，作者：IBM Corporation。
参阅 [URL=http://www-unix.gridforum.org/mail_archive/ogsa-wg/msg00235.html]Global Grid Forum GGF8[/URL] 上 OGSI Implementations Session 中讨论的技术列表，该会议于 2003 年 6 月在西雅图举行。
参阅 [URL=http://www.globus.org/research/papers/ogsa.pdf]The Physiology of the Grid[/URL]。
关于作者
Jay Unger 是 IBM Grid Computing Emerging Business Opportunity 部门的高级技术人员和首席技术架构师。他拥有 30 年开发计算机、操作系统、通信网络和应用系统的经验。他于 1974 年在纽约州金斯顿加盟 IBM，从事 IBM 操作系统的开发，并参与过 MVS、JES、SNA 和耦合系统的早期开发。他在很多技术领域工作过，包括数据库和文件系统、电子出版物、图像和文档管理系统、自然语言处理和信息检索、生物信息学、嵌入式系统、分布式系统和网络计算、Web 技术以及高性能计算。他是 IBM Academy of Technology 的成员。
Matt Haynos 是 IBM Grid Strategy and Technology 小组的程序主管，这个小组的总部位于纽约 Somers。他在该小组中负责多项工作，包括与构建 IBM 网格计算业务相关的广泛构想。他在 IBM 的应用程序开发、程序指导和业务开发领域拥有多个技术和管理职位。他拥有罗彻斯特大学的计算机科学/应用数学和认知科学的学士学位，以及佛蒙特大学的计算机科学硕士学位。他与妻子和两个儿子居住在美国康涅狄格州。
[返回] 中文XML论坛 - 专业的XML技术讨论区 →
W3CHINA.ORG讨论区 - Web新技术讨论 → 『 云计算，网格，SaaS，P2P 』 → [转帖]开放网格服务架构之旅
(订阅本版)
2005/2/18 21:04:00
顶端 
[转帖]开放网格服务架构之旅(17144字) － admin，2005年2月18日
新浪微博
