SOA 案例研究：Web 2.0 SOA 場景

作者：developerWorks 中國, 編輯團隊, IBM

原文連結：http://www.ibm.com/developerworks/cn/webservices/redbooks/soa-case/11.html?ca=drs-cn-1028

Web 2.0 技術概述

Web 2.0 代表一個不斷髮展的網際網路平臺。Web 1.0 是指人與計算機的互動以及提高計算機效率的技術。Web 2.0 是指人通過計算機進行交流以及提高使人類生產力的技術（參見圖 1）。

圖 1. Web 1.0 和 Web 2.0

Web 2.0 改變了業務與其客戶之間的互動方式。注意關於 Web 2.0 的以下資訊：

• 它是可消費服務、富網際網路應用和簡化的程式設計模型。
• 它構建了環境關係並促進了知識共享。
• 它與人及其協作方式有關。

代表性狀態傳輸 (REST)

代表性狀態傳輸 (REST) 是網際網路構建的體系架構模型。REST 之所以流行是因為其簡單性和易用性。

REST 提供了以下原則：

• REST 提供了一種資源導向型服務方式（相對於 RPC 導向型服務方式）。
• 所有資源都可以通過相對 URL 進行定址，例如：/JKHLE/employees 和 /JKHLE/employees/sandy。
• REST 通常使用 HTTP 作為傳輸協議並支援 HTTP GET、POST、PUT 和 DELETE。
• 可以使用在 Web 瀏覽器（或任何其他客戶端或伺服器）中執行的程式碼輕鬆訪問 REST 式服務，並且可以輕鬆保留 REST 式服務並利用現有內容。
• REST 中的領先實踐源於 Web 的使用，因為它是為使用而構建的。

RESTful SOA

RESTful SOA（有時稱為 WOA 或 ROA）是 SOA 的一個例項，它使用來自 Web 的概念作為主服務架構：

• 更易實現 SOA 的有限選項
• 主要使用 REST 表示和訪問服務
• 將資料編碼為 JSON 或 XML（包括 XML 模式，比如 ATOM）
• 在適當的時候可以使用其他方法，比如 JSON-RPC
• 支援使用 AJAX 構建的 富使用者介面

REST 風格的架構保留 SOA 原則。它支援以元件為中心的模型，在該模型中各種伺服器端和客戶端元件可以以一種可伸縮且簡單的方式重用。

案例研究簡介

如前所述，JKHL Enterprises (JKHLE) 是一個虛擬公司，它期望能擴充套件其旅行代理部門。在本節中，我們將介紹 JKHLE 公司的業務和技術挑戰，並檢查其當前的基礎設施（當前架構）。

從事旅遊業的 JKHL 公司

JKHLE 擁有一個旅行代理部門，該部門使用一個線上旅行網站提供所有旅遊資源的一站式訪問。該旅行代理公司的主要業務包括：

• 航班預訂
• 酒店預訂
• 遊艇預訂
• 天氣狀況
• 交通狀況
• 城市資訊（比如方向和感興趣的領域）

JKHLE 想開發一種最好的旅行網站。該網站應該能夠為客戶提供易用的服務，並簡化公司的基礎業務流程。

JKHL 公司的業務挑戰

JKHLE 有以下一些急需解決的業務挑戰：

• 提供一種快速且簡單的架構，以快速地向客戶和合作夥伴交付新產品。
• 使用第三方的新介面，如天氣和交通報告。
• 通過利用 SOA 基礎設施和可消費的服務端消除業務孤立。
• 持續快速地提供簡單的新業務資料和服務。
• 降低呼叫中心成本。
• 以可消費的形式向公共網路公開業務資料。

當前架構和技術挑戰

KHLE 使用的當前架構如圖 2 所示。

圖 2. 當前架構

該架構提出了以下技術挑戰：

• 業務策略被嵌入到業務流程中。業務策略的更改需要更新業務流程，但是更新業務流程非常緩慢、昂貴且容易出錯。 隨著 JKHLE 的持續擴充套件，此限制將變得尤為突出。
• 每個業務系統都孤立執行，當試圖為客戶實現多渠道策略時，這就會造成重大問題。
• 很難將第三方服務整合到整體解決方案中。但是包含這些第三方服務很重要，因為它們有助於將 JKHLE 的旅行產品與其競爭者區分開來。
• 類似地，第三方公司在與 JKHLE 的服務整合時也會遇到困難，這就限制了外部各方使用 JKHLE 的旅行服務。

  使用 Web 2.0 SOA 場景實現

  Web 2.0 SOA 場景可用於幫助 JKHLE 解決其業務和技術挑戰。該場景定義了 3 種實現：

  • RESTful Service 建立實現

  描述對映到資料來源的基於資源的模式。

  • Rendering and Consuming RESTful Services 實現

  描述呈現資料的格式，以及基於 RESTful 服務架構的資料使用。

  • UI Composition and Communication 實現

  描述從 REST 式服務到使用者收集的資料展示。

  每個實現都可以組合或單獨使用以解決業務解決方案。

  將要使用的架構

  為了解決其業務和技術挑戰，JKHLE 構建了一個新架構，該架構使用 Web 2.0 SOA 場景的原則。圖 3 展示了此架構，以及使用實現的位置。

  
  圖 3. 將要使用的架構
  
  

  新的架構具有以下優勢：

  • 業務邏輯和業務策略現在是獨立的實體，這就支援對業務流程變數的快速、簡單且不間斷的補充。
  • 簡化的開發介面使 JKHLE 業務流程能夠更容易地呼叫第三方服務，並使得第三方服務能夠更方便地呼叫 JKHLE 的服務。
  • 新服務和新渠道可以快速整合到架構中。

  客戶端和 RESTful 伺服器的解決方案

  JKHLE 要採用的架構將充分利用客戶端和 RESTful 伺服器之間的設計模式，如圖 4 所示。

  
  圖 4. 客戶端和 RESTful 伺服器的解決方案模式
  
  

  該解決方案模式的使用如下所示：

  • 客戶端（通常是 RIA）向 RESTful 伺服器發出一個基於資源的呼叫。
  • 伺服器將 JSON、XML、RSS 或 ATOM 的負載返回到客戶端。通過 RIA 或呼叫服務來使用返回的負載。
  • 客戶端對 XMLHttpRequest (XHR) 呼叫使用 GET、POST、PUT 或 DELETE 方法，以對映到 RESTful 實體行為。

  產品對映

  圖 5 展示了 JKHLE 用於實現將要使用的參考架構的產品。

  
  圖 5. 產品對映
  
  

  在本紅皮書的其他部分，我們將更詳細地介紹每個實現，以及 JKHLE 用於實現每個實現的產品。

  RESTful Service 建立實現

  JKHLE 使用 RESTful Service 建立實現來解決網際網路服務域和服務整合域之間的互動，如圖 6 所示。

  
  圖 6. JKHLE 使用 RESTful Service 建立實現的位置
  
  

  以下架構考慮因素與 RESTful Service 建立實現有關：

  • 建立 REST 式服務的資料來源（比如 Web 服務、資料庫和螢幕抓取）
  • Java™ 物件（比如 Java beans、EJB™ 3 和 JPA）
  • 對映到後端實體的資源模型
  • 安全性
  • 治理

  設計模式

  本節將介紹 REST 式服務建立實現的 2 種設計模式。第一種設計模式如圖 7 所示。

  
  圖 7. 設計模式
  
  

  該設計模式描述了以下資訊：

  • 現有遺留資料被轉換為 REST 式服務。
  • 每個資源有一個 URI/URL，並且這些資源使用 REST 實體模式進行公開。
  • 可以使用簡化的實體命名規則。例如：GetOrderServices?ordernumber=12345 可更改為 /rest/orders/12345。
  • REST 式服務提供的每種操作都是一種 HTTP 方法。例如，URI 為 /JKHLE/hotel/reserve 的資源能夠使用 GET /JKHLE/hotel/reserve 進行呼叫。
  • REST 服務負責呼叫應用程式服務。該應用程式服務可以通過一個介面卡與另一個後端服務的企業服務匯流排進行連線。

  第二種設計模式如圖 8 所示。

  
  圖 8. 設計模式
  
  

  這個設計模式描述了模式的構建方式：

  • 構建 Java EE 工件，比如 EJBs、servlets 或重用現有 Java EE 工件。
  • 使用 WebSphere® Application Server Feature Pack for Web 2.0 公開這些工件，如通過 HTTP 的 JSON，或通過 HTTP 實體的 XML。
  • 必要時使用 WebSphere DataPower® in the DMZ 新增更多 Web 2.0 安全性服務和轉換。
  • 根據客戶端傳送正確的 HTTP 內容。例如，將 JSON 傳送到 Web 瀏覽器，將 XML、ATOM 和 RSS 傳送到其他客戶端。

  
  

  Rendering and Consuming RESTful Services 實現

  JKHLE 使用 Rendering and Consuming RESTful Services 實現來解決消費者渠道和網際網路服務域之間的互動，如圖 9 所示。

  
  圖 9. JKHLE 使用 Rendering and Consuming RESTful Services 實現的位置
  
  

  以下架構考慮因素與 Rendering and Consuming RESTful Services 建立有關：

  • 響應負載（比如 XML、JSON、 ATOM 和 RSS）
  • REST 介面分組治理
  • 安全性（包括 HTTPS 和 SPNEGO）

  執行時考慮因素

  以下產品可用於實現 Rendering and Consuming RESTful Services 建立：

  • WebSphere Application Server Feature Pack for Web 2.0
  • 通過 REST 公開基於 Java EE 的工件。
  • WebSphere sMash
  • 為建立 Web 2.0 應用提供了開發和執行時環境。
  • 提供與 Dojo widgets 和 Groovy 或 PHP 指令碼的緊密 REST 整合。
  • WebSphere DataPower
  • 提供了 Web 2.0 應用，支援 REST-SOAP 和 JS 檢查。

  本節將介紹這些產品的作用，以及在 Rendering and Consuming RESTful Services 實現中使用這些產品的設計模式。

  WebSphere Application Server Feature Pack for Web 2.0

  Web 2.0 Feature Pack 擴充套件了 WebSphere Application Server 的功能，它具有以下元件：

  • Web 2.0 到 SOA 的連線性

  該元件用於支援從 Ajax 客戶端到 SOA 服務和其他 Java EE 資產的連線性。該元件通過 Web 提要將企業資料擴充套件到客戶和合作夥伴。

  • Ajax 訊息傳輸

  該元件用於將 Ajax 客戶端連線到即時更新資料，比如股票報價或即時通訊。

  • Ajax 開發工具集

  該元件是 WebSphere Application Server 基於開源 JavaScript™ 執行環境的最佳 Ajax 開發工具集。

  Web 2.0 Feature Pack 可以在設計模式中使用，如圖 10 所示。

  
  圖 10. 設計模式
  
  

  該設計模型支援將 Ajax 客戶端和混搭應用程式連線到外部 Web 服務、內部 SOA 服務和其他 Java EE 資產。它通過 Web feeds 向客戶和合作夥伴擴充套件企業資料。

  WebSphere sMash

  WebSphere sMash 支援開發人員使用整合執行環境和工具包中的 PHP 指令碼、REST 和 Dojo 快速構建並靈活地執行基於 Web 2.0 的應用程式。WebSphere sMash 側重於快速麵市、易於開發和部署，以及慣例優先原則。

  WebSphere sMash 提供了乾淨且簡單的 REST 介面。每個 REST 都由一個事件處理程式檔案定義，並具有對映到 REST 動詞的獨特函式。例如，REST 動詞 POST 對映到事件方法 onCreate()， 並擁有名為 /resources/people 的示例 URL。

  WebSphere sMash 提供了將響應資料到 XML、JSON 和 ATOM 的自動化轉換。

  WebSphere DataPower

  WebSphere DataPower 是一個特殊的網路應用集合，它有助於整合、簡化和加速 SOA，並加強安全性。 WebSphere DataPower 可以多種方式支援 Rendering and Consuming RESTful Services 實現：

  RESTful 資源聚合：

  • 場景：跨多個服務實現的資源請求。這些呼叫的結果需要聚合或組合成一個複雜的報告。
  • 解決方案：WebSphere DataPower 充當定義聚合資源 URI 的中介。該中介將請求傳送給供應商並聚合響應。

  媒體型別轉換：

  • 場景：現有供應商實施一種媒體型別，而客戶端需要其他媒體型別。
  • 解決方案：WebSphere DataPower 充當在請求資訊中轉換 Accept 頭部和在響應資訊中轉換 Content-Type 頭部的中介。該解決方案擴充套件了線速轉換。

  REST / SOAP 仲裁：

  • 場景：供應商支援 REST，但是現有客戶端需要 SOAP。
  • 解決方案：WebSphere DataPower 充當公開 SOAP 的中介。它將請求資訊從 SOAP 轉換到 REST，並將響應資訊從 REST 轉換到 SOAP。

  版本仲裁：

  • 場景：消費者和供應商各自發展。目標是最小化供應商實現的數量。
  • 解決方案：WebSphere DataPower 充當代理多個資源版本的中介。資源請求轉換為新版本。還將執行任何需要的標題和實體轉換、改進或篩選。

  服務仲裁質量：

  • 場景：消費者簽訂使用資源配額的合同。必須監控該使用合同，並且根據請求率和請求數量執行。
  • 解決方案：必要時，WebSphere DataPower 充當監控和執行服務限制質量、調速和請求形成的中介。

    UI Composition and Communication 實現

    JKHLE 使用 UI Composition and Communication 實現，以提供業務域的更多功能，如圖 11 所示。

    
    Figure xxx. Requires a heading
    
    

    圖 11 JKHLE 使用 UI Composition and Communication 實現的位置

    
    

    以下架構考慮因素與 UI Composition and Communication 實現有關：

    • 無狀態實體
    • 框架（比如 Dojo 和 JSF）
    • 容器（比如 portlets、iWdigets 和 iViews）
    • 治理
    • 安全性（包括 HTTPS 和單點登入）

    執行時和工具考慮因素

    因為有很多客戶端軟體和技術可供選擇，所以 IBM 意識到它必須支援從異構到客戶端 SOA 這一範圍內的所有領域。為了實現該目的，IBM 制定了以下策略：

    • 支援通過標準進行 UI 聚合。

    這包括 Web 標準（比如 JSR 53 和 JSR 127）、portlet 應用（比如 JSR 286 和 JSR 168）、混搭（比如 OpenAjax 和 iWidget）和豐富的桌上型電腦 / 裝置（比如 Eclipse 和 iView）。

    • 通過產品交付開源聚合。

    IBM 提供並宣傳應用內容的技術。這包括客戶端容器的 W3C 開源 / Web 標準和開源框架（比如 Web 瀏覽器和 Lotus® Expeditor），以及臺式和移動應用的 Eclipse 和 SWT。

    • 支援通過中介軟體進行客戶端 UI 整合。

    IBM 完全支援使用者整合、邊緣整合和 SOA 層之間的整合。

    IBM 端到端軟體客戶端平臺策略如圖 12 所示。

    
    圖 12. IBM 端到端軟體客戶端平臺策略
    
    

    Dojo

    Dojo 是一個用 JavaScript. 編寫的開源 DHTML 工具集。Dojo 支援將動態功能輕鬆地構建到 Web 頁面中。Dojo 提供了許多功能，並且由 3 個主要層構成：Dojo Core、Dijit 和 DojoX。

    Dojo 工具集是一個 JavaScript. 工具集，它具有豐富的使用者介面，用於開發 Ajax 應用。它在大多數現代客戶端容器上都能很好地工作，並且佔用資源少、效能高。IBM 支援 Dojo 工具集； 在 Dojo 工具集中建立的 Ajax 應用可以被 WebSphere Application Server 和 WebSphere Portal 使用。

    可從以下網址下載 Dojo 工具集：

    http://www.dojotoolkit.org/

    
    

    設計模式

    WebSphere Portal 和 Dojo 可用於支援 UI Composition and Communication 實現，如圖 13 中的設計模式所示。

    
    圖 13. 設計模式
    
    

    該設計模式描述了以下資訊：

    • WebSphere Portal 支援支援 Ajax 的 portlet，可以使用 IBM Rational® Application Developer 或 Portlet Factory 生成這些 portlet。

    此應用允許選擇部分更新。

    • Dojo Dijit 用於呈現 portlet 內部的小部件。
    • portlet 的目的是呼叫 REST 式服務。

      結束語

      JKHL 實現了基於 Web 2.0 SOA 場景的 3 種實現的解決方案：

      • RESTful Service 建立實現
      • Rendering and Consuming RESTful Services 實現
      • UI Composition and Communication 實現

      這些實現使 JKHLE 能夠構建更好的旅行代理網站。該網站提供的快速架構可以交付新產品、使用新服務、消除業務孤立，以及以可消費形式在 Internet 上公開業務資料。

      
      

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