WSRP（Web Services for Remote Portlets）引见(转)

WSRP（Web Services for Remote Portlets）介绍(转)

本文介绍了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 服务技术

使用门户的一个主要优点是，门户用户可以定制一组可用的应用程序（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. 涉及 WSRP 的一个典型的发布-发现-绑定（publish-find-bind）使用场景

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

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

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

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

http://www.oschina.net/bbs/thread/8003