在服務交互的時候，數據是通過文檔傳遞的。文檔是顯式建模的樹狀容器。在上面提到過的自描述性是面向文檔的一個重要特征。理想狀況下的文檔應該是按照真實世界的文檔來建模的，如采購單、發票或帳戶聲明。設計良好的文檔在特定問題域的上下文環境中很有幫助，即它應該被一個或多個服務所采用。
類似于真實世界的紙質文檔，在服務中交換的文檔會包含冗余的信息。例如，客戶的地址可能與客戶的ID信息放在一起（盡管只有客戶ID就足夠了）。這些冗余的信息會被顯式的使用，它的作用在于將服務和服務消費者和服務提供者的底層數據模型進行隔離。當使用面向文檔模式的時候，服務調用成為了有意義的業務信息交換而不僅僅是上下文無關的RPC調用。盡管沒有要求，一般都假定用XML來作為這種文檔的格式/語法。
消息在通過SOA互連的異構系統間的參與者之間流動著。松耦合原則要求對于共有認知的依賴越小越好。當消息在分布式對象或RPC環境中傳遞時，客戶端和服務端依賴的是一組用同一個接口描述文檔自動生成的代理類（stubs和skeletons）。如果不采用這樣的方式，若契約本身不支持雙方交互則將無法通訊。所以說，RPC形式的架構必然要求客戶端和服務端代碼同步變化。
通過下面的比較我們來看一看�？紤]以下消息：
“2006-03-1347113”
將它和
<order />
<date />2006-03-13</date />
<product />4711</product />
<quantity />3</quantity />
</order />
比較一下。
顯然后者比前者的可讀性更好，并且對于后者來說，除了使用固定的語法，參與者還可以使用例如XPath這樣的技術來隔離細微的非顛覆性的變化。反過來說，如果用了像XML這樣的自描述格式的消息卻仍然使用RPC方式進行通訊，其作用無非只能證明XML是最消耗帶寬的一種方式。如果你使用XML,那么一定要利用它的優點而不是缺點。
7）松耦合
大多數SOA倡導者都認同松耦合是一個重要的概念。但不幸的是，對于一個系統“松耦合”特性的認定卻有很多不同的選項。認定一個系統是松耦合還是緊耦合的，根據具體的需求和上下文可以有許多維度，從某些維度來看可能是松耦合，但是從另一些維度來看又可能那是緊耦合。這些維度包括：
時間：當（服務）參與者在時間維度上松耦合時，他們不是必須同時在線才能進行交互。這要求他們之間必須有某種緩沖和隊列的機制。當一個參與者發送消息到對方的時候，它不必依賴立即的消息回復也能繼續流程。
位置：如果參與者需要知道其它參與者的位置信息來進行通訊，那么位置的松耦合意味著當這些位置信息的改變時應該不需要重新編程、重新配置或重新啟動通訊中的各個參與者。這就隱含要求了服務的調用需要有一個尋址過程，并需要某種目錄或地址簿存儲服務終端的位置。
類型：類似編程語言中的靜態類型/動態類型或強類型/弱類型，類型的松耦合使得服務的參與者不依賴文檔的全部或哪怕部分結構。
版本：服務的參與者可能依賴特定版本的服務接口，也可能可以接口接口的（一定程度上）變化。越是依賴服務的特定版本，參與者的松耦合的程度就越低（在該維度上）。一個不錯的參考準則是Postel法則：服務提供者的實現應當盡可能接受各種版本，以擁有更大的自由度（甚至可以容錯），而服務的消費者則應該盡可能地遵循特定的語法和文檔接口。這樣可以增加系統整體上的可靠性和靈活性。
關聯：在某些情況下，服務消費者和服務提供者之間是1：1的關系，尤其是在“請求-答復”式交互或使用顯式的消息隊列的情況下。而在另外一些情況中，服務的消費者（叫“消息發送者”或“事件源”更合適）可能不知道甚至根本不在乎收到的消息數。
查詢：請求服務調用的參與者既可以根據服務提供者的（物理的或邏輯的）名字來跟它們通訊，也可以首先根據一組能力描述執行一個服務查找操作。這意味著需要有一個可以將消費者需求和服務提供者能力進行匹配的服務注冊表或服務倉庫。
接口：既可以要求參與者依賴服務所提供的特定接口，也可以要求它們支持一個通用的接口。如果使用通用接口，所有使用這個通用接口的參與者就可以和所有提供這個通用接口的參與者進行交互。盡管乍一看這樣做非常別扭，但這種單一（統一）通用接口卻是WWW結構中的核心所在。
任何創建的系統不可能、也不需要滿足上述所有維度的松耦合。對于不同類型的服務需要做不同程度的權衡。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
