了解不同的面向服務的體系結構 (SOA) 反模式，這些反模式對通常出現的會產生確定性負面結果的情形或解決方案進行了描述。隨著越來越多的企業開始大舉從 Web 服務轉向 SOA，引入、采用和成功實現 SOA 方面的各種障礙變得越來越明顯。其中一些障礙與導致過去的關鍵活動失敗的因素類似；而其他障礙則是 SOA 特有的。對這些障礙和最差實踐進行記錄，將幫助顧問、架構師和專業人員不再犯同樣的錯誤，并學習如何避免這些問題的發生。此處匯集和說明的反模式是由作者通過作為 IBM 架構師的個人經驗、研究過去和當前的 SOA 應用案例以及通過分析那些參與客戶 SOA 應用的技術先驅提供的信息而得到的。
模式與反模式
“示例不是另一種學習的方法，而是學習的唯一方法。”——阿爾貝特·愛因斯坦
模式和模式語言捕獲并正式地將良好設計和基于經驗的最佳實踐系統化，以供其他人員對其進行重用。它們成功而清楚地表述了常見問題及其解決方案。總的來說，常見概念、描述這些概念的詞匯以及將其聯系在一起的語言是所有采用這些設計和實踐的學科和領域的基礎。
Christopher Alexander 關于建筑物和城市設計的研究通常被認為是基于模式的思維最早的成果（請參閱參考資料）。他提出了術語“模式語言”，以此代表他認為人類進行設計的能力和使用語言的能力都是天生的這一信念。
很多學科都在使用模式和模式語言的概念，包括從生理學和流程到項目管理和軟件工程等領域。在 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides（經常將他們稱為 Gang of Four）的“Design Patterns: Elements of Reusable Object-Oriented Software”一書出版后，軟件設計模式得到了廣泛的認可和使用。
軟件社區目前正使用模式來解決在軟件生命周期中遇到的不斷重復的問題，包括軟件體系結構和設計，以及近來的軟件開發流程和拓撲。這些模式全面捕獲了一個知識體系，以標識我們對可以實現設計良好的軟件解決方案的結構和機制的理解。
模式經常被定義為“泛型化的、命名的問題到解決方案的映射”。它捕獲在特定環境中重復出現的問題的成功解決方案。
通常使用與表 1“模式模板”中描述的模板類似的模板來記錄軟件模式。
表 1. 模式模板
| 內容 |
說明 |
| 名稱： |
用于進行標識的名稱 |
| 問題： |
在領域中重復出現的問題 |
| 解決方案： |
該問題的最佳實踐解決方案 |
| 結果： |
所建議的解決方案的優點和缺點 |
| 示例 |
一些已經應用了所建議的解決方案的示例 |
軟件模式提供了一個在架構師和設計人員中捕獲知識和經驗的機制。它們提供了一種公共語言，可促進對其他地方成功應用的方法的重用，從而為軟件項目帶來以下方面的好處：風險更低、質量更好且交付時間更短。
而在另一方面，反模式則記錄出現錯誤的情況。對數百個軟件開發項目的各種調查勿庸置疑地證明了軟件開發會出現錯誤（實際上經常是這樣）。研究表明每六個項目中就有五個會不成功：交付遠遠超過預期預算、嚴重滯后或被取消。這就表明可能（至少）值得投入精力研究一下老是失敗而很少成功的原因（注意 Bitter Java 的作者 Bruce Tate 在他的 developerWorks 文章中說明了為什么反模式是設計模式的必要和互補的同伴——有關更多信息，請參閱參考資料）。
應該對這些重復失敗的軟件開發項目或“反解決方案”加以研究，以收集關于出現了什么問題以及為什么會這樣的有用知識。很顯然，只對錯誤的原因進行分類并不一定非常有用，而還應研究如何加以避免以及出現時如何恢復。系統化后，這個知識集合可以提供軟件模型的有價值的擴展（歸類為反模式）。
反模式 使用非常頻繁，但主要是問題的無效解決方案。這個術語最初是用于指示設計模式出現了錯誤。與模式類似，反模式的使用也擴展到了軟件開發的各個階段，并深入到了其他領域中。反模式記錄常見的對效率有負面影響的重復解決方案。它們通常捕獲重構解決方案描述，說明如何更改反模式，以得到更為穩定的解決方案。反模式通常使用模板進行描述，在其中標識癥狀、結果、根本原因和可能的解決方案。盡管與模式相比，反模式的研究并不很廣泛，相關文檔也不多，但軟件領域對其中一些具有引人矚目的反模式（如分析停頓、Blob、意大利面條式代碼和“煙囪”系統）已耳熟能詳。表 2 提供了一些這些示例的概述，這些示例均摘自 Brown 等的關于反模式的書中（有關更多信息，請參閱參考資料部分）。
表 2. 已知反模式的示例
| 錯誤類別 |
反模式 |
描述 |
| 設計 |
Blob |
一個大型類具有太多的屬性，且是系統的“核心”所在 |
| 設計 |
Poltergeists |
非必要類且抽象過多 |
| 結構 |
意大利面條式代碼 |
程序代碼沒有結構（很多 goto 語句） |
| 結構 |
“煙囪”系統 |
應用程序是唯一的也是孤立的 |
| 技術 |
Wolf ticket |
聲明具有開放性的技術并與標準測試不相符 |
| 技術 |
不斷退化模式 |
試圖使用最新的版本 |
| 重用 |
剪切與粘貼 |
軟件錯誤被復制 |
| 重用 |
Golden hammer |
強制所有內容適應一個選定的工具 |
反模式為什么重要？反模式是用于防止問題的工具，可在問題出現之前對其進行標識，并能提供關于如何防止其發生的知識。通過將錯誤原因正式地系統化，我們可以更容易對其加以理解。一旦出現問題，反模式可以提供幫助，能說明如何從其進行恢復。
簡要總結一下，反模式包括以下元素：
- 關于不能工作的方案的記錄
- 常見術語表
- 詳細的修復方法
- 環境的描述和備選解決方案
- 可能成為將來的反模式的熱門解決方案
圖 1
說明了模式和反模式之間的區別。模式從試圖解決的問題開始，記錄針對此問題的可重復成功解決方案。此解決方案可帶來一些好處、相應的結果以及可能會有一些問題。反模式說明對效率具有負面影響的常用的問題解決方案。它描述導致出現問題的原因，并說明如何防止或對解決方案進行修正。
圖 1. 模式與反模式（摘自 Brown 等的“AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis”）
SOA：簡要介紹
在過去五年中，有大量的文章談面向服務、SOA，而最近幾乎所有的東西都可以面向服務了。但我們所說的服務和面向服務到底指什么？
有很多不同的定義，而這些定義在不斷地發生變化，以反映行業和 SOA 實踐的成熟。我們將在此給出一些本文中將要使用的基本定義。這些定義在圖 2 中得到了反映。
圖 2. SOA 的定義
- 首先，什么是服務？服務是業務任務的可重復邏輯表現形式。此處有必要強調的是，我們所談的是業務流程的一部分，而不是軟件或 IT 的一部分。
通過技術實現后，“服務”這一術語則應用到使用外化規范的軟件資源（可發現的）。此服務規范可以供服務使用者進行搜索、綁定和調用。服務提供者對服務規范實現進行實現，并向服務使用者交付服務質量要求。服務將由聲明性策略進行控制，因此支持可動態重新配置的體系結構樣式。
- 第二，什么是面向服務？以我們的服務定義為基礎，面向服務是一種將業務作為一組相關聯的服務集成的方式。我們談的仍然不是技術；我們談論的是一種看待業務及其操作方式的新方法。
- 什么是 SOA？SOA 是一種支持面向服務的體系結構樣式。SOA 是一種用于根據需要對資源進行關聯的企業級 IT 體系結構。這些資源被表示為與業務一致的服務，這些服務可以參與和包含到價值網、企業或業務線中，以滿足業務需求。
- 最后，什么是組合應用程序？它是一組集成的服務。組合應用程序是為了支持業務的各項功能而裝配和組合到一起的實際運行的服務。SOA 應用程序的主要結構化元素是服務，而不是子系統、系統或組件。
標識 SOA 反模式的方法
SOA 反模式是通過使用以下方法標識的：
- 已發布反模式的調查文獻
- 作者在與客戶會談中發現而記錄下的反模式
- 通過調查 SOA CoE 和 CoP 成員的經驗而得到的反模式
- 已使用的被認可的反模式模板/語言
- 本文中包含的得到了三位作者一致認可的反模式
反模式模板/語言
反模式是使用以下模板/語言進行描述的：
SOA 反模式
已標識的反模式分為三類：
- SOA 采用反模式：此類為阻礙或延遲客戶和業務的 SOA 采用進程的反模式。討論的屬于此類的反模式有：
- A1. 技術跟風
- A2. 老調重談
- A3. 大爆炸
- 服務標識和設計反模式：此類反模式是技術先驅在作為 SOA 活動的一部分對服務進行標識和設計時遇到的反模式。討論的屬于此類的反模式有：
- I1. Web 服務 = SOA
- I2. 豎井( Silo) 方法
- I3. 注冊中心行為不正常
- 服務實現反模式：此類反模式捕獲實現服務的最差實踐。很多此類反模式主要關注 Web 服務實現（最常見的 SOA 實現）。在本文中，我們給出的是不關注 Web 服務的 SOA 實現反模式的部分列表，因為對于以 Web 服務為中心的 SOA 實現反模式在 Web 服務專門論壇上已經進行了大量的討論。討論的屬于此類的反模式有：
- R1.通信較多的服務
- R2.點到點服務
- R3.無組件的服務
隨著 SOA 越來越成熟，其應用越來越多，則有希望標識越來越多的反模式。
表 3. 反模式列表
| 類別 ID |
反模式 |
描述 |
| 采用-A1 |
技術跟風 |
一種非常值得注意的常見趨勢，在此情況下，企業決定采用流行的新技術，而沒有仔細考慮此技術是否對業務有所幫助。 |
| 采用-A2 |
老調重談 |
缺乏對 SOA 和以前的計算范例之間區別的了解，從而使其提出置疑，認為 SOA 不過是同樣的舊技術的一個名稱而已。結果是，即使采用 SOA 能為業務帶來好處，也反對采用它。 |
| 采用-A3 |
大爆炸 |
此反模式也稱為“囫圇吞棗”。當將 SOA 視為萬能的，而立即對所有企業系統和體系結構進行全面更改時，采用的就是此反模式。這樣急于求成地采用 SOA 會導致一些會不公平地歸咎于 SOA 的錯誤。 |
| 標識和設計-I1 |
Web 服務 = SOA |
當架構師將 SOA 與 Web 服務劃上等號時，他們實際上在冒險，可能會使用不具有合適體系結構的 Web 服務替換現有 API。這樣將導致標識很多與業務不一致的服務。 |
| 標識和設計-I2 |
豎井方法 |
在此反模式中，服務是根據獨立的應用程序標識的，因此不同的小組可能會使用不同的名稱標識同樣的服務。因此，不能實現公共服務或服務共享。 |
| 標識和設計-I3 |
注冊中心行為不正常 |
重復的服務注冊表項，所屬關系重復、不清楚，從而由于重復而導致管理災難和運行時混淆、潛在的性能低下和計劃外成本。 |
| 實現-R1 |
通信較多的服務 |
此反模式描述了一個常見錯誤，開發人員在通過實現很多 Web 服務（這些服務彼此需要就一小部分數據進行通信）而實現服務時，通常可能犯這個錯誤。這將導致實現大量服務，從而導致性能下降，開發成本增加。 |
| 實現-R2 |
點到點的服務 |
在應用程序間使用 XML 或 SOAP over HTTP 代替點到點 Web 服務的中間件，將導致點到點集成的出現，而成為事實上的集成模式。 |
| 實現-R3 |
無組件的服務 |
不清楚與所屬組件關聯的情況下就直接進行 Web 服務的開發和實現，將會導致未結構化、不受約束的體系結構（沒有嚴格的分層機制）。這將導致服務接口后端和保留現有應用程序和軟件包的遺留限制方面的靈活性低下。 |
SOA 采用反模式
這些是阻礙或延遲客戶和業務的 SOA 采用進程的反模式。
A1：反模式名稱：技術帶寬（另請參閱：Web 服務 = SOA）
- 問題
我們發現，很多公司從 IT 的角度開始著手 SOA 工作，而不是從業務角度看待問題。實現可能從技術角度而言是可行的，有時候也能成功，但由于首先沒有考慮業務，因此其對業務的影響可能無法實現。
- 環境
此反模式主要出現在建立了良好的 IT 部門的大型企業中，此部門主要雇傭的是技術人員，決策方面受到技術層面的影響更多。
- 癥狀
此反模式的常見癥狀表現為發起人不能清楚地闡釋采用 SOA 的價值主張。此外，另一個癥狀可能表現為缺乏針對 SOA 實現的業務/項目一致性。
- 結果
由于此反模式，IT 成本將會上升，卻沒有實現任何投資回報 (ROI)。此外，公司可能會失去為 IT 投資組合注入靈活性的機會。
- 根本原因
在大多數情況下，此反模式的根本原因在于，為了趕上通過采用此技術可能實現領先地位的競爭者所宣稱的能力，公司因此而承受壓力。由于這個原因，公司可能發現開展基于技術的工作來引入 SOA 更為容易，而不會花時間和精力將其與業務需求結合。
- 解決方案
處理此反模式的最佳方法是建立沒有浮夸的 SOA 價值主張，可以通過標識和描述特定于客戶的難點或業務挑戰來實現這一點。此方法可以通過開發用于在業務的支持下恰當地引入技術的路線圖來進行互補。
- 解決方案示例：根據沒有浮夸的 SOA 價值主張開發 SOA 平臺
一家全球汽車租賃公司了解可支持其關鍵業務動力的 SOA 解決方案的價值主張：
- 可提供一個靈活的業務模型，以提高交付新業務服務的速度和靈活性
- 通過簡化流程來降低操作成本，從而使成本下降
- 通過為其客戶提供率先推向市場的創新服務來縮短外部業務流程的周期和成本
- 通過允許方便靈活的集成來支持多個交付渠道，從而在整個企業范圍內進行集成
A2：反模式名稱：老調重談
- 問題
此反模式描述的情況是這樣的：公司置疑 SOA 不過是相同的舊技術的一個名稱而已，SOA 并不能提供任何它們尚未提供的新功能。從表面上來看，似乎可能是這樣，但過去已經提供的功能和通過恰當實現 SOA 可以提供的功能相比，Web 服務和 XML（以及其他相關的標準）的出現則是一個重大的區別。
- 環境
這個反模式主要出現在那些習慣其已經長期使用的技術，而不愿意引入或考慮進行改變的 IT 專業人員身上。當 IT 部門經歷了大費周折的技術轉換后，或新技術并不能實現最初的承諾時，也可能出現此反模式。
- 癥狀
最明顯的癥狀就是公司中的一些技術管理人員強烈反對將 SOA 作為處理合法業務問題的正式方法。反對可表現為強烈而明顯的爭辯，反對采用 SOA；或者可以表現為隱含的被動的方式，在討論業務問題的解決方案時完全忽略 SOA。
- 結果
此反模式很可能會導致缺乏 SOA 支持，而最終會導致失去實現將支持業務難點的 SOA 價值主張的機會。
- 根本原因
盡管 SOA 構建于其他計算范例（例如，面向對象和基于組件的開發）所引入和支持的相同原則之上，很多有經驗的 IT 團隊仍然不能真正理解 SOA 與這些其他計算范例之間的區別。缺乏理解是此反模式的一個基本根源。另一個根本原因則是 IT 團隊在實現太多的“范例轉換”方面的經驗不豐富（而不愿嘗試新的技術）的直接結果。
- 解決方案
處理此反模式的一個方法就是強調 SOA 與早期解決方案的不同之處。例如，應對 API 和服務之間的區別加以討論，應對開發標準依賴性及其區別屬性進行說明。另一個主要不同點在于作為 SOA 主要組件的企業服務總線 (ESB) 的出現。ESV 提供的工具（如傳輸服務、中介服務和事件服務）就是一些通過采用 SOA 所提供的新服務的例子。不過，最有效的解決方案則是提供一些成功的示例，以突出區別和演示實現 SOA 解決方案的成功案例和可行性。
- 解決方案示例：SOA 培訓
對業務部門和 IT 部門進行培訓，闡釋 SOA 的概念、其價值主張，并說明其在提供支持業務所需的 IT 靈活性方面的好處。促進對 Web 服務和 XML 標準及實現 SOA 中的新興標準的重要性的理解，這些內容正是 SOA 與過去的范例轉換的不同之處。
A3：反模式名稱：大爆炸（也稱為：囫圇吞棗）
- 問題
此反模式可以看作“老調重談”反模式的對立面。此處的問題在于，支持者將 SOA 視為萬能的，而立即對所有企業系統和體系結構進行全面更改。
- 環境
此反模式和“技術跟風”反模式的環境一樣。特別在其主要股東具有很強的技術背景，且比對應的業務方面的人員更有影響力的企業中，他們就很可能會采用“囫圇吞棗”的方式，而完全不考慮對業務的影響。
- 癥狀
如果業務單位對采用 SOA 所帶來的更改十分擔心，則清楚地表明此采用了此反模式。
- 結果
應用此反模式后，將會出現嚴重的錯誤，無法提供 SOA 所承諾的好處（可以從現有體系結構獲得回報），從而延遲（甚至消除） SOA 所具有的任何潛在優勢。采用此反模式的另一個結果就是可能會將任何交付錯誤歸咎于 SOA，而不是查找問題的根本原因。
- 根本原因
任何企業中的狂熱技術支持者都可能是此類反模式的根源所在，特別在這些技術支持者處在可以優先于業務考慮做出 IT 決策。
- 解決方案
為了消除此反模式，一種解決方案是指定一個業務支持路線圖，以采用增量的方式逐步采用 SOA。不要采用試圖通過使用 SOA 進行全面更改的方式解決所有企業問題，更好的做法是首先構建一個試驗性業務案例，當試用成功后，則使用路線圖選擇下一個可能從 SOA 獲益的目標業務領域。如果可為組織中那些負責 SOA 推廣的人員提供 SOA 入門培訓，也將十分有用。
- 解決方案示例：開發實現 SOA 的路線圖。
一家大型銀行在考慮到其業務策略后，確定其正確的體系結構方向是 SOA 解決方案，此解決方案可以幫助其實現其業務目標。該銀行首先對其服務集成方面的成熟度水平進行了評估。然后，開發了路線圖來幫助銀行以增量的方式遷移到 SOA 環境，以在繼續提供必要的業務功能的同時最小化風險。該銀行選擇了一個試驗性項目來驗證 SOA 體系結構樣式，并找出在遷移到 SOA 范例過程中可能出現的任何技術和組織問題。
SOA 標識和設計反模式：
此類反模式是技術先驅在作為 SOA 活動的一部分對服務進行標識和設計時遇到的反模式。
I1：反模式名稱：Web 服務 = SOA（也稱為服務增殖綜合癥）
- 問題
對于很多人而言，SOA 不過是 Web 服務的另一個名稱而已。盡管實現 Web 服務是采用 SOA 過程中的一個合理的入口點，但企業不應將 Web 服務和 SOA 劃上等號。
- 環境
目前的大部分生產 Web 服務系統都不是 SOA。它們只是通過 SOAP 或結構良好的集成體系結構的遠程過程調用或點到點消息傳遞而已。各種組織發現，通過僅實現 Web 服務而宣稱遷移到 SOA 的方式更為簡單。
- 癥狀
在不采用恰當的體系結構的情況下使用 Web 服務替代 API，并實現不與業務一致的服務是此反模式的明顯癥狀。
- 結果
Web 服務的增殖是應用此反模式的直接結果。這個結果是將任何接口都作為 Web 服務實現，而不管這些服務是否是 SOA 價值主張的一部分而造成的。另外，最終的系統也可能沒有反映服務請求方要求的接口。
- 根本原因
此反模式的根本原因有兩種。首先是操之過急，意在走捷徑，以快速廉價的方式開展 SOA 方面的工作。其次是缺乏對 SOA 和 Web 服務的區別的認識，不理解對好的服務建模技術的需求。
- 解決方案
處理此反模式的一個方法是制定可行的 SOA 轉換計劃，此計劃要求組織對其 SOA 價值主張進行定義。實現 SOA 價值主張要求同時使用 SOA 和 Web 服務。這將要求對 SOA 和 Web 服務的區別進行培訓，并應用好的服務建模方法，如面向服務的建模和體系結構（Service-Oriented Modeling and Architecture，SOMA）。
- 解決方案示例：應用服務建模以標識粗粒度的服務和將 Web 服務作為 SOA 解決方案的實現技術加以利用
引入和采用良好的服務建模技術來確定供業務解決方案使用的恰當粗粒度服務，并利用 Web 服務來實現 SOA 解決方案。恰當服務粒度水平將幫助盡可能減少過分細粒度服務的增加。實現 SOA 價值主張要求同時使用 SOA 和 Web 服務。
I2：名稱：豎井方法
- 問題
此反模式帶來的問題是標識服務的方式。當根據獨立的應用程序（而不是以企業策略為中心）對服務進行標識時，期望 SOA 實現所帶來的好處將永遠不能實現。
- 環境
此反模式主要出現在根據獨立工作的具有塔狀結構的功能模型進行組織的企業中。每個功能塔所享有的自治權將導致采用豎井方式進行工作。
- 癥狀
此反模式的一個癥狀是不同的小組使用不同的名稱對相同的服務進行標識。沒有標識公共服務，或未實現服務共享，同樣也清楚地表明應用了此反模式。
- 結果
由于采用豎井(silo)方法會導致服務被多次標識和實現，不必要的昂貴開發成本或服務重復使得采用 SOA 所能帶來的好處大打折扣。而且，由于使用此反模式，會使不同應用程序的受益人間的重用減少或完全消失。
- 根本原因
在大多數情況下，組織的邊界和約束是此反模式的根本原因。在某些企業中，缺乏對“服務公開決策”的有所控制的方法也是根本原因。
- 解決方案
此反模式的解決方案是建立一個控制框架，以確保跨功能塔進行服務標識和通信。另外，還應當進行以標識公共服務為目的的相關工作。這可以通過使用 SOMA 等好的服務建模方法來完成。
- 解決方案示例：標識公共服務
像大多數企業一樣，一家大型銀行是按照業務塔進行的組織，這些業務塔為不同類型的銀行客戶提供類似的業務功能。SOMA 用于開發服務模型，以促進業務塔間的重用和了解此類重用機會。從更高的角度來看，在支持業務功能所需的業務服務中，約有 90% 都具有相似性，這是潛在的重用領域。
I3：反模式名稱：注冊中心行為不正常
- 問題
在沒有一致的 SOA 控制模型的情況下采用 UDDI 將導致流程和設計的效率低下。特別是重復的注冊中心可能導致效率低下，使得性能下降，并可能產生安全和遵從性漏洞。
- 環境
沒有注冊中心控制協議，但卻嘗試建立 UDDI 用途的企業將經常遇到此反模式。
- 癥狀
考慮到 UDDI 是標準而不是產品，如果使用不恰當，可能導致建立重復的服務注冊中心和重疊的、不明確的關系。這將表現為不正確的、容易引起誤會的服務接口信息，特別在共享服務模型內的組合服務場景的發現操作期間表現得十分明顯。盡管注冊中心中單個服務接口的描述是正確的，但重復的條目將導致整個服務的發現不正確。而且，缺乏控制模型可能是由于服務在生命周期流程的各個階段注冊，當不具有一對一的所屬關系轉換時被遺棄而造成的。例如：假定某個開發人員向內部 UDDI 添加了三個服務。然后，服務管理員可能會將其中兩個遷移到生產 UDDI 中。這就產生了孤立服務。服務組件也可能出現類似的情況。
- 結果
在試圖確定注冊中心中哪個服務導致無法滿足 SLA 時，重復的注冊中心將導致控制災難和運行時混淆。此外，此類重復還會導致性能下降和安全漏洞及遵從性漏洞。此類反模式的另一個結果就是由于重復而會產生計劃外成本。
- 根本原因
缺乏設計時一致性（SOA 控制模型）是導致此反模式的主要原因。具體來說，此問題的核心是服務注冊中心所屬關系不清楚且沒有建立和執行企業級 SOA 參考體系結構。
- 解決方案
為了避免此反模式，公司必須建立 SOA 控制模型，以定義和采用服務注冊中心最佳實踐、所屬關系以及相關團隊間的通信。這將消除重復條目和不正確的接口信息，并最小化包含孤立服務的結果。由于只有一個服務描述源（其中包含關聯的 SLA 和策略），因此還可以消除運行時混淆。使用 SOA 企業級參考體系結構間建立和執行遵從性應是 SOA 控制模型制度化的第一步。
SOA 實現反模式
此類反模式捕獲實現服務的最差實踐。
R1：反模式名稱：通信較多的服務
- 問題
此反模式描述開發人員通過實現一系列 Web 服務（這些服務彼此需要就一小部分數據進行通信）來實現服務的情況。同一個反模式的另一表現是服務實現最后會進行大量的微型信息通信，而不是采用將數據組合到全面的類似于文檔的格式中。
- 環境
如果組織中的開發人員急于在沒有恰當的建模的情況下開始進行實現，這些組織將最終受到此反模式的困擾。在某些情況下，開發人員被要求在沒有了解如何從 SOA 獲得最大利益的情況下使用 Web 服務替代 API，將通常會導致此反模式。
- 癥狀
如果有實現大量過分細粒度服務的需求，則表明應用了此反模式。
- 結果
性能下降和開發成本增加是此反模式的主要結果。此外，使用者必須進行額外的工作以對這些過分細粒度的服務進行聚合，以實現相關優勢和獲得如何將這些服務一起使用的知識。
- 根本原因
由于不知道任何更好的辦法，很多開發人員采用的方法就是采用 Web 服務的形式模擬 API 的實現。這與我們在最開始采用面向對象的編程技術時的情況（開發人員使用面向對象的語言來開發過程型的程序）十分相似。另外，急于采用這項新技術，可能會導致所有內容都成為 Web 服務，卻不能帶來任何好處，而且成本會急劇增加。
- 解決方案
為了避免此反模式，需要集中精力進行設計重構，以將各個數據片斷組合到一個文檔中，以消除通信量過多的服務。另外，就 API 和服務之間的區別進行培訓（并強調恰當的服務粒度），也會有用。不過，避免此反模式的最有效辦法是定義映射回業務目標的服務。可以通過引入和使用好的服務建模技術來為業務解決方案確定恰當的粗粒度服務，從而完成此工作。這將最小化服務通信過多的行為，因為此行為已在 SOA 中正確的粒度級別得到了標識。應用 Service Litmus Test (SLT) 也可以幫助確定要公開的正確服務級別。SLT 的一個例子是考慮服務是否提供了支持業務流程和目標所需的業務功能單元。
R2：反模式名稱：點到點服務
- 問題
基本問題是開發人員在不考慮使用環境的情況下嘗試使用點到點 Web 服務作為集成方法替代中間件。
- 環境
此模式出現在缺乏長期系統集成遠景而強調短期結果的組織中。
- 癥狀
此反模式的一個表現是在內部應用程序之間使用 SOAP over HTTP。
- 結果
由于使用此反模式，點到點集成解決方案將作為企業的事實上的集成模式出現。這將對任何實現恰當 SOA 實現的所有優勢的可能帶來負面影響。
- 根本原因
此模式的主要根源是缺乏對總體系統的長期維護和發展的考慮（可能是由于強調短期解決方案而造成的）。在某些情況下，急于在別處使用服務也可能導致此類點到點服務方法使用的增多。
- 解決方案
為了避免采用此反模式的結果，應該考慮將智能連接器（如服務總線）作為正式集成方法使用。使用服務總線，應用程序可以簡單有效地一起工作，以支持業務需求，并同時保持協作系統和應用程序間的松散耦合。
- 已知的例外情況
有一些例外的情況，在這些情況下此反模式解決方案是可以接受的。例如，為了解決即時的業務問題以及可以使用點到點服務的情況下，就需要采用快速的短期集成方案。不過，這些解決方案有可能會在生產中長時間存在。因此，應用此反模式時應當小心地進行監視，并應當配備相應的控制，以防止長期采用此反模式。
R3：反模式名稱：無組件的服務（也稱為“邏輯分層已過時”）
- 問題
用于服務建模的最佳實踐將促進已標識的服務與其所屬的組件相關聯。此反模式帶來的問題是，開發人員趨于在沒有與所屬組件明確關聯的情況下直接進行 Web 服務的開發和實現。
- 環境
此反模式出現在體系結構模式未得到應用或考慮的環境中，例如，分層體系結構模式。缺乏體系結構規則使得環境極易出現此類反模式的應用。
- 癥狀
對服務進行檢查，將會發現系統可以在不遵循任何體系結構的結構要求就可以直接達到系統的任何部分。在這些情況下，Web 服務是在不考慮任何分層和分離概念的情況下開發的。
- 結果
最值得注意的結果是服務接口之外非常不靈活，因為模塊設計、信息隱藏和邏輯結構原則均未得到遵循。這將導致仍然保留了現有應用程序和軟件包的遺留限制，從而可能導致在將來不能進行重新設計。
- 根本原因
與違反了最佳操作的任何其他情況一樣，此反模式的根本原因在于缺乏良好的設計。
- 解決方案
組件和 SOA 的真正潛能僅在同時具有兩者的情況下才能實現。解決的辦法是采用由基于組件的靈活應用程序支持的一致服務接口。這將要求開發人員繼續利用 J2EE 和常見 EAD 最佳實踐及分層模式，將其作為克服此反模式的缺陷的方法。
- 解決方案示例：理解組件對于 SOA 的價值
服務最好使用組件實現。如果沒有組件，服務接口后端就沒有靈活性可言，并可能要擔心實現的可伸縮性和可移植性。現有應用程序和軟件包將保留其遺留限制，這將最大程度降低地提供支持不斷變化的業務需求所需的靈活性的能力。組件可使用其松散耦合和重用功能提供支持服務接口所需的可伸縮性和靈活性。
總結
在本文中，我們了解了一些通過觀察所得的 SOA 反模式，并介紹了一些影響 SOA 的采用、標識和設計及實現的 SOA 項目。