级别： 中级

Xiaobo Yang (x.yang@dl.ac.uk), 软件开发人员, Consultant
Xiao Dong Wang (x.d.wang@dl.ac.uk), 高级软件开发人员, Consultant
Robert Allan (r.j.allan@dl.ac.uk), 小组负责人, Consultant

2007 年 5 月 31 日

构建于网格中间件之上的网格门户担当着网格大门的角色，因为它们使人们能更顺利地学习使用网格。在 “基于标准的网格门户开发” 系列的第 1 部分中，我们将对网格门户作一个总体介绍，重点讲述当前基于标准（JSR 168 和 WSRP 1.0）的第二代网格门户。在第 2 部分中，将举例说明如何使用 portlet 技术开发网格门户。而第 3 部分将讨论 WSRP 应用程序和网格门户的未来。

对 Globus Toolkit 和门户的简短回顾

20 世纪 90 年代，网格开始兴起，人们随之将一些分布式资源（如超级计算机和实验工具）结合使用，用来探索当时最重大、无法解决的问题的解决方法。大家提议使用虚拟组织（virtual organisation，VO）的概念来描述随需应变的社区，该社区可以动态地进行构造。现在，这类网格系统得到了研究机构的广泛采用，并逐渐在整个行业中得到部署。网格系统可根据其规模进行分类。一个小规模的系统（校园网格）可能只包含几个研究小组的资源，而一个大规模的系统则可能整合了全国范围内的资源，如 U.K. National Grid Service (NGS)，或者甚至是世界范围内的资源，如 Enabling Grids for E-science (EGEE) 项目。

在继续介绍网格门户之前，我们先大致了解一下 Globus Toolkit（GT）。GT 实际上被看作网格技术的标准，自 V2.x 版本以来，它已得到广泛部署。使用 GT 可构建网格系统和应用程序。GT2 包含了一组脚本，用于执行如代理凭证创建、远程作业提交和基于 GridFTP 的文件传输之类的任务。在世界范围内现已构建了很多基于 GT2 的网格系统。例如，NGS 使用 GT2 为英国多个学科的研究人员提供产品服务。

2002 年，Global Grid Forum (GGF) 提议使用新架构 Open Grid Services Architecture (OGSA) 来定义基于网格的应用程序的通用标准和开放式架构。OGSA 扩展了 Web 服务的概念以定义网格服务。网格服务的关键属性在于它有状态，而传统的 Web 服务无状态。

GT3 是由 Globus Alliance 开发的 OGSA 实现。虽然 GT3 引入了一个新架构并尝试利用 Web 服务行业标准的优势，但由于过于复杂，并未得到广泛的部署。不过，有些国家开发了基于 GT3 的项目。例如，ShanghaiGrid 项目瞄准了一些超级计算机，将它们连接起来以便共享大量存储和计算能力。该项目的目标是：使用此网格系统的能力为上海的交通拥塞状况提供实时的控制和指引。

Globus Alliance 迅速对 GT3 带来的问题作出反应，发布了基于 WS-Resource Framework（WSRF）的 GT4。而最初由 Globus Alliance 和 IBM® 提议设立的 WSRF，则成为了 Organization for the Advancement of Structured Information Standards (OASIS) 标准。 WSRF 用于使 Web 服务状态化的方式标准化。 事实上，Web 服务和网格社区正在合并。

由于 GT 已经升级，因此采用它的项目也需要升级。不管采用的是哪个版本，得到的应用程序软件都必须保持用户界面友好。虽然研究人员知道使用网格可带来很多益处，但是他们并不愿意改变习惯。为了更顺利地学习使用网格，最终用户有两个选择：1) 使用桌面客户机，2) 使用基于 Web 的网格门户。第一个选项是软件发布的传统方法。基于网格中间件可开发客户机工具，提供执行网格相关任务的强大功能。这些工具通常需要打开一组端口以使用 GridFTP 执行文件传输之类的任务。这种方法非常适用于一些特殊机构（比如学校），但是需要执行大量的管理工作，并且灵活性不如第二种方法。Web 是发布服务的一个理想平台，并且几乎所有的桌面都配备了浏览器（比如移动电话和 PDA 之类的设备）。这使基于 Web 的网格门户成为了提供桌面客户机所能提供的相同服务的一个自然的选择。最大的优点是：网格门户不需要安装客户机软件 —— 只需一个 Web 浏览器即可。由于不再限制用户必须使用带有网格中间件的计算机，因而使普适访问成为可能。我们希望网格系统和可通过 Web 门户透明访问的应用程序能吸引越来越多的用户。

回页首

第一代网格门户

第一代网格门户通常是利用基于 Perl 的 GridPort Toolkit V2 或基于 Java™ 技术的 Grid Portal Development Kit (GPDK) 来构建的。GridPort 和 GPDK 都包装了常用的网格功能以便提供一组高级别的编程 API 和工具。在一些其他项目中，需要反复地构建一些常用的任务（如代理管理和作业提交），但是无法重用这些工具。在实践中，工具是依据每个项目的自身需求来开发的，并未考虑到代码的重用性。门户技术的采用改变了这一状况，并展示了如何开发常见的基于 Web 的服务。

网格门户开发人员开始通过考察编程框架来改进软件的可重用性。他们考察了如 Jetspeed-1（一个提供 portlet 的 Apache 项目）之类的项目。例如，U.K. NGS 门户和 Open Grid Computing Environment (OGCE) 的第一个版本是以 Comprehensive Collaborative Framework (CHEF) 为基础的。CHEF 是 Sakai 的前身，后者构建于 Jetspeed-1 之上以提供非标准的 portlet 支持。Jetspeed-1 展示了一种很有前途的、构建开发人员共享的可重用 Web 组件（如 Java portlets）的方法。2003 年，OASIS 批准以 Web Services for Remote Portlets (WSRP) 1.0 和 Java Portlet Specification V1.0 (JSR 168) 作为今天的第二代网格门户的基础。

回页首

第二代网格门户

JSR 168 中的门户、portlet 和 portlet 容器 门户 是基于 Web 的应用程序，用于提供来自不同源的个性化单点登录内容集合，并承载信息系统的表示层。 portlet 是基于 Java 技术的 Web 组件，由 portlet 容器进行管理，后者用于处理请求和生成动态内容。 portlet 容器 运行 portlet 并为其提供所需的运行时环境。

第二代网格门户是基于标准的。特别地，JSR 168 已得到网格门户开发人员的广泛采用。JSR 168 和 WSRP V1.0 用于解决门户和 portlet 开发和部署中的互操作性问题。此外，第二代网格门户还担当着服务客户机的角色，以便适应今天的面向服务的架构（SOA）。在下一部分中，我们将讨论两种门户和 portlet 标准：JSR 168 和 WSRP，以及 SOA 在门户世界中的应用情况。

JSR 168 和 WSRP 1.0

JSR 168 是一种规范，通过定义一组 Java API 来使 portlet 和 portlet 容器之间的通信标准化。除了提供一些如自定义、不同模式和窗口状态之类的益处之外，此规范还允许 portlet 开发人员交换 Web 组件（比如 JSR 168 兼容的 portlet）。这些 portlet 可部署在任何 JSR 168 兼容的 portlet 容器中，无需修改源代码。门户则构建在 portlet 容器的周围，后者用于管理其 portlet 的生命周期。一个典型的门户框架通常提供如用户帐号管理和 portlet 部署支持之类的功能。因此极大地减轻了门户开发人员的负担，而开发人员则可主要集中于 portlet 开发，特别是业务逻辑层的开发。

顾名思义，JSR 168 是 Java 门户开发人员遵循的一种规范。问题在于：如何重用由 Java 编程语言以外的语言（比如 Perl 和 PHP）发布的 Web 内容（portlet）？人们提议使用其中的 OASIS WSRP V1.0 规范来回答此问题。

由于 WSRP 将 portlet 和门户分开，从而引入了生产者 和消费者 的概念。生产者是服务提供者，而消费者是服务客户机。与传统的面向数据的 Web 服务不同的是，WSRP 生产者为其消费者提供了格式化的（而非随意的）数据。消费者负责将请求从终端用户重定向到相应的带有如输入参数的名称和值之类信息的生产者服务。然后生产者处理请求并将响应发送回带标记片段的消费者。接下来客户端门户就可以在其消费者中检索这些标记片段，以便在用户浏览器中呈现完整的 Web 页面。

WSRP 实现了一个一次部署、随处运行的范例。Portlet 供应商再也不需要将 portlet 分发到客户机了。现在，只要托管了这些 portlet，也就拥有了对它们的完全控制权。此方法貌似 Java Web Start 方法，后者启用了一个软件提供程序，始终为其客户机提供最新的软件版本。

由于 WSRP 基于 Web 服务，因此它自动实现了语言独立和平台独立。理论上讲，消费者和生产者都应该可用如 Perl 和 C# 之类的语言开发。遗憾的是，当前的 WSRP 在开源门户框架中的实现仍然不成熟。就我们所知道的而言，惟一的以另一种语言编写的开源 WSRP 生产者是由 EDINA 小组使用 Perl 编写的。WSRP 得到了几家最主要的 IT 公司的支持，包括 IBM。一个 Microsoft® .NET 平台支持 WSRP 的例子是 NetUnity，它用于将 .NET 应用程序植入 Web 门户中。

作为 JSR 168 和 WSRP V1.0 的后继者，JSR 286 和 WSRP V2.0 预计于 2007 年发布，它们应当能提供一些改进，解决如 portlet 间通信和远程 portlet 生命周期管理之类的问题。

在网格门户中采用 SOA

第二代网格门户一般担当了服务前端的角色。Web 服务实际上成为了今天的 SOA 实现的标准。Portlet 广泛地被设计为 Web 服务客户机以使用远程服务。通过这种方法，门户很好地适应了 SOA 的表示层。

虽然通过将表示和业务逻辑清楚地分开，把门户作为服务客户机对待确实让 portlet 开发人员受益，但是有时却需要将表示和业务逻辑包含在一起，以便能重用 Web 组件。如图 1 所示，SOA 被表示为一个三层架构，其中的三层分别为：门户、服务 和资源 层。与 GridPort V4 架构中相同。此处扩展了服务层以便包含表示逻辑。此外，门户层不再是服务客户机的容器，而是自身就是一个服务提供者。这就强调了 WSRP 中提议的面向表示的服务，并且使门户层可将 Web 组件作为服务来提供。

回页首

网格门户示例

OGCE Release 2

OGCE 是由美国的 National Science Foundation（NSF）所资助的一个项目，目的是构建可集成到一个通用门户容器系统中的可重用门户组件。OGCE Release 1 基于 CHEF，后者反过来基于带有非标准 portlet 支持（前面曾提到过）的 Jetspeed-1。不出所料，OGCE 的第二个版本采用了 JSR 168 标准并提供了一组网格 portlet 和服务。此外，OGCE Release 2 还推出了自己的服务以解决 portlet 间的通信问题，而这一点在 JSR 168 规范中并未涉及。保留了基于速度的 portlet 支持以使 Jetspeed-1 portlet 可迁移至 JSR 168 兼容的容器中。OGCE release 2 还支持 uPortal 和 GridSphere。基于部署 portlet 的经验，将 OGCE portlet 迁移至 JSR 168 兼容的门户框架中应该不难。

GridPort V4

基于 Perl 的 GridPort V4 现在基于 Java 技术并与 JSR 168 兼容。与 OGCE Release 2 类似，它也提供了一组网格相关的 portlet（如 GridPort Information Repository (GPIR) 浏览器 portlet 和 Condor 作业提交 portlet），帮助用户建立网格门户。GridPort V4 拥有清晰的三层架构，包括门户层、服务层和资源层。门户层与终端用户交互，而服务层则接下来处理与资源层的交互。

GridPort 4 架构被看作是面向服务的架构。例如，核心网格功能 —— GridFTP（用于文件传输）和 Grid Resource Allocation and Management 服务 (WS-GRAM)（用于作业提交） —— 被打包并公开为 Web 服务。这些服务以后可供驻留在门户层中的 portlet 使用。

NGS Portal release 2

在开发 U.K. NGS Portal 时采用了与开发 OGCE 相似的方法。NGS Portal Release 2 与 JSR 168 兼容，而 Release 1 则是基于 CHEF。最初，为 CHEF 开发了一组网格 portlet 并将其迁移至一个自定义版本的 StringBeans（另一个开源门户框架）。添加了 MyProxy LoginModule 以允许 NGS Portal 在使用从 NGS MyProxy 服务器检索到的网格代理凭证登录时自动创建用户上下文。其他关键功能被包装在基于 Java CoG V1.2 的可重用 Java 包中。

在开发期间，我们意识到采用 SOA 的重要性，并调查了 portlet 开发中的 J2EE 技术应用程序。我们编写了 Enterprise JavaBeans (EJBs) 来实现主要业务逻辑。在 EJB V2.1 规范（该规范允许将无状态会话 bean 转换成 Web 服务）的帮助下，将 LDAP 查询 bean 转换成了 Web 服务。

我们最近针对 WSRP 对于门户开发的重要性进行了广泛地研究。虽然 WSRP V1.0 规范的可用实现还不成熟，但是让 WSRP 生产者和消费者正常运作却可以实现。我们已经为 Sakai 开发了 WSRP 消费者，其中为 NGS Portal 开发的网格 portlet 得到了成功的使用。WSRP 提供了一种有前途的、构建联合门户的方法。我们将在本文的最后一部分讨论这一未来门户开发趋势。

结束语

分享这篇文章...... 将本文提交到 Digg 发布到 del.icio.us 提交到 Slashdot！

第二代网格门户以标准为依据，且能很好地适应 SOA。JSR 168 和 WSRP V1.0 两者都瞄准解决门户和 portlet 的开发和部署中的互操作性问题。在本文中，我们简要地回顾了网格门户的历史并介绍了一些标准。在第 2 部分，我们将通过三个示例来阐释 LDAP 查询、网格代理凭证检索和远程计算资源作业提交。这就形成了很多一般网格门户的基础。而在第 3 部分，我们将讨论 WSRP 应用程序和网格门户的未来。

参考资料

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
  
  
• JSR 168: Portlet Specification 是由 Java Community Process (JCP) 开发的，用于使 portlet 和 portlet 容器之间的通信标准化。
  
  
• Web Services for Remote Portlets Specification 是由 OASIS 开发的 portlet 规范，用于使 portlet 容器之间的通信标准化。
  
  
• Open Grid Services Architecture (OGSA) 代表了向基于 Web 服务的网格系统架构的演变。
  
  
• Introduction to Grid Portals 是一篇教程，它展开论述了本文提到的一些内容。
  
  
• 在 developerWorks 中国网站 Grid Computing 专区 中可找到更多适合于网格开发人员的资源。
  
  
• 网格技术文档库：developerWorks XML 专区提供了大量的技术文章和技巧、教程、标准与 IBM 红皮书。
  
  
• developerWorks 技术活动 和 网络广播：随时关注技术的最新进展。
  
  

• Globus Toolkit 是启用网格的实际标准实现。
  
  
• U.K. National Grid Service 为英国的研究人员提供了对计算资源和数据网格资源的一致的电子访问。
  
  
• OGCE Portal Toolkit 瞄准开发 JSR 168 兼容的 portlet 和 Web 服务，用于为科学网关构建 Web 门户。
  
  
• GridPort Toolkit 提供了一组 portlet 接口和服务，用于快速开发网格门户。
  
  
• Sakai Project 针对为培训提供协作和学习的环境。
  
  
• IBM 试用版软件：用这些试用版软件开发您的下一个项目，可直接从 developerWorks 下载。

• 通过参与 developerWorks blogs 加入到 developerWorks 社区。
  
  

作者简介

		Xiaobo Yang 是一名软件开发人员，就职于英国 CCLRC e-Science Centre 的 Grid Technology Group。他对网格、协作虚拟研究环境和各种 Web 技术（包括网格门户技术），以及面向服务的架构（Service-Oriented Architecture，SOA）都有着浓厚的兴趣。

		Xiao Dong Wang 是一名高级软件开发人员，就职于英国 CCLRC e-Science Centre 的 Grid Technology Group。他所感兴趣的领域有：网格中间件设计、应用程序、门户用户接口、portlet 开发、JSP 和 JSF。他在 Java 编程、Web 和网格服务开发方面有超过六年的经验。

		Robert Allan 是英国 CCLRC e-Science Centre 的 Grid Technology Group 的小组负责人。他原来是一名物理学家，自从 20 世纪 80 年代以来，致力于使用最新技术开发高性能的计算应用程序。他在英国管理几个大型的 HPC 和 e-science 项目。他对如何使网格得到广泛使用有浓厚兴趣。

原文链接: http://www.ibm.com/developerworks/cn/grid/gr-stdsportal1/index.html