用過濾器使現有Portlet適應新門戶應用程序

2019-11-18 13:16:57

字體：大中小

來源：轉載

供稿：網友

　　引言
　　已經開發和交付了為數眾多的 Portlet，這些 Portlet 可以安裝在 WebSphere Portal 中。除了包含在 WebSphere Portal 中的內部 Portlet 以外，企業應用程序供給商為了提供對他們的系統的訪問也開發了許多的 Portlet，單個開發人員為了執行特定的門戶功能或者為了提供針對特定問題的解決方案也紛紛推出了許多的 Portlet。單單通過 WebSphere 門戶目錄就已經可以找到成百上千的 Portlet 可供使用，這些 Portlet 涵蓋了各種各樣的應用程序和行業。通常，門戶將使用一個或多個現有的 Portlet 來提供特定的功能并加速開發過程。在某些情況下，由于安全性控制或不公開的接口的緣故，從門戶訪問特定于廠商的企業應用程序的惟一途徑就是使用現有的 Portlet。
　　
　　雖然 Portlet 一般會通過配置提供一些自定義功能，但通常這是很有限的。在將現有的 Portlet 用于門戶之前，有時還需要其他的自定義功能，包括簡單的自定義（如提供與門戶的其他部分更一致的外觀）和復雜的自定義（如添加新的功能）。我們來考慮一個現有的文件上傳 Portlet。我們可能需要加入一種常規算法來檢查待上傳的文件內容；假如文件內容不合適，那么在它抵達后臺系統之前會被拒絕。對于一個提供實時世界新聞的現有新聞頻道 Portlet，它可能只關注特定地區或特定主題的新聞，而不應該顯示其他的新聞。在很多情況下，門戶范圍的性能調優可能需要在門戶的每一個 Portlet 中添加其他的邏輯，以便測量執行時間。
　　
　　有多種方法可以修改和自定義現有的 Portlet。最常用的方法就是面向對象的繼續，它使你能夠從現有的 Portlet 派生新的 Portlet 以便添加新的功能，因為 Portlet 的核心是一個或多個 java 類。這種方法的主要缺點是：
　　
　　首先，新的 Portlet 要想能夠自定義，就必須從現有的 Portlet 創建。
　　其次，因為 Portlet 應用程序是作為 web 應用程序檔案文件（WAR）交付的，所以新的 Portlet 不能直接引用現有的 Portlet 的 WAR 中的類；WAR 中的所有類及其依靠性都必須先解包，然后再重新打包到新的 Portlet 的 WAR 中。
　　另外，調用 Portlet 方法（如 service 和 actionPerformed）時還必須謹慎以防它將只被容器調用。
　　
　　與基于繼續的自定義相比，WebSphere Portlet 過濾器技術提供了一種更輕易且更好的方法來重用和自定義現有的 Portlet：
　　
　　Portlet 過濾器是一個（或多個）可重用的 Java 類，可以通過一種標準的方式來聲明性地添加或刪除，而無需對它所修改的現有 Portlet 或 Portlet 組進行更改。
　　過濾器并不是一個 Portlet；過濾器不創建對請求的響應，但是它截取和修改請求（在請求傳送到目標 Portlet 以進行處理之前）及響應（在響應聚集到門戶頁面之前）。
　　過濾器并沒有綁定到任何特定的 Portlet，因此它的生命周期不依靠于任何單個 Portlet。這就意味著，一旦過濾器初始化完畢，它就能夠動態地應用到所有的可應用 Portlet，而無需進一步的初始化。
　　另外，由于過濾器獨立于任何 Portlet，所以現有的 Portlet 或 Portlet 的 WAR 幾乎不需要創建過濾器。
　　
　　WebSphere 代碼轉換和機器翻譯是基于 Portlet 過濾器技術。關于 WebSphere 代碼轉換和翻譯的具體描述可以在版本 5.0 的 WebSphere portal 信息中心中找到，而相關的文章列表請見參考資料部分。
　　
　　本文介紹了 WebSphere Portlet 過濾器的基礎知識、Portlet 過濾器和 Servlet 過濾器的不同之處、以及如何開發和使用 Portlet 過濾器來自定義 Portlet。另外，還將解決各種開發問題以幫助簡化其使用。一種稱為文件內容過濾器（File Content Filter）的過濾器為現有的文件上傳 Portlet 添加了細粒度的文件控制機制，本文就是以它為例來說明 Portlet 過濾器的使用的。
　　
　　您可以找到一些適用于 WebSphere Portal 的文件上傳 Portlet。在 WebSphere Portal 中 Portal Document Manager（PDM）Portlet 和 Portlet Installation Portlet 都是缺省安裝的。更有許多是在 WebSphere Portal Catalog 中列出的。本文以 PDM Portlet（PDM）為例來說明文件內容過濾器的使用。在 WebSphere Portal V5 中，PDM Portlet 在缺省狀態下自動安裝在 My Portal 中的 Document 頁面內。它給門戶的用戶提供了簡單實時的文檔查看和解決方案。PDM 讓用戶具有編輯者（Editor）的權限，使得他們幾乎可以上傳任何類型的文件。然而，對于許多組織來說，這種功能的需求可能遠遠比 PDM Portlet 提供的標準行為復雜得多。例如，文件控制機制可以用于控制能夠上傳的文件的類型、記錄上傳的文件和它們的屬性、報告上傳成功或失敗的狀態等等。本文中的文件內容過濾器將修改 PDM Portlet 的行為，這樣就只有某些類型的文件被答應上傳。
　　
　　Portlet 過濾器與 Servlet 過濾器
　　假如您熟悉 Servlet 過濾器（請參閱 Java Servlet 規范以獲得具體信息），從已經閱讀的資料中，您可能已經注重到了 Portlet 過濾器和 Servlet 過濾器的相似性。實際上，它們之所以是相似的，是因為二者都可以聲明性地嵌入，從而截獲并修改請求和響應。但是理解它們之間存在著很大的不同是非常重要的。在一定程度上，它們之間的差異是與 Servlet 和 Portlet 之間的差異相聯系的：Servlet 過濾器是一個門戶級過濾器，它可以修改由一些小的部分（來自頁面上所有 Portlet 的響應）集合而成的整個門戶頁面；而 Portlet 過濾器只能用于那些小的部分。Servlet 過濾器（假如已經安裝的話）是接收和修改客戶端請求的第一個組件，同時也是修改對客戶端的響應的最后一個組件（請參見圖 1）。
　　
　　圖 1. 帶有 Servlet 過濾器和 Portlet 過濾器的客戶端請求事件序列
　　　用過濾器使現有Portlet適應新門戶應用程序（圖一）

　　如圖 1 所示， Servlet 請求（步驟 1）在分派給一個或多個 Portlet 請求（步驟 3）之前首先通過一個 Servlet 過濾器鏈進行處理（步驟 2）。在結果集聚到一起（步驟 6 和 7）之前，Portlet 請求進一步轉發到 Portlet 過濾器鏈進行處理（步驟4）。接著，將集聚的結果發送回 Servlet 過濾器進行處理，之后，將集聚的結果最終顯示給用戶（步驟 9）。
　　
　　一個過濾器鏈包含一個或多個過濾器。在一個過濾器完成處理之后，新的請求和響應將傳送到鏈上的下一個過濾器；鏈上的最后一個過濾器調用目標資源（Servlet 或 Portlet）。
　　
　　與 Servlet 過濾器一樣，Portlet 過濾器也是 WebSphere portal 體系結構中的一個可選的組件。因此在解決實際的問題時，可以使用一種類型的過濾器，也可以同時使用兩種類型的過濾器，還可以不使用過濾器。例如，Servlet 過濾器可以用于壓縮和加密整個門戶頁面，而 Portlet 過濾器可能更適合只壓縮和加密門戶頁面的一部分。在 WebSphere Portal Transcoding Technology（請參見參考資料）中，Portlet 級代碼轉換使用 Portlet 過濾器來進行內容轉換、標記轉換和注解等等，而門戶級代碼轉換使用 Servlet 過濾器（或門戶過濾器，在 WebSphere portal 中是這樣稱呼的）來提供 Deck 片段。
　　
　　Portlet 過濾器的支持和開發
　　Portlet 過濾器的支持類定義在 WebSphere portal 的 com.ibm.wps.pe.pc.legacy.cmpf 包中。PortletFilter 接口提供了三個方法來治理 Portlet 的生命周期：
　　
　　void init(PortletFilterConfig config)
　　容器調用一次這個方法來預備用于服務的過濾器。對象 PortletFilterConfig(config) 使得過濾器能夠訪問配置參數以及對門戶上下文的引用。
　　void destroy()
　　這個方法是在將過濾器從服務移除之后調用的。這個方法使得過濾器能夠清除任何存放的資源。
　　void doFilter(PortletFilter.Method method, PortletRequest request, PortletResponse response, PortletFilterChain filterChain)
　　這個方法執行實際的過濾工作。這個方法使得過濾器能夠檢查和修改請求和響應，或者完全跳過請求的處理。第一個參數（method）是過濾器能夠調用的請求方法的類型（如 SERVICE 或 ACTIONEVENT）。最后的參數（filterChain）包含一個已經注冊且正在運行的過濾器的列表。
　　
　　包中的 PortletFilterAdapter 類為 PortletFilter 接口提供了一個缺省的實現。根據作為 doFilter 方法中的第一個參數傳送的請求方法的類型，可以將 doFilter 方法的缺省實現委托給一組 do 方法（doService、doTitle、doActionEvent、doMessageEvent、doLogin、doBeginPage 和 doEndPage）。do 方法的缺省實現做的惟一一件事情就是將最初的請求和響應發送到鏈上的下一個過濾器或目標 Portlet。過濾器的每個 do 方法都是在目標 Portlet 的對應方法調用之前調用的。表 1 列出了每個過濾器方法和目標 Portlet 方法之間的映射。
　　
　　表 1. Portlet 和 Portlet 過濾器方法
　　　用過濾器使現有Portlet適應新門戶應用程序（圖二）

　　自定義的 Portlet 過濾器應該擴展 PortletFilterAdapter 類，并且覆蓋表 1 中所列的一個或多個方法。舉例來說，假如自定義過濾器僅支持 Portlet VIEW 并且修改輸出，那么就只需要覆蓋 doService 方法。然而，假如過濾器支持 Portlet ActionEvent 并且修改輸出，那么 doService 和 doActionEvent 都應該被覆蓋（請參見下一部分以獲得具體信息）。WebSphere Portal 提供了三個便利的包裝類：
　　
　　PortletRequestWrapper（用于 PortletRequest）
　　PortletResponseWrapper（用于 PortletResponse）
　　ClientWrapper（用于客戶端接口）
　　
　　包裝類應該用于創建自定義請求、響應和客戶端類，這樣，就可以輕易地添加新的功能而不必實現整個接口了。
　　
　　圖 2. 帶有 Portlet 過濾器的服務請求的請求

上一篇：創建通過 WDO訪問數據的 JSF 應用程序（5）

下一篇：華山論劍：C＃對Java