1 概述
門戶（Portal）一詞從最初被提出，到2003年十月發布的Portlet1.0規范以及2005年十二月重新投票通過的Portlet2.0規范以來，已經有很長一段歷史了。非常流行的Spring框架也在2.0 M1版本將Potlet MVC框架融入進來。但Portlet MVC框架和現在流行的MVC框架的無縫整合還是不太理想，直接影響Portlet技術的普及率。那么此技術究竟是歷久彌新的技術還是日漸消亡，最終被取代的技術？不是本文所要說明的重點。本文主要是從一個Portal初學者的角度對Portal的主要概念，應用場景等等做一些簡單的描述，作為本階段Portal研究的一個總結報告，并為將來做更深層次的研究做好準備。
2 基本概念
這部分主要針對JSR168規范中的主要內容做了一些說明。
在Portlet規范中是這樣描述Portal的，“Portal是一種Web應用，通常用來提供個性化、單點登錄、聚集各個信息源的內容，并作為信息系統表現層的宿主。聚集是指將來自各個信息源的內容集成到一個Web頁面里的活動”。
Portal功能可以主要分為以下幾個方面：
1) 個性化：個性化服務的基本實現使用戶能從兩個方面個性化他的頁面：第一，頁面的個性化，用戶用戶根據自身喜好決定標題條的顏色和圖標；第二，內容的個性化，用戶可以決定他的頁面上有哪些Portlets。例如，如果我是個體育迷，我可能會用一個能提供我鐘愛球隊的portlet來取代股票和新聞的portlets。另外，基于規則的個性化，一些在個性化服務方面領先的商業實現版本允許你自定義為用戶顯示什么樣的頁面所依據的標準（如收入和興趣）。在這種情況下，可以設定像“對收入為X的用戶顯示饋贈商品的portlet”和“對收入為X用戶顯示打折商品的portlet”這樣的商業規則。例如，WebSphere Portal 5的個性化功能可以基于規則引擎，用戶喜好（preference）和用戶屬性信息（profile）來定制用戶相關的個性化頁面。Weblogic Portal的文檔中是這樣描述個性化內容的，“個性化內容就是根據特定上下文（通常和當前用戶相關聯）而生成的內容。在Weblogic Portal中，這個特定上下文一般包括用戶屬性信息（profile），用戶當前的請求（request），用戶當前的session，當前的日期和時間（date and time），另外，Portal也支持自定義業務規則來滿足特定的用戶需求”。
2) 單點登錄：只需登錄Portal服務器一次就可以訪問所有其它的應用，這意味著你無需再分別登錄每一個應用。例如一旦我登錄了我的intranet網站，我就能訪問mail應用、IM消息應用和其它的intranet應用，不必再分別登錄這些應用。Portal服務器會為你分配一個通行證庫。你只需要在mail應用力設定一詞用戶名和密碼，這些信息將以加密的方式存儲在通行證庫中。在你已登錄到intranet網站并要訪問mail應用的時候，portal服務器會從通行證庫中讀取你的通行證替你登錄到mail服務器上。你對其它應用的訪問也將照此處理。
3) 內容聚集：Portlet規范中規定portal的主要工作之一是聚集由各種portlet應用生成的內容。Portlets是一種Web組件，就像servlets一樣是專門為合成頁面里的內容聚集在一起而設計的。通常請求一個portal頁面會引發多個portlets被調用。每個portlet都會生成標記段，并與別的portlets生成的標記段組合在一起嵌入到portal頁面的標記內。
1) portlet：Portlet是被portlet容器所管理的基于Java技術的web組件，它處理客戶端請求并生成動態內容。通常請求一個portal頁面引發多個portlets被調用，每個portlet都會生成一個標記段，并與別的portlets生成的標記段組合在一起形成一個完整的portal頁面展示給用戶。每個portlet的生命周期被portlet容器所管理。每個portlet可能隨當前登錄用戶不同而生成不同的內容。
2) portlet容器：Portlet容器負責管理portlets的生命周期并提供portlets的運行環境。它還提供portlet preferences的持久化存儲功能。Portlet容器從portal接受請求并分配到它所管理的potlets中去執行。
3) portlets和servlets的關系：
portlets在以下方面與servlets相似：
l portlets是基于Java技術的web組件；
l porlets由特定的容器管理；
l portlets生成動態內容；
l portlets的生命周期由容器管理；
l portlets通過請求/響應模式與web客戶端交互。
portlets在以下方面與servlets相異：
l portlets只能生成標記段，而不是整個文檔；
l portlets沒有可供直接訪問的URL地址。不過你還是能夠讓別人通過URL訪問到portlet，你可以把包含該portlet的頁面的URL發給他；
l web客戶端通過一個portal系統和portlets交互；
l portlets包含action請求和render請求；
l portlets有預先定義好的portlet模式和窗口狀態；
l portlets可以在一個portal頁面上同時存在多個；
l portlets不能在響應中設置字符集編碼和HTTP 和headers；
portlets和servlets/JSP的通訊：
portlet容器和servlet容器的關系：
portlet容器是servlet容器的擴展，于是portlet容器一般是建立在servlet容器之上并且具有servlet容器所有的功能，portlet容器支持Servlet規范2.3。
4) portlets附加的功能：
l 設置參數的持久化存儲：portlets提供了一個PortletPreferences對象用來保存用戶的設置參數。這些參數被存入一個持久化數據庫，這樣服務器重啟后數據依然有效。開發者不必關心這些數據存儲的具體實現機制。
l 請求處理：portlets提供了更為細粒度的請求處理。對于用戶在portlet上動作時向該portlet發出的請求(一種稱為活躍期的狀態)，或者因用戶在其它portlet上動作而引發的刷新頁面請求，Portal服務器提供了兩種不同的回調方法來處理。
l Portlet模式：portlets用模式的概念來表示用戶在做什么。JSR 168定義了三種Portlet模式：VIEW、EDIT和HELP。一個portlet實例在任何時候都可以恰巧在一種 portlet模式下。其他自定義portlet模式（如配置和源）都是可能的。VIEW模式是默認的模式。Portlet規范建議EDIT模式允許portlet用戶定制portlet實例，以及HELP模式顯示關于portlet的用法信息。Portlet必須支持VIEW模式，但在portlet中對EDIT模式和HELP模式的支持是可選的。在使用mail應用的時候，你可能會用它來讀信、寫信或檢查信件――這些都是mail應用的預定功能，Portlets通常以VIEW模式提供這些功能。但還有一些活動，像指定刷新時間或（重新）設置用戶名和密碼，這些活動允許用戶定制應用的行為，因此它們用的是EDIT模式。Mail應用的幫助功能用的是HELP模式。
l 窗口狀態：窗口狀態決定了portal頁面上留給portlet生成內容的空間。JSR 168定義了三種Window狀態：NORMAL、MINIMIZED和MAXIMIZED。Portlet實例任何時候都可以恰好是一種window狀態。其他自定義window狀態（如半頁）也是可能的。在NORMAL狀態下，portlet占了屏幕區的一小部分。屏幕狀態與其他portlet共享。在MINIMIZED狀態下，portlet的內容被隱藏, portlet只顯示為標題條。在MAXIMIZED狀態下，portlet的內容占屏幕區的大部分。其他共享同一頁面的portlet在MAXIMIZED狀態下被隱藏。
l 用戶信息：通常portlets向發出請求的用戶提供個性化的內容，為了能更加行之有效，portlets需要訪問用戶的屬性信息，如姓名、email、電話等。Portlet API為此提供了用戶屬性的概念，開發者能夠用標準的方式訪問這些屬性，并由管理員負責在這些屬性與真實的用戶信息數據庫（通常是LDAP服務器）之間建立映射關系。
l portlet context：每個portlet關聯一個PortletContext對象的實例。通過此對象，可以獲得上下文相關的初始化參數，設置和保存一些上下文相關的屬性以供別的servlets和portlets獲取。另外還可以通過它得到一個request dispatcher對象來轉發到servlets和JSPs。
圖2.3.1顯示了Portal頁面的各種元素。
圖2.3.1 portal頁面的元素
每個portlet頁面由一個或多個portlet窗口組成，每個portlet窗口又分為兩部分：一個是外觀，它決定了portlet窗口的標題條、控制和邊界的樣式；另一個是portlet段，它由portlet應用填充。Portal服務器決定了portal頁面的整體觀感，像標識、標題條顏色、控制圖標等。通過修改幾個JSP和css模板文件就可以改變portal的整個觀感。
為了成功地創建portlet，您必須遵照portlet生命周期。javax.portlet.Portlet接口中的方法定義了該生命周期，這些生命周期方法是init()、render()、processAction()和destroy()。
1) 初始化
當啟動一個portlet應用或懶加載條件下portal容器需要某個portlet來執行來自客戶端的請求時，需要執行init()方法。它用于獲得所需的任何昂貴資源（如數據庫連接），并執行其它一次性活動。在portlets初始化時，經常需要用到portletConfig對象獲取初始化參數和各種資源。
2) 處理請求
通過調用processAction()方法處理不同種類的動作和render()方法呈現內容。通常是通過portlets創建的URL提交請求。Portlet URLs包括action URLs和render URLs兩種類型。一般情況下，一個aciton URL對應一個action請求和當前portle頁面上所有的portlets的render請求，一個render URL對應當前portle頁面上所有的portlets的render請求。但是如果portlet使用了緩存技術，則portal/portlet容器可能不會調用render()方法，而直接從緩存中取出展現標記段。
l 動作處理
調用processAction()方法，在此方法中可以獲得ActionRequest和ActionResponse兩個參數。通過ActionRequest參數，可以獲取action請求的參數，窗口狀態，porlet模式，portal上下文對象，portlet會話對象和portlet preference數據。在處理action請求時，可以轉發到一個指定的URL。通過ActionResponse對象，portlet可以改變它的模式和窗口狀態。
l 呈現內容
調用render()方法，在此方法可以獲得RenderRequest參數和RenderResponse兩個參數。通過RenderRequest參數，可以獲取action請求的參數，窗口狀態，porlet模式，portal上下文對象，portlet會話對象和portlet preference數據。通過RenderResponse對象可以生成呈現內容或委托給servlet或JSP生成呈現內容。但也有一些限制：第一，生成HTML標記段不得使用下列標簽：base, body, iframe, frame, frameset, head, html和title；第二，生成XHTML和基于XHTML標記段不得使用下列標簽：base, body, iframe, head, html和title。
javax.portlet.GenericPortlet類提供了呈現內容的一些默認功能。我們創建的大多數portlet將會擴展javax.portlet.GenericPortlet類，而不是直接實現javax.portlet.Portlet接口。GenericPortlet類實現了render()方法。如果portlet的window狀態被最小化，那么render()方法不能做任何事情。如果portlet的window狀態不是最小化，那么render()方法設置在portlet.xml文件中指定的標題，并調用doDispatch()方法。根據Portlet模式， doDispatch()方法適當地調用doView()、doEdit()和doHelp()方法。這樣，由于GenericPortlet類幫助實現render()方法，并且提供doView()、doEdit()和doHelp()方法來覆蓋，因此GenericPortlet類比Portlet接口更便于擴展。
3) 完成
當portlet的實例被撤銷部署時，使用destroy()方法來釋放這些資源。
使用portlet標簽庫允許我們在JSP中獲取portlet特定的元素，例如RenderRequest對象和RenderResponse對象。還可以在JSP中生成portlet URL。在JSP頁面中必須有類似下面的聲明：
<%@ taglib uri=”http://java.sun.com/portlet” prefix=”portlet” %>
在實際的應用場景中，我們經常需要把不同的應用程序集成在一個統一的用戶界面上。Portal技術可以很好的解決這一問題，但需要開發一定數量的portlets。但有時我們需要把同一個portlet部署在不同的門戶中，此時可能我們要費很大的力氣重新為每個門戶重新開發相同的portlet。有很多通用的portlets在升級應用服務器時不能很好的做到重用。此時我們怎么辦？
我們只有遵循業界公認的標準，標準可以幫助我們減輕移植和互操作的帶來的痛苦。隨著門戶標準JSR168和用于遠程Web服務portlet（WSRP）的廣泛采用，我們將能夠很容易的做到重用和維護。
總的來講，這些新標準正在給門戶部署的本質帶來根本性的變化，伴隨而來的是門戶開發商市場的劇變。越來越多的客戶在根據門戶的總體體系結構是否符合該企業來選擇門戶技術，而不是根據門戶的一組專用的特性，例如portlets的數目來選擇。
1) JSR168
JSR168規范為創建portlets建立了標準的API。它是為實現portlet、基于Java的門戶服務器和其他Web應用程序之間的互操作性而設計的。現在大多數開源的和商用的Portal產品都支持JSR168。因此開發符合JSR168規范的portlet的客戶可以很容易的將portlets從某一開發商的門戶移到另一個開發商的門戶中。此外，客戶現在還可以使用迅速增長的開箱即用、符合標準的portlets。按照Java標準化組織（Java Community Process）所述，JSR168 portlet擁有一個適用于所有門戶客戶端的簡單的，標準的API，支持多種類型的客戶端（多設備，多瀏覽器），支持本地化和國際化，允許門戶應用程序的熱部署和重新部署，并包含聲明性安全（與servlet和EJB規范中使用的機制相同）。
2) WSRP
由JSR168標準獲取的益處被WSRP進一步得到增強。WSRP是由OASIS（一個由開發電子商務標準的行業專家所組成的非贏利性社團）創建，它使得開發的portlets可以被遠程的門戶展現出來。WSRP使原來極難實現的功能成為可能。例如，部署一次portlet，可以把它們傳遞到任何符合標準的門戶中去；將第三方提供的portlets整合進自己的門戶中，增強來自不同開發商的門戶之間的互操作性。
在JSR168規范中只定義了Portal所應具有的功能的一個最小集合。然而在現實場景中，不論是開源的portal框架實現，還是商業Portal產品都在標準的基礎上作了擴展。總的說來，一般Portal可能會包含以下功能，見表3.1：
|
功能 |
描述 |
|
內容聚合 |
能夠把各種不同應用的內容聚合到一個統一的頁面呈現給用戶。 |
|
基于角色的視圖定制 |
能夠基于組織機構中不同的用戶的角色生成不同的視圖內容。例如，人力資源總監和財務經理登錄后所看到的頁面也是不同的。 |
|
個性化 |
用戶能夠根據個人喜好定制符合自己風格的頁面和內容。例如，小王喜歡淡藍色的格調，并且投資股票，則他可以選擇一個淡藍色風格的主題，并且使用一個已經定制好的股票portlet，允許小王設定此portlet的自動刷新時間和自選股等。 |
|
單點登錄 |
只需登錄Portal服務器一次就可以訪問所有其它的應用，這意味著你無需再分別登錄每一個應用。 |
|
協作功能 |
一些Portal框架可能會提供復雜的portlets用于聊天，應用程序共享，白板，在線會議，論壇等。 |
|
國際化 |
根據locale的不同呈現不同國家的文字。 |
|
工作流 |
這里主要指支持跨越不同數據源和應用的工作流。 |
|
支持不同的客戶端 |
包括主流web瀏覽器，PDA等。 |
表3.1 Portal功能
4 部分開源Portal框架的分析和比較
開源框架中我實際接觸到的兩個開源框架就Liferay和JetSpeed，而且時間不長，以我的經驗很難做出客觀的評價。在網上查了一些資料，有一份比較權威的報告給出了一些評價標準和測試數據，應該能夠比較客觀的給出一些結論。
每個開源框架都有其優點和缺點，如果沒有一套全面的標準來評價，很難說清楚哪個框架更好。其實從做項目的觀點出發，沒有最好的技術，只有最適合的技術。但我們一般都會在選擇某項技術的時候，盡可能的追求功能完善，易于開發和擴展，文檔全面等等。下面是這份權威資料給出的標準：
1) 遵循JSR168規范
這是這些標準中最重要的一個要求，對規范支持得好，意味著做到很好的重用和別的Portal產品的交互等。
2) 便于安裝
包括數據庫的配置以及在web應用服務器中的發布等。
3) 文檔
是否有詳細的安裝文檔，開發文檔和用戶手冊等。
4) 在線支持
包括開發社區，Wiki，郵件列表等，當使用Portal產品遇到問題時是否能快捷的尋找到解決問題的方法。
5) Potal管理
包括管理節目是否友好，方便，易于添加用戶管理，角色管理，分類管理，布局，皮膚管理，增加和刪除portlets等等。
6) portlet資源庫
一般portal框架都能附帶的發布一些可被重用的portlets。例如郵件portlet，日程表portlet，搜索portlet等等。這里我們主要的評價標準是這些portlets是否能被很好的復用。
7) 性能
包括portal框架的啟動時間，portlet的裝載時間，數據庫的訪問時間等等。
8) 安全
很多portal框架都有默認的安全機制，但默認的認證和授權機制遠遠不能滿足某些大項目的要求。在這里，主要考慮portal框架是否能夠很好的和JAAS，SSO，SSL等安全技術整合以及整合的難易程度等。
9) 技術
不同的portal框架基于不同的技術開發，同時可能要求portlet開發人員也使用同樣的技術，例如Struts，JSF，Spring，Hibernate，Tiles，EJB以及Web services等技術。
10) Portal特性
通常情況下Portal框架除了作為一個portal/portlet容器外，還附帶一些很有用的特性，例如內容管理系統（CMS），工作流（Workflow），管理工具，監控工具等。
11) 服務器兼容性
此標準主要檢驗portal框架是否能夠很好的運行在大部分的服務器中，包括Tomcat，JBoss，Weblogic，Websphere等主力的服務器。
12) WSRP標準
對The Web Services for Remote Portlets(WSRP)規范的支持。
4.2 選中的開源Portal框架
在這份標準中，被選中來作評價和測試的框架一般都是在某個行業使用比較廣泛或當前比較流行的開源框架，但可能也有漏掉一些相當不錯的開源框架，例如Aapche JetSpeed。下面列出被選中的框架及其被選中的簡短理由：
l Sakai 1.5（廣泛的用于Virtual Research Environment(VRE)領域）
l uPortal（廣泛的用于Academic Institutes work領域）
l GridSphere（第一個支持JSR168規范的開源portal框架）
l eXo平臺（當前非常流行）
l Liferay（當前非常流行，良好的用戶界面以及豐富的內建portlets）
l StringBeans（非常易用）
對于每個portal框架，我將不再做詳細介紹，有興趣的可以去它們的網站或google一下。
下面將基于4.1給出的評價標準，仔細的給每個開源Portal框架打分，1~5分，其中5分是滿分，最后統計總分，就是我們評價的最優開源Portal框架，見表4.3.1：
|
標準 |
Portal框架 |
|
|
Sakai 1.5 |
uPortal |
GridSphere |
eXo平臺 |
Liferay |
StringBeans |
|
遵循JSR168規范 |
0 |
5 |
5 |
5 |
5 |
5 |
|
便于安裝 |
3 |
5 |
5 |
5 |
5 |
5 |
|
文檔 |
2 |
2 |
4 |
3 |
3 |
5 |
|
在線支持 |
3 |
3 |
4 |
4 |
3 |
5 |
|
Potal管理 |
3 |
5 |
4 |
5 |
4 |
5 |
|
自定義 |
4 |
3 |
4 |
3 |
5 |
4 |
|
portlet資源庫 |
4 |
3 |
4 |
3 |
5 |
3 |
|
性能 |
2 |
4 |
3 |
4 |
3 |
3 |
|
安全 |
3 |
4 |
3 |
4 |
4 |
4 |
|
技術 |
3 |
3 |
4 |
5 |
4 |
3 |
|
Portal特性 |
2 |
2 |
3 |
5 |
4 |
2 |
|
服務器兼容性 |
3 |
3 |
3 |
4 |
5 |
3 |
|
WSRP標準 |
0 |
3 |
0 |
3 |
3 |
0 |
|
合計 |
35 |
49 |
51 |
57 |
58 |
51 |
表4.3.1 評價結果
基于上表的評分，每個項目可以基于自己的特性和對各個Portal框架的了解程度，酌情的調整打分，以選擇最適合自己項目的Portal框架。