合約通訊程式設計

一、通訊模型和執行流程

EOSIO智慧合約可以相互通訊，例如讓另一個合約執行某些與當前action相關的操作，或觸發當前action範圍之外的未來交易。

EOSIO支援Inline和Deferred兩種基本通訊模式。Inline通訊可以理解為在當前action中執行操作，可視為同步通訊，Deferred通訊可以理解為觸發未來事務操作，可視為非同步通訊。

1. Inline通訊

Inline通訊的形式是請求作為呼叫操作的一部分而執行。Inline通訊使用原始交易相同的scope和許可權作為執行上下文，並保證與當前action一起執行。可以被認為是transaction中的巢狀transaction。如果transaction的任何部分失敗，Inline動作將和其他transaction一起回滾。無論成功或失敗，Inline都不會在transaction範圍外生成任何通知。

2. Deferred通訊

Deferred通訊在概念上等同於傳送一個transaction給一個賬戶。這個transaction的執行是eos產快節點自主判斷進行的，Deferrd通訊無法保證訊息一定成功或者失敗。

如前所述，Deferred通訊將在稍後由產快節點自行決定，從原始transaction（即建立deferred通訊的transaction）的角度來看，它只能確定建立請求是成功提交還是失敗（如果失敗，transaction將立即失敗），Deferred通訊承擔傳送transaction的權力，也可以取消Deferred的transaction。

3. Inline通訊流程

下圖說明了多級巢狀的多action事務，僱主執行工資單，將支付轉入員工賬戶，員工賬戶由銀行管理，銀行向其客戶（員工）提供通知，以便客戶可以利用銀行提供的服務，例如支票和儲蓄賬戶之間的自動轉賬。

在本例中，原始transaction對employer合約執行兩項操作：employer::runpayroll和employer::dootherstuff。這兩項action中更有趣的是runpayroll。以下是它的功能，縮排與巢狀的Inline操作一致。

runpayroll進行從僱主賬戶到銀行賬戶的eosio::token::transfer這個Inline通訊，此示例選擇在銀行所需的資訊的“memo”欄位中加入了以確保合適的員工獲得付款的資訊。

        eosio::token::transfer  action執行轉賬操作，

        然後通知僱主，

        然後通知銀行。

銀行有一份合約，收到eosio::token::transfer通知。收到後，原始transaction中的“memo”中的引數

                將用於某些特定的業務，以將資金轉入員工的帳戶。

銀行的行為通知員工賬戶存款。

員工有一個監聽eosio::token::transfer通知的合約。收到後，引數用於確定轉移

                        是否為自己，Employee的合約傳送Inline操作bank::doacctpolicy。

bank::doacctpolicy 根據客戶配置的政策為客戶執行一些操作，例如，

在員工的銀行支票和儲蓄賬戶之間轉移資金。

dootherstuff 做了一些其他的行動，說明一個交易可以有多個行動。

下圖描繪了上例中transction跟蹤：

4. Deferred通訊流程

上述情況也可以使用Deferred通訊完成，下圖顯示了Deferred通訊場景。

Deferred通訊和Inline通訊有一些差異：

1. 員工提交Deferred操作而不是Inline操作。

2. Deferred通訊將導致transaction進行排隊等待可能的進一步處理，而不是直接處理給出處理結果。這是Deferred交易一個非常重要的特徵！ 

3. 當被呼叫時，動作執行的上下文與發出Deferred請求的原始transaction上下文無關。

二、Inline/Deferred通訊程式設計