＊＊＊ 本系列文章與程式碼範例 均為 賴信仁 (Ringle Lai) 所撰寫 ＊＊＊

在之前的課程中，我們曾經說明過SOA的設計來源其實是從架構面的 使用案例 (Use Case) 模型分析而來。本次課程我們將進一步地說明，如何利用標準化的設計準則來設計一個公司的SOA架構。

以下是屬於 SOA (Service Oriented Architeture) 的定義：

A service-oriented architecture is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components—services—that can be reused and combined to address changing business priorities.
Ref: Service-Oriented Architecture (SOA) Compass, by Bieberstein et al. (2006)

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Ref: http://en.wikipedia.org/wiki/Service-oriented_architecture#cite_note-9

從上述的定義來看，所謂 SOA 的目的，其實只是在分散處理的環境，提供了一個「分散但可預期的」整體環境。

從這個定義來看，其實在數年前由產業界的力量所推出的「RosettaNet」，就是這一波 SOA 的濫觴；只是目前的SOA的觀念，從產業間的合作關係，逐漸地往企業內部的整體流程整合邁進。但從其基本觀念觀之，其實正是「Design to Interface」觀念的衍生。

那麼，SOA 究竟是怎樣的觀念呢，其基本的結構又會是如何？我們以下圖來呈現一般 SOA 所建議的架構(由於 SOA 畢竟並非一個標準化的架構，因此，各個不同的廠商或是學者，各自有其對 SOA 架構的看法，以下筆者所採取的，是筆者比較認同的SOA架構圖)：

（點擊圖片鏈接看原圖）圖 1 、SOA的參考架構
(Ref: SOA Practitioners’Guide Part 2: SOA Reference Architecture, 2006, p.19)

從這個架構圖，可以看出 SOA 架構的立體性。

在 SOA 架構中，對於企業 (Business)有意義的部分，在於整體企業服務層次的提供，這是上圖中最上方的三角形的部分，也因此，一般在實現 SOA 時，我們必須先從 Business 著手；至於下方的三個 Tier，則是從 IT 的架構層面出發，其主要的目的，在於提供 Business Service 一個穩定性的地基。 以上圖來看，其實 Service Tier 所代表的意義，在於將企業的 應用程式 (Application) 做適當的包裝，好讓其可以簡單地 Mapping 到 Business 的 Service。

也因此，所謂的 SOA 並非是一個固定的產品或是規則，相反地，先讓我們確認 SOA 的主要目的(Business Service <-> Information Service)，再從這個主要目的去找尋適合的開發方式 (Development Process)與適用的技術，如此一來，對於 SOA 的整體規劃才不至於見樹而忘林，甚至在不知不覺間，被特定的廠商牽著鼻子走，反而忘掉了 SOA 的最根本的目的！