使用 WebSphere Portlet Factory 構建SOA 前端
在許多門戶的專案中,客戶對門戶的使用體驗都有非常高的要求。基於現階段的 portlet 技術對豐富的 Web 2.0 前端展現存在著一定的技術難度。WebSphere Portlet Factory (WPF) 利用 SOA 的構建方法,提供無需編寫程式碼的開發環境進行基於 Web 2.0 技術的門戶開發。使得開發人員可以快速地構建良好使用者體驗的門戶應用。加速企業門戶專案的成功實施。本文從 WebSphere Portlet Factory 的整體開發方式出發,完整地講述了 WebSphere Portlet Factory 中支援 Web 2.0 技術的各項功能,為門戶開發人員及使用者提供一個指引及幫助。
根據以往的經驗,開發 portlet、Web 服務和複合應用都需要某一方面的開發技術和專案經驗。但是,在過去幾年內,portlet 的開發社群內發展起了一套使使用者介面 (UI) 和底層的業務應用與流程分離的開發方法。這種方法基於面向服務的體系架構 (SOA),使得關於業務的應用可以更加靈活,本文中的 WPF 正是此類開發方法的軟體工具之一。IBM WebSphere Portal 軟體是目前業界領先的門戶軟體。它可以允許企業的員工、合作方及終端使用者通過安全可個性化定製的 Web 訪問方式與企業內部所有的業務資料及流程進行互動。為了加速企業門戶的開發速度,在 IBM WebSphere Portal 中提供了 IBM WebSphere Portlet Factory(WPF)這一自動化軟體工具,幫助我們開發人員進行基於 SOA 的 Portlet 開發。它可以通過簡單易用的嚮導配置出各種使用者介面及訪問後臺業務系統的程式片段,並整合成可部署到 IBM WebSphere Portal 上的 Portlet 應用。在 2007 年推出的新版本中,該工具更提供了非常豐富的 Web 2.0 技術支援。大大的加快了開發人員開發良好使用者體驗的 Portlet 應用。
本文將從整體上對這一工具進行介紹,並對 IBM WebSphere Portal 中 Web 2.0 技術的支援作了一個描述。在後半部分,本文詳細的講述了 WPF 中對 Web 2.0 技術的使用及開發的一些要點。以求拋磚引玉,讓開發人員瞭解到這一快速開發工具的優勢及如何更好的利用它來開發 IBM WebSphere Portal 的應用。
WebSphere Portlet Factory (WPF) 提供了一個用於建立 portlet 和 Web 應用的框架和部署環境。框架指的是使用 Builder 模式構建我們的 portlet 以及 Web 應用的方法。部署環境指的是利用 WPF 的自動部署以及執行時提供的程式碼支援。WPF 的最新版本為 6.0.1.2。WPF 與其它 Portlet 開發工具的不同之處在於,它提供一個近於零編碼的快速開發環境。可以迅速的以 SOA 的方式整合後臺各種資源,如:Web 服務、關係型資料庫和企業應用如:SAP、Domino 等。而且利用 WPF 開發出來的 Portlet 應用,可以很好的支援利用編輯和配置模式對應用進行定製化。這大大加快了企業構建個性化門戶的建設。
WebSphere Dashboard Framework 以及其上面的 KPI (Key performance Indicaiton) 包如 Sales Dashboard 與 Executive Dashboard 都是基於 WPF 的一整套構建器。其中更關鍵的是 Dashboard Framework 提供了許多易用的 UI 構建器可以迅速的將資料以各種圖表的方式進行展現,以滿足企業當中對業務狀況監控等的需求。
Rational Application Developer 7 (RAD7) 同樣可以進行 Portlet 的開發。它提供了一個完整的 Java 開發環境。它的優勢在於可以進行一個完整的端到端 Portal 應用的建立、測試與排錯等工作,而且具有對 Portal 站點的視覺佈局的編輯功能,即我們可以直接在 RAD7 中進行主題與皮膚的開發。但使用 RAD7 進行開發,則對開發人員的知識有更高的要求,我們開發人員需要對整個 Portal 的應用程式碼以及 Portlet 控制的程式碼進行完整的學習才能在 RAD7 上順利的進行開發。RAD7 更適合於熟悉 Portal 原理以及 Portlet 程式碼的開發人員。與之相比,則 WPF 提供了一個近於零程式碼的開發環境,無需過多的涉及 Portlet 程式碼即可以開發出靈活的門戶應用。當然,使用 WPF 則需要放棄對 Portlet 應用程式碼的完全控制,因為所有的程式碼都是由 WPF 的構建器動態生成的。
另外一個可選的開發環境則是 Lotus Component Designer,此環境更適合於習慣使用指令碼語言進行程式設計的開發人員。有興趣的讀者可以在參考資料的連結中找到相關的內容。
我們可以從中看出 WPF 的定位在於迅速的構建各種系統的前端展現。這也是我們在以後的開發專案中選用 WPF 的基本原則,它是 Portal 強大的整合能力的一個重要技術支援。
利用資料提供者與資料使用者模型。基於 SOA 的架構思想,我們利用資料提供者模型去包裝所有前端可以提供的資料。前端可以利用使用者介面(UI)的構建器對獲取到的資料以不同的表現形式(如表、圖等)進行展現。
資料提供者與資料使用者模型
資料提供者與資料使用者模型是利用 WPF 開發 Portlet 應用的核心模式。它表述瞭如何使用 SOA 的方法將後臺系統的資料來源進行有效整合的方法。利用這種開發模式,我們可以利用不同型別的構建器整合後臺各型別的系統,用統一的表現形式展現給門戶的使用者。這種開發模式使得我們的開發重用性極高,資料的訪問層與表現層相獨立的方式,更能使得開發團隊可以獨立進行工作而不影響進度。這一模式是我們在利用 WPF 進行開發工作中需要掌握的基本原則。
Builder(構建器):構建器提供易用的嚮導介面用於 Portlet 的開發。構建器的實質是利用嚮導中收集的資料生成應用中所有的程式碼,包括:Java 程式碼、XML、變數等。構建器貫穿我們利用 WPF 進行開發的整個生命週期。WPF 內建已經有超過 120 個可用的構建器,大大的提高了我們開發 Portal 應用的效率。
Profile(概要檔案):概要檔案是應用程式中可變引數的集合。也就是說,概要檔案將應用程式中所有可配置的資訊進行引數化。如:使用者身份、語言、地區、使用者組別等。利用這些可配置的資訊,我們可以自動的利用已有的構建器生成針對不同使用人群的應用。比如我們可以針對某些特定的使用者修改後端訪問的資料來源、生成的圖表形式等。概要檔案給予我們開發人員的是強大的配置能力,使得我們只需要修改配置資訊即可重新生成新的門戶應用。
Model(模型):模型是一個構建器的列表。例如,如果我們需要開發一個 Portlet,則需要新建一個模型,並將相應的構建器新增到模型當中去。
以上概念在開發環境中的體現
Web 2.0 是關於如何加強人與人之間的聯絡,如何提升我們的協作能力的概念與技術。它帶來的是一系列因特網服務,這些服務加強了線上的資源共享與協作。其實 Web 2.0 並不是一門專有的技術,而是一些因特網社群內為加強協作與共享的技術或者一類應用的總稱。這些技術包括 AJAX(Asynchronous JavaScript. and XML)、REST、RSS、blog、wiki、mashup 等等。這裡麵包括了幾個方面的內容:一是達到這一線上協作與共享目標的業務模型;二是如何實現這一模型所需要的服務和產品,IBM 的 portal 產品就屬於這一型別;最後是如何更好的使用這些服務、產品當中的技術去開發實現我們所需要的應用,這就是本文所討論的利用 WPF 中相關的工具去實現更好使用者體驗的應用。
我們這裡重點討論的是 AJAX 的技術。其在前端展現在扮演重要的角色。它的基本原理是使瀏覽器開啟的頁可以被分為許多的片段,這些頁面的片段可以獨立的根據後臺不同的資料來源進行更新而無須重新整理整個布面。本文限於篇幅不去深入講述 AJAX 的原理。這裡強調的一點是,AJAX 的開發是需要有一定的 web 開發經驗才能很好的掌握而且運用它的。如果您希望更多地瞭解 AJAX,可以訪問 developerWorks 網站上的Ajax 技術資源中心,這裡是有關 Ajax 程式設計模型資訊的一站式中心。
這裡,我們很自然就會看到為什麼我們需要 WPF。原因就是我們開發 portlet 應用的人員可能在業務整合方面有良好的技術基礎,或者在使用 JAVA 語言編寫業務邏輯程式碼方面有很好的技巧,但是他們不一定有非常豐富的 web 開發經驗。基於這一點,WPF 提供了已經有良好 AJAX 支援的構建器給我們使用,這讓我們不需要去學習許多 JaveScript. 和 XML 的知識,即可以輕鬆的通過配置完成我們 Web 2.0 的 SOA 前端構建。
IBM WebSphere Portal 是使用者與企業內所有資訊系統互動的一個入口。如何提升使用者對資訊系統的使用體驗,Portal 6 版本中已包含有了許多 Web 2.0 的功能,例如:PDM and QuickPlace 的資源工享;WCM 的 inline editing 工具可以直接在釋出頁面上進行資訊的建立;線上感知的功能,加強人與人之間的溝通。這裡特別強調的是在 portal 中使用了一些 AJAX 的功能:上下文選單,可以根據使用者的角色許可權等動態生成;Portlet 皮膚,支援直接的拖拽用於新增 Portlet;頁面上直接的 Portlet 拖拽;單個 portlet 重新整理功能。
WebSphere Portal 自身所帶的 Web 2.0 功能
WPF 對 AJAX 的支援在 6.0.1 版本中得到了新的增強。當我們需要在單個 portlet 的基礎上進行,部分 portlet 頁面的動態重新整理時,我們可以利用三種方式在我們的應用中增加 Web2.0 的展現效果。這些功能都是集中在使用者介面(UI)的構建器當中,即在開發資料使用者模型時進行配置。下面我們將詳細討論一下這三種方式。
這種方式是 WPF 在新版中對原有構建器的增強,主要包括有按鈕、連結、圖形按鈕、 HTML 事件操作、定時操作、客戶端事件處理等構建器。與《在 Portlet Factory 中使用 Ajax 技術》一文描述相一致,這一類構建器(如圖)提供了執行後重新整理或者替換指定位置的功能,這一功能可以生成可工作的 JavaScript. 程式碼,按照我們指定的位置進行更新操作。
操作後行為構建器
這裡有一點需要注意的是,我們在使用這一重新整理功能的時候,要麼顯式的執行一次頁面呈現方法,要麼在呈現方式中選擇如下圖。最佳實踐告訴我們,在開發時候直接在構建器中選擇呈現方式是推薦的做法。
需要注意的引數
通過這種方式實行的效果是將特定區域的內容進行重新處理。舉一個例子,我們可以將頁面部分的內容與某變數相關聯,那麼在處理動作時候我們更新了這個變數,頁面這個部分的內容隨即改變。
有一類特別的構建器這裡需要提出的是事件宣告構建器,該構建器現在可以支援指定事件是傳送到伺服器端進行處理或者是在客戶端直接進行處理或者是兩者都進行。在此基礎上我們可以使用客戶端事件處理或者事件處理構建器進行事件的處理。在事件處理程式中,我們仍然用操作後行為進行部分更新。
客戶端事件構建
這種方式的好處是可以允許同時部分更新頁面上多處位置,我們是利用多個客戶端的事件處理程式進行處理。這種方式還可以用於 portlet 之間的通訊而無需要整個頁面進行重新整理。這種方式大大的方便我們在使用 MVC(model/view/controller)的架構時,可以利用事件的觸發,分別在客戶端進行部分頁面更新,而且將事件傳送到伺服器端進行伺服器端的一個更新操作。這裡面需要注意的是,伺服器端的觸發總是會在客戶端事件觸發之前的。
這一構建器與是舊版本當中的 Asynchronous Client Loader builder ( 已取消 ) 的升級。這一構建器可以將頁面上一個區域進行打包,在任何觸發區域內發生的事件都會引起這個 AJAX 區域的更新。詳細的說明可以參考《在 Portlet Factory 中使用 Ajax 技術》一文中對這一構建器的描述及其與操作後行為的對比。
WPF 還包含了其它使用 AJAX 的高層構建器,如:動態驗證(Dynamic Validation)和 Ajax 預輸入構建器(Ajax Type-Ahead 前身為 Incremental Search)。
AJAX 區域構建器
另外一個用於構建 Web 2.0 應用的重要技術則是 Dojo。Dojo 是一整套純 AJAX 的客戶端開源庫,它可以方便的與其它的技術整合,如 JSF、JSP、PHP 等等。它使用 AJAX 的客戶端互動方式進行頁面更新,其特點在於增加了一些擴充套件的包,裡面包含有豐富的 widget 庫以供使用。Dojo 的框架提供了相當方便的呼叫以支援客戶端的事件處理、資料邦定、拖拽等功能的實現。Dojo Toolkit 當前版本為 0.4.x ( 包含 JavaScript, HTML,CSS)。在眾多 web 開發中已經應用到了這一開源庫。IBM 當前正是這一開源專案的主要貢獻者。因此,在我們的 WPF 工具當中,也對 Dojo 這一工具包提供了良好的支援。
需要使用 Dojo 的功能,我們必須在專案的功能元件中新增對 Dojo 的支援。
在專案中啟用 Dojo
在 WPF 中直接可以使用構建器支援的有以下三種: Drag/Drop 構建器:這類構建器允許我們直接在頁面上新增拖拽的功能。 Dojo 內聯編輯:這一構建器支援我們直接在資料頁(如檢視和表單構建器)上面增加內聯編輯的功能。
Dojo 內聯編輯構建器
內聯編輯功能演示
Dojo 工具提示:該構建器支援顯示一個小的提示塊。
Dojo 提示工具
功能演示
除了以上提到的三種直接支援 Dojo 功能的構建器以外,我們還可以手動的新增 Dojo 的功能模組。我們會使用 Dojo 啟用構建器(Dojo Enable Builder)直接編寫 JavaScript. 的程式碼。
需要其他 Dojo 功能的手工處理
如果錯誤的現象比較明顯,如在伺服器的日誌中發現一些程式碼中丟擲來的錯誤,我們就可以直接進行排查。但往往使用 AJAX 技術應用,在出錯的時候會比較難找到出錯的資訊。一般情況下,我們可能做的是點選後獲得瀏覽器的 JavaScript. 錯誤。另外我們可以使用 Firefox 上的 Firebug, 它支援強大的對 JavaScript. 排錯、跟蹤的功能。在上面的截圖中都有表使用 Firebug 的介面。有興趣的讀者可以參考文章後面的連結下載使用。
WebSphere Portlet Factory 軟體提供了豐富的構建器用於日益增長的對 portal 作為 SOA 前端的應用需求的支援。WPF 支援我們在原有的資訊系統基礎上進行有效的整合。開發人員可以在合理使用構建器的情況下,靈活的面對業務上多變的需求。靈活的運用這些構建器,可以使得我們 portal 的使用者在 Web 體驗方面有一個大的提升。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/14789789/viewspace-434483/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- WebSphere Portlet效能優化Web優化
- WebSphere 和 SOA 新手入門Web
- 構建SOA的IT捷徑:BEAAquaLogicServiceBus
- 監控 WebSphere DataPower SOA AppliancesWebAPP
- 奇幻RPG(人物構建 與 Abstract Factory模式)模式
- 如何使用Docker構建前端專案Docker前端
- 使用WebSphere中介軟體構建資料庫環境故障排除Web資料庫
- 使用 IBM Installation Factory 簡化 WebSphere Application Server 安裝和部署IBMWebAPPServer
- 使用Vite快速構建前端React專案Vite前端React
- WebSphere Business Events 構建業務事件應用程式Web事件
- WebSphere Adapter和WebSphere Process Server為SAP構建RESTful整合,第1 部分WebAPTServerREST
- 前端構建_webpack前端Web
- 使用Gulp構建前端自動化解決方案前端
- 前端構建大法Gulp系列(一):為什麼需要前端構建前端
- 前端構建祕籍前端
- 使用 Nginx 構建前端日誌統計服務Nginx前端
- SOA之(1)——SOA架構基礎概念架構
- 使用 Hbuild 快速構建生成現代化前端專案UI前端
- 前端任務構建利器Gulp.js使用指南前端JS
- 構建一個使用 Virtual-DOM 的前端模版引擎前端
- 構建前端mock伺服器前端Mock伺服器
- 構建一個高可用 WebSphere Business Events 事件基礎設施Web事件
- 使用 Dojo 工具包和 JSON-RPC 構建企業 SOA Ajax 客戶端JSONRPC客戶端
- 使用 Go 和 ReactJS 構建聊天系統(五):改善前端GoReactJS前端
- 後門構建工具Backdoor Factory
- 【前端構建】WebPack例項與前端效能優化前端Web優化
- 基於SOA構建隨需應變的企業應用薦
- 前端測試套件構建實踐前端套件
- 如何構建大型的前端專案前端
- 使用React,Vue和Single-spa構建微前端Micro FrontendsReactVue前端
- 分層架構和SOA架構
- SOA之(2)——SOA架構基礎概念與設計框架架構框架
- 使用Packer構建映象
- Jenkins +nginx 搭建前端構建環境JenkinsNginx前端
- 前端⼤規模構建演進實踐前端
- SOA構建電子政務平臺可用多種通訊手段訪問
- 單體架構,SOA,微服務架構微服務
- SOA:編織未來IT架構架構