在 IBM Bluemix 雲平臺上開發並部署您的下一個應用。

概述

企業資訊門戶作為企業內部門戶基礎平臺，一大主要用途是實現現有的業務系統、資料資源、人力資源的整合，實現資訊（資料）的合理聚集；通過實現統一的使用者和統一的訪問入口來訪問門戶平臺中整合的相關資訊資源，真正實現資源的有效利用，更大發揮企業現有資源的使用價值，提高生產效率。

門戶應用整合技術作為關鍵性的技術手段，實現入口網站與業務系統之間單點登陸，以及內容聚集。本文件通過歸納總結，將企業應用整合中可以使用的技術做出相應闡述，為實現門戶與業務系統整合提供技術參考。

本文將結合實際情況，分析企業應用中，常用的整合技術的核心環節，以及每項技術適用範圍。本文件提供技術性的參考，實際工作中將需要結合具體情況選擇最適合的整合技術來解決實際的問題，技術在日益更新，文件也將實時將最新的整合技術歸納總結。文章並不涉及具體編碼、配置的實現細節，只針對相關的整合技術做闡述，具體實現應當專注於具體的技術環節，同時根據環境與實際需求來做相應的調整。

回頁首

名詞解釋

門戶

這裡專指利用門戶產品構建的各種門戶系統，包括 B2E 門戶、B2C 門戶、B2B 門戶。

單點登入

使用者僅需要在門戶系統登入一次，就可以訪問被授權訪問的欄目或者其他應用，使用者只需要記住一個帳號即可。通過提供安全登入訪問和集中管理應用軟體和資料的資訊框架，實現使用者只需登入一次，即可獲得授權範圍內所有企業應用程式的訪問權。

portlet

Portlet 是特殊型別的 Web 模組，它們被設計成在入口網站的環境中執行，是獨立地開發、部署、管理和顯示小入口網站的應用程式。Portlet 不僅僅是現有 Web 內容的簡單檢視。portlet 是完整的應用程式，遵循標準模型－檢視－控制器設計。Portlet 有多個狀態和檢視方式以及事件和訊息傳遞能力。同時 Portlet 是可再用的 Web 模組，它們在入口網站伺服器上執行並提供對基於 Web 的內容、應用程式和其他資源訪問。

WSRP

通過定義一組公共介面，WSRP 允許門戶在它們的頁面中顯示遠端執行的 portlet，而不需要門戶開發人員進行任何程式設計 , 使面向呈現的 portlet 應用程式可以被發現並重用而不用任何額外的開發和部署活動。

回頁首

整合的基礎統一使用者目錄

在門戶整合專案實施中，首先要考慮的是使用者目錄的因素。使用者目錄是用於儲存使用者身份資訊，可利用以下幾種方式實現：基於 LDAP 協議，符合 X500 標準的使用者目錄服務產品；

定製使用者登錄檔介面（如：基於關係型資料庫系統實現、基於本地使用者系統實現）；統一使用者目錄可以分為物理的統一和邏輯的統一。

物理統一使用者目錄

物理統一使用者目錄是要求門戶與待整合的業務系統使用統一的使用者目錄登錄檔，物理統一的使用者目錄不僅僅包含有使用者基本資訊，同時包含相關的業務系統資源資訊，與業務系統相關的賬戶資訊。

為了保證可用性，統一使用者目錄一般分為中央目錄伺服器及分支目錄伺服器，門戶系統試用中央目錄伺服器作為使用者儲存，各業務系統，可以試用中央目錄伺服器也可以試用分支目錄伺服器。

中央目錄伺服器和分支目錄伺服器通過目錄複製技術進行資料同步，如可實現全域性複製，也可以實現選擇性複製。如圖 1。

圖 1. 物理統一使用者目錄

邏輯統一使用者目錄

一般情況下，由於歷史遺留問題以及企業要求等各方面的原因，實現物理統一使用者目錄的情形不多，更多的是採用邏輯統一使用者的方式。邏輯統一使用者是指門戶與待整合的業務系統不使用唯一的使用者登錄檔，門戶資訊系統使用單獨的使用者資訊，業務系統使用另外一套自己的使用者登錄檔。建立邏輯統一的使用者目錄，必須建立門戶使用者目錄與業務系統使用者目錄之間的聯絡，實現門戶使用者與業務系統使用者之間對映技術主要包括：

Credential Vault （憑證保險庫）

Credential Vault （憑證保險庫）是由 WebSphere Portal 提供一專案服務，幫助 portlet 和入口網站使用者來管理多個標識。憑證服務包含處理基本認證、LTPA 令牌認證和簡單基於表單的使用者標識／密碼登入提問的物件。如圖 2

圖 2. 憑證保險庫

GSO-Lockbox

利用 GSO-Lockbox，可以建立起一個使用者身份資訊和後臺應用系統之間的對應關係。這需要依賴於門戶應用（portlet 應用或 J2EE 應用）來維護這樣的關係對映表（包含門戶使用者與業務系統帳戶之間的關係）。

門戶使用者與待整合業務系統之間對映關係完成之後，可根據業務系統認證方式來選擇實現單點登入。

使用者目錄資訊同步

使用者關係對映表建立後，需要隨時可以對這種對映關係進行維護，通過定期強制密碼更新策略讓每一個使用者維護自己業務系統的使用者、密碼是一種選擇。更常見的選擇是通過管理員進行統一的賬戶管理和密碼的同步推送，這項需求可通過開發完成，或者藉助於成熟的企業級安全產品，例如 TIM/TDI。如圖 3 所示，利用 TIM/TDI 實現門戶目錄與應用系統直接使用者目錄統一管理和使用者資訊的同步及清理。

圖 3. 試用 TIM/TDI 實現目錄統一管理和資訊同步

回頁首

統一認證與單點登入

認證意味著使用者標識自己以獲取對系統的訪問權。IBM WebSphere Portal 支援以下幾種方式的認證：

WebSphere Application Server 的基於定製表單認證機制，這是 IBM WebSphere Portal 預設認證方式；

第三方認證（通過外部安全性管理器，如 Tivoli Access Manager 或者 CA SiteMinder），第三方認證提供者確定提問機制和認證方法；

安全套接字層（SSL）客戶機認證。

使用者在未標識自己的身份而嘗試訪問受保護的資源時，Portal（門戶資訊系統將提示使用者提供認證憑證。

WebSphere Portal 還支援與其它的應用系統實現認證的統一，即支援其它標準的、非標準的認證方式來實現單點登入和應用整合以下其它系統的認證方式均為 WebSphere Portal 能夠支援的：

Form 方式，使用者名稱和密碼、CA 認證 (X.509v3)、Token 認證、WAP 身份認證、資源敏感的認證或者自行開發的認證等方式

門戶與業務系統實現 SSO

門戶與業務系統實現 SSO（單點登陸），通過在門戶使用 portlet 技術實現，為業務應用提供訪問連線，當用戶點選門戶站點頁面中的連線，或者直接訪問門戶頁面中的某第三方系統的業務模組 Portlet 時，自動將登陸到需要訪問的業務系統，而無需再次進行使用者認證。

單點登入的實現從技術上可以從不同的維度著手，一般分為“客戶端 Web 應用 SSO（Client-Web App SSO）”方式和“Portal 後臺應用 SSO(Portal-Back End SSO)”方式，每種方式均有相應的技術實現，如圖 4 Portal 單點登入服務：

圖 4. Portal 單點登入服務

在實際的專案中，常用的 SSO 的實現方式按照應用系統與 Portal Server 的互動程度分為三種。需要指出這些 SSO 的實現方式並沒有優劣之分，不同的實現方式適應不同的應用環境。解決現實中遇到的不同問題。

真實單點登陸：

門戶認證中心

利用門戶系統建立統一的 SSO 認證中心，通過 SSO 中心認證後，應用系統利用 SSO API 同 Portal Server 通訊，驗證使用者是否經過認證。新開發的應用系統大多使用這種 SSO 的實現方式。這種方式需要對應用系統的認證模組進行修改。多數情況下，使用信任關聯攔截器（TAI）也是建立 SSO 認證中心的常見方式。

門戶伺服器實現了 Java 認證和授權服務（Java Authentication and Authorization Service（JAAS））體系結構。JAAS 提供了一種用來認證 subject 和提供細粒度訪問控制的辦法。JAAS 是標準 Java 安全性模型的一部分；它使應用程式不依賴於所使用的底層認證和授權機制。

JAAS 使用模組化的服務提供者介面來執行登入和登出操作。通過入口網站的 JAAS 登入模組建立的憑證包括 CORBA 憑證、使用者和組專有名稱、使用者標識和密碼以及 LTPA 令牌。在分散式 J2EE 環境中，portlet 可以使用 JAAS API 來訪問啟用了 JAAS 的後端應用程式。

認證中心的建立，可以利用 JAAS 安全模型實現，例如，通過實現 WebSphere 自帶的 LTPA 令牌技術來實現門戶及各應用系統的認證統一，利用 Portal 建立公共的 SSOToken 實現認證統一。也可以通過一些開源的認證模組來實現，如 CAS、OpenSSO 等。

LTPA

另外，IBM 的產品體系中，大部分產品已經可以通過配置的方式實現真實單點登入。如：IBM WebSphere Base 產品（例如 IBM Connections、Quickr、ECM 等）、IBM WebSphere Portal、IBM Lotus Domino Server 之間的使用者身份認證和單點登入。IBM WebSphere Portal 與 IBM Domino 提供基於 cookie 的輕量級第三方認證機制（LTPA）。當 LTPA 機制用於由多個伺服器組成的環境中時，它是通過使用 Domain Cookie 而啟用的。這種經過加密的會話 cookie 被放置在使用者瀏覽器中，幷包含了一些資訊，WebSphere 或者 Domino Application 伺服器可以加密這些資訊，並使用這些資訊來說明使用者已經通過該 cookie 所覆蓋的 DNS（Domain Naming Service，域名服務）域中的認證。

偽單點登陸

通過 WebSphere Portal 認證或者 SSO 中心認證後，應用系統還要自己進行使用者的認證。這種方式適用於那些無法修改認證模組的應用系統。這種情況可以利用應用系統比較基礎的介面來實現，如 URL+User+Password、Form 表單代填等。主要有以下幾種技術選擇：

利用 WebSphere Portal 憑證庫認證模組

portlet 通過獲得一個 CredentialVaultPortletService 物件並呼叫它的 getCredential 方法來獲得憑證。對於所返回的憑證，有兩種選擇：

使用來自被動憑證（passive credential）的密碼或金鑰，用特定於應用程式的呼叫來傳送這些密碼或金鑰。使用被動憑證的 portlet 需要從憑證中提取出加密資訊並與後端應用程式進行所有認證通訊。

呼叫主動憑證（active credential）的認證方法。主動憑證物件向 portlet 隱藏了憑證的加密資訊，沒有任何辦法可以從憑證中提取出這些資訊。主動憑證提供另外的方法來執行認證。

後一種情況允許 portlet 通過基本認證、SSL 客戶機認證、摘要認證或者 LTPA 來觸發遠端伺服器的認證，而不必知道憑證值。使用主動憑證意味著入口網站代表 portlet 進行認證，而且這個 portlet 可以只使用開放連線。儘管這可能並不適合於所有情況，但它卻是您應該首選的技術。

基於 Form 方式

這種方式是通過模擬使用者憑證提交，將業務系統相關的使用者憑證通過 Form 提交的方式，傳遞給業務系統認證模組。

這種方式適合待整合的業務系統認證方式採用 From 表單，當通過 portlet 技術封裝 Form 表單包含有業務系統相關的使用者憑證，以及資源 URL。通過將業務系統所需的使用者憑證通過 Form（表單）提交方式，模擬使用者登陸，業務系統將使用者所需的資源通過 web 方式反饋使用者。

適用於基於 B/S 的 Web 業務應用系統，並且使用者認證方式提供 Form 表單認證服務功能。

URL

將使用者憑證直接通過 URL 的方式傳送給業務系統，業務系統的認證程式將截獲的使用者請求 URL 中獲取使用者憑證，從而實現門戶與業務系統的單點登陸。或者將使用者憑證儲存在 HTTP 請求報頭，業務系統認證程式通過解析 HTTP 請求頭資訊，獲取使用者憑證。

模擬會話

利用 WebSphere Portal 以及應用系統的介面，模擬應用系統的認證狀態。

模擬證書

實現單點登陸的業務系統使用者認證方式並不是基於 Form，也不是採用 HTTP Header。需要客戶端（此是門戶資訊系統將被作為客戶端，業務系統將作為伺服器）提供客戶電子證書，這需要通過 portlet 應用程式，或 J2EE 應用程式來實現模擬將電子證書傳送給業務系統認證模組。

整合第三方軟體的單點登陸

使用信任關聯攔截器（TAI）的第三方認證。如 Tivoli Access Manager，CA SiteMinder 等。門戶通過使用第三方認證伺服器作為外部安全管理器單點登陸。通過定義訪問控制規則，由第三方認證伺服器來實現使用者登陸業務系統的認證功能，將大大簡化整合帶來的煩瑣工作。

通常第三方認證伺服器（如 Tivoli Access Manager、WebSeal 或者 CA SiteMinder）會提供預設的驗證機制採用內建共享庫的形式支援通過使用者名稱和密碼客戶方證書 RSA SecurID 令牌或 HTTP header( 報頭 )。選擇性將會更多，便於使用者根據實際軟體需求配置所需的方式。

認證方式包括

• Forms-based login
• HTTP basic authentication
• Digital Certificate (X.509v3)
• RSA SecurID Token
• WAP identity mechanism
• Resource-sensitive authentication
• Kerborse

還可以支援 Credentials Acquisition Service (CAS)，從而實現外掛的使用者認證方式，如：

• 資料庫的認證方式，如 Oracle，DB/2
• 其它 security tokens (Vasco DigiPass)
• 使用者定義的認證方式，如使用使用者訪問程式碼 PIN 和 Code
• RADIUS
• Biometrics

回頁首

利用門戶實現企業應用整合

利用門戶產品來實現企業應用整合，需要根據企業業務系統的現狀，以及具體的業務需求，進行最合理的規劃與設計。同時，還要兼顧企業的未來發展以及整體 IT 規劃的考慮，企業應用整合包括的內容很複雜，涉及到結構、硬體、軟體、資料、技術、介面以及流程等企業系統的各個層面。

頁面前端整合展現（基於頁面內容的整合）

iFrame Portlet

基於頁面的整合整合可以通過 iFrame Portlet 的方式，這也是門戶專案中常見的一種整合方式。IBM WebSphere Portal 提供 webPage Portlet 將待整合的業務系統頁面實現與門戶站點進行整合。

通過 iFrame Portlet 整合依賴於以下幾種情況：

1. 此方法只適合 B/S 的業務應用系統。
2. 此種整合方式的前提是：門戶系統和應用系統之間已經實現 SSO。由於應用系統的頁面之間在門戶頁面中展現，故需要考慮 SSO 的自動實現。例如：

   方式一：可以在使用者登陸門戶站點時，將登陸門戶的業務系統賬號統一儲存在使用者會話中。並且實現應用系統的認證環節，當通過 iFrame 方式實現頁面整合時，通過將業務系統的使用者憑證從使用者會話提取，然後直接通過配置的 URL 展現即可。

   方式二：對 Iframe Portlet 通過 Portlet 程式設計進行預處理，實現應用系統的認證。而不是在使用者登陸 Portal 時載入。

3. 業務系統介面需滿足 VI 設計要求

   為保證門戶站點的整體風格，業務系統的展示頁面將必須滿足門戶站點的 VI 設計要求。

4. 需要應用系統提供具體的，可配置的 URL。
5. 可選，為了更好的適應整合的需要，可能需要更改業務系統 URL 級介面或者修改認證模組。例如：業務系統修改認證模組，來滿足整合的要求 ; 業務系統修改功能模組加入 URL 認證能力。

通過 iFrame Portlet 的方式進行整合，除了上述限制條件外，效果不一樣會好。這主要是由於：

1. 使用 Iframe 框架，可能會改變原有應用的 HTML 結構，導致某些指令碼無法執行。
2. 在一個頁面中過多的潛入 IFrame，由於不同 IE 版本對於 IFrame 的處理能力各異，可能會出現不可預料的異常效果。

Web 應用聚合器 (Web Application Integrator)

Web Application Integrator 提供了一種方法，可輕鬆將現有 Web 應用嵌入 WebSphere 門戶，從而帶來更高的價值。該技術在感官上與傳統的門戶整合方式不同，傳統的門戶整合方式一般是把業務系統的區域性或整體介面嵌入到門戶頁面中，而 Web 應用聚合器是指在業務系統的頁面中嵌入門戶的主題導航、顯示風格等元素，以讓業務系統的操作介面保持與門戶系統一致。本方式可以使業務系統更多的利用門戶的價值，並保持企業內所有系統具有一致的操作體驗。Web 應用聚合器可通過以下方式實現：

1. 在門戶中建立一個標準的 Portal URL 頁面，並將頁面連結指定到需要整合的 Web 應用的頁面。
2. 使用 WebAppIntegrator portlet 為該 Web 應用頁面生成一段 HTML 標記程式碼。<Script>Tag。
3. 將 script tag 加入到 Web 應用頁面的 Header 部分。對於某些特殊的頁面模式，script tag 可能也必須加入到 Footer 部分。

   效果如下圖：

   圖 5. Web 應用聚合器

   

約束條件：

顯而易見，開發人員必須具有在業務系統中修改頁面的許可權。

業務模組化整合展現（基於應用介面、業務功能模組的整合）

業務模組化整合，是比較深入的整合方式，可實現很好的整合效果，在此模式中，業務應用與門戶之間，業務應用與業務應用之間，利用應用中的介面和函式提供接近實時的整合。例如在企業 B2E 門戶整合中，把業務人員使用的核心業務系統與其它企業業務資源、協作功能構建在一起，實現綜合業務處理平臺；在一些 B2B 整合系統中使用 Web 門戶來實現 CRM 系統與企業後端應用的整合，構建能夠充分利用多個業務系統資源的電子商務入口網站。

在企業門戶中，實現業務模組化整合，可以作為企業 ESB 建設的前期嘗試和技術積累。一些已經實施了 ESB 專案的企業，利用門戶產品可以更大的發揮 ESB 的價值。模組化整合可通過以下技術實現：

1. 對於純展現類的資訊模組（資訊整合），可以利用業務系統中預設提供的底層介面，如 HTML 介面（可以容易通過 HTML Parser 解析的）、XML 介面、Json 介面、Rest 介面等，使用 RAD、Portlet Factory 等開發工具開發實現。此類場景中，門戶專案經理及開發工程師主要是需要理清業務系統究竟可以提供哪些現成的介面，利用哪些介面可以更快速的實現開發、部署。
2. 對於一些標準化產品的模組化整合，比如需要整合 Domino 郵件、SAP 財務模組。一般這些產品會提供多個層面的標準介面，Domino 提供 JAVA/CORBA、JDBC、EJB、Web Service 等方式，SAP 可以提供 BAPI、Web Service 等介面。同時，選擇合適的執行、開發平臺來加速開發也很重要，例如可以使用 WebSphere Portlet Factory 中開箱即用的構建器（Builder）來來快速生成表單，加速整合進度。
3. 對於一些互動性模組的整合或者一些非標準化的業務整合需求 ( 應用整合 )，例如需要在門戶的內容釋出模組直接選擇 OA 系統中的公文進行釋出，例如需要在門戶中實現統一待辦等，均需呼叫這些應用系統的介面，並進行二次開發實現。
4. 增加協作功能，模組化整合方式中，均需基於某些介面進行二次開發，故為了更好的實現整合的價值，儘量在業務模組的實現協作能力，如實現線上感知、實現個人名片等功能，促進人員之間的協作。
5. 保持鬆耦合，從企業 IT 運作的角度來說，先前的應用之間彼此獨立，每當有新的業務需求產生時，企業的 IT 部門都要做大量的改進工作，耗費大量的人力、物力和財力。使用門戶進行應用整合時，需要建立不同應用系統間的鬆耦合機制，從而為將來開發面向新的業務的應用奠定基礎，以最終節省成本。

效果圖如下：

圖 6. 業務模組化整合展現示例

約束條件：

以上整合工作，均需或多或少的呼叫應用系統的介面，有些還需要業務系統做出若干調整。故，基於國情，門戶實施過程中，協調應用系統進行介面的開放和配合工作是第一重要的事情，是門戶專案能夠順利開發實施，並取得滿意整合效果的非常重要的條件。

業務過程整合

企業中，往往有以下需求：在應用層面，處理一項業務，人們要在不同的業務系統間來回切換，由此降低了工作的效率，並影響了工作的效果。在業務層面，業務流程分散，不完善，致使企業不能根據業務需求自由組合業務流程。比如，企業的業務功能和業務流程被分割成許多小塊，分散在不同的資訊系統中，而這些系統之間的通訊又是微弱的，存在很多的人為工作。故，需要通過門戶進行業務過程的整合，以便改進操作、減少成本、提高響應速度。

當對業務過程進行整合的時候，企業必須在各種業務系統中定義、授權和管理各種業務資訊的交換，業務過程整合包括業務管理、程序模擬以及綜合任務、流程、組織和進出資訊的工作流，還包括業務處理中每一步都需要的工具。對於非流程類的業務過程，可以通過業務模組化整合技術實現，對於流程類的業務過程參考以下環節。

企業門戶常用來實現跨系統的業務流程整合，業務流程本質是一組按一定次序執行的活動（Activity），流程中的每一步或每一項活動都可以通過服務（Services）來實現，在標準的業務流程執行協議中，服務可以被編排用來實現流程，業務流程本身也是一種服務，服務編排通過業務流程執行語言 BPEL 來描述。在非標準的流程類業務系統中，系統通過其它方式來編排服務（Services）。因此，門戶對流程的整合主要體現在對服務（Services）的整合，通過重新編排、組合跨業務系統的服務，門戶能夠提供：

• 人與應用組合的流程 (Human-task workflow)
• 審批過程中需要有第三方人的參與，團隊的協作
• 審批過程中需要查閱、對比相關的資料
• 審批過程中需要利用以後的知識
• 交易和補償
• 對流程資料的操作

同樣，門戶對於流程引擎本身的整合，也非常的方便，例如，可以使用 Portal 使用者認領（Claim）和處理 WebSphere Process Choreographer 中的任務。門戶中提供待辦任務列表、提供待辦任務提醒模組，對每一個被選中待處理的任務，門戶都會啟動相應的頁面應用例項（Instance）。

• 同一型別的任務可以啟動多個頁面；
• 正在處理特定任務的上下文場景會被傳遞到頁面應用中；
• 任務完成後，頁面自動關閉。

效果圖如下：

圖 7. 流程整合示例

約束條件：

實現業務整合，必須貫穿於企業的多個業務環節，門戶實施人員必須對企業環境具備很深厚的業務背景。對於業務方，也必須有一個重量級的 Leader，才能協調整個專案的順利實施。

資料整合展現（基於業務資料整合整合）

資料整合的另外一層含義包括資料和資料庫的整合，包括資料的標識化和編目，包括主資料管理，還包括元資料建模，包括資料在資料庫系統中的分佈和共享等。在這裡，主要是指已經處理好的資料，如何通過門戶進行展現的問題。

將業務系統相關的業務資料通過 portlet 技術實現與門戶站點內容聚集，在實際整合中會經常遇到。通常業務系統並沒有提供相關的業務資料整合功能，門戶需要將不同業務功能的業務資料在一個 portlet 做集中展現，或者將某一個業務功能統計的資料部分展現。資料整合展現的主要技術實現如下：

1. 通過 JDBC、Web Service 等方式，直接訪問後臺業務系統的資料來源，並在 RAD 或 Portlet Factory 中進行 Portlet 開發。
2. 通過 WebSphere Dashboard Framework 進行 Portlet 開發，利用內建的開箱即用的構建器（Builder）加速對 BI 系統的開發實施，利用內建的圖形化引擎 (iLog Jview)，實現豐富的展現效果。
3. 直接利用 iLog Jview 圖形化引擎進行 Portlet 開發。
4. 某些特殊效果，比如動畫效果，還可利用 Flex 開發 Flash 格式的 Portlet，然後嵌入到門戶中。

效果圖如下：

圖 8. 資料整合示例

約束條件：

對於 Dashboard、Flex、JView 開發技能有一定的要求。同時，美工的水平對最終的展現效果至關重要。

門戶與 C/S 業務系統實現 SSO

對於 C/S 結構的應用，通常使用可以採用如下方式實現整合：

1. 門戶作為該應用的入口，通過定製開發的 Portlet，啟用應用系統的客戶端程式；通過客戶端程式訪問應用。而門戶僅僅起到入口作用。門戶上的 Portlet 啟用應用系統的客戶端程式後，所有的訪問與門戶無關。
2. 通過定製開發新 Portlet 呼叫應用提供的各種介面，如 Web Service 介面、通過定製開發新 Portlet 呼叫應用提供的各種介面，如 Web Service 介面、API、XML 等，獲取應用系統需要在門戶上展現的資料，並根據門戶的介面風格規範形成展現介面，在門戶上實現展現整合
3. 通過第三方軟體實現 C/S 系統 B/S 訪問方式。對業務系統的要求：提供符合當前 Portal（門戶資訊系統）VI 標準的使用者介面；修改或新增業務功能介面，以便實現頁面或業務資料在門戶資訊系統的內容聚集；
4. 另外，Tarantella 和 Citrix 都是將 C/S 應用系統轉化為 Web 應用的第三方軟體系統。

MainFrame 應用的整合

對於某些大型機的應用，可能也需要整合到門戶中。具體技術方案是，通過 HATS（Host Access Transformation Server）可將終端應用轉成 Portlet 或者 Web 應用。HATS 提供開放、靈活的環境建立 Portlet，支援 Click-to-Action、協作 Portlet、Credential Vault、單點登入。

整合的標準

要實現完全的資料整合，必須首先選擇資料的標準格式。要實現完全的應用整合，必須首先明確應用的標準介面，整合的標準化促成了資訊和業務資料的共享和分佈，構成了企業應用整合的核心，包括 COM+/DCOM、CORBA、EDI、JavaRMI 和 XML.

採用 portlet 技術實現業務系統資料與門戶站點內容聚集，資料的儲存、傳遞可選擇如下標準：

常用的資料傳輸標準規範明細：

1. XML 檔案

   XML 是可擴充套件置標語言，使用基於 XML 技術的資料封裝，將異構資料來源增加一個以 XML 為格式的封裝體，在不改變資料來源的前提下，用 XML 對資料來源的定義描述字、資料來源的建立等相關資訊進行封裝。

   XML 的核心是資料，通過採用基於 XML 技術的資料封裝實現 portlet 與待整合業務系統之間的互動，portlet 應用程式不需要了解業務系統的資料格式。

   XML 技術已經成為了業界標準的異構系統間的資料傳輸技術。

2. 文字檔案

   文字檔案相對而言沒有固定標準，資料儲存可由 portlet 應用實現與業務系統之間協商資料的儲存格式。按照協商的資料儲存格式，業務系統將業務資料進行封裝，portlet 應用程式將資料檔案採集、分解，實現業務資料內容與門戶站點內容的聚集。

3. 其他

   可採用例如 Excel 或 word 檔案儲存的方式。

   通過採用以上幾種方式將資料封裝，門戶 portlet 應用通過多種通訊協議（如：HTTP、FTP 等）, 通過應用程式開發實現資料檔案的採集，分解資料檔案，通過 portlet 程式設計實現業務資料與門戶站點內容聚集。

4. Web services 方式

   Web services 是基於網路的、分散式的模組化元件，它執行特定的任務，遵守具體的技術規範，這些規範使得 Web Services 能與其他相容的元件進行互操作；Web services 是自包含的、模組化的應用程式，它可以在網路（通常為 Web）中被描述、釋出、查詢以及呼叫。

   通過改造待整合的業務系統，由業務系統通過提供 Web services 服務的方式，由 portlet 呼叫 Web services 服務來實現業務資料的採集，由 portlet 完成業務資料與門戶站點內容的聚集。

5. 直接訪問業務系統資料來源

   業務系統直接提供資料來源的訪問地址（如資料庫伺服器 IP），通過 JDBC 或 ODBC 技術，由 portlet 應用程式程式設計實現資料資料採集，而無需修改待整合的業務系統。

回頁首

結束語