評論專欄: 使 Web 2.0 趨向成熟

CloudSpace發表於2010-08-20
Web
Roland Barcia (barcia@us.ibm.com), Software Services for WebSphere, IBM

簡介： Web 2.0 迅速成為主流應用程式。富網際網路應用程式和社交網路比比皆是。瀏覽器的日益成熟、網路速度的迅速增長、以及 HTTP 基礎架構的建立都鑄就了這一切。Ajax 是客戶端的主要服務呼叫模型。中介軟體逐漸無用武之地。然而在這種情況下，構建現代應用程式時仍然有許多人墨守陳規，這就會導致技術方案變難。

解放思想

應用程式在不斷演化當中，基礎架構和最佳實踐也是。圖 1 是在 Java™ EE 中常見的一個經典 Web 架構例子。在這個架構中，應用程式伺服器被看作既執行業務邏輯又處理 Web 事務。除了執行事務邏輯之外，執行在此架構中應用程式伺服器上的應用程式必須：

  • 生成 HTML。
  • 組合 HTML 佈局。
  • 處理一個 Web 頁面向另一頁面的流動。


圖 1. 經典 MVC
圖 1. 經典 MVC

Struts 和 JSF 這類架構提供裝置管理。對於如今的許多應用程式來說，這類架構仍然有重大作用，但是對這個應用程式模型存在負面影響：

  • 這些典型的應用程式依賴於 HTTP 會話狀態。久而久之，這將導致 HTTP 會話變得十分龐大，因此影響應用程式的可伸縮性。會話狀態越龐大，對可伸縮性和執行能力的影響越大。
  • 伺服器的記憶體佔用通常比較大。很多時候, 框架維護應用程式檢視的記憶體副本，例如，建立維護 UI 樹所需物件和任何請求限定物件的一個典型的 JSF 應用程式。這會隨著 UI 物件的垃圾收集而增加 CPU 週期。
  • 緊耦合開發是這種方法的另一個劣勢。Web 頁面開發人員與建立業務邏輯的開發人員的技能不同。Web 開發人員往往在語言、HTML、CSS 和指令碼呈現方面較為嫻熟。他們常常使用 WYSIWYG 編輯器、指令碼編輯器和瀏覽器除錯工具之類的工具。他們經常為實現 Web 頁面視覺化而進行快速變更，且頻繁四處移動。業務邏輯開發人員通常精通資料訪問、訊息傳遞、事務處理和整合，且精於使用各種工具。

由於瀏覽器現在可以託管富網際網路應用程式了，它會是一個一流的服務使用方。Dojo 等工具包啟用了一整套 UI 工具。 瀏覽器現在可以管理這些事務：佈局管理、元件之間的 Web 流、MVC、Web 狀態和其他 Web 事務。應用程式伺服器現在可以處理資料呈現、執行業務邏輯和業務流，且變得越來越無狀態和可伸縮。圖 2 展示了一個現代風格的 Web 2.0 應用程式。


圖 2. 現代 Web 2.0 架構
圖 2. 現代 Web 2.0 架構

這種方法有許多優點：

  • 檢視顯示邏輯向瀏覽器移動，這使伺服器更為無狀態且更加可伸縮。
  • 伺服器記憶體佔用減少了，因為保持請求級別狀態只需較少的物件。
  • UI CPU 週期移出到瀏覽器以外，這使得業務服務層減少 CPU/資源爭用。
  • Web 開發人員依賴於無處不在的 Web 核心技術（HTML、JavaScript™ 和 CSS），而很少依賴於伺服器端技術。
  • Web 研發更為靈活。因為模擬 JSON 之類的 Web 負載比較容易，現在 Web 開發人員可以勉強接受 Web 伺服器。Web 2.0 客戶端開發人員不需要功能全面的應用程式伺服器，一個普通 Web 伺服器或單元測試檔案系統也可以。我現有的幾個開發工作中，Web 開發人員在無實際服務可用的情況下開發了 80% 的 Web 層。整合測試周期也減少了。圖 3 是該模式的一個例子。


圖 3. Web 介面
圖 3. Web 介面

放鬆約束條件

在企業中, 我認識到我們不能總是完全基於客戶端瀏覽器進行 UI 呈現。對此有幾個原因。最重要的一個是安全邏輯。因為瀏覽器一般用來檢視資源，而有些邏輯您又不想讓客戶瀏覽。這種情況下，就需要伺服器端頁面了。例如，您可以將您的純 HTML 內容包裝在一個 JSP 中，然後實現一些邏輯。UI 邏輯例子在伺服器上執行是否安全取決於終端使用者在瀏覽器上可以看到什麼。圖 4 展示了這個例子。


圖 4. 安全邏輯的伺服器呈現
圖 4. 安全邏輯的伺服器呈現

當您想隱藏決定終端使用者所見內容的 “邏輯” 時，這個模式是最好的選擇。關於初始載荷，您可以用一個簡單的伺服器頁面標記同業務邏輯對話來進行管理。

然而，我想將這同隱藏使用者不能檢視的資料選項區分開。例如，假設您不得不呈現一個動態表單，並隱藏基於使用者許可權的輸入欄位。您可以輕鬆建立一個 JSON 元服務，它僅提供許可欄位（僅向瀏覽器提供這些欄位）和有一個通用客戶端呈現器，使用 DTL in Dojo 這樣的技術。圖 5 展示了這個模型的一個例子。


圖 5. 帶有元服務的動態表單
圖 5. 帶有元服務的動態表單

難上加難

很多情況下，一個簡單的伺服器頁面包裝器就足夠了。然而，發開人員經常在經典 Web 風格和 Web 2.0 風格架構的混合中走向極端。例如，JavaServer Faces (JSF) 等技術在伺服器上提供了一個完整的元件呈現模型。如果您繼續保留黑箱模式，您可以使用這個模式勉強對付；有人認為，伺服器小部件部件模型中的輸出是一個黑箱。伺服器小部件的提供者能夠改變一個元件在瀏覽器中的顯示方式。

不過這只是我的經驗，您絕不能 100% 使用這個模式，且經常不得不偶爾加入一些原生程式碼。在這個模式中，加入原生程式碼的次數可能要更多一些，因為伺服器端工具包通常落後於新的、更豐富的元件。在這個方面，UI 層的風險較大，因為對那些經常改變需求的業務人員來說，它是一個可視層。一旦您必須向程式碼中增加定製的 Ajax 和 JavaScript. 行為，您的實現開始一分為二且受損的風險更大。因為 JavaScript. 經常不得不同一個伺服器元件產生的顯示程式碼進行會話，您只能任由底層小部件集發生變更，這是不容易演化的。


圖 6. 混合呈現將引發破損和膨脹
圖 6. 混合呈現將引發破損和膨脹

模式演變的下一步是用一個工具包（比如，JFS）包裝另一個工具包（比如，Dojo）。這經常發生，因為人們更習慣使用 Java，且認為底層呈現模式是一個熟悉的工具包，它可以抵消黑箱問題。然而以我的經驗，開發人員經常不得不成為伺服器小部件和底層客戶端小部件技術這兩方面的專家，因為他們必須排除故障和維護系統。因此，您失去了成為一個純 Java 開發人員的價值， 更不用說這個模式將使您的架構臃腫：

  • 您可能要為伺服器和瀏覽器中的記憶體付出雙倍的代價。瀏覽器上有 DOM 和小部件，而伺服器上有 JSF 樹。
  • 您錯過了介面解耦議題。Web 開發人員現在需要瀏覽器工具和一個完整的 Java 應用程式伺服器來執行全面測試。

在您支援 Open Web 技術、Flex 和 Mobile App 平臺等多個網際網路 UI 範例的場景中，JSF 這類技術仍具有實用性。您可能想要保留帶各種呈現功能的一套元件，但這僅適用於特殊情況。


圖 7. 伺服器呈現應當關注多渠道
圖 7. 伺服器呈現應當關注多渠道

Web 2.0 成熟度

像 Dojo 這類瀏覽器端技術和 JAXRS 這類客戶端技術正在日益成熟。我曾參與了若干專案，這些專案使用純 Web 技術成功交付了 Web 2.0 應用程式。此外，使用類似 Dojo 的框架可使程式碼易於維護且容易演化，更多跡象表明框架已經隨著時間的推移而走向成熟。Web 2.0 成熟度的不同階段:

  • 視覺化

    使用者介面在繼續驅動 Web 上的大量應用程式。就這點而論，滿足 Web UI 視覺化需求是關鍵。



    圖 8. 視覺化
    圖 8. 視覺化

    UI 設計人員和開發人員必須緊密合作。UI 設計人員必須精通 CSS 才能在這個世界上得以生存。一旦您使資料視覺化，這將導致您的 REST API 首次迭代的形成。

  • 公開

    當您明白了您的使用者視覺化資料的方式，規劃您的 REST API 是走向成熟的下一步。REST 是 World Wide Web 的設計原則，World Wide Web 旨在以可伸縮的方式提供瀏覽內容，含有連結其他 Web 頁面的 Web 頁面。整個頁面被傳輸給使用者，即狀態傳遞。基於 REST 的 Web 服務是圍繞建立無狀態 Web 服務來向客戶傳遞資源這一原則設計的。資源用一個 URI 描述。以這種方式設計 Web 服務有很多益處。

    REST 圍繞約束集建立 Web 服務。以既定方式使用 HTTP 來遵守約束能夠使服務提供者優化這些模式。通過遵守約束，您可以更好地利用 Web 基礎設施。為傳遞最佳 Web 內容，路由器、快取代理（包括瀏覽器中的快取）和 Web 伺服器經過優化。例如，通過在您的資料服務中設定某個快取訊息頭，您可以將瀏覽器作為一個自由快取使用。通過這些渠道交付您的服務也可以使其達到最優。REST 圍繞 REST 式原則交付 SOA，遵循 Web 架構。

    當您的 REST API 演化時，您可以為新的視覺化提供機會。您的使用者可以選擇您的 Web 視覺化，也可以按照 REST API 建立他們自己的視覺化。新客戶有助於 REST API 的演化。



    圖 9. REST API
    圖 9. REST API

  • 社會化

    在 Web 2.0 中社交方面至關重要。提供 REST API 能幫助建立社交團體，因為您的內容格式可以通過簡單的網際網路渠道使用。許多人已經意識到這個價值。例如，我在 developerWorks 上的部落格可以通過一個 Atom 提要得到。由於一個 REST API 是圍繞內容提供的，現在我可以通過我的 Facebook 頁面提供我的部落格，這樣使我的 Facebook 社群和 developerWorks 讀者都能從中獲益。



    圖 10. 內容社會化
    圖 10. 內容社會化

    實現內容社會化是 Web 2.0 走向成熟的下一步。儘管您可能不想讓您的所有內容對公眾開放，企業們逐步意識到防火牆後內部團體的價值。

Web 2.0 技術為您的開發過程提供了諸多益處，包括系統的可伸縮性和資料獲取，但是一些您自己的傳統系統可能會阻礙 Web 2.0 趨向成熟。開始接受 Web 平臺並通過採用現代架構使其發展，這是很重要的。

 

致謝

作者感謝 Kyle Brown 和 Chris Mitchell 審閱本文並提出寶貴反饋。

原文連結：http://www.ibm.com/developerworks/cn/websphere/techjournal/1005_col_barcia/1005_col_barcia.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-671478/，如需轉載，請註明出處，否則將追究法律責任。

相關文章