IBM®
跳转到主要内容
    中国 [选择]    使用条款
 
 
Select a scope:Search for:    
    首页    产品    服务与解决方案     支持与下载    个性化服务    
跳转到主要内容

developerWorks 中国  >  Grid computing  >

基于标准的网格门户开发,第 3 部分: WSRP 和网格门户的未来发展

developerWorks
文档选项

未显示需要 JavaScript 的文档选项


级别: 中级

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 年 6 月 28 日

构建于网格中间件之上的网格门户担当着网格大门的角色,因为它们使人们能更顺利地学习使用网格。在共分三部分的 “开发基于标准的网格门户” 系列文章的第 1 部分中,我们将对网格门户作一个总体介绍,重点讲述当前基于标准(JSR 168 和 WSRP 1.0)的第二代网格门户。在第 2 部分中,我们开发了 3 个 portlet 来阐述如何使用 JSR 168 兼容 portlet 来构建网格门户。本文是该系列文章的第 3 部分,我们将讨论 WSRP 的应用以及网格门户的未来发展。

在网格门户中使用 WSRP 的研究

当我们在 第 1 部分 中讨论为门户开发应用 SOA 技术时,关键概念之一是表示逻辑可以与业务逻辑集成在一起,并作为一个服务对外提供。WSRP V1.0 规范对如何使用 Web 服务技术将 portlet 提供给远程 portlet 容器进行了标准化。在 WSRP 中,生产者会作为 portlet 所在的 portlet 容器进行建模。这种生产者可以用作服务提供者,同时,各个客户机都可以消费这种调用 portlet 所使用的服务。要清楚地理解 WSRP 是如何工作的,请阅读 WSRP V1.0 Primer,以及 V1.0 规范本身(请参看 参考资料)。

WSRP4J: 开源 WSRP V1.0 实现

WSRP V1.0 定义的 4 个接口

ServiceDescription 接口 是一个必需的接口,它为获取制造商的元数据定义了一个操作,让消费者可以发现生产者所提供的服务。

Markup 接口 是第二个必需的接口,定义了从 portlet 获取标记以及处理用户与该标记之间的交互所执行的操作。它也会处理 HTTP cookie。

Registration 接口 是一个可选接口,它让消费者可以通过定义建立、更新和销毁注册的操作来在生产者处注册。

PortletManagement 接口 是另外一个可选接口,它包括了 portlet 的生命周期和属性。这个接口定义了获取 portlet 元数据、为进一步定制化克隆 portlet 以及与属性接口进行交互所需要的操作。

尽管由 IBM® 所发起的 Apache WSRP4J 项目仍然处于孵化阶段,但是以我们的经验来看,WSRP4J 生产者比其他开源门户框架(例如 eXo 平台和 Liferay)的 WSRP 生产者更具实用性。因此,我们选择 WSRP4J 来解释在本系列文章中开发的网格 portlet 如何在其他系统中重用,从而允许配备 WSRP 的消费者充分利用网格工具的优势,而不用进行本地开发。

WSRP4J 生产者使用了 Pluto —— Apache 提供的 JSR 168 的参考实现 —— 作为自己的 portlet 容器。它提供了 4 个 WSRP V1.0 规范的定义的接口:ServiceDescription、Markup、Registration(可选的)和 PortletManagement(可选的)。消费者可以与 ServiceDescription 接口进行联系,从而检索对生产者的描述,包括它持有的所有 portlet 和本地支持信息。消费者然后可以与生产者联系,从而访问一个特定的 portlet 。Markup 接口负责接收请求,并返回标记片断(portlet 的输出)。

发布和使用样例网格 portlet

本文不会详细介绍如何安装和配置 WSRP4J 生产者。通常,要将 portlet 部署到 WSRP4J 生产者中,首先需要将编译好的 war 文件拷贝到 Tomcat 中,这是部署 WSRP4J 生产者的位置。记得要将这个 war 文件重命名为 grid.war。您必须要在 WSRP4J 生产者目录中名为 portletentityregistry.xml 的文件中注册这个 portlet ,如清单 1 所示。(更多信息请参看 参考资料。)


清单 1. 在 WSRP4J 生产者中注册 portlet
                
    <application id="grid">
        <definition-id>grid</definition-id>
        <portlet id="LdapBrowserPortlet">
            <definition-id>grid.LdapBrowserPortlet</definition-id>
        </portlet>
        <portlet id="JobSubmissionPortlet">
            <definition-id>grid.JobSubmissionPortlet</definition-id>
        </portlet>
        <portlet id="ProxyManagerPortlet">
            <definition-id>grid.ProxyManagerPortlet</definition-id>
        </portlet>
    </application>

一旦 portlet 被部署到 WSRP4J 生产者内部之后,消费者就可以请求访问这些 portlet 了。要发布 uPortal 中的一个远程 portlet,您需要定义上面介绍的 WSRP4J 生产者接口,以及 portlet 的句柄,后者与上面的 definition-id 相同。 Axis TCP Monitor 是用来监视 WSRP 消费者和生产者通信的一个非常有用的工具。图 1a 和图 1b 是两个屏幕快照,分别说明了在 uPortal 和 Sakai 中 LDAP Browser 和 Proxy Manager portlet 的使用情况。(Sakai 是一个开源 e-Learning 框架,更多信息请参看 参考资料。)uPortal 有自己的 WSRP 消费者,而 Sakai 则配备了我们基于 WSRP4J 消费者 ProxyPortlet 所开发的一个 WSRP 消费者。


图 1a. 通过 WSRP 在 uPortal 内部运行的 LDAP Browser portlet
通过 WSRP 在 uPortal 内部运行的 LDAP Browser  portlet


图 1b. 通过 WSRP 在 Sakai 内部运行的 Proxy Manager portlet
通过 WSRP 在 Sakai 内部运行的 Proxy Manager  portlet

尽管网格 portlet 可以直接部署到 uPortal 内部,但是我们并没有将它们部署到 Sakai 中,这是因为在撰写本文时,Sakai 尚不支持 JSR 168 规范。这清楚地展示了 WSRP 的强大功能。不用重新部署这些网格 portlet ,Uportal 和(尤其是)Sakai 现在可以提供在远程 WSRP4J 中进行维护的网格工具。惟一的需求是它针对一般的 WSRP 消费者。这种方法可以消除本地部署网格工具的需求,在某些情况中,这种需求是不希望的。





回页首


网格门户的未来发展

网格门户在 Web 和网格之间架起了一座桥梁。如今,第二代网格门户主要依赖于 Java™ 标准。JSR 168 可以帮助门户开发人员编写可重用的 Web 组件,而 WSRP V1.0 则定义了一种 Web 服务方法来重用这些组件。为了响应最终用户的要求,网格门户正在变得越来越复杂。目前,网格门户正着重于服务和资源的集成,其中可视化和工作流是两个非常重要的方面。

可视化和工作流

可视化对于科学研究中的实验和数值研究必不可少。复杂的可视化系统通常需要专用硬件和软件,而它们很难集成到 Web 门户中。目前,可视化依然限制于 Java 2D/3D、Java applet 和 Java Web Start 技术的使用,它与网格门户是相对独立的。网格也引入了分布式数据源,这对于可视化技术也是一种挑战。有时候,数字仿真过程中需要对临时结果进行交互式可视化,这样就可以根据可视化的反馈来随时调整、暂停并重用这些结果。

工作流对于网格门户的重要性正在日益增加,尤其是因为诸如 GT4 之类的网格中间件正在并入到面向服务架构(SOA)中。随着更多服务的开发,将会对工作流系统进行广泛地研究,以提供服务集成的能力。例如,生物信息学中一个典型的科学研究程序可能会涉及以特定顺序执行的一组服务。这可以通过使用诸如 Taverna(英国 myGrid 项目中的一个组件)之类的工作流系统进行很好的管理。

与可视化类似,工作流系统通常也都有自己的 GUI,这使它很难集成到网格门户中 —— 通过 Java applet 之类的方法可以使集成变为可能。目前正在进行一些将工作流系统集成到网格门户中的工作。举例来说,JSR 168 portlet 可以在 GridSphere 中进行部署和测试,从而通过一个门户接口来提供 myGrid 工作流。

尽管目前正在进行可视化和工作量在网格门户中的集成工作,但是以我们的经验来看,网格门户依然没有用于这些目的的桌面应用程序那样吸引人。这也解释了为什么门户用户不多的原因。总之,需要加强门户开发人员与最终用户之间的沟通,这样门户才能符合最终用户的需要。接下来,我们将讨论如何从技术的观点吸引最终用户。

Web 2.0

在 Web 设计和开发社区中,Web 2.0 已经成为一个非常热门的术语。尽管很难为 Web 2.0 给出一个精确的定义,但是 Web 2.0 包含了很多内容托管方面的技术,例如 blogs、wikis、RSS 提要等。这些技术的目标都是为信息共享提供更具协作性和交互性的 Web 环境。用户不仅仅作为信息接收者,还可以作为信息提供者。

除了基于社区的技术之外,Asynchronous JavaScript And XML(Ajax)通过利用与 Web 浏览器进行交互的空闲时间来构建交互式富 Web 应用程序。Google 就是最终用户体验 Ajax 强大功能的一个很好例子。Gmail、Google Suggest 和 Google Maps 都利用了 Ajax 来增强与用户的交互能力。例如,当用户输入某个搜索术语时,Google Suggest 会弹出一些关键字来帮助用户完成输入。

Google Maps 允许用户将地图拖拽到不同的视图中,而不用等待服务器的响应 —— 实际上没有必要刷新整个 Web 页面。传统的在线地图提供商,例如 Multimap.com,要求用户每次操作都需要等待服务器的响应才能刷新整个页面。

Ajax 可以应用到 JSR 168 portlet 中,因为它们都是基于 JavaScript 的。例如,Google portlet 中的 portlet 可以进行拖拽,这样用户就可以根据自己的喜好来简单地放置自己的 portlet。图 2 给出了一个正在被拖往一个新位置的 “Quote of the Day” portlet。图 2 中的虚线框表示这个 portlet 的当前位置。


图 2. Google portlet:正被拖拽的 portlet
Google portlet:正被拖拽的 portlet

显然,portlet 开发人员可以使用 Ajax 来设计交互性更好的 portlet,从某种程度上来说,这会成为吸引最终用户的关键。但是根据我们最初的调查结果,由于安全性方面的考虑,Ajax 并不能在远程 portlet 中很好地工作,不过已经存在一种解决方案了。

对于在研究活动中交流思想、组织项目会议等方面,还需要一些协作工具,例如即时消息和在线论坛。网格门户可以用作配备了一些协作工具的 电子学习或电子调研系统的网关。我们相信这些网格门户可以吸引更多用户。

重用现有的 Web 应用程序

缺少可以共享的开源 portlet 现在已经变成一个实际问题了。因此,将现有应用程序转换成 portlet 非常重要。例如,Struts 和 JavaServer Framework(JSF)是市场上两个主要的 Web 开发框架。Struts 在 Java 领域被广泛地用于 Web 开发框架,而其后继者 JSF 现在已经成为 Java EE 5 的一部分,可以作为一种关键呈现技术使用。JSF 通过充分利用 Inversion of Control(IoC)和 UI 组件对 Web 开发进行了简化。这些 UI 组件都有自己的状态 —— 事件加上输入转换和验证。它们都可以被编写并分发给其他 Web 开发人员。

诸如 Struts 和 JSF 之类的技术应该在 portlet 开发中受到支持,因为它们现在已经是 Web 开发的主流了。基于 Struts 的 Web 应用程序有很多,新颖的 JSF 技术也正在获得用户的兴趣。Apache Portals 中的 Struts 和 JSF 桥接器非常有吸引力,因为它们承诺不需(或只需很少的)改变就可以将 Struts 和 JSF 应用程序作为 portlet 应用程序部署。除了 Struts 和 JSF 之外, Apache Portals 为 PHP、Perl 和 Velocity 提供了桥接器。

Shibboleth

作为服务客户机,门户自然会与本地或远程服务进行通信。凭证委托对于构建安全门户和服务非常关键。除了诸如 XML Signature、XML Encryption、WS-Security、SAML 和 XACML 之外,Shibboleth 主要注重联邦门户的构建,其中的 Web 资源可以被共享。Shibboleth 是网格门户中单点登录(SSO)的一个很好例子。在英国,Shibboleth 正在被部署为高校中的单点身份验证,用于访问分布式数字资源。这些机构和大学都有自己的身份验证系统供本地用户使用,它们都可以在启用 Shibboleth 的 Web 应用程序中使用。

门户联邦

当我们讨论有关网格门户中的 SOA 时,重要的是不但要对服务进行重用,而且还要对诸如 portlet 之类的组件进行重用。后者是构建将来的联邦门户的关键。门户应该使用本地和远程 portlet 来构建,其元数据都分布在注册服务器上。





回页首


结束语

分享这篇文章……

digg 将本文提交到 Digg
del.icio.us 发布到 del.icio.us
Slashdot 提交到 Slashdot!

目前,作为网格社区中的资源和应用程序网关,网格门户扮演了非常重要的角色。特别是,网格门户通过 Web 浏览器为研究人员提供了一个熟悉的 UI,它隐藏了计算网格和数据网格系统的复杂性。在这个共分 3 部分系列文章中,我们对门户进行了总体介绍,并对第一代和第二代网格门户进行了讨论。我们构建了 3 个网格 portlet 来展示如何使用 JSR 168 兼容 portlet 构建基本的网格门户。我们还展示了如何通过 WSRP 来重用这些网格 prtlet,并对未来的网格门户开发进行了思考。

JSR 168 和 WSRP V1.0 是两个用来解决 portlet 和 portlet 容器之间互操作性问题的规范。特别是,目前的网格门户是面向服务的。一方面,门户可以作为服务客户机来使用传统的以数据为中心的 Web 服务。另外一方面,门户提供了以呈现为中心的服务,这样就能够轻易地构建联邦门户。

随着与网格有关的基本功能的成功实现(如代理管理器和作业提交),高级网格门户目前着重于与复杂应用程序的集成,包括可视化和工作流系统。Web 2.0 技术已经出现了,Ajax 被推荐用于门户开发,从而使网格门户更具交互性,更加吸引用户。将来,网格门户还应该将现有的 Web 应用程序包括进来。随着安全技术的不断发展,凭证委托也会在网格服务的联邦和共享中扮演重要角色。



参考资料

学习
  • 您可以参阅本文在 developerWorks 全球网站上的 英文原文

  • 请阅读 “基于标准的网格门户开发” 系列文章的 第 1 部分

  • 请阅读 “基于标准的网格门户开发” 系列文章的 第 2 部分

  • JSR 168 是 JCP 开发的一个 portlet 规范,用来对 portlet 和 portlet 容器之间的通信进行标准化。

  • WSRP V1.0 是由 OASIS 开发的 portlet 规范,用来对 portlet 容器之间的通信进行标准化 。

  • WSRP V1.0 Primer 为介绍 WSRP V1.0 规范的主要概念提供了一个面向教程的说明。

  • 请务必阅读 Jesse James Garrett 撰写的 “Ajax: A New Approach to Web Applications”。

  • Shibboleth 是一个基于标准的开源中间件,提供了在组织边界内部或组织边界之间提供 Web 单点登录(SSO)功能。

  • 浏览 developerWorks 上的 网格技术文档库

  • 要收听针对软件开发人员的有趣访谈和讨论,请查看 developerWorks podcasts

  • 随时关注 developerWorks 技术活动和网络广播

  • 了解全球范围内即将来临的面向 IBM 开源开发人员的会议、商业展览、网络广播和其他 事件

  • 请访问 developerWorks 中国网站开源软件技术专区,这里有丰富的 how-to 信息、工具和项目更新信息,可以帮助您使用开源技术进行开发,并与 IBM 产品一起使用。


获得产品和技术
  • Globus Toolkit 是启用网格的一个事实上的标准实现。

  • myGrid Project 的目的是为了激发对网格技术的兴趣,其重点是信息网格。

  • Pluto 是 Apache 提供的 JSR 168 的参考实现。

  • Sakai Project 的目标是为培训提供协作和学习环境。

  • WSRP4J 提供了 Apache 开发的一个 WSRP V1.0 规范的实现。

  • 请下载 IBM 产品评测版,试用来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。

  • 使用 IBM 试用版软件 改进您的下一个开源开发项目,这些软件可以从 developerWorks 下载或从 DVD 获得。

讨论


作者简介

 Xiaobo Yang

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


Xiao Dong Wang

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


Robert Allan

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




对本文的评价

太差! (1)
需提高 (2)
一般;尚可 (3)
好文章 (4)
真棒!(5)

建议?




回页首


IBM 公司保留在 developerWorks 网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可,请勿转载。如果您希望转载,请通过 提交转载请求表单 联系我们的编辑团队。
    关于 IBM 隐私条约 联系 IBM 使用条款