導讀：
本文關注這種這樣的情況：orchestration中的消息通過發送端口（無論是單向發送端口還是雙向發送端口）發送消息，需要在orchestration獲得發送消息是否正常的回應，如果回應正常，則流程正常執行，如果回應不正常，orchestration如何進行異常處理。
首先，orchestration發送端口主要有兩個類別，一般發送端口和web發送端口。
一般發送端口就是通過在工具箱中拖拽Port形狀到orchestration形成的發送端口。
Web發送端口是通過biztalk項目引用webservices形成的web端口類型，是biztalk用來消費外部web services的方法。
這兩種發送端口對發送出去的消息的回應處理機制不一樣，所以分別討論。
一、 一般發送端口
一般發送端口需要Delivery Notification屬性設置為Transmitted後，orchestration才會要求物理發送端口返回ACK和NACK消息。
如果一般發送端口未將Delivery Notification屬性設置為Transmitted，orchestration的發送端口把消息發送到messagebox，並能路由到物理發送端口（也可能是其它可以訂閱消息的服務），則認為消息已經成功發送。至於消息在物理發送端有沒有被成功的發送出去不影響到orchestration的運行。這種情況下，不會因為物理發送端口的問題引起orchestration發送端口的異常，所以
本文只討論一般發送端口被設置為Transmitted的情況。
關於詳細的ACK和NACK的原理和測試，請參看《深入biztalk中Delivery Notification和ACK、NACK機制》《biztalk中ACK、NACK詳測示例》兩篇文章。
1、發送消息
orchestration發送端口把消息發送出去的同時，在發送端口處產生一個實例訂閱，訂閱發送端口返回來的ACK或NACK信息。
消息發送後，orchestration繼續往下走。
2、如果是雙向發送端口
如果是雙向發送端口，orchestration流程運行到返回消息的接收形狀停下來，等待消息的返回。收到返回消息後orchestration流程繼續運行下去。
3、接收ACK或NACK消息
如果收到ACK消息，表示消息發送成功；如果收到NACK，orchestration的發送端口會拋出一個DeliveryFailureException異常。
根據發送形狀是否在scope中，分兩種情況：
3.1. 發送形狀在非atomic類型的scope中
一般的，設置了發送端口的Delivery Notification屬性就是為了在orchestration獲知消息發送出去後有沒有被成功的處理，所以一般都會在發送形狀外面加上一個scope，用於捕獲消息發送後不成功產生的異常。
一個非atomic類型的scope形狀，可以有多個Exception Handler（跟C#中的catch語句塊相似，scope本身就相當於try語句塊了），NACK消息將引發DeliveryFailureException異常，所以這種情況下Exception Handler的捕獲異常類型設置為DeliveryFailureException類型。
消息發送出去後，orchestration繼續往下走，直到遇到非atomic類型的scope的邊界，orchestration暫停，等待發送端口訂閱的ACK或NACK消息返回。
