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