簡介
這種具備中立的接口定義（沒有強制綁定到特定的實現上）的特徵稱爲服務之間的
鬆耦合。
鬆耦合系統的好處有兩點，一點是它的靈活性，另外一點是，當組成整個應用程序的每一個服務的內部結構和實現逐漸地發生改變時，它可以繼續存在。而另外一方面，
緊耦合意味着應用程序的不一樣組件之間的接口與其功能和結構是緊密相連的，於是當須要對部分或整個應用程序進行某種形式的更改時，它們就顯得很是脆弱。
對
鬆耦合的系統的須要來源於業務應用程序須要根據業務的須要變得更加靈活，以適應不斷變化的環境，好比常常改變的政策、業務級別、業務重點、合做夥伴關係、行業地位以及其餘與業務有關的因素，這些因素甚至會影響業務的性質。咱們稱可以靈活地適應環境變化的業務爲按需（On demand）業務，在按需業務中，一旦須要，就能夠對完成或執行任務的方式進行必要的更改。
雖然面向服務的
體系結構不是一個新鮮事物，但它倒是更傳統的
面向對象的模型的替代模型，面向對象的模型是
緊耦合的，已經存在二十多年了。雖然基於
SOA 的系統並不排除使用
面向對象的設計來構建單個服務，可是其總體設計倒是面向服務的。因爲它考慮到了系統內的對象，因此雖然 SOA 是
基於對象的，可是做爲一個總體，它卻不是
面向對象的。不一樣之處在於接口自己。SOA 系統原型的一個典型例子是通用
對象請求代理
體系結構（Common Object Request Broker Architecture，
CORBA），它已經出現很長時間了，其定義的概念與 SOA 類似。
然而，如今的 SOA 已經有所不一樣了，由於它依賴於一些更新的進展，這些進展是以
可擴展標記語言（eXtensible Markup Language，
XML）爲基礎的。經過使用基於 XML 的語言（稱爲Web 服務描述語言（Web Services Description Language，
WSDL））來描述接口，服務已經轉到更動態且更靈活的接口系統中，非之前 CORBA 中的接口描述語言（Interface Description Language，
IDL）可比了。
Web 服務並非實現 SOA 的唯一方式。前面剛講的 CORBA 是另外一種方式，這樣就有了面向消息的
中間件（Message-Oriented Middleware）系統，好比
IBM 的 MQseries。可是爲了創建
體系結構模型，您所須要的並不僅是服務描述。您須要定義整個應用程序如何在服務之間執行其
工做流。您尤爲須要找到業務的操做和業務中所使用的軟件的操做之間的轉換點。所以，SOA 應該可以將業務的商業流程與它們的技術流程聯繫起來，而且映射這二者之間的關係。例如，給供應商付款的操做是商業流程，而更新您的零件數據庫，以包括進新供應的貨物倒是技術流程。於是，
工做流還能夠在 SOA 的設計中扮演重要的角色。
此外，動態業務的
工做流不只能夠包括部門之間的操做，甚至還能夠包括與不爲您控制的外部合做夥伴進行的操做。所以，爲了提升效率，您須要定義應該如何得知服務之間的關係的策略，這種策略經常採用服務級協定和操做策略的形式。
最後，全部這些都必須處於一個信任和可靠的環境之中，以同預期的同樣根據約定的條款來執行流程。所以，安全、信任和可靠的消息傳遞應該在任何 SOA 中都起着重要的做用。
編輯本段特徵
SOA的服務級別抽象圖，以下圖所示：
一、可重用
一個服務建立後能用於多個應用和業務流程。
二、
鬆耦合
服務請求者到服務提供者的綁定與服務之間應該是
鬆耦合的。所以，服務請求者不須要知道服務提供者實現的技術細節，例如程序語言、底層平臺等等。
三、明肯定義的接口
服務交互必須是明肯定義的。Web服務描述語言（Web Services Description Language，WSDL）是用於描述服務請求者所要求的綁定到服務提供者的細節。WSDL不包括服務實現的任何技術細節。服務請求者不知道也不關心服務到底是由哪一種
程序設計語言編寫的。
四、無狀態的服務設計
服務應該是獨立的、自包含的請求，在實現時它不須要獲取從一個請求到另外一個請求的信息或狀態。服務不該該依賴於其餘服務的上下文和狀態。當產生依賴時，它們能夠定義成通用業務流程、函數和 數據模型。
五、基於開放標準
當前SOA的實現形式是Web服務，基於的是公開的W3C及其餘公認標準．採用第一代Web服務定義的SOAP、WSDL和UDDI以及第二代Web服務定義的WS-*來實現SOA。
編輯本段元素
面向服務的
體系結構中的角色包括：以下圖所示：
一、服務請求者：服務請求者是一個應用程序、一個軟件模塊或須要一個服務的另外一個服務。它發起對註冊中心中的服務的查詢，經過傳輸綁定服務，而且執行服務功能。服務請求者根據接口契約來執行服務。
二、服務提供者：服務提供者是一個可經過網絡尋址的實體，它接受和執行來自請求者的請求。它將本身的服務和接口契約發佈到服務註冊中心，以便服務請求者能夠發現和訪問該服務。
三、服務註冊中心：服務註冊中心是服務發現的支持者。它包含一個可用服務的
存儲庫，並容許感興趣的服務請求者查找服務提供者接口。
發佈：爲了使服務可訪問．須要發佈服務描述以使服務請求者能夠發現和調用它。
查詢：服務請求者定位服務．方法是查詢服務註冊中心來找到知足其標準的服務。
綁定和調用：在檢索完服務描述以後，服務請求者繼續根據服務描述中的信息來調用服務。
（1）服務：能夠經過已發佈接口使用服務，而且容許服務使用者調用服務。
（2）服務描述：服務描述指定服務使用者與服務提供者交互的方式。它指定來自服務的請求和響應的格式。服務描述能夠指定一組前提條件、後置條件和/或服務質量（Q0S）級別。
編輯本段利用價值
對 SOA 的須要來源於須要使業務 IT 系統變得更加靈活，以適應業務中的改變。經過容許強定義的關係和依然靈活的特定實現，IT 系統既能夠利用現有系統的功能，又能夠準備在之後作一些改變來知足它們之間交互的須要。
下面舉一個具體的例子。一個服裝零售組織擁有 500 家國際連鎖店，它們經常須要更改設計來遇上時尚的潮流。這可能意味着不只須要更改樣式和顏色，甚至還可能須要更換布料、製造商和可交付的產品。若是零售商和製造商之間的系統不兼容，那麼從一個供應商到另外一個供應商的更換可能就是一個很是複雜的軟件流程。經過利用 WSDL 接口在操做方面的靈活性，每一個公司均可以將它們的現有系統保持現狀，而僅僅匹配 WSDL 接口並制訂新的服務級協定，這樣就沒必要徹底重構它們的
軟件系統了。這是業務的水平改變，也就是說，它們改變的是合做夥伴，而全部的業務操做基本上都保持不變。這裏，業務接口能夠做少量改變，而內部操做卻不須要改變，之因此這樣作，僅僅是爲了可以與外部合做夥伴一塊兒工做。
另外一種形式是內部改變，在這種改變中，零售組織如今決定它還將把連鎖零售商店內的一些地方出租給專賣流行衣服的小商店，這能夠看做是採用店中店（store-in-store）的業務模型。這裏，雖然公司的大多數業務操做都保持不變，可是它們如今須要新的內部軟件來處理這樣的出租安排。儘管在內部
軟件系統能夠承受全面的檢修，可是它們須要在這樣作的同時不會對與現有的供應商系統的交互產生大的影響。在這種狀況下，SOA 模型保持原封不動，而內部實現卻發生了變化。雖然能夠將新的方面添加到 SOA 模型中來加入新的出租安排的職責，可是正常的零售管理系統繼續如往常同樣。
爲了延續內部改變的觀念，IT 經理可能會發現，軟件的新配置還能夠以另外的一種方式加以使用，好比出租粘貼海報的地方以供廣告之用。這裏，新的業務提議是經過在新的設計中重用靈活的 SOA 模型得出的。這是來自 SOA 模型的新成果，而且仍是一個新的機會，而這樣的新機會在之前多是不會有的。
垂直改變也是可能的，在這種改變中，零售商從銷售他們本身的服裝徹底轉變到專門經過店中店模型出租地方。若是垂直改變徹底從最底層開始的話，就會帶來 SOA 模型結構的顯著改變，與之一塊兒改變的還可能有新的系統、軟件、流程以及關係。在這種狀況下，SOA 模型的好處是它從業務操做和流程的角度考慮問題而不是從應用程序和程序的角度考慮問題，這使得業務管理能夠根據業務的操做清楚地肯定什麼須要添加、修改或刪除。而後能夠將
軟件系統構造爲適合業務處理的方式，而不是在許多現有的
軟件平臺上經常看到的其餘方式。
正如您能夠看到的，在這裏，改變和 SOA 系統適應改變的能力是最重要的部分。對於開發人員來講，這樣的改變不管是在他們工做的範圍以內仍是在他們工做的範圍以外都有可能發生，這取決因而否有改變須要知道接口是如何定義的以及它們相互之間如何進行交互。與開發人員不一樣的是，
架構師的做用就是引發對 SOA 模型大的改變。這種分工，就是讓開發人員集中精力於建立做爲服務定義的功能單元，而讓
架構師和建模人員集中精力於如何將這些單元適當地組織在一塊兒，它已經有十多年的歷史了，一般用
統一建模語言（Universal Modeling Language，
UML），而且描述成
模型驅動的
體系結構（Model-Driven Architecture，
MDA）。
對於面向同步和異步應用的，基於請求/響應模式的分佈式計算來講，SOA是一場革命。一個應用程序的
業務邏輯（business logic）或某些單獨的功能被模塊化並做爲服務呈現給消費者或
客戶端。這些服務的關鍵是他們的
鬆耦合特性。例如，服務的接口和實現相獨立。應用開發人員或者系統集成者能夠經過組合一個或多個服務來構建應用，而無須理解服務的底層實現。舉例來講，一個服務能夠用
.NET或J2EE來實現，而使用該服務的應用程序能夠在不一樣的平臺之上，使用的語言也能夠不一樣。
SOA特性
SOA服務具備平臺獨立的自我描述XML文檔。Web服務描述語言（WSDL， Web Services Description Language）是用於描述服務的標準語言。
SOA 服務用消息進行通訊，該消息一般使用XML Schema來定義（也叫作
XSD， XML Schema Definition）。消費者和提供者或消費者和服務之間的通訊多見於不知道提供者的環境中。服務間的通信也能夠看做企業內部處理的關鍵商業文檔。
在一個企業內部，SOA服務經過一個扮演目錄列表（directory listing）角色的登記處（Registry）來進行維護。應用程序在登記處（Registry）尋找並調用某項服務。統一描述，定義和集成（UDDI， Universal Description， Definition， and Integration）是服務登記的標準。
每項SOA服務都有一個與之相關的服務品質（
QoS， quality of service）。QoS的一些關鍵元素有安全需求（例如認證和受權），可靠通訊（譯註：可靠消息是指，確保消息「僅且僅僅」發送一次，從而過濾重複信息。），以及誰能調用服務的策略。
爲何選擇SOA？
不一樣種類的操做系統，應用軟件，系統軟件和應用基礎結構（application infrastructure）相互交織，這即是IT企業的現狀。一些現存的應用程序被用來處理當前的業務流程（business processes），所以從頭創建一個新的基礎環境是不可能的。企業應該能對業務的變化作出快速的反應，利用對現有的應用程序和應用基礎結構（application infrastructure）的投資來解決新的業務需求，爲客戶，商業夥伴以及供應商提供新的互動渠道，並呈現一個能夠支持有機業務（organic business）的構架。SOA憑藉其
鬆耦合的特性，使得企業能夠按照模塊化的方式來添加新服務或更新現有服務，以解決新的業務須要，提供選擇從而能夠經過不一樣的渠道提供服務，並能夠把企業現有的或已有的應用做爲服務， 從而保護了現有的IT基礎建設投資。
如圖1的例子所示，一個使用SOA的企業，可使用一組現有的應用來建立一個供應鏈複合應用（supply chain composite application），這些現有的應用經過標準接口來提供功能。
服務架構
爲了實現SOA，企業須要一個服務架構，圖2顯示了一個例子：
在圖2中， 服務消費者（service consumer）能夠經過發送消息來調用服務。這些消息由一個服務總線（service bus）轉換後發送給適當的服務實現。這種服務架構能夠提供一個業務
規則引擎（business rules engine），該引擎允許業務規則被合併在一個服務裏或多個服務裏。這種架構也提供了一個服務管理基礎（service management infrastructure），用來管理服務，相似審覈，列表（billing），日誌等功能。此外，該架構給企業提供了靈活的業務流程，更好地處理控制請求（regulatory requirement），例如Sarbanes Oxley（SOX），而且能夠在不影響其餘服務的狀況下更改某項服務。
SOA基礎結構
要運行，管理SOA應用程序，企業須要SOA基礎，這是SOA平臺的一個部分。SOA基礎必須支持全部的相關標準，和須要的運行時容器。圖3所示的是一個典型的SOA基礎結構。
SOAP， WSDL， UDDI
WSDL，UDDI和SOAP是SOA基礎的基礎部件。WSDL用來描述服務；UDDI用來註冊和查找服務；而SOAP，做爲傳輸層，用來在消費者和服務提供者之間傳送消息。SOAP是Web服務的默認機制，其餘的技術爲能夠服務實現其餘類型的綁定。一個消費者能夠在UDDI註冊表（registry）查找服務，取得服務的WSDL描述，而後經過SOAP來調用服務。
WS-I Basic Profile
WS-I Basic Profile，由Web服務互用性組織（Web Services Interoperability Organization）提供，是SOA服務測試與互用性所須要的核心
構件。服務提供者可使用Basic Profile
測試程序來測試服務在不一樣平臺和技術上的互用性。
J2EE 和 .Net
儘管J2EE和 .NET平臺是開發SOA應用程序經常使用的平臺，但SOA不只限於此。像J2EE這類平臺，不只爲開發者天然而然地參與到SOA中來提供了一個平臺，還經過他們內在的特性，將可擴展性，可靠性，可用性以及性能引入了SOA世界。新的規範，例如 JAXB（Java API for XML Binding），用於將XML文檔定位到Java類；JAXR（Java API for XML Registry）用來規範對UDDI註冊表（registry）的操做；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用來調用
遠程服務，這使得開發和部署可移植於標準J2EE容器的Web服務變得容易，與此同時，實現了跨平臺（如 .NET）的服務互用。
服務品質
在企業中，關鍵任務系統（mission-critical system，譯註：關鍵任務系統是指若是一個系統的可靠性對於一個組織是相當重要的，那麼該系統就是該企業的關鍵任務系統。好比，電話系統對於一個電話促銷企業來講就是關鍵任務系統，而文字處理系統就不那麼關鍵了。）用來解決高級需求，例如安全性，可靠性，事物。當一個企業開始採用服務架構做爲工具來進行開發和部署應用的時候，基本的Web服務規範，像WSDL，SOAP，以及UDDI就不能知足這些高級需求。正如前面所提到的，這些需求也稱做服務品質（QoS，quality of services）。與QoS相關的衆多規範已經由一些標準化組織（standards bodies）提出，像W3C（World Wide Web Consortium）和OASIS（the Organization for the Advancement of Structured Information Standards）。下面的部分將會討論一些QoS服務和相關標準。
安全
Web服務安全規範用來保證消息的安全性。該規範主要包括認證交換， 消息完整性和消息保密。該規範吸引人的地方在於它藉助現有的安全標準，例如，SAML（as Security Assertion Markup Language）來實現web服務消息的安全。OASIS正致力於Web服務安全規範的制定。
可靠
在典型的SOA 環境中，服務消費者和服務提供者之間會有幾種不一樣的文檔在進行交換。具備諸如「僅且僅僅傳送一次」（ once-and-only-once delivery），「最多傳送一次」（ at-most-once delivery），「重複消息過濾」（duplicate message elimination），「保證消息傳送」（guaranteed message delivery）等特性消息的發送和確認，在關鍵任務系統（mission-critical systems）中變得十分重要。WS-Reliability 和 WS-ReliableMessaging是兩個用來解決此類問題的標準。這些標準如今都由OASIS負責。
策略
服務提供者有時候會要求服務消費者與某種策略通訊。好比，服務提供商可能會要求消費者提供Kerberos安全標示，才能取得某項服務。這些要求被定義爲策略斷言（policy assertions）。一項策略可能會包含多個斷言。WS-Policy用來標準化服務消費者和服務提供者之間的策略通訊。
控制
當企業着手於服務架構時，服務能夠用來整合數據倉庫（silos of data），應用程序，以及組件。整合應用意味着例如異步通訊，
並行處理，數據轉換，以及校訂等進程請求必須被標準化。在SOA中，進程是使用一組離散的服務建立的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用來控制這些服務的語言。WSBPEL目前也由OASIS負責。
管理
隨着企業服務的增加，所使用的服務和業務進程的數量也隨之增長，一個用來讓系統管理員管理全部運行在多相環境下的服務的管理系統就顯得尤其重要。
WSDM（Web Services for Distributed Management）規定了任何根據WSDM實現的服務均可以由一個WSDM適應（WSDM-compliant）的管理方案來管理。
其它的
qos特性，好比合做方之間的溝通和通信，多個服務之間的事務處理，都在WS-Coordination 和 WS-Transaction 標準中描述， 這些都是OASIS 的工做。
SOA 不是Web服務
在理解SOA和Web服務的關係上，常常發生混淆。根據2003年4月的Gartner報道，Yefim V. Natis就這個問題是這樣解釋的：「Web服務是技術規範，而SOA是設計原則。特別是Web服務中的WSDL，是一個SOA配套的接口定義標準：這是Web服務和SOA的根本聯繫。」從本質上來講，SOA是一種架構模式，而Web服務是利用一組標準實現的服務。Web服務是實現SOA的方式之一。用Web服務來實現SOA的好處是你能夠實現一箇中立平臺，來得到服務，並且隨着愈來愈多的軟件商支持愈來愈多的Web服務規範，你會取得更好的通用性。
SOA的優點
SOA的概念並不是什麼新東西，SOA不一樣於現有的
分佈式技術之處在於大多數軟件商接受它並有能夠實現SOA的平臺或應用程序。SOA伴隨着無處不在的標準，爲企業的現有資產或投資帶來了更好的重用性。SOA可以在最新的和現有的應用之上建立應用；SOA可以使客戶或服務消費者免予服務實現的改變所帶來的影響；SOA可以升級單個服務或服務消費者而無需重寫整個應用，也無需保留已經再也不適用於新需求的現有系統。總而言之，SOA以藉助現有的應用來組合產生新服務的敏捷方式，提供給企業更好的靈活性來構建應用程序和業務流程。