什么是面向服務的體系結構（SOA）？
面向服務的
體系結構（SOA）表示您可以如何使用 Web 服務的大圖景。Web
服務規范定義了實現服務以及與它們的交互所需要的細節。然而，面向服務的體系結構（SOA）是一種用于構建分布式系統的方法，采用 SOA
這種方法構建的分布式應用程序可以將功能作為服務交付給終端用戶，也可以構建其他的服務。面向服務的體系結構（SOA）可以基于 Web
服務，但是它可能改為使用其他的技術來代替。在使用面向服務的體系結構（SOA）設計分布式應用程序時，您可以將 Web
服務的使用從簡單的客戶端-服務器模型擴展成任意復雜的系統。
因而，單個的軟件資產成為開發其他應用程序的基本構件。您可以通過與新的代碼
和遺留代碼一起使用的共同交互方式來減少系統的復雜性（CBDi 的 Lawrence Wilkes
開玩笑說，面向服務的體系結構（SOA）可以代表“節省我們的資產（Save Our
Assets）”）。有一種標準的方法可以用于表示這些軟件資產和與它們交互；現在人們關注的重點已經轉移到基于這些構件的應用程序裝配上來了。
雖
然在這里討論的是用于業務應用程序的面向服務的體系結構（SOA），但是面向服務的體系結構（SOA）同樣也可以用于其他的分布式系統，比如網格計算和高
級 Web 服務規范（例如，Web 服務分布式管理（WS-DistributedManagement）、Web
服務信任（WS-Trust）以及 UDDI）。
什么是服務？
在
面向服務的體系結構（SOA）中，服務（service）是封裝成用于業務流程的可重用組件的應用程序函數。它提供信息或簡化業務數據從一個有效的、一致
的狀態向另一個狀態的轉變。用于實現特定服務的流程并不重要，只要它響應您的命令并為您的請求提供高質量的服務就可以了。
通過定義的通信協
議，可以調用服務來強調互操作性和位置透明性。一個服務表現為一個軟件組件，因為從服務請求者的角度來看，它看起來就像是一個自包含的函數。然而，實際
上，服務的實現可能包括在一個企業內部的不同計算機上或者許多業務合作伙伴擁有的計算機上執行的很多步驟。就封裝的軟件而言，服務可能是一個組件，也可能
不是一個組件。如同類對象，請求者應用程序能夠將服務看作是一個整體。
Web 服務是以使用 SOAP 消息（它是用像 HTTP 這樣的標準協議上的 WSDL 來描述的）的調用為基礎的。使用 Web 服務的最佳實踐就是與外部的業務伙伴通信。
松耦合
服務請求者到服務提供者的綁定與服務之間應該是松耦合的。這就意味著，服務請求者不知道提供者實現的技術細節，比如程序設計語言、部署平臺，等等。服務請求者往往通過消息調用操作——請求消息和響應——而不是通過使用 API 和文件格式。
這
個松耦合使會話一端的軟件可以在不影響另一端的情況下發生改變，前提是消息模式保持不變。在一個極端的情況下，服務提供者可以將以前基于遺留代碼（例如，
COBOL）的實現完全用基于 Java 語言的新代碼取代，同時又不對服務請求者造成任何影響。這種情況是真實的，只要新代碼支持相同的消息模式。
明確定義的接口
服務交互必須是明確定義的。Web 服務描述語言（Web services Description Language，WSDL）是受到廣泛支持的方法，用于描述服務請求者所要求的綁定到服務提供者的細節。服務描述的重點在于與下面幾部分交互所用的操作：
服務
調用操作的消息
構造這種消息的細節
關于向何處發送用于構造這種消息的處理細節的消息的信息
WSDL
不包括服務實現的任何技術細節。服務請求者不知道也不關心服務究竟是由 Java
代碼、C#、COBOL，還是由某種其他的程序設計語言編寫的。它可以描述使用 HTTP 的 SOAP
調用。由于它的擴展機制，它也可以定義其他類型的交互，比如通過 JMS 提交的 XML
內容、直接方法調用、由管理遺留代碼的適配器處理的調用（CICS），等等。
WSDL
的通用定義允許開發工具創建各種各樣類型的交互的通過接口，同時隱藏它是如何由應用程序代碼調用服務的細節。例如，如果服務是以多種交互類型公開的，
Web 服務調用框架（Web Services Invocation
Framework，WSIF）通過允許運行時決定調用高質量服務的最優方法來使用這種能力。
無狀態的服務設計
服
務應該是獨立的、自包含的請求，在實現時它不需要從一個請求到另一個請求的信息或狀態。服務不應該依賴于其他服務的上下文和狀態。當需要依賴時，它們最好
定義成通用業務流程、函數和數據模型，而不是實現構件（比如會話密鑰）。當然，請求者應用程序需要服務調用之間的持久狀態，但是這不應該與服務提供者分
開。
這里有一個定義會話的錯誤方法的示例：
Requester: “What is Bruce’s checking account balance?"
Provider: “$x"
Requester: “And what is his credit limit?"
Provider: “$y"
?
提供者被要求記住請求之間 Bruce 的帳號，這就在服務實現中引入了復雜性。無狀態的服務設計將重新定義會話，如下所示：
Requester: “What is Bruce’s checking account balance?"
Provider: “$x"
Requester: “What is Bruce’s credit limit?"
Provider: “$y"
?
服務粒度
操
作的粒度是一項重要的設計要點。對于外部的消耗推薦使用粗粒度的接口，而細粒度的接口可能用于企業內部。粗粒度接口可能是特定服務的完整處理，例如
SubmitPurchaseOrder，在這里消息包括定義訂購單所需的所有業務信息。細粒度接口可能具有用于以下方法的不同操作：
CreateNewPurchaseOrder、SetShippingAddress、AddItem，等等。
雖然細粒度的接口為請
求者應用程序提供了更多的靈活性，它同樣也意味著交互的模式可能隨著不同的服務請求者而不同。這可能使對于服務提供者的支持更加困難。粗粒度接口保證服務
請求者將以一致的方式使用服務。面向服務的體系結構（SOA）不要求使用粗粒度接口，但是推薦使用它們作為外部集成的最佳實踐。服務編排可以用來創建運行
由細粒度操作組成的業務流程的粗粒度接口。
服務質量需要考慮的問題
面
向服務的體系結構（SOA）設計將跨越計算機系統，并且還可能跨越企業邊界。您不得不考慮在使用 Internet
時安全性功能和需求以及如何鏈接伙伴的安全域。Internet
協議并不是為可靠性（有保證的提交和提交的順序）而設計，但是您不得不確保消息被提交并被處理一次。當這不可能時，請求者必須知道請求并沒有被處理。
例如，您可能需要考慮您所部署服務的度量、可靠性以及響應時間，以便確保它們在承諾的范圍之內。當您設計使用來自其他業務伙伴的服務的系統時，您就不得不考慮面向服務的管理來以協作方式管理伙伴之間的服務。