面向服務的架構(SOA)是一個組件模型,它將應用程序的不一樣功能單元(稱爲服務)進行拆分,並經過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的,它應該獨立於實現服務的硬件平臺、操做系統和編程語言。這使得構建在各類各樣的系統中的服務能夠以一種統一和通用的方式進行交互。編程
這種具備中立的接口定義(沒有強制綁定到特定的實現上)的特徵稱爲服務之間的鬆耦合。鬆耦合系統的好處有兩點,一點是它的靈活性,另外一點是,當組成整個應用程序的每一個服務的內部結構和實現逐漸地發生改變時,它可以繼續存在。而另外一方面,緊耦合意味着應用程序的不一樣組件之間的接口與其功能和結構是緊密相連的,於是當須要對部分或整個應用程序進行某種形式的更改時,它們就顯得很是脆弱。
對鬆耦合系統的須要來源於業務應用程序須要,根據業務的須要變得更加靈活,以適應不斷變化的環境,好比常常改變的政策、業務級別、業務重點、合做夥伴關係、行業地位以及其餘與業務有關的因素,這些因素甚至會影響業務的性質。咱們稱可以靈活地適應環境變化的業務爲按需業務,在按需業務中,一旦須要,就能夠對完成或執行任務的方式進行必要的更改。安全
雖然面向服務的體系結構不是一個新鮮事物,但它倒是更傳統的面向對象的模型的替代模型,面向對象的模型是緊耦合的,已經存在二十多年了。雖然基於 SOA 的系統並不排除使用面向對象的設計來構建單個服務,可是其總體設計倒是面向服務的。因爲它考慮到了系統內的對象,因此雖然 SOA 是基於對象的,可是做爲一個總體,它卻不是面向對象的。不一樣之處在於接口自己。SOA 系統原型的一個典型例子是通用對象請求代理體系結構,它已經出現很長時間了,其定義的概念與 SOA 類似。然而,如今的 SOA 已經有所不一樣了,由於它依賴於一些更新的進展,這些進展是以可擴展標記語言(eXML)爲基礎的。架構
在SOA架構風格中,服務是最核心的抽象手段,業務被劃分(組件化)爲一系列粗粒度的業務服務和業務流程。業務服務相對獨立、自包含、可重用,由一個或者多個分佈的系統所實現,而業務流程由服務組裝而來。一個"服務"定義了一個與業務功能或業務數據相關的接口,以及約束這個接口的契約,如服務質量要求、業務規則、安全性要求、法律法規的遵循、關鍵業績指標(Key Performance Indicator,KPI)等。接口和契約採用中立、基於標準的方式進行定義,它獨立於實現服務的硬件平臺、操做系統和編程語言。這使得構建在不一樣系統中的服務能夠以一種統一的和通用的方式進行交互、相互理解。除了這種不依賴於特定技術的中立特性,經過服務註冊庫(Service Registry)加上企業服務總線(Enterprise Service Bus)來支持動態查詢、定位、路由和中介(Mediation)的能力,使得服務之間的交互是動態的,位置是透明的。技術和位置的透明性,使得服務的請求者和提供者之間高度解耦。這種鬆耦合系統的好處有兩點:一點是它適應變化的靈活性;另外一點是當某個服務的內部結構和實現逐漸發生改變時,不影響其餘服務。而緊耦合則是指應用程序的不一樣組件之間的接口與其功能和結構是緊密相連的,於是當發生變化時,某一部分的調整會隨着各類緊耦合的關係引發其餘部分甚至整個應用程序的更改,這樣的系統架構就很脆弱了。編程語言