在過去幾年間，面向服務的體系結構（Service-Oriented Architecture，SOA）受到了極大的關注，帶來了軟件開發和業務敏捷性的新時代。不過，僅僅 SOA 本身并不能解決世界的 IT 問題。我們仍然需要可靠而有效的軟件工程實踐，因為管理落后的 SOA 實現和其他體系結構方法一樣會出錯（如果不是更糟糕的話）。本文將從實際的角度看待 SOA（技術和業務兩方面），并將提供一個實際的案例研究，說明通過成功的 SOA 實現帶來的好處。
關于 SOA，目前并沒有統一的定義，但為了實現靈活性和業務敏捷性的體系結構目標，確定了以下這個得到廣泛認可的抽象定義：
定義 SOA 的體系結構風格描述一組模式和指導原則，以創建松散耦合的基于標準且與業務相結合的服務，由于描述、實現和綁定之間實現了關注分離，這些服務能夠提供更高級別的靈活性，以響應業務威脅和機會。
 |
|
按照達爾文的優勝劣汰觀點，SOA 是之前的分布式體系結構風格（如分布式組件對象模型（Component Object Model，DCOM）、Common Object Request Broker Architecture (CORBA) 和 Enterprise JavaBeans (EJB)）的自然進化，但其中又融合了各種標準（特別是基于 XML 的標準），以提供更好的互操作能力。另外還特別明確地強調業務一致性，而這在之前的體系結構中并沒有占到主流地位。SOA 通過這一點為業務流程驅動的開發提供了理想的平臺，可讓業務分析人員完全參與到軟件開發生命周期中來，而這就是它的一個重要優勢。
不過，直接采用 SOA 并不能保證項目成功（ESB 并不是企業的尚方寶劍�。�，有些項目根本就不應該采用 SOA 方法。我們都聽到過人們談論各種不好的體系結構和失敗項目，然后說“SOA 應該能夠解決這個問題”。但是，就像我們很可能會創建笨拙龐大的基于 Java™ 2 Platform Enterprise Edition (J2EE) 的體系結構一樣，我們也很容易用錯 SOA。如果 EJB 的早期實現失敗了，其原因應是有些架構師并沒有真正地了解技術的限制（親歷過由于某種數據庫搜索而導致應用程序將數百個在容器管理的持久性 [CMP] 實體 Bean 加載到內存中的情況的人應該清楚我所指的是什么）。但就 SOA 而言，這并不簡單。對服務采用類似的全權委托理論已導致了對每個應用程序功能調用都內部使用 Web 服務的應用程序的出現——不再是完全的性能解決方案！
謝天謝地，我們似乎從過去這些沉痛的教訓中吸取了經驗。例如，創建通過 J2EE 經驗總結的模式和關聯的反模式過程中獲得的知識已經被用于構造有關 SOA 的類似最佳實踐。IBM® 已經成功地開發了 SOA 應用程序方面可重用的模式和藍圖，并制定了行業特定的模型，可幫助進行體系結構決策和提供服務標識方法。
通過使用此類構件，可以對引入 SOA 的成本造成極大的影響。對于任何新技術，都會存在相關的啟動成本，而 SOA 會讓人覺得初期投資特別大。對重用和靈活性的強調是有代價的，而這很難在項目級別為 SOA 推行提供支持，因為并不一定會給項目帶來好處�；谀Ｊ降募铀倨骱同F成資產能夠幫助縮短交貨時間，但最終需要對初始 SOA 項目進行一定的投資。不過，有證據表明，隨著整個企業的后續 SOA 項目擴展和重用服務目錄中的服務，將會降低開發成本，從而讓開始 SOA 之旅的組織在中期收回這些成本。
 |
|
嘗試回答問題“什么是 SOA 時？”，務必考慮您的目標受眾的觀點，他們的看法通�？蓺w為兩類：IT 或業務。根據其出發點不同，他們可能會出于不同的原因而支持采用面向服務的概念，而且所認識的潛在的好處和缺點也不盡相同。
每種觀點都會從不同的角度描述方法和對采用此技術進行評價。并沒有關于如何開始引入 SOA 的非常明確的方法；SOA 并不是規定性的東西，所注重的是靈活性，不僅體現在最終結果上，也體現在實現結果的過程中。
下面讓我們進一步對這兩個方面進行討論。
從 IT 角度而言，SOA 定義一個軟件體系結構，此體系結構由松散耦合的分布式組件組成，而這些組件通過通信通道進行合作，從而形成了組合應用程序。SOA 的目標是實現組件重用，而不受實現語言或主機平臺的影響，可以將此視為好的軟件工程實踐的外推法，讓我們從類重用上升到服務重用的級別——真正的組件體系結構。
如果服務是基于組件的體系結構的開發的自然發展步驟，用于對其進行鏈接的企業服務總線（Enterprise Service Bus，ESB）則可以視為輪輻式集成樣式的發展。ESB 消除了輪軸作為單一錯誤點的角色，帶來了可伸縮性、智能路由、安全性和中介，而這些均基于 SOAP 和 WS* 開放標準。
那么這項新技術給 IT 專業人士帶來了什么呢？
- 組件體系結構：這提供了用于構建可伸縮和可重用的軟件組件的獨立于平臺和語言的靈活方法。
- 松散耦合：ESB 的使用提供了理想的機制來對服務使用者和提供者進行松散綁定，完全消除了點對點接口。
- 實用工具服務：通過這些可構建可重用 IT 服務庫，提供電子郵件服務、信用卡服務等等，其通過 SOA 成為企業資產的一部分。
- 遺留支持：雖然通常使用 SOAP/HTTP，但服務并不一定為 Web 服務。本機應用程序和遺留系統都完全可以加入到 SOA 中來，例如，可以使用 Java Message Service (JMS) 掛鉤到 IBM iSeries® 平臺上的 MQ 集群中，從而給遺留 RPG 應用程序帶來新生。
- 平臺獨立性：標準的采用已成為了 SOA 中的關鍵，從而讓之前不兼容的技術跨一系列平臺進行協作。
這些特性可帶來直接的技術優勢，通�？蔀橐� SOA 思維方式鋪平道路，特別是在中小型企業 (SMB) 領域中，IT 通常推動 SOA 的引入�？梢栽趩蝹�項目級別實現此方法（雖然有些 SOA 方面可能不會帶來短期好處），單個 SOA 項目的成功可能會導致此技術在整個企業內大幅度推廣開來。
事實上，通過這種方式采用 SOA 不僅為給 IT 帶來好處，而且會間接地為業務提供幫助。隨著部署的 SOA 項目越來越多，此方法的好處將變得越來越明顯：
- 組件重用度的提高應該會減少開發工作量，并在 IT 項目交付方面表現出較大改善。
- 由于使用了接口分離特定的運營系統，因此應該在業務規劃方面具有更大的靈活性。
- 點對點連接的消除應該可以簡化引入新業務系統的工作。
這些因素減少了風險和成本，可提高業務敏捷性；不過，這些最終都是 IT 帶頭開展的活動，業務沒有控制權。
|
|
2006 年度 IBM 全球 CEO 調查（請參見參考資料部分提供的鏈接）（全球有超過 750 位 CEO 參與了此項調查），發現 87% 的 CEO 認為接下來兩年所需的最基本更改就是要推動創新。Gartner 的著名分析師 Roy Schulte 捕捉到了這些想法，認為“以前構建應用程序是為了長久使用，現在構建應用程序需要考慮進行變更”。
那么 SOA 為業務提供了什么來對此加以管理呢？回頭看看本文前面的 SOA 定義，可能很難發現如何引起業務部門對其的興趣；松散耦合、關注分離 和體系結構風格 都是以 IT 為中心的術語。不過，從業務角度而言，定義中的關鍵詞是靈活性。
與之前相比，業務必須比以往任何時候都需要能夠快速地適應不斷變化的業務條件。IT 體系結構開始向集成模式發展，要構建跨多個操作系統的業務流程，并將現成產品與遺留系統連接起來。SOA 提供了支持該模型的靈活性，特別是提供了理想的平臺來采用一項關鍵性技術：業務流程建模（Business Process Modeling，BPM）。
通過 IBM WebSphere® Business Modeler 之類的工具，業務分析人員能以圖形方式定義和建模業務流程。但這不僅是文檔工作；WebSphere Business Modeler 可以使用業務流程執行語言（Business Process Execution Language，BPEL）表示生成的構建；BPEL 是一種 XML 語言，可以導入到 IBM WebSphere Integration Developer 之類的各種工具中。此時可以通過將業務服務（或者更準確地說，其接口）連接到業務流程中的任務，以組成解決方案。流程并不會考慮基礎服務的實現或接口的技術細節，只要滿足其需求即可。
用于構建軟件解決方案的此方法可為業務帶來明顯的好處，這可以通過以下方面得到證實：
- 業務驅動的開發：業務分析人員為軟件開發工作打下基礎，但不用考慮技術細節。
- 企業級解決方案：解決方案明確設計為跨多個業務部門，而不是由特定 IT 系統的可用性決定。
- 可重用業務組件：您將最終構建可重用現有業務服務的投資組合（試著詢問典型的保險公司的 IT 部門，他們有多少個創建保單 功能的不同實現）。
- 績效指標：盡管本文中沒有提到，但通過使用 BPEL 可在流程中嵌入關鍵績效指標（Key Performance Indicator，KPI）�？梢詫⑵溆糜谙驑I務部門提供有關系統狀態的智能反饋。
- 業務敏捷性：IT 的重點在提供業務價值和敏捷性�？梢酝ㄟ^重新編寫業務組件（而非完全更改整個應用程序代碼）來最小化和專注于業務需求變化的影響。
最終的結果是，業務分析人員有效地定義與其業務單位的需求一致的軟件流程，并以靈活的環境為基礎，從而能夠專注于更改的影響。業務擁有控制權。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
