消息參與者
讓我們想象一下，我需要寫一封感謝信給我朋友Rusty，因為他上周給了我一 張足球比賽的門票。我們假定需要把信件郵寄到Rusty的辦公室。現實生活中， 發送Email給Rusty或許是更加方便和省錢的方式。那可能是更加復雜的例子，有 時候寫信會更加合適。那麼郵寄一份信件我需要經過多少種步驟呢?
大家知道，正常情況下我需要先寫一封感謝信在我郵寄以前。當我寫信的時 候，我需要提到足球比賽的事情，因為無緣無故地給一個人寫感謝信會非常奇怪 。接下來我會把信放到信封裡，然後寫上收信人地址然後貼上郵票。最後一步就 是把信投到信箱裡，讓郵政服務機構來把信件轉交給Rusty。可以想象Rusty將會 知道感謝信是我寫的，而且知道我是為了足球票的事情感謝他。
當我們描述消息參與者的時候，把他們對應到消息發送過程的角色是非常有 用的。通常來說，有三種類型的消息參與者：初始發送者、最終接受者和中介者 。
讓我們想象一個更加真實的商業場景- Contoso回飛棒公司的訂單處理系統。 基本上，客戶在網站上訂購回飛棒，網站產生一個消息並且為了處理和完成訂單 流程而發送到其他的系統，如圖2-1所示。
圖2-1：Contoso回飛棒公司的消息流
場景中暗示的幾個事實：
網站和其它幾個系統已經在之前就消息格式達成共識。
網站可以依據之前的格式創建消息
網站知道如何向其他系統發送消息
內部系統可以使用接受到的消息中的數據區填充訂單，發送確認信息和提交 訂單。
Contoso訂單處理系統至少有兩個消息參與者。網站是消息發送者，內部系統 是消息接受者。可能還有一個負載均衡路由來負責轉發消息到適合的系統。如圖 2-2所示，我們可以認為路由就是中介者。
圖2-2：在帶消息路由的Contoso回飛棒公司的消息流
初始發送者
明確消息發送者比看起來要困難，在我們的感謝信例子中，我看起來就是消 息的發送者，有點是是而非，但是把我的信件堪稱是對Rusty 送球票行為的響應 。如果我們這樣考慮，Rusty就是消息的發送者，我的感謝信就是對其慷慨的回 應。沿著這些路線，可能我會再2個月前發送一個新建所要球票。當Rusty回應我 的時候，就給了我2個球票。我的感謝信就是對Rusty響應的響應。也可以能是我 們共同的朋友建議他應該給我這些球票。這個例子裡，我們的共同的朋友就是消 息的最初發送者。
我們的訂單處理系統看起來也是有些迷糊。咋一看，網站可能就是消息的最 初發送者。可是從內部系統的角度來看，也許不是這樣。按照那個觀點，最初發 送者可能是網站或者另外一個內部系統（記得消息路由）。我們可以繼續不停。 但事實上消息的最初發送者是相對的。相對，我的意思是最初的消息發送者可以 基於賦予消息的上下文環境而改變。在我們的兩個例子裡，我們可以畫出任意一 個包圍2個或者多個消息參與者的邊界，並且改變消息的最初發送者。
如果我們把初始從初始消息發送者裡去掉，我們可以更具體地想象一個消息 的參與者。如果我們回顧一下感謝信的例子，Rusty 或許不在乎誰是初始的消息 發送者；他就想知道誰寫的感謝信。實際上，初始消息發送者和消息發送者之間 的經常不值得去區分。因此，我會使用發送者代替。如果你在萬維網聯盟（W3C ）的文檔或者規范裡看到初始發送者這個單詞，要知道定義裡的含義。解釋了這 麼多，下面是我關於發送者的描述：
一個發送者是一個發起通信的實體。
中介者
當信件到達Rusty手裡的時候，幾個人已經處理過了這個感謝信。這裡提到一 些：
負責收信的郵局工作人員
負責分信的郵局工作人員
把信投遞到Rusty辦公室大樓的郵遞員
把信件轉交給Rusty的郵件收發室的工作人員
從經歷來說，我們不知道多少人處理我們過我們發送的信件。我們很希望知 道從處理我們信件的人那裡的確定操作。比如，我們希望他們不要打開信件或者 修改內容。我們同樣系統每個信件處理人員盡量把信送到我們想寄給的人那裡， 不論是處理的過程中還是實際地址。這些消息的路徑節點就是中介者。說了一堆 ，我這裡給出中介者的定義：
中介者是對發送者不可見的，並且處於發送者和接受者中間的。
辨別中介者同樣比看起來困難。在我們郵寄信件的例子裡，郵遞員不是簡單 撿起信件然後把它交給另外一個郵遞員？下一個郵遞員是不是繼續向前投遞給下 一個郵遞員？如果他或者她向前發送一個信件，郵遞員不可以是初始發送者嗎？ 事實上卻是如此，每個處理信件的郵遞員在流程裡都會向前發送信件。每個郵遞 員都會從別另外一個郵遞員或者發送者處接收信件。邏輯上，郵遞員對於發信人 是不可見的，因此發信人不會特地寫明地址。同樣，郵遞員不會創建一個消息； 他們只是簡單地處理和投遞消息。
同樣，在處理信件的時候，信封可能被修改。思考一下郵戳。郵戳不會改變 信件的內容。但是它提供了一些有用的關於何時何地信件被收入的信息。如果地 址無效，郵政服務可能要增加一個“退回給發件人”的標記。更高層次上，這些 操作偶讀是可以由中介者完成。一個中介者，不應該修改消息的內容。
為了一個基於計算機的中介者的例子，我們重新審視一下Contoso 的訂單處 理系統。Contoso銷售客戶定制和標准的回飛棒。標准回飛棒的訂單可以通過倉 庫存貨系統處理，而定制的回飛棒則需要交給制造系統。 Contoso的系統架構師 或許以已經決定把業務邏輯放在一個路由系統裡，把業務邏輯從網站中分離出來 。這個設計的作用就是網站發送消息到消息路由服務器。這個路由系統不會再本 質上修改消息內容。但是它可以轉發訂單到任意系統。高層次來看，路由系統扮 演一個中介者的角色，在初始發送者（網站）和最終接受者（倉庫存貨系或者制 造系統）。
業務邏輯簡介
這個架構中的附加層對於捕獲業務流程非常有用。過去，應用系統的業務邏 輯都是硬編碼在系統中。比如，也許需求或者規則可能需要Contoso財務系統在 訂單完成以前接受回飛棒付款。傳統的分布式系統會把業務邏輯分散到這個業務 流程、網站、財務系統和出貨系統中。這個設計有個很大的缺陷就是：當業務需 求或者規則變化的時候，系統的每個部分都要修改。
最近這些年，很多公司已經開始花錢開發自己的內部系統來解決這些問題。 經常是花費很大精力來定義表現業務邏輯的XML文法以及構建一個自定義的運行 時引擎來解析這些規則。我猜測，常見的結果就是無果而終。
正如第一章提到的，“月亮是藍的”微軟Windows Communication Foundation (WCF)一起發布的一個產品叫 Windows Workflow Foundation (WF)。在這些產品力，WF是設計來捕捉業務流程的。WF能夠為復雜的業務需求建 立業務流程引擎。未來幾年，希望工作流成為商業應用系統開發工作的更多部分 。
最終接受者
我的感謝信是想郵寄給我的朋友Rusty。當我郵寄信件的時候，我不知道多少 人會處理它，但是我希望每個處理者的工作都是為了把信件送達到Rusty。所以 ，我就定義了最終接受者：
最終接受者是消息期望和可達的目標
單個消息可只有一個最終消息接受者。例如，不可能在信封上寫多個地址。 事實上，一個地址可能提到多個實體。比如，Rusty的部分是負責發送球票的， 我可以把一個部門作為感謝信的地址。我們的意思是在這個例子裡，部門裡每個 人都會收到消息。也可能我的信件被貼到公告牌上，發給每個部門員工，或者在 部門會議裡宣讀。最後，消息是期望是一個邏輯實體，消息最終接受者
【地址】：http://www.cnblogs.com/frank_xl/
