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 顯示了一個典型的使用場景，有以下幾個步驟：
- 提供者已經開發了一組 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 的更多資訊請參閱下面的參考資料。
- 從 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 平台下的面向服務的體系結構和分布式計算技術。