消息剖析
小時候，我們學習到郵票應該貼在信封的右上角，地址應該寫在中間。如果 我們願意，可以增加一個回復地址在信封的左上角。所有被處理的信件必須遵守 這個基本的結構。如果格式不對，或者地址不清晰，或者地址不合法，郵政服務 會認為這個郵件無效，並且無法投遞。如果我們幸運的話，郵件會被退回（如果 寫地址的話）。可以想象沒寫地址有多混亂。如果發送者可以允許亂放郵票或者 地址，郵政服務需要查遍整個信封來確定郵票和地址。很可能，為了完成新加投 遞任務，每次可能要增加遠多於2美分的郵資。實際上，郵局定義的信封結構， 從發信人角度來看，會改進信件處理的效率和一致性而不需要犧牲可用性。
與郵寄信件的例子相反，SO消息不需要在遵守結構模式。像郵寄信件的例子 ，一個定義好的信封格式改進提高工作效率，可靠性和系統的功能。記住消息應 用系統概念不是新的。起源於各種各樣不同廠商的消息已經經歷過了幾十年來應 用的發展。沒有標准的結構，各個廠商偶讀可以開發自己的消息架構，結果就是 這些千差萬別的消息架構不能夠用來進行系統間的互操作。
如果我們看一下FedEx, UPS, 和DHL這些公司，我們可以看到一個相似的模式 。每個組織已經定義好的他們自己的地址格式和打包規范。很難看到一個貼著 UPS標簽的過夜包裹在FedEx 公司裡投遞。技術角度來說是可行的，但是商業壓 力和效率阻礙了這些公司於另外一個公司的地址格式和包裝標准通用。
用相同的概念檢驗一個可收購企業的計算系統並不苦難。總體來說，廠商不 希望自己的應用系統可以與其他的系統交互。他們有足夠的時間讓自己的系統與 單個設備通信，單獨與其它系統互操作。過去，客戶希望，在一定程度上，用一 個廠商的工具集解決他們所有的企業需求。客戶面對的選擇是“誰能賣給我這樣 的完整包裹？”而不是“那個產品最適合我的每個需求？”。隨著社會發展，一 站式銷售很難滿足潛在的客戶。結果，軟件廠商不得不坐到一起來開會，來制定 一些列公共消息規范和標准，讓他們的應用系統產生的消息遵守這些規范。為了 這些標准的簡歷和通過，已經花費的很多年時間，但是最終這些標准誕生，並且 我們可以希望這些標准日益完善。
有許多關於消息標准的文章，在閱讀本書的時候我們可以多次提到這些標准 。這些規范是，不論哪種形式，許多都是基於SOAP，並且每個規范的作用不同。 出於學習上的好奇心，完全的SOAP消息規范可以在這裡查看： http://www.w3.org/TR/soap12-part1/。由於SOAP的靈活性，現在SO消息的消息 都是SOAP消息。SOAP，它的核心，是一個基於XML的消息結構。SOAP定義了3個主 要的可以定義任意XML消息的XML元素：信封，消息主體和消息頭。這裡是個簡單 的SOAP消息的例子:
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap- envelope">
<env:Header>
</env:Header>
<env:Body>
</env:Body>
</env:Envelope>
因為WCF一個為了與其它系統互操作的SO平台，它發送、接受和處理SOAP消息 。正像你將會再第4章：“WCF101”裡看到的一樣，我們可以認為WCF是一個可以 用無數行為來創建、發送和解析消息的工具包。目前，我們可以弄清楚所有的 SOAP消息的共同點。
消息信封
正如名字的含義一樣，消息信封包裝消息體和消息頭。所有的SOAP消息都有 一個消息信封作為根元素。消息信封經常被用來定義不同的貫穿消息的命名空間 （和前綴）。這令人對SOAP消息非常興奮。
消息頭
消息頭是可以選擇的，如果出現的話，必須是消息信封envelope標簽的下第 一個元素。一個SOAP消息頭由一個或多個SOAP消息頭塊組成。SOAP消息頭塊包含 可以被最終接受者和中介者使用的信息。典型的就是，這些消息頭塊包含描述消 息體數據的信息。換句話說，安全信息，關聯或者消息上下文都可以放到消息頭 部分裡。如果需要特定的消息行為，消息頭塊是必須的。再補充一次，這個想法 可以由郵政系統來闡明。如果我想通過郵政系統發送一個新建並且希望在新建到 達以後得到一個反饋，我必須填寫收信信息並且把它貼到信封上。填寫退回地址 不會改變新建的內容。它可以改變消息參與者的行為：我必須填寫和黏貼退信的 信息。郵遞員必須所要簽名，最終的接受者必須簽字接收，郵遞員必須返回簽收 郵件的收據給我（至少是我的郵箱）。
SO消息可以包含相似的信息在消息頭裡。比如，在我們的訂單處理場景裡， 與路由的確認信息相比，網站或許更想接受消息接受實體的確認信息。這個例子 裡，網站可以為消息指定一個標識，然後加到請求確認的消息頭裡。在到達接受 者之前，路由需要轉發消息到目的習題，然後要求一個確認信息。這個確認信息 可以給直接返回給網站或經過路由返回。
也可以中介者修改了SOAP消息頭或者增加了一個SOAP消息頭塊。實際上，一 個中介者不應該修改消息或者刪除消息頭，除非消息是發給它的。基於這個模型 ，就可以輕易的創建一個包含包含路徑記錄的消息。每個中介者都可以增加它的 SOAP消息頭，直到消息到達最終的接受者，消息包含一串所有接觸這個消息的中 介者。如前所述，這個行為是建模在一個真實的郵政系統郵戳或者消息路由的例 子上。
消息體
消息體是必須的並且包含消息的有效部分。習慣上，消息體裡的數據都是給 最終的消息接受者的。不管中間有多少防火牆、路由或者中介者處理了這個SOAP 消息。這個不是正式的規定。就像沒有規定說郵局不能打開信件一樣，同樣不能 保證一個中介者不打開和改變SOAP消息體。一種可能就是使用數字簽名和加密來 保證消息從初始發送者到最終接受者的完整性
WCF支持SOAP, REST和 POX（樸素的舊的消息）。大部分目前的WCF應用編程 接口（API），是使用SOAP消息結構的。毋庸質疑的是，將來會擴展消息結構， 加入新的消息結構，比如JSON。
消息傳輸
SOAP消息是獨立於傳輸的。換句話說，沒必要在消息裡添加任何傳輸規范。 這個簡單的特性是許多關鍵特性之一，它使得這個消息結構無比強大。再說一次 ，用我們的郵政服務例子可以解釋。如果一惡搞郵件依賴運輸工具，就等於告訴 郵遞員你郵寄信件的地址，並且不包括信封上的信息。如果我們慣性思考，信件 會緊緊地與郵遞員綁在一起。這種緊密的耦合不好的幾個原因如下：
·消息可以只能被郵遞員投遞
·其它郵政人員不能與消息交互（除非前一個郵遞員告訴他）
·批量分類和投遞信件是困難的
·因為沒有信件返回地址，如果信件在處理的時候出現問題，發送者無法被 通知。
從面向服務的角度來看，這是一個糟糕的場景。一個更好的計劃是它本身應 該包含所有相關的地址信息，因此可以避免與傳輸層的機密耦合。當消息包含這 些信息，許多SOAP行為（包括前面提到的行為）是可能的。例如，我們都知道郵 件是被郵遞員收取、轉給分類工具並且通過飛機、火車、輪船或者汽車發送給其 他的分類工具和別的郵遞員。在我們日常的郵件例子裡，可以看到在投遞信件的 時候運輸可以改變（郵遞員、分類器、飛機等等），這可以提高效率。如果沒有 地址的話，那些都不可能。
【地址】：http://www.cnblogs.com/frank_xl/
