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