當今 IT 環境的特點是：異構而複雜的應用程式、進度緊張、受預算約束，以及一個不斷變化的業務需求前景。幾乎沒有企業能夠以一種高效率的方式，靈活而有效地增強其現有的基礎架構，來迎接和克服這些挑戰。即便如此，為了快速而經濟高效的處理源源不斷的高度複雜而動態的業務需求，企業需要一種靈活而動態的方法來自動化、構建和管理關鍵業務流程。

　　解決方案

　　面向服務架構（SOA）常常被奉為解決上述業務挑戰的一種可行的解決方案。SOA 是一種通過使用和組裝構建模組來概念化、設計和構建應用程式的方法，每個構建模組通常被表示為一個可重用的服務。目前使用的許多 SOA 方法只是簡單地封裝一些業務功能，然後是用在應用程式中，而且採用了一種臨時、靜態和不靈活的方法。開發未來應用程式和業務流程的推薦方法是採用正式的 SOA 實現框架，該框架是動態的、靈活的和可伸縮的，足以滿足變化的和複雜的業務需求。不管您是否為 SOA 實現購買或構建了一個框架，該框架的功能必須要保證有利於您的解決方案。

　　SOA 實現框架概覽

　　OA 實現框架是一種允許利用 SOA 原理高效構建應用程式和業務流程的技術。它為架構師、開發人員和管理員提供了一個操作框架和工具，允許他們配置、使用和管理企業服務，這些企業服務構成了應用程式和業務流程的構建模組。這個框架在實現流程的各個級別和階段中使用了一種以服務為中心的方法，並具有以下普遍特徵：

　　利用高度安全的、獨立於協議的方法來動態連線客戶機和服務的能力。

　　可靠的處理服務執行的同步和非同步模式的能力。

　　以宣告方式定義和處理事件的能力。

　　在客戶機和服務之間動態轉換資料格式的能力。

　　以集中方式管理分散式 SOA 資源（服務、配置、策略等）的能力。

　　在服務執行過程中捕獲和處理異常的能力。

　　記錄和監控在客戶服務交易期間出現的不同事件並進行度量的能力。

　　提供統一的可重用服務呼叫程式碼庫，用於企業中所有應用程式。

　　支援 Web 服務標準堆疊，以促進大規模的採納和互操作性。

　　框架元件

　　服務註冊

　　服務註冊是企業啟用 SOA 解決方案的一個基礎部分。它用於定義、配置和實施業務服務，這些服務以集中方式使用在應用程式中。因為缺乏一個精心設計和管理的服務註冊，許多公司無法實現 SOA 全部的潛力。這包括用於定義和配置服務到服務、提供者、消費者、服務互動、策略和所有相關配置所需的重要資訊。服務註冊駐留在一個高效能資料儲存中，並可使用服務管理器來檢視和管理，這將會在稍後予以說明。

　　服務匯流排

　　服務匯流排是一個在客戶機應用程式與服務之間進行協調的高效能元件，它通過代表客戶機以及旨在提高統一而又可重用的技術性功能的服務來提供功能的公共部件，從而提高了其價值，這就是 SOA 真正實現的關鍵所在。它通過提供一種標準機制來連線服務並封裝服務實現細節，使客戶機可以集中關注業務邏輯。

　　服務匯流排使用了一種流水線的方法，即把匯流排看作一系列的部件 — 一條流水線。流水線的每個階段本質上都是一個增值的部件，從前一個階段接收一系列的輸入，然後處理資料，並把輸出傳輸到下一個階段。

　　服務匯流排的特點如下：

　　動態連線性和路由：動態連線性是指不需要為每一個服務使用一個分離的靜態 API 或者代理就可以動態連線到網路服務。現在的大多數企業應用程式都是執行在一種靜態連線方式上，並且每個服務都需要一些靜態程式碼片段。動態服務連線性是企業靈活性的關鍵。動態連線性 API 也是如此，如果不考慮服務實現協議（Web 服務、JMS、EJB/RMI、POJO 等等）。客戶端應用程式可以通過 URI 介面訪問服務，該介面要麼直接對映到服務上，要麼根據服務請求的環境或者內容被路由到服務上。

　　可靠的訊息傳輸：可靠的訊息傳輸是指把服務需求訊息進行排序並確保這些訊息被傳輸到目的地的能力。如果需要，它還包括將響應訊息回饋給請求方的響應能力。這種能力主要用於處理事件，這對以非同步方式響應客戶和成功的 SOA 實現至關重要。它主要是通過使用可靠的 JMS 排序與儲存、傳送和確保交付的能力實現的。

　　安全：一般來說，處理和加強安全是 SOA 實現的一個關鍵成功因素。主要考慮以下問題：

　　 聯合驗證：這個特性擷取服務請求並新增適當的使用者名稱和憑證。它還可以在傳送服務執行請求之前驗證服務請求。

　　 授權：驗證每一個服務請求併發放授權，來確保傳送方具有訪問服務的正確許可權。

　　 加密/解密：在元素層加密請求和響應資訊的 XML 內容，並且解密相反的指令碼。

　　轉換：在客戶端和服務使用不同的資料格式時需要進行轉換，即根據規定的轉換規則把資料的既有格式轉換成目標格式的能力。

　　快取記憶體和效能策略：對提高服務的效能和質量，以及最終增強提高整體顧客服務來說非常重要。它可以在不同的層次上執行，包括服務配置，服務響應資料的服務和其他 SOA 資源，取決於如何通過優化來獲得高效能。整體效能還可以通過壓縮在節點間傳輸的基於 XML 的訊息來獲得提高，這樣可以降低頻寬利用率。為了達到這個目標，壓縮和解壓縮代理被安裝在 SOA 柵格的邊緣。

　　日誌：在出於審計、問題診斷和監控等目的而需要跟蹤系統執行和效能。可以為任何服務記錄日誌，還可以在各種不同的層中記錄日誌。

　　監控：是指跟蹤通過匯流排發生的服務活動，並提供可見的度量標準和統計資料的能力。監控的特殊意義是指能夠發現業務流程中出現的問題和異常情況，並且快速採取行動來解決問題。

　　服務水平協議（SLA）：SLA 定義了與 Web 服務操作和業務流程相關的效能擔保——諸如響應時間和服務可用性等——效能擔保對業務關鍵的操作來說很重要。服務提供商可以使用 SLA 來推廣和建立服務水平協議。這可以幫助他們提供適當數量的資源和優先提供維護服務。

　　版本控制：是指版本化 Web 服務和前攝性地幫助客戶開展客戶端應用程式遷移工作，Web 服務的最新版本一經推出，就立即幫助客戶把客戶端應用程式遷移到最新版本中。版本控制支援包括能夠註冊同一服務的不同版本，根據需要向客戶端提供所有版本的 API 和庫，以及幫助把客戶端遷移到新版本中。版本控制組件使用基於 XLST 的轉換規則把對舊版本服務的請求轉換成對新版本的請求。

　　異常管理：是指在客戶訪問業務服務時跟蹤和處理出現的異常的能力。異常細節包括捕獲和日誌記錄的異常程式碼、名稱、原因和描述。可以通過按照預先定義的次數嘗試重複連線，路由到一個替代服務中，或者簡單地返回執行失敗的原因來處理異常。

　　定製業務邏輯處理：為在服務處理過程中插入定製的業務邏輯提供靈活性。舉例來說，一個具體的業務邏輯要麼先於提交服務執行請求之前在服務請求上執行，要麼先於傳送服務響應到客戶端之前在服務請求上執行。

　　服務匯流排本身是作為一種服務實現的，使用了 Web 服務或者 EJB 技術。這種服務被部署到伺服器池或者群集中，並可以橫向擴充套件。上述元件必須符合相應的 Web 服務標準。

　　服務管理器：

　　服務管理器是一種基於 UI 的管理工具，它可以授權管理員和業務經理來定義、配置、管理和監控業務服務以及應用程式中使用的相關資源。它可以被看作是 SOA 實現的控制中心，主要用於供應和監控服務。服務管理器的兩個關鍵功能如下：

　　服務配置管理：使用這個功能，管理員可以隨時隨地配置服務註冊中存放的服務。使用者可以定義服務、位置、繫結資訊和服務配置設定（如安全性、快取記憶體、轉換、日誌和監控）。他們還可以定義服務提供商和消費者以及相關的服務契約。

　　服務活動監控：為業務經理和管理員提供一個檢視通過匯流排發生的服務活動相關的主要效能資料和統計指示板。使用者可以檢視和監控服務使用、響應時間、服務異常、行為日誌、資訊等等。服務管理器就像一種基於 Web 的應用程式，可以在沒有任何客戶端安裝需求的情況下訪問。

　　客戶端 SDK

　　客戶端 SDK 是一種連線服務匯流排時所需的軟體。SDK 被以 API 的形式包裝和提供，可以從服務管理器中下載這個軟體。它是一種易於使用的庫，開發人員可以用來在應用程式和業務流程中發現、訪問和利用業務服務。這樣可以顯著的提高了開發人員的生產力，因為它把開發人員從資訊調查工作中解放出來，而由服務匯流排來執行。客戶端 API 不使用服務位置依賴的、硬連線的代理和呼叫存根來訪問服務。相反，它使用一種動態機制來通過匯流排連線到服務。

　　SOA 實現框架使用

　　OA 實現框架可以用來開發強大的應用程式和業務流程。圖2展示了一個使用場景，使用 SOA實現框架來構造客戶自我服務的應用程式，其中包括訂單管理和客戶支援功能。應用程式使用客戶端 SDK 通過匯流排來連線訂單和支援流程中的核心業務，諸如提交購買訂單、第三方信用驗證、訂單狀態、支援案例條目和支援案例狀態等。這些功能要麼作為 Web 服務，要麼作為其他 Java API 釋出，通過在現有應用程式中包裝業務邏輯 ——SAP訂單管理和定製的客戶支援應用程式。進一步說，信用服務是一種駐留在合作伙伴站點中的 Web 服務。

　　這個例子闡述了客戶端應用程式輕鬆地以一種統一的、獨立於服務邏輯的方式連線異構服務的能力。

　　SOA 實現的最佳實踐

　　除了使用強大而靈活的 SOA 實現框架之外，任何成功的 SOA 實現都需要一系列在開發週期不同階段中的指導和最佳實踐。一組核心的指導如下：

　　使用新服務的流程必須是受配置和發現流程驅動的，這與實現一種冗長的手工流程週期相對。這樣可以確保整個系統能夠以最少的投入來滿足未來需求。

　　一次 SOA 實現就像用來設計業務服務的方法一樣成功，每一服務必須被抽象為一種粗粒度的業務功能，並按照可以在企業之間耦合和重用的方式進行設計。

　　在可以縮短響應時間和提高整體使用者體驗的地方，服務必須設計成非同步的。

　　客戶端應用程式必須使用統一的服務訪問機制，以一種獨立於協議的方式，而且不必考慮服務是本地還是遠端。此外，客戶必須關注業務邏輯，而業務連線性邏輯必須從客戶端 SDK 中抽象出來。這樣確保了集中式管道邏輯、更高的應用程式開放人員生產力以及易於維護。

　　OA 實現框架中的普通元件必須以一種標準方式釋出，來促進程式碼的統一和重用。

　　在可能的地方使用配置，而不是基於定製和程式碼的業務邏輯。這樣可以提高以最少的投入和最短的時間來滿足未來業務需求的能力。

　　重用和包裝現有業務應用程式邏輯和更加粗粒度的業務水平服務。避免重寫原有實現邏輯。