Web 2.0 使用者介面技術

Web 2.0 使用者介面技術 讓伺服器部署的應用程式具有優於瀏覽器的使用者體驗

文檔選項 將此頁作為電子郵件發送 拓展 Tomcat 應用 下載 IBM 開源 J2EE 應用伺服器 WAS CE 新版本 V1.1 層級: 初級 Sam Thompson, 解決方案架構師，IBM Emerging Internet Technologies, IBM 2007 年 2 月 26 日 假設您需要建立一個適合 Web 2.0 環境的新應用程式。一部分使用者非常喜歡基於 HTML 的使用者介面，而其他使用者希望他們使用的每個應用程式都表現得像 Excel 那樣的傳統型應用程式。您的老闆要求有工作效率高的使用者體驗，但是 CIO 不允許開發需要使用者手工部署的任何東西。您知道 HTML 無法達到這樣的目標，但是怎麼做才能符合要求呢？本文要討論一系列 Web 2.0 使用者介面技術，讓您構建的應用程式具有比瀏覽器更好的使用者體驗。而且，可以像任何其他 Java 2 Enterprise Edition（Java EE）應用程式一樣集中地部署和管理它們。 在使用者介面方面，當今的公司專屬應用程式程式開發人員受到來自使用者和運營部門的雙重壓力。一方面，代表使用者的業務部門希望應用程式具有豐富的使用者介面，能夠最大限度地提高使用者的工作效率。他們希望所有應用程式都表現得像 Microsoft 的 Excel 或者其他客戶機應用程式一樣。希望應用程式能夠提供即時響應。此外，若有相同資料的多個視圖（例如，一個表格視圖和一個圖形視圖），那麼還希望在其中一個視圖中進行修改時，其他視圖能夠立即反映出這一修改。 另一方面，IT 運營部門喜歡純粹的基於伺服器的交付模型。儘管他們知道 HTML 使用者體驗不如基於本機作業系統（OS）的使用者介面那麼健壯，但他們認為為了改進使用者體驗，安裝、配置和管理客戶機代碼的成本太高了。 IT 組織中的許多人都親身體驗過 20 世紀 90 年代的客戶機/伺服器部署模型，不願意再重複那樣的經曆。實際上，如果有客戶機組件存在，許多 Java 2 Enterprise Edition（Java EE）應用程式可能不會構建起來，因為成本對於應用程式的營運目標來說太高了。伺服器交付的部署模型為 IT 組織提供了低成本高效率的部署方式，這在 90 年代是 IT 組織的夢想。大多數組織都意識到了伺服器部署的 Java EE 應用程式的經濟優勢，因此根本不會考慮部署那些必須在各個客戶機上進行安裝的代碼，除非是不得已。 那麼，企業開發人員應該怎麼做呢？使用者不希望由於幾秒的伺服器回應時間而降低工作效率，而 IT 部門又不同意採用在客戶機上部署和管理代碼的老方法。如何能夠滿足這些表面上相互衝突的需求，讓雙方都滿意呢？ 幸運的是，現有的技術使您能夠提供比瀏覽器更好的使用者體驗，同時不必在客戶機上手工安裝代碼。用這些技術構建的應用程式有時候被稱為 Web 2.0 應用程式。在 Tim O'Reilly 的文章 “What Is Web 2.0? Design Patterns and Business Models for the Next Generation of Software” （參見 參考資料）中，他指出： 我們正在進入一個前所未有的使用者介面革新時代，Web 開發人員最終能夠構建出與本地 PC 應用程式同樣豐富的 Web 應用程式。 Web 2.0 應用程式同時提供了兩種環境的優點：低成本高效率的基於伺服器的部署模型，以及幾乎可以與客戶機應用程式媲美的使用者體驗。 對於為當今的 Java EE 應用程式提供豐富的使用者體驗，有幾種技術可供選擇： Flex 和 OpenLaszlo IBM Workplace Managed Client 和 IBM Lotus Expeditor Faces Client Components Ajax HTML Flex 和 OpenLaszlo Flex 和 OpenLaszlo 是極其相似的聲明式方法，用來為 Java EE 應用程式建立比瀏覽器更好的使用者體驗。Flex 由 Adobe/Macromedia 提供，而 OpenLaszlo 是最初由 Laszlo Systems Inc 建立的開放源碼軟體。在這兩種環境中，都使用獨特的基於 XML 的文法來布置和建立使用者介面。 例如，為了在 Flex 中使用一個按鈕，可以用 MXML（Multimedia XML）編寫以下代碼：<a name="code-text"><mx:Button label="Submit"</mx:Button></a> 而對於 OpenLaszlo，可以用 LZX（LasZlo XML）編寫以下代碼：<a name="code-text"><button<Submit</ button></a> 為了允許不同的 UI 元素與伺服器進行互動和通訊，可以用 ActionScript（Flex）或 JavaScript（OpenLaszlo）編寫指令碼。 儘管這兩種技術有許多相似性，但關鍵的一點差異是它們需要的運行時基礎設施。對於需要與伺服器交換資料的客戶機，Flex 需要一個 Flex Data Services Server，它與 Flash Player 外掛程式中啟動並執行客戶機進行通訊。在本質上，這個伺服器為客戶機和應用程式的伺服器組件之間的所有通訊和資料交換提供中介。 OpenLaszlo 的最新版本做了一些運行時改進，使它對於開發人員更具吸引力。一項改進是版本 3 引入了一種 SOLO 開發模式，使得在某些部署配置中不再需要 Laszlo Presentation Server。另一個主要的改進是客戶機運行時環境。最新版本（OpenLazlo 4）正處於 beta 測試階段，它使基於 Laszlo 的應用程式能夠不帶 Adobe/Macromedia Flash Player 外掛程式運行。許多公司不願意被限制於某種專有的外掛程式（比如 Flash Player），他們會歡迎這一改進。 如何判斷哪種產品更適合您的組織？Flex 的主要優點是可以從 Adobe/Macromedia 獲得充分的產品支援，但是要為 Flex Data Services Server 的許可證付費。對於某些公司來說，付出許可證費用來換取得到充分支援的產品是值得的。Adobe Flex 2 應用程式也需要 Flash Player plug-in V9。儘管 Flex 可以建立豐富的使用者體驗，但是某些公司不願意承受費用和外掛程式限制。 OpenLaszlo 技術最初是作為商業產品發布的，但是在 2004 年 Laszlo Systems 開放了這種技術的源碼，採用了 Common Public License（V1.0）許可方式。Laszlo Systems 提供支援訂閱，而且因為它是一個開放源碼項目，您可以選擇使用免費資源支援它。對於 OpenLaszlo，費用不是大問題，但是有些組織的公司策略不允許使用開放源碼軟體，所以可能不能選用 OpenLaszlo。 回頁首 IBM Workplace Managed Client 和 Lotus Expeditor IBM Workplace Managed Client 和 Lotus Expeditor 都是在開放源碼的 EclipseRPC 代碼基上構建的。EclipseRPC 這種技術源自 Eclipse 開發工具工作台，這是由 eclipse.org 管理和控制的通用工具開發平台。如果業務需要進行無串連操作，而且可以在客戶機上安裝組件，那麼 Workplace Managed Client 和/或 Lotus Expeditor 是構建和部署應用程式的最佳技術。 IBM Workplace Managed Client 是 IBM 的 Workplace 產品系列的一個組件。它將各種協作服務組合在一個整合架構（或者說案頭環境）中。它提供的功能包括文件管理、訊息傳遞（包括立即訊息）、網頁瀏覽、Notes 7 的直接介面、eLearning、團隊空間、Web 會議以及一個用來跟蹤任務相關的線索的Active Manager。Lotus Expeditor 提供一個富客戶機平台，它支援公司專屬應用程式程式、交易處理、裝置管理和 Web 服務。儘管選擇 Workplace Managed Client 或 Lotus Expeditor 都有不少合理的理由，但是如果應用程式在本質上是協作型的，那麼 Workplace Managed Client 通常是最佳選擇。但是，如果應用程式在本質上是事務性的，那麼通常建議選用 Lotus Expeditor。 Workplace Managed Client 和 Lotus Expeditor 都使開發人員能夠建立駐留在客戶機上的富客戶機應用程式，可以支援無串連操作。因為應用程式駐留在客戶機上，客戶機可以充分利用它所在工作站的功能，可以建立出高度互動性的使用者體驗。Eclipse 是 Workplace Managed Client 和 Lotus Expeditor 共同的基礎，它提供了一個獨立於作業系統的平台，對開發人員隱藏了作業系統的細節差異，同時儘可能利用本機作業系統服務。因此，您可以開發一個 Java 代碼基，它能夠在 Linux 和 Windows 上運行，以後甚至能夠在 Macintosh 上運行。 為了利用這種技術，需要讓應用程式利用 Eclipse 外掛程式體繫結構。使用者介面組件是使用 SWT（Standard Widget Toolkit）組件或 jFace 組件構建的。SWT 是一個與本機視窗系統整合的組件集和圖形庫，但是使用獨立於作業系統的 API。jFace 是一個使用 SWT 實現的 UI 工具包，它簡化了許多常見的 UI 編程任務。jFace 在 API 和實現兩方面都獨立於視窗系統，其設計目的是使用 SWT 而不是隱藏它。最終結果是更具互動性的使用者體驗，其外觀和感覺與使用者熟悉的其他本機作業系統應用程式相似。 最後，“由伺服器管理” 這一特性使基於 Workplace Managed Client 或 Lotus Expeditor 的應用程式有別於本機 Windows 應用程式。這項關鍵特性消除了與客戶機駐留的應用程式代碼相關聯的大多數（如果不是全部的話）系統管理成本。因此，部署應用程式的企業會獲得伺服器部署的 Java EE 應用程式的所有成本優勢，同時使用者能夠享受作業系統特有的客戶機駐留的應用程式的使用者體驗；對於大多數組織，這都是雙贏的結果。 回頁首 Faces Client Components JavaServer Faces（JSF）是一種 Java EE 1.4 組件，最初是作為 JSR 127 開發的。這種技術的關鍵目標是，降低為 Java EE 應用程式開發使用者介面時要求 Java 開發人員具備的技能水平。因為 JSF 是一個架構，它提供了許多開箱即用的功能；在過去，開發人員在用 JavaServer Pages（JSP）構建同樣的使用者介面時需要手工編寫這些功能。 例如，假設您有一個大型 JDBC 結果集，需要將它向使用者顯示。JSF 架構提供了一個 DataTable 組件，可以用來顯示資料。如果使用簡單的 JSP 構建使用者介面，您就必須系統管理使用者與這個資料表的互動，並決定應該向使用者顯示哪些資料行。 通過使用 JSF DataTable，當使用者點擊 Next 來顯示表中的後 x 行資料時，JSF 架構將會處理 Next 請求，您不必自己編寫任何代碼。儘管 JSF 簡化了建立豐富的 HTML 使用者介面的過程，但是根據設計 JSF 是一種基於伺服器的技術。對後 x 行資料的請求從瀏覽器發送到伺服器，JSF 架構代碼在伺服器上處理這個請求。JSF 需要一次到伺服器的請求/響應往返。 為了改進基本的 JSF 組件，IBM 的 Rational Application Developer V6 引入了 Faces Client Components。Faces Client Components 是 JavaServer Faces 技術的一種擴充，允許在用戶端執行某些 JSF 架構服務。例如，如果在上面的樣本中使用 DataGrid Faces Client 組件，那麼後 x 行資料的顯示就不需要到伺服器的請求/響應往返。 對於 Rational Application Developer JSF 開發人員，使用 Faces Client Components 是自然的選擇。為了使用 Faces Client Components，要建立一個 Faces JSP 頁面並選擇 “Basic with client-side data caching ” 作為模型。當在 Rational Application Developer 中構造使用者介面時，只需從 Rational Application Developer 的工具面板中的 Faces Client Components 部分中選擇適當的 UI 控制項。 在 Faces Client Component 的幕後發生了許多情況。會將 JSF 控制項的 JavaScript 實現下載到瀏覽器中，並使用符合行業標準的 Service Data Objects 在瀏覽器和伺服器之間進行通訊。但是，這一切理所當然都是對使用者隱藏的；使用者只會注意到，與典型的基於瀏覽器的應用程式相比，他的應用程式的響應速度快多了。 回頁首 Ajax Ajax（非同步 JavaScript 和 XML）是 Jesse James Garrett 創造的一個術語，它是指一種基於標準的技術/設計模式，用來為伺服器部署的應用程式開發比瀏覽器更好的使用者體驗。Ajax 對伺服器技術沒有什麼要求，可以處理 Java EE 應用程式、.Net 應用程式和其他應用程式。通過使用 Ajax，可以編寫 JavaScript 代碼來改進 HTML，建立出豐富的互動性使用者體驗。例如，JavaScript 可以執行本機使用者輸入驗證，為相同的資料提供不同的視圖（橫條圖、表格、餅圖等等），或者通過瀏覽器的 XMLHTTPRequest 對象與應用程式的伺服器組件進行非同步互動。 根據 Gartner Group 的 Hype Cycle for Emerging Technologies 2000 報告（2006 年 7 月 18 日），Ajax 已經達到了 “過度期望的頂峰”，“幻想” 已經開始成為現實了。看看書店裡有那麼多 Ajax 圖書，就能夠知道這股風潮有多麼熱了。按照我的觀點，有三種東西協助 Ajax 跨越了 Geoffrey Moore 指出的技術鴻溝： 現代瀏覽器。 在過去，編寫 JavaScript 的開發人員必須處理 Netscape、Internet Explorer 和其他瀏覽器之間的許多不相容問題。在某些情況下，甚至同一種瀏覽器的不同版本也有不相容問題。儘管仍然存在一些不相容問題，但是大多數內部網應用程式通常需要 Internet Explorer 5.5 或更高版本和/或者 Firefox 1.0 或更高版本，在這些瀏覽器中以前存在的大多數不相容問題已經被糾正了。近來組成了一個開放的行業協會 OpenAjax，它的目的是解決 Ajax 的不相容性問題，以及解決其他 Ajax 相關問題。 Ajax 工具包。 在過去，希望使用 Ajax 的大多數開發人員實際上必須從頭開始，而 Ajax 工具包現在可以替他們完成許多繁重的工作。工具包提供了各種預製的基於 JavaScript 的使用者介面控制項（組件），讓開發人員可以輕鬆地建立基於 Ajax 的使用者體驗。工具包通常還提供更進階的抽象，從而對開發人員隱藏前面提到的瀏覽器不相容問題。 工具。 直到最近，大多數 JavaScript 開發人員實際上沒有開發工具來協助簡化開發和調試。從 Firefox 瀏覽器發布開始，它就為 Ajax 開發人員提供了一些有用的外掛程式，而且 IBM 最近在 Ajax Toolkit Framework 中整合了一系列有用的技術來協助進行 Ajax 開發。ATF（Ajax Toolkit Framework）可以從 Apache 網站免費下載，它提供一個基於 Eclipse 的 Ajax 開發環境。ATF 提供的工具包括 JavaScript 文法敏感的編輯器、JavaScript 控制台和 XMLHTTPRequest 對象查看器。ATF 還附帶三個預製的個人化組件：Dojo、Zimbra 和 Rico。 最後，按照我的觀點，當 Google 發布基於 Ajax 的 Google Maps 應用程式的 beta 版本時，Ajax 真正的轉折點到了。以前使用過地圖 Web 網站的任何人都會很快看出 Google 地圖軟體的優點。非技術人員感到吃驚，想知道 Google 是怎麼做到的；而知道其原理的程式員開始注意到 Ajax，並開始考慮如何使用基於 Ajax 的技術改進自己應用程式的易用性和響應性。 回頁首 純 HTML 儘管許多開發人員認為所有使用者像他們自己一樣，使用最新的 Firefox 瀏覽器並帶 10 個最流行的外掛程式，但事實是許多機器仍然使用 Netscape 3.x 或 Internet Explorer 4.x 來訪問互連網。使用這種水平的瀏覽器可能是為了使用某一應用程式（它的原始碼已經丟失了，無法修改了），或者是因為使用者非常保守，他們按照 “如果沒有出問題，就不必自找麻煩” 的原則來對待瀏覽器升級，所以仍然使用 Internet Explorer 4.0。 儘管 HTML 顯然不能提供其他技術可以提供的那麼豐富的使用者體驗，但是基於 HTML 的使用者介面仍然會長期佔據一定的地位。還沒有其他技術能夠像純 HTML 使用者介面一樣讓那麼多使用者都能夠使用。因此，在未來的許多年內，許多應用程式仍然會提供這種使用者介面。 回頁首 結束語 總的來說，當今業界的重要方向是改進伺服器提交的應用程式的使用者體驗。Ajax 仍然還不太成熟，但是已經有了一定的實力，而且許多企業（包括小型和大型企業）已經開始在生產中使用它。本文提到的其他技術沒有得到這麼大的關注，但是到目前為止還不能明確地說它們沒有前途。 還存在其他使用者介面技術，包括商業產品和開放源碼產品（比如 Nexaweb、Backbase 和 JackBE），但是由於篇幅限制本文沒有提到它們。關鍵一點是，這些技術都不是放之四海皆準的，所以沒有任何技術對於所有情境都是最佳選擇。這些技術都有各自的優點，都有其適合的情境。 那麼，如何做出選擇呢？對於初學者來說，如果技術選擇背後的主要目標是接觸儘可能多的使用者，那麼沒有任何技術能夠超越老式的 HTML。在另一個極端，如果您需要無串連操作，而且可以在使用者機器上安裝應用程式的組件，那麼基於 EclipseRPC 的替代品之一（Workplace Managed Client 或者 Lotus Expeditor）是最佳選擇。 如果需要的豐富使用者體驗只能通過 Flash Player 來獲得，那麼可能應該使用 Flex 或 OpenLaszlo。如果使用 JavaServer Faces 構建應用程式，那麼使用一些 Faces Client Components 會更好。 最後，如果您的目標只是在現有的 HTML 使用者介面中增加一些易用性特性，或者是提供基於標準的外掛程式免費的豐富使用者體驗，那麼應該考慮使用 Ajax。按照目前的輿論，Ajax 似乎成了最流行的 Web 2.0 技術選擇，但是我不能肯定其他技術在成熟之後會不會取代它的地位。 選擇正確技術的關鍵是，讓應用程式的需求決定對使用者體驗技術的選擇。儘管這個建議似乎是理所當然的，但是在許多情況下開發人員所做的正好相反，他們被時髦的技術宣傳所蠱惑，做出 “技術驅動的選擇”，這常常導致許多困難的實現和部署問題，從而在開發項目時導致嚴重的延誤和問題。不要讓這種情況發生在您身上。 參考資料 學習 您可以參閱本文在 developerWorks 全球網站上的 英文原文 。 What Is Web 2.0? Design Patterns and Business Models for the Next Generation of Software,（Tim O'Reilly，O'Reilly，2005 年 9 月）：瞭解 Web 2.0 的含義。 Workplace Managed Client：這種產品提供完全整合的伺服器管理的協作環境，可以提供豐富的使用者體驗。 Lotus Expeditor：這種平台提供基於 OSGi 和 Eclipse 的伺服器管理的客戶機平台、工具和相應的伺服器端組件，可以使用它構建、部署、維護和整合支援各種裝置和網路的富客戶機和可行動裝置 App程式。 Adobe Systems Flex：這是一種基於 Adobe Flash 的豐富的互連網應用程式架構，可以用它為幾乎任何平台建立漂亮的可伸縮的應用程式。 OpenLaszlo：這是一種開放源碼的平台，可以用它建立無需安裝的 Web 應用程式，而其使用者介面功能可以與案頭客戶機軟體媲美。 Ajax 技術資源中心：developerWorks 上所有有關 Ajax 的問題都可以在這裡找到解答。 Ajax: A New Approach to Web Applications（Jesse James Garrett，AdaptivePath，2005 年 2 月 18 日）：這篇文章首創並解釋了 Ajax 這個術語，所有 Ajax 開發人員都應該讀一讀。 OpenAjax：訪問 OpenAjax Alliance 的網站，這是一個由使用 Ajax 的廠商、開放源碼組織和公司組成的組織，它致力於成功地推廣開放的可互操作的基於 Ajax 的 Web 技術。 JSR 127: JavaServer Faces：JSF 體繫結構和 API 簡化了 Java Server 應用程式 GUI 的建立和維護。 Faces Client Components Developer's Guide（Laurent Hasson，developerWorks，2005 年 5 月）：減少與伺服器的往返互動次數，同時簡化互動性 Web 頁面的開發，改進它們的易用性和效能。 Ajax Toolkit Framework：Ajax Toolkit Framework（ATF）是一個 Eclipse Web Tools Incubator Project，它是一個可擴充的架構和工具集，用於為不同的 Ajax 運行時產品（比如 Dojo、Zimbra 或 Rico）構建 IDE。 使用 XML-RPC 為 C++ 應用程式啟用 Web 服務（Karthik Subbian 和 Ramakrishnan Kannan，developerWorks，2006 年 6 月）：這個分步的指南講解如何將 C++ 方法作為服務公開，可以協助您為 C++ 程式構建自己的基於 XML-RPC 的服務。 developerWorks 的 Architecture 部分：利用在這裡找到的參考資料提高您在體繫結構領域的技能。 Web 開發專區：這裡有關於 Web 2.0、Ajax、wiki、PHP、mashup 和其他 Web 項目的豐富的參考資料。 technology bookstore：瀏覽關於這些主題和其他技術主題的圖書。 developerWorks Web 開發專區：利用專門講解 Web 技術的文章和教程提高您的網站開發技能。 developerWorks 技術活動和網路廣播：隨時關注這些技術活動。 獲得產品和技術 IBM 產品評估版：體驗一下這些來自 DB2、Lotus、Rational、Tivoli 和 WebSphere 的應用程式開發工具和中介軟體產品。 developerWorks RSS 和 Atom 提要：進一步瞭解提要並構建自己的提要。 討論 通過參與 developerWorks blog 加入 developerWorks 社區。 developerWorks 論壇：參與任何以 Web 為中心的論壇。 關於作者 Sam Thompson 於 1980 年加入 IBM，擔任過 VM 產品開發中的許多技術和管理職務。1992 年，Sam 被調到位於北卡羅來納州羅利城的系統管理開發實驗室，協助將幾種 SystemView 產品推向市場。SystemView 與 Tivoli Systems 合并時，Sam 作為技術傳道者週遊世界，解釋這次合并、Tivoli 的新戰略和產品以及 IBM 和 Tivoli 工作群組產品的集中戰略。1997 年 3 月，他在 IBM 的 Emerging Technologies jStart（jump start）小組就任現在的職務，協助 IBM 客戶組織構建利用 IBM 的 XML、Java、Web 服務、富客戶機、Web 2.0 和自動計算技術的解決方案。