WSRP（Web Services for Remote Portlets）介绍

From: http://www.ibm.com/developerworks/cn/webservices/ws-wsrp/

Bryan Castle ([email protected]), 高级顾问, Booz Allen Hamilton

2005 年 4 月 15 日

本文介绍了WSRP（Web Services for Remote Portlets），一个定义了如何利用基于 SOAP 的 Web 服务在门户应用程序中生成标记片断的规范。通过定义一组公共接口，WSRP 允许门户在它们的页面中显示远程运行的 portlet，而不需要门户开发人员进行任何编程。对于最终用户，这些 porlet 就和运行在他们本地的门户上一样，但是实际上这些 portlet 来自于远程运行的 portlet 容器，并且交互是通过 SOAP 消息的交换来实现的。在面向服务的体系结构中利用 WSRP 将是一个强大的组合，从而使面向呈现的 portlet 应用程序可以被发现并重用而不用任何额外的开发和部署活动。

在过去的几年中，面向服务的体系结构（SOA）已经变成了一个流行的行业术语，但其实这个概念并没什么新的东西。虽然 SOA 经常在技术团体中被讨论，但是 SOA 到底如何影响最终用户呢？最终用户需要查询一个服务目录来查找满足需求的 Web 服务吗？并且如果最终用户知道一个 Web 服务存在的话，如何与该服务进行通信？他需要编写一个客户端或者 UI 来同 Web 服务进行交互吗？恐怕不需要。那么，SOA 到底为最终的服务用户提供了什么直接的优点呢？ 恐怕也没有 －－ 更确切的说，到目前为止是这样。WSRP 是一项呈现技术，并且最近获得了众多门户市场主要厂商的支持，包括 IBM®，BEA，Oracle 和 Microsoft®。WSRP 的最终目标是将 Web 服务和面向服务体系结构的优点带给最终用户。

WSRP 规范是 OASIS（Organization for the Advancement of Structured Information Standards）的一个产品，这个组织是推动技术标准采纳的一个协会。WSRP 规范的 1.0 版本在 2003 年的八月份定稿，并且目前正在进行 2.0 版本的编写，预计将在 2005 年内推出。既然门户市场的主要成员都加入了 OASIS 的 WSRP Technical Committee，该项技术应该会继续在行业中被更广泛的接受。OASIS 的 WSRP 规范定义了通用的，设计良好的接口，可以与可插入的，面向呈现的 Web 服务进行交互。这些服务处理用户交互，并且为门户集合提供了标记片断。

上面定义中的两个最重要的术语需要特别注意。首先，该服务面向呈现，意味着他们提供了一个用户接口，允许最终用户直接与服务进行交互。这与在更程序化的级别上专注于处理需求和生成响应的传统 Web 服务是非常不同的。第二，该规范定义了通用的，良好定义的接口，来管理门户如何同服务进行通信，并且搜集为最终用户呈现页面所需的标记片断。正是这个通用的接口允许门户应用程序使用远程运行的容器中的 portlet。

WSRP 在现有的 Web 服务标准比如 SOAP，WSDL 和 UDDI 上构建并没什么价值（参阅参考资料）。虽然本文只是集中于最常见的 WSRP 使用场景 －－在门户中使用的 HTML 标记片断的生成 －－ 但用 WSRP 传输其他标记语言并没什么困难。图 1 显示了 WSRP 是如何适应技术体系的。

图 1. WSRP 依赖于现有的 Web 服务技术

在研究 WSRP 技术以前，首先我应该阐明术语门户和 portlet 的意思。门户的定义比较广泛；十个软件工程师可能得出十种不同的定义。基于本文的目的，门户可以被认为是一个基于 Web 的应用程序，最终用户可以自定义外观和门户包含的应用程序。更进一步，门户可以被认为是内容和应用程序的聚合，或者是一组用户工具和应用程序的单个入口点。

现在你已经知道了门户是什么，那么到底什么是 portlet 呢？portlet 可以被认为是一个小型的 Web 应用程序，与许多类似的实体一同运行在门户页面中。portlet 是一个 Web 组件，由容器进行管理，可以处理请求并生成动态内容。Portlets 有多种特性 －－ 一些是基于标准的，然而其他一些是他们所在的门户所专有的。Java Portlet 规范（JSR-168）在 2003 年 10 月份获得通过，该规范为基于 J2EE 的门户平台定义了一个标准 API。JSR-168 的目标是提供一套标准，任何符合标准的 portlet 可以部署在任何支持规范的门户上。图 2 显示了一个传统的门户模型，门户有一个 portlet 容器，运行多个不相关的 portlet。每个 portlet 都生成标记片断，门户把这些片断集合在一起，创建一个完整的页面呈现给用户

 

如果 Web 服务提供一个机制来创建独立于平台的服务，且 JSR-168 定义了一个标准来开发 portlet，那么你为什么需要 WSRP 呢？答案很简单。虽然 Web 服务提供了重用后端服务的能力，WSRP 却让你能够重用整个用户接口！

例如，你可能想要为门户的最终用户提供输入证券代码可以查询股票信息的能力。你知道目前很可能已经有 Web 服务提供了完整的功能。你可以在 UDDI 中查询这些股票报价服务。在查找到一个这种服务的基础上，接下来你需要编写一个客户端来绑定并使用 Web 服务，也可以开发一个 portlet 来允许门户用户与这个服务进行交互。使用 Web 服务工具包可以使 Web 服务客户端的开发相对容易；然而，开发用户接口可能不是这么简单。而且，你必须执行在你的门户服务器上部署新开发的 portlet 和 Web 服务的全部步骤。到这一步，你必须开发、编译和部署一些新的代码来向最终用户提供股票报价服务功能。虽然利用第三方开发的股票报价服务可以减少开发时间，但开发和部署为门户用户提供功能的前端应用程序的流程却是繁琐且耗时的。

在这个例子中加入 WSRP，你可以更加容易的将股票报价 portlet 集成到你的门户中。你可以浏览 UDDI 目录来为用户提供 portlet 本身，或者提供用户浏览 portlet 注册表的能力。一旦发现了 Stock Quote Portlet，将其添加到门户上只需要点击几下鼠标就完成了。你不需要执行任何代码编写或者部署活动，因为该 portlet 是通过 WSRP 来调用的。最终用户不需要了解任何关于 WSRP 的知识，甚至不知道他们的 portlet 实际上是远程托管的！最终用户只知道他们有一个可用的 portlet 目录，他们可以从中进行挑选。还有什么可以更容易呢？

在深入了解 WSRP 实际工作以前，让我们简要的说明一下 WSRP 体系结构中的不同部分。下面的图 3 举例说明了 WSRP 体系结构中的每个主要参与者，以及门户在聚集标记片断中所扮演的角色。虽然这个图只是显示了一个门户仅使用来自一个生产者的 WSRP portlet，但是没有理由说门户不能使用多个 WSRP 生产者提供的 portlet。WSRP 规范在 WRSP 体系结构中定义了如下的参与者：

• WSRP 生产者（WSRP producer）：这是一个 Web 服务，提供了一个或者多个 portlet，并且实现了一套 WSRP 接口，因此也为消费者提供了一组常用操作。生产者仅仅可以提供一个 portlet，或者提供一个运行时（或容器）来部署和管理多个 portlet，这取决于实现方式。 WSRP 生产者是一个真实的 Web 服务，通过 WSDL 和一组端点完成。WSRP 中的每个生产者都是通过标准的 WSDL 文档来描述的。
• WSRP portlet： WSRP portlet 是一个可插入的用户接口组件，存在于 WSRP 生产者内，通过生产者定义的接口进行远程访问。WSRP portlet 并不是一个 Web 服务（它不能被直接访问，必须通过他的父生产者来访问）。
• WSRP 消费者（WSRP consumer）：这是一个 Web 服务客户端，调用生产者提供的 WSRP Web 服务并且为用户提供环境来同一个或多个生产者提供的 portlet 进行交互。WSRP 消费者最常见的例子是门户。

 

正如前面间接提到的那样，WSRP 定义了一组公共接口，所有的 WSRP 生产者都需要实现这些接口，并且WSRP 消费者必须使用这些接口来同远程运行的 portlet 进行交互。由于这些接口已经被完善定义，用来同任何符合 WSRP 的生产者进行通信，因此标准化这些接口使门户可以与远程运行的 portlet 进行交互。WSRP 规范需要每个生产者实现两个必需的接口，还可以实现另外两个可选接口：

• 服务描述接口（必选）： 服务描述接口允许 WSRP 生产者向消费者介绍它的功能。WSRP 消费者可以使用这个接口来查询生产者，以便发现其提供了哪些 portlet，以及关于生产者自身的一些其他元数据。这个接口可以作为一个发现机制来确定所提供的 portlet，但是同样重要的是让消费者可以了解关于生产者技术能力的附加信息。生产者元数据可以包含消费者与任何 portlet 交互之前，生产者是否需要注册或初始化 cookie 的信息。
• 标记接口（必选）： 标记接口允许 WSRP 消费者同 WSRP 生产者的远程运行的 portlet 进行交互。例如，当用户通过门户页面提供一个表单时需要使用这个接口执行一些交互。另外，门户可能需要根据 portlet 当前的状态来获取最新的标记（例如当用户点击刷新或者与当前页面的另一个 portlet 进行交互的时候）。
• 注册接口（可选）： 注册接口允许 WSRP 生产者要求 WSRP 消费者在通过服务描述和标记接口与服务进行交互之前进行某种形式的注册。通过这个机制，生产者可以为特定类型的消费者定制他的行为。例如，生产者可能基于特定的消费者过滤一些提供的 portlet。另外，注册接口提供了一个机制允许生产者和消费者进行对话，这样他们可以交换关于彼此技术能力的信息。
• Portlet 管理接口（可选）： Portlet 管理接口使 WSRP 消费者可以访问远程运行的 portlet 的生命周期。通过这个接口，消费者具备定制 portlet 行为甚至是销毁一个远程运行的 portlet 实例的能力。

清单 1 显示了一个服务的 WSDL 定义，该服务支持必选和可选的接口。

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:urn="urn:oasis:names:tc:wsrp:v1:bind"
                  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  targetNamespace="urn:myproducer:wsdl">
  <wsdl:import namespace="urn:oasis:names:tc:wsrp:v1:bind"
        location="http://www.oasis-open.org/committees/wsrp/
           specifications/version1/wsrp_v1_bindings.wsdl"/>
  <wsdl:service name="WSRPService">
    <wsdl:port name="WSRPBaseService"
            binding="urn:WSRP_v1_Markup_Binding_SOAP">
 <soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
               location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
    <wsdl:port name="WSRPServiceDescriptionService"
               binding="urn:WSRP_v1_ServiceDescription_Binding_SOAP">
 <soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
               location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
    <wsdl:port name="WSRPRegistrationService"
               binding="urn:WSRP_v1_Registration_Binding_SOAP">
 <soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
        location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
    <wsdl:port name="WSRPPortletManagementService"
               binding="urn:WSRP_v1_PortletManagement_Binding_SOAP">
        <soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
        location="http://myproducer.com:7007/portal/producer"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

使用门户的一个主要优点是，门户用户可以定制一组可用的应用程序（portlet）。用户可以创建他自己的页面并且根据情况添加新的 portlet。然而，通过这样的方式定制门户，他首先必须知道什么 portlet 是可用的。如果有一个集中的注册中心（或可能是多个注册中心），门户用户可以动态的发现和绑定新的 portlet，根据他们特定的需求创建工作环境。

从 portlet 提供者的角度来看，集中的注册中心是相当重要的，因为它允许他们发布和描述他们提供的 portlet。提供者可以提供文本的描述、分类和其他的有用的元数据，从而详细描述他们的 portlet，使消费者可以更加有效的发现这些服务。毕竟，如果没人知道他们所提供的 portlet 的话，那么提供 portlet 又有什么意义呢？

通用描述和发现接口（Universal Description Discovery Interface，UDDI）提供了一个机制，将提供 portlet 服务的 WSRP 生产者和寻找新应用程序的 WSRP 消费者集中到一起。由于 UDDI 已经成为 Web 服务发现的标准，因此 UDDI 自然也成为 portlet 发现 的中心。但是，请不要混淆 -- 毕竟 portlet 不是真正的 Web 服务。

正如上面提到的那样，在 WSRP 世界，WSRP 生产者是真正的 Web 服务，并且 WSRP portlet 只能通过他们的生产者提供的 API 进行访问。虽然 WSRP portlet 从逻辑上可以被认为是一个服务，但是它并不是一个真正的服务，因为它没有提供可以供消费者直接调用的 API。然而，当处理 portlet 发现时，最常见的情况就是最终用户查找一个 portlet 并且将其添加到他的门户页面中。最终用户对 WSRP 生产者没有概念，他也没有必要理解 WSRP 的概念。然而，由于 portlet 只能通过它的生产者进行访问，因此 WSRP portlet 和 WSRP 生产者都必须公布在注册中心中。

应该注意一旦消费者已经在注册中心中发现了 portlet 服务，那么 portlet 的元数据就将包含消费者直接联系生产者和消费 portlet 的所有信息。Portlet 发现作为一个机制严格的执行，允许生产者在消费者可以发现的集中场所描述他们的 portlet 服务。

图 4 显示了一个典型的使用场景，有以下几个步骤：

1. 提供者已经开发了一组 portlet，通过设置 WSRP 生产者并将其公开为 WSRP portlet，使这些 portlet 可用。提供者希望这些 portlet 可以公用，因此他将它们发布到一个集中的 UDDI 注册中心中。由于 UDDI 公开了 Web 服务接口，提供者可以通过自定义构建 UI 或者 通过 UDDI 服务器提供的 UI 来执行发布。
2. 最终用户正在为他的门户寻找 portlet。他使用他的门户提供的工具（或者为了这个目的而自己编写的工具）执行了对 portlet 的查找，一旦用户发现想要添加到门户的 portlet，他很容易的就将新的 portlet 应用程序添加到他的一个门户页面上。或者，门户管理员可以搜索 UDDI 注册中心并将他们添加到门户的内部注册中心中，使其对于最终用户可用。
3. 当用户访问添加了新 portlet 的页面时，该页面现在就已包含了远程运行的 portlet。幕后的活动是门户将 Web 服务请求发送给远程生产者，生产者为门户返回标记片断以集成到门户页面中。然而，最终用户对 WSRP 的繁琐细节一无所知 －－ 他所知道的就是他可以将新的应用程序简单的无缝集成到他的门户中。
   
   

本文介绍了 WSRP，并且说明了如何利用 WSRP 的能力来方便的在现有门户中集成新的应用程序。WSRP 的出现意味者你不再是只可以重用后端服务，还可以重用面向呈现的服务。WSRP 可以被用来促进整个网络的面向呈现的 Web 服务开发。一旦使用得当，门户用户可以方便的发现并使用任意数量服务。开发人员没有必要创建定制的适配器、构建客户端代码，或者花费时间在本地部署 portlet。向门户工作环境中添加 portlet 仅仅需要点击几次鼠标。

本文仅仅介绍了一些实现 WSRP 的浅层次的技术细节，希望您现在对于 WSRP 如何变成一个强大的用于鼓励共享和重用前端应用的机制已经有了一个大体的了解。关于 WSRP 的更多信息请参阅下面的参考资料。

 

• 从 alphaWorks 上下载 WSRP Conformance Test Kit。
  
  
• 在 OASIS Web 站点上查找 WSRP Specification 1.0。
  
  
• 在 WSRP Primer from OASIS 中学习更多关于 WSRP 的知识。
  
  
• 要了解 Java Portlet 规范的更多信息， Sun 的 JSR-168 白皮书介绍是一个很好的起点。
  
  
• 你可以在 Java Community Process Web 站点查找到 JSR-168 规范和 API。
  
  
• 在 Arthur Ryman 的理解 Web 服务 （developerWorks，2003 年 7 月）中获取 Web 服务的更好的描述。
  
  
• 学习更多关于 UDDI 和其在面向服务体系结构中扮演的角色，请参考 Steve Graham 编写的"The role of private UDDI nodes in Web services" 系列文章（developerWorks，2001 年 5 月）。
  
  
• 访问 Developer Bookstore，获取技术书籍的完整列表，包含数百本 Web 服务主题的书籍。
  
  
• 通过参与 developerWorks blogs 加入到 developerWorks 社区。
  
  
• IBM developerWorks 社区有很多技术讲座，您可以免费申请参加。
  
  
• 想要更多信息？IBM developerWorks SOA 和 Web 服务专区有数百篇关于开发 Web 服务应用程序的文章和入门级、中级和高级教程。
  

Bryan Castle 是 Booz Allen Hamilton 的一名高级顾问。他专注于开发基于 Web 技术的解决方案，包括 J2EE 平台下的面向服务的体系结构和分布式计算技术。