级别： 初级 Thomas Myer (tom@tripledogdaremedia.com), 主席
2003 年 12 月 01 日 本期的“网格观察”专栏向我们快速展示了 OGSA、OGSI 以及其他 GGF 的与架构相关的项目。
在
本专栏第一篇文章中，我向您简要介绍了开放网格论坛（Global Grid Forum，GGF）。现在，我将把注意力转移到网格架构上来。我发现这个话题讨论起来极为困难。这并不是因为我认为架构问题很无聊，或是没有必要。恰恰相反，这正是一个巨大的、无序的、复杂的话题，我的任务就是在这里挑出一些对开发人员团体来说很重要的问题，这样大家就不会迷失方向了。
网格架构为什么重要？
在我们开始讨论网格架构之前，我想先回退一步，问一个问题：“对于开发人员来说，网格架构中有什么？为什么网格架构很重要？”
网格架构之所以重要，就是因为在现实世界里架构也很重要。网格就像一种固定的结构，它可以：
- 以任何规模出现。
- 由多种不同的材料组成。
- 可用于各种目的。
- 具有不同级别的通信量（吞吐量）和容量。
- 要求具备不同级别的安全性。
- 要求具备不同类型和层次的基础设施。
计算网格是非常复杂的计算资源网络。网格中的系统可以运行于不同的硬件配置上的不同操作系统，并且由不同的组织所有，包含不同级别的可用共享资源，等等。
一个成功的网格架构可以帮助网格对整个异质环境中的资源进行管理。一个好的架构应该提供开放的、发布于众的接口，允许各种不同的网格组件能够进行交互。如果运气好的话，好的架构甚至可以享受到网格计算中的圣餐之一 -- 服务质量（QoS）。
所以对您来说网格架构的含义就是：好的架构意味着好的网格。
OGSA
架构领域（Architecture Area，“Area”一词是指 GGF 中广泛的组织结构）中包括若干工作和研究小组，每一个小组都代表构建网格的不同架构方法。层次最高的组致力于开放网格服务架构（Open Grid Services Architecture，OGSA）的研究。
OGSA（GGF 成员将其读做“awg-sah”）的设计目标是用某种方法处理前面介绍的所有问题。其中的大部分标准都建立在现有 Web 服务（特别是 SOAP）标准之上。如果您理解了 Web 服务，再跳到基于 OGSA 的网格上时，就不会碰到太多的问题。如果您尚未理解 Web 服务，那么请花一些时间访问一下 developerWorks 的
Web 服务专区。
研究 OGSA 最好的方式是将其想像成一个一层一层的蛋糕。如果您熟悉 OSI 协议栈的话，理解这一点就没有问题。在 OGSA 栈的最底层是物理资源。服务器、存储设备和网络都可以是物理资源。紧挨着物理资源之上的是逻辑资源，通常是一组中间件应用程序的集合，包括数据库、文件系统、工作流管理器等等。基本上来说，这一层中包含了能够帮助网格使用和聚合可用物理资源的工具。
接下来是 Web 服务层。在这一层上，所有的资源（包括逻辑资源与物理资源）都只是服务。将服务器的可用 CPU 周期看作是服务，而不是一种东西，这种想法确实有些古怪，但是在 Web 服务领域中，这样想法是很有意义的。
Web 服务层为支持服务提供了坚实的基础。比如说，Web 服务中内建了发现可用服务的特性，也具有让服务对自身进行描述的方法，这样调用服务就很容易了。更进一步看，对服务请求和服务响应的传输也有标准的方法。
但是只有 Web 服务提供的这些好工具并不意味着我们马上就能使用。大多数特性还必须要经过扩展，我们将在另一部分中做更深入的介绍。
在 Web 服务层之上的是网格服务层。在这一层中您可以找到数据提取、程序执行、监视以及其他一些核心服务。这一领域还需要观察，对它的定义目前也在进行之中，我猜想定义的过程将会持续一段时间。在这个问题上还有一点需要注意，即开放网格服务基础设施（Open Grid Services Infrastructure，OGSI）的重要性。毫不夸张地讲，OGSI是在 OGSA 中将 Web 服务层和网格服务层结合起来，同时又对核心 Web 服务进行扩展的第一次尝试。
随着网格服务层逐渐变得坚实，您将会看到独立的应用程序开始出现在最顶层，这一层也称为网格应用程序层。作为开发人员来说，我们要在栈中其他层的基础上构建应用程序。您可以画一张图，将这个栈和 OSI 栈对比一下。只要您理解了 SMTP 协议，就很容易构建一个电子邮件应用程序了。这里情况也是一样。
类似于 Web 服务，但不完全相同
好了，到现在为止我们已经知道了，很多 OGSA 背后的概念都是建立在 Web 服务标准之上的。从很多方面来讲，网格操作就像是 Web 服务一样；换句话说，都是由一个系统请求另一个系统执行某项任务，并获得一个响应。
然而，Web 服务有很多与生俱来的特征，使其不适合在网格环境中使用。首先，Web 服务是无状态的，它们不会记住从调用到调用过程中您请求（或收到）了什么。如果您要进行一系列相关的计算或查询（这种情况与网格环境中极为相似），您就必须找到一种方法来将一次计算的结果传递给下一次调用。
那么这里的问题就是过于短暂了。所有的 Web 服务都比它们的客户机存在的时间长。换句话说，Web 服务不是短暂的。如果，某一个客户可以访问一些数据，那么另外一个客户机也可能看到（或修改）这些数据。
OGSI 将包括这些在内的很多问题都考虑了进来。基本上说，OGSI 对 Web 服务进行了扩展，在网格中实现瞬间服务与状态管理并存。更进一步说，人们可以认为，OGSI 的实现方式使我们能够构建健壮的、面向服务的架构（services-oriented architecture，简称 SOA），这一点可能是 CIO 或 IT 主管非常喜欢的。
现在我们来看看 OGSI 的细节问题。
OGSI 简述
OGSI 与任何其他网格计算事物一样，与其他计算概念十分类似。在任何兼容 OGSI 的网格服务中，客户机请求服务工厂构建服务实例。每一个服务实例都有唯一一个 GSH （Grid Services Handle，网格服务句柄），因此在系统中可以唯一标识。GSH 与 Web 服务中的 URI 十分类似。如果客户机需要与服务进行通信的话，它就将 GSH 解析为一个 GSR（Grid Service Reference，网格服务引用），然后用它与工厂创建的服务实例进行联系。当客户机想要销毁这个服务实例时，它可以显式地调用一个销毁操作，或是简单地依赖 OGSI 内置的基于生命期的垃圾回收机制（稍后将详细讲述）。
因为这些实例都是瞬变的，它们最终都会被销毁。实例的生命期根据应用程序的不同而不同，可以根据需要通过 OGSI 提供的接口进行扩展或压缩。一般而言，实例的生存期和客户机需要它的时间一样长。按照这种方式，每一个客户机都使用它自己的实例。然而，若干个客户机可能共享单个实例，如果我们能够通过仔细的生命期管理，让实例在一段不活跃时间过后自行销毁，那就最好了。
每一个网格服务中都包含 Service Data（服务数据），这是用于描述网格服务的一组数据。Service Data 的存在使我们能够实现一种自省机制，即网格服务具有向外界实体描述其自身的能力。
网格服务中另一重要方面是 portType。网格服务 portType 实质上与 Web 服务的 portType 是相同的。它的功能是作为一个接口，用于在端点之间来回传递消息。GridServices portType 是必需的核心功能，它用于找到和查询一个网格服务、判断服务的终止时间，或者执行其他基本功能。Factory portType专用于创建新的服务。出于安全性、生命期管理、任务执行以及其他用途的需要，这些专用的 portType 可以通过扩展核心 portType 来实现。
因为 portType 和 Service Data 都是由 XML 表示的（确切地说是 WSDL 文档），因此，兼容 OGSI 的网格都从 Web 服务中继承了一组非常丰富的、表达力极强的工具和技术，支持将遗留系统暴露为 Web 服务。然后，网格服务扩展允许这些暴露的服务在多个管理域中进行集成和共享，这些管理域可以在一个组织内部，也可以跨越多个组织。
一定要注意的是，OGSI 仍然是一种“提议的推荐标准（Proposed Recommendation）”。只有当存在若干种互操作实现的时候，它才能成为推荐标准。只有到那个时候，OGSI 才可看作是“完成了”。
架构和基础设施之间有哪些区别？
如果您能够听懂我在说什么，那么您现在可能会想，“OGSA 和 OGSI 之间有什么区别？”或者，您也许会问另外一个更普遍的问题，“架构和基础设施之间有什么区别？”架构，如 OGSA，定义了一种网格服务；而基础设施，如 OGSI，可以用个别的工具来实现，从而创建一个真正的网格服务。
举个例子说，如果您想造一座桥，您会请一名建筑师。这名建筑师会将所有的规划绘制出来，但是她还要和一名结构工程师协作，这名结构工程师将负责在搭建这座桥时使用合适的材料。最后，所有这些规划和材料规格都将交给一队建筑工人，由他们根据这些蓝图和材料规格来搭建这座桥。
如果把这座桥当成我们的网格服务，那么建筑师就是 OGSA，结构工程师就是 OGSI，造桥的工人就是实现工具，比如 Globus Toolkit 3、Unicore/GS、OGSI:Lite 或者 OGSI.NET。
架构中还有哪些工作？
OGSA 和 OGSI 不是 GGF 架构领域中唯一进行的项目。还有其他一些工作和研究小组，包括：
-
语义网格（Semantic Grid）：这个研究小组负责跟踪 Semantic Web 项目，并找出适用于网格计算的最佳实践和案例研究。
-
网格协议架构（Grid Protocol Architecture）：这个研究小组的主要目标是提供“一种概念性框架，用于讨论相互关系、完整性以及实现网格服务的协议最小化。”
-
服务管理框架（Service Management Framework）：这个研究小组负责在正在兴起的面向服务网格（Service Oriented Grid）社团中，检查和开发技术与管理问题。这些问题包括（但不局限于）在不同框架中服务的动态注册、发现、绑定和分离；提供支持自治服务的机制与元数据。
-
通用管理模型（Common Management Model）：这个工作小组致力于将一组通用的 IT 资产管理标准结合在一起。
-
新生产力项目（New Productivity Initiative）：这个工作组将为分布式计算管理定义一个特别轻量级的高层架构。
结束语
我刚才已经讨论了很多领域的问题，非常引人入胜。也许您觉得有很多东西需要深入探讨，或是又发生了很多变化，或是有些使人迷惑，不论哪种情况，您都是正确的。
参考资料
关于作者  | 
| | Thomas Myer 是 Triple Dog Dare Media 的主要创始人。Triple Dog Dare Media 位于美国德克萨斯州的奥斯汀，是一家致力于构建 Web 服务、XML 和数据库应用程序的公司。可以通过
tom@tripledogdaremedia.com与 Thomas Myer 联系。
|
对本文的评价
| 
