文檔選項
<a>将此頁作為電子郵件發送</a>
級别： 中級
2006 年 9 月 04 日
本文說明了多種用于快速将 Web 應用程式內建到在 WebSphere Portal 下運作的門戶中的技術。
<a>引言</a>
各個公司都希望能夠快速将其多個不同的網站聚合到單個使用者界面中，也希望提供具有一緻外觀且支援單點登入（Single Sign-On，SSO）的站點。他們很快就認識到門戶可實作此目标。不過，他們的門戶設計人員和開發人員面臨的最大挑戰之一是，要确定用于将現有 Web 應用程式內建到門戶中的最有效方法。
理想的情況下，應該通過将表示層移植到自主開發的 Portlet 來內建這些 Web 應用程式。通過此方法可利用 WebSphere Portal 用于提供一緻外觀的功能，還能利用其他功能（如安全性、個性化、協作 Portlet、内容/文檔管理、搜尋、可伸縮性/可用性功能等）和各種裝置支援。
不過，自定義開發工作有時候可能會超出使用者的預算。幸運的是，WebSphere Portal 提供了多種機制，可以用于将 Web 應用程式內建到門戶中。
本文讨論了其中的幾種機制。您可以采用以下方法：
安裝并使用即時可用的基于目錄的全功能 Portlet。這是最便于實作的方法；不過，此方法靈活性較差，因為 Portlet 自定義僅限于配置選項。我們不打算讨論此備選方案。
使用 IBM Rational® Application Developer、Rational Software Architect 或其他幫助建構 Portlet 的工具來開發自己的自定義 Portlet。
<a href="http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0607_boezeman/0607_boezeman.html#main">回頁首</a>
<a>使用 Web Page Portlet 建立 iFrame</a>
Web Page Portlet 将 iFrame 顯示為 Portlet。其中包括以下支援：
設定 iFrame 的大小。
對相同域上的站點進行身份驗證。如果所連結的站點要求基本身份驗證或基于表單的身份驗證，則可能需要使用此功能。Web Page Portlet 身份驗證僅在 iFrame 站點與門戶位于同一個域時才會工作。
使用來自憑據庫的資訊進行身份驗證。
可以友善地配置 Web Page Portlet 和支援快速将多個網站內建到門戶中。它非常适合進行概念驗證；不過，在将其應用到生産中時必須非常小心。從門戶的角度而言，此 iFrame 是門戶頁上的一個保留方框，門戶不能控制其内容或格式。
決定在門戶中使用 iFrame 時需要考慮的一些問題：
逾時是一個非常麻煩的方面，因為 iFrame 或門戶都可能在其他元素前出現逾時。
目前的浏覽器中的跨站點腳本（Cross-Site-Scripting，CSS）限制會阻止 iFrame 内的 JavaScript 通路父視窗或其他 iFrame 中的變量或周遊其中的 DOM。當二者位于同一個域且使用相同協定（HTTP 或 HTTPS）時例外。此情況會導緻很多基于 iFrame 且依賴于 JavaScript（很多情況下都是如此）的應用程式失敗。當出現 CSS 問題時，變量将為空，進而導緻 JavaScript 失敗或停止執行。此情況使得調試工作變得非常困難。
來自 iFrame 的連結會引用 JavaScript <code>top</code> 變量或 <code>navigator</code>，進而可以讓使用者通路 iFrame 外甚至門戶外的内容。使用此類變量可能會導緻整個浏覽器視窗進入其他位置，而不會将其限制在 iFrame 的範圍内。
iFrame 并不會對狀态進行維護；是以，當使用者與 iFrame 中的内容互動時，可能會遇到意外的行為。例如，假定您在頁面上的某個 Portlet 中使用 iFrame，而該 Portlet 中“包括”外部站點上的一個應用程式。使用者将采用以下方式與外部站點互動：單擊連結并在新頁面上填寫表單；切換到不同的門戶頁；然後再切換回包含 iFrame Portlet 的頁面。使用者将看到初始 外部站點頁，而不是進行互動時離開的表單頁。隻有目标外部站點使用會話 Cookie 等普通 Web 技術來處理自己的狀态管理時，使用者才會看到“通常”的行為。在此情況下，當使用者傳回 iFrame 頁時，外部站點将顯示表單頁，而不是初始頁。
iFrames 可能會導緻很難在門戶中控制和提供一緻的外觀。完整網頁的 iFrame 通常包含頁 Header 和導航資訊，而這并不是 Portlet 中所希望的方式。完整的網頁通常設計為适合全屏顯示，通常不會将 Portlet 視窗内的滾動條（特别是水準滾動條）視為良好的使用者界面 (UI) 設計。圖 1 顯示了這些 UI 問題。IBM 網站嵌入在頁面右側底部的 iFrame 内。其中的外觀并不一緻，且未內建導航。
iFrames 無法利用 WebSphere Portal 的功能。例如，iFrames 和 Web 剪輯不支援 Portlet 消息傳遞或協作 Portlet。它們無法利用門戶的個性化引擎、流程內建或很多内容管理功能。
<a>圖 1. 通過 iFrame 內建了 ibm.com 網站（右下角）的門戶頁</a>
<a>建立自定義 iFrame Portlet</a>
假定您希望使用 iFrame，但要提供 Web Page Portlet 之外的其他功能。您可以将 iFrame 嵌入到 Portlet JSP 中并對 iFrame 名稱進行編碼（使用命名空間），進而編寫自己的 iFrame Portlet。
此部分說明了決定編寫自定義 iFrame Portlet 時需要處理的一些問題。
<a>防止名稱沖突</a>
必須對 iFrame 名稱進行編碼，以防止在頁面上存在 Portlet 的多個執行個體時出現沖突。使用命名空間對此名稱進行編碼，如清單 1 中所示。
<a>清單 1. 使用命名空間對 iFrame 名稱進行編碼</a>
<a>處理會話逾時</a>
當向 Portlet 添加 iFrame 時，必須對會話逾時的可能性進行管理。如果使用者花費太多的時間在 iFrame 内進行互動，門戶會話可能會逾時，具體取決于為門戶伺服器會話設定的逾時值。
可以使用隐藏 iFrame 或 AJAX 在 Portlet 内重新整理門戶頁，進而解決此問題。
清單 2 顯示了如何在 Portlet 内使用隐藏 iFrame 重新整理頁面
<a>清單 2. 使用隐藏 iFrame 重新整理頁面</a>
清單 3 顯示了相應的 AJAX 方法，該方法将使用 <code>XMLHttpRequest</code> 調用在 Portlet 内重新整理門戶頁。
<a>清單 3. 使用隐藏 AJAX 重新整理頁面</a>
同樣，對于 iFrames Portlet，需要對所有相應内容使用命名空間。即，對每個 JavaScript 變量、JavaScript 函數名稱、iFrame 名稱和 iFrame ID 都要使用 <code>encodeNamespace</code>Portlet 标記。例如：
<code>var <portletAPI:encodeNamespace value=' wps_PortalTimer ' /> = setInterval("<portletAPI:encodeNamespace value=' wps_PokeTheSession ' /> ();", 1740000);</code>
<a>域外的身份驗證</a>
對于涉及到域外的 iFrame 的身份驗證，目前并沒有真正的解決方案可用，因為浏覽器會嘗試保護使用者。出于安全考慮，很多浏覽器都不允許 iFrame 或 <code>XMLHttpRequest</code> 通路主浏覽器請求域之外的其他域。是以，您需要確定 iFrame 所嵌入到的應用程式與門戶伺服器屬于相同的域。
如果站點要求身份驗證，則必須對其他應用程式進行自己的自定義表單身份驗證或基本身份驗證。如果應用程式使用 Header，則在生成 iFrame 時，代碼可以讀取 HTTP Header 并将其轉發到後端應用程式。Cookie 轉發也是如此。
<a>狀态管理</a>
使用 iFrame Portlet 時，浏覽器的“後退”、“前進”和“重新整理”按鈕會導緻操作不一緻。如果使用者單擊“重載”/“重新整理”按鈕，将重新生成整個浏覽器頁，進而會丢失所有 JavaScript 狀态資訊。為了解決此問題，可以使用衆多持久性方法中的一種，如 Cookie、表單字段等。另外，由于會重新生成整個頁面，是以主題将使用原始 URL 建立 iFrame。如果此站點不使用 Cookie 或其他方法維護狀态，iFrame 生成操作還需要重新生成目标資訊。
對于浏覽器的“後退”按鈕，如果 iFrame 的狀态發生更改而更新浏覽曆史，則可能會正常工作。而将給使用者帶來困擾的是，當使用 WebSphere Portal 和 iFrame 時，浏覽器曆史可能不能按照預期的方式進行顯示。我們的經驗表明，即使是同一門戶中的兩個使用者也可能期望得到不同的結果。
<a>使用 Web Clipping Portlet</a>
将 Web 應用程式內建到門戶中的另一個解決方案是使用 IBM Web Clipping Portlet 建立自己的剪輯 Portlet（也稱為 Web Clipper）。可以使用 Web Clipping Editor 建立 Web Clipper，如圖 2 中所示。要使用 Web Clipping Editor，請打開 WebSphere Portal Administrative 頁，然後展開 Portlet Management。
<a>圖 2. Web Clipping Editor</a>
可以使用 Web Clipper 在 Portlet 中顯示文檔的特定部分。還可以使用其進行以下工作：
添加參數來指定額外的 Header
使用 URL 重寫
通路防火牆後的内容
将特定 Cookie 從客戶機-門戶對話複制到門戶-原始伺服器對話中。
指定緩存逾時
在頁面上啟用其他 Portlet，以重置 Web Clipping Portlet 狀态
Web Clipping Portlet 具有以下限制：
有些站點超出了頁面尾部。雖然 Web Clipping Editor 設計用于處理各種網站編碼技術，但并不能處理出現的所有情況。如果遇到了其設計能力無法處理的網站，結果可能并不會是您所預期的。如果一個頁面上有兩個 Web Clipping Portlet，JavaScript 名稱可能會沖突。另外，所剪輯内容和另一個 Portlet 及主題間可能出現 JavaScript 名稱和命名空間沖突。
Web Clipping Portlet 已得到增強，在處理 JavaScript 方面更為可靠和穩定。不過，存在外部站點 JavaScript 會導緻意外行為的情況。例如，當使用相對 URL 進行 JavaScript 編碼時，可能會由于未修改 JavaScript 内的 URL 而遇到問題。當站點對使用 DHTML 的頁面結構的特定層次或浏覽器特定功能具有依賴性時，也會出現不可預見的結果。
來自 Web Clipper 的連結可能會存在行為不規範的情況，進而可能會将使用者帶到 iFrame 甚至門戶外的位置。例如，應用程式可能存在将每個 URL 重寫到 Clipper Portlet 時未檢測到的連結。
HTML 分析器希望接收到格式正确的 HTML。格式存在問題的 HTML 可能會導緻顯示意外的結果。
與 Web Page Portlet 相比，Web Clipping Portlet 在處理外部站點方面成熟得多。它能更好地處理 JavaScript，且支援反向代理，是以使用者能從防火牆後通路内容；此外，它的身份驗證機制也更為成熟。不過，在使用 Web Cliping Portlet 時可能遇到一些與 Portlet 技術或 WebSphere Portal 完全無關的問題。
Web Clipping Portlet 直接從外部站點接收标記和 JavaScript，它必須對代碼進行調整，以便能夠在整個聚合頁面上共存。WebSphere Portal 無法控制來自外部站點的代碼的品質，也不能保證與聚合到頁面上的其他外部站點代碼的相容性。是以，Web Clipping Portlet 的靈活性完全依賴于所剪輯的外部站點代碼的品質。它最初的時候可能很可靠；不過，如果使用格式存在問題的 HTML、與頁面上的另一個外部站點具有相同名稱的 JavaScript 變量或包含相對 URL 的 JavaScript 對外部站點進行了更新，則 Portlet 可能生成不一緻的結果。
<a>IBM WebSphere Portlet Factory</a>
一緻地確定聚合和呈現時聚合标記的穩健性、可伸縮性、準确性和可靠性的唯一方法是，直接從 Portlet 生成。當然，這意味着必須編寫自定義 Portlet。
現在編寫自定義 Portlet 的過程已經變得更為簡單了。IBM Rational Application Developer（或 Rational Software Architect）提供了多個向導類幫助您構造 Portlet。此外，IBM 還在今年推出了 WebSphere Portlet Factory，提供了一個快速應用程式開發備選方案來幫助開發人員快速開發 Portlet。可以使用 Rational Application Developer 或 Eclipse 插件 WebSphere Portlet Factory Designer 來建立 WebSphere Portlet Factory Portlet。
WebSphere Portlet Factory Portlet Development 範式與标準 Portlet 開發範式不同。它存在一個學習過程；掌握了這種方法後，就可以快速開發和測試複雜的 Portlet。另外，此方法僅需要很少的 J2EE 知識。
通過使用 WebSphere Portlet Factory Designer 工具，可以通過将預先建構的元件（稱為“建構塊”）快速組合到一起來建構組合應用程式。可以使用标準建構塊（Portlet Factory 提供了 70 個即時可用的建構塊）或編寫自己的建構塊。可以将建構塊組裝為模型，就像将 Portlet 組裝為組合應用程式一樣。在運作時，此模型将生成應用程式代碼，包括 JSP、Java 類和 XML 文檔。您所進行的工作實際上就是捕獲和自動建構動态 Portlet 的流程。模型打包為 WAR 檔案，是以，從 WebSphere Portal 的角度而言，它就是一個 Portlet 應用程式。
WebSphere Portlet Factory 提供了對 JSR 168、WSRP、單點登入內建、憑據、Portlet 到 Portlet 通信等的全面支援，實作了與 SAP、資料庫、Peoplesoft、Domino、Seibel、Excel 工作表等的無縫內建。
<a>結束語</a>
有很多解決方案支援快速将 Web 應用程式內建到 WebSphere Portal 中。這既包括快速但并非最佳的 iFrame，也包括 Web Clipping Portlet，還包括新 IBM WebSphere Portlet Factory。每個解決方案都有自己的優點和缺陷。iFrame 是一個很有價值的工具，但需要注意它們的限制，并要事先進行計劃。
<a>緻謝</a>
作者感謝 Scott DeWitt 和 Usman Memon 為撰寫本文提供的幫助。
本文轉自kenty部落格園部落格，原文連結http://www.cnblogs.com/kentyshang/archive/2008/06/06/1214929.html如需轉載請自行聯系原作者
kenty