jim yeh on 七月 23rd, 2007

企業或產業價值鍊的整合,常常會牽涉跨部門、跨組織的資訊系統。在價值鍊活動過程中所發生的交易,需要與價值鍊其它活動相互整合,因此會經歷較長的處理過程,一般稱為長時間交易。這種交易避免鎖定非本地端資源、使用補償作業來處理交易失敗、潛在地聚合較小而具有 ACID 特性的交易、通常利用一個協調器來完成或放棄交易[1]

長時間交易有複雜的處理過程,當交易因故無法完成時,無法以 rollback 的方式,回復異動前的資料狀態,而是必須對此筆交易執行補償作業。例如,如果有人向銀行發送一筆付款指示,付款銀行在扣帳後,卻收到了受款帳號發送了無法入帳的通知,付款銀行就必須執行退款的補償作業以還原付款帳號在交易前之狀態,故長時間的交易亦常被稱做補償式交易。

換言之,長時間交易並不屬於不可分割的交易。在交易過程中,必須根據交易的處理狀態來決定後續的作業,這些作業可能是一組流程或是具有 ACID 特性的交易(這類交易才具有不可分割的特性)。

由上可知,欲解決長時間交易的處理問題,交易的處理狀態將變成很重要的概念。有了處理狀態的概念,長時間交易的設計就變得簡單多了,讓交易過程是非同步的,並非讓使用者枯等交易結果卻不能做別的事,而是當使用者發送交易之後,使用者不須等待交易處理完畢,系統會默默處理此交易,而隨後可由使用者查詢交易處理的進度,或是在交易完成後,由系統發送通知給使用者。

於是運用上述的設計概念,我們可以設計出可以解決長時間交易的設計架構。如果我們要設計銀行的付款系統,假設安控簽驗章模組、帳務主機系統及銀行網路環境都已經是現成的,我們要如何整合這些既存的模組、系統及環境呢?其實把它們都看做元件,然後再用服務的概念來封裝它們,問題就單純多了,我們可以這樣設計:

此設計圖中,Inbound 知道如何從銀行網路環境取得交易訊息,並透過 SignatureService 來檢驗交易訊息的簽章。然後再呼叫 TxnProcessor 來處理交易。而 PaymentProcessor 實作了 TxnProcessor,它會依據交易的處理狀態,知道該如何來處理交易。例如,檢核交易、執行扣帳作業、或是發送訊息通知,而處理交易過程中,PaymentProcessor 透過 TxnStateService 來更新交易狀態。

此設計看起來很容易理解,但實作起來卻有個地方要特別注意。那就是 Inbound 呼叫 TxnProcessor 及 TxnProcessor 呼叫 ForwardService 的部分,必須用非同步的呼叫方式。因為 Inbound 只須通知 TxnProcessor 有那一筆訊息要處理後,就可以繼續自己後續的工作了,而不應該等待 TxnProcessor;同樣的道理,TxnProcessor 也不應該等待 ForwardService 把訊息轉遞完成才能繼續處理後面的交易。

因應交易流程整合的非同步呼叫考量,有兩種實作方式可以達成目的。一種做法是 database sharing,另一種則是採用 message queue 的概念;前者是透過背景程式以 polling 的方式,從資料庫中讀取交易處理狀態,而後者則透過 messaging system,將交易訊息傳送給訊息處理者。這兩種實作方式會殊途而同歸,最後都會依據處理狀態,呼叫後端服務進行後續處理。

其實,由前述的元件圖,不難理解其實 TxnProcessor 亦可視為是一種服務,這種設計思路讓我們可以用服務的概念來封裝交易與流程,等同看待兩者,設計可以變得簡潔而更具彈性。對於流程相當單純的長時間交易而言,交易流程的變動並不會衝擊到個別的交易元件,只要改變 TxnProcessor 的實作(PaymentProcessor)即可,而且也很容易因應業務需求而增添其他交易流程元件。

例如,我們可增加一個 FinpayProcessor 的跨行付款交易的流程元件,用來處理跨行付款的交易訊息[2],而帳務處理、訊息傳送及處理狀態維護等元件都可以再用或加以抽換適用的元件,這是因為元件並非與元件緊密耦合,而是透過服務加以鬆綁。所以,服務層其實是整合交易與流程的最佳利器呀。



附註  
  1. Long-running transaction. (2007, May 20). In Wikipedia, The Free Encyclopedia. Retrieved 02:50, July 24, 2007.[]
  2. 在金融電子資料交換(FEDI)的領域中,當付款銀行在處理完付款指示(PAYEXT)訊息並且由付款帳號扣款成功後,會發一筆跨行付款交易訊息(FINPAY)給收款銀行,中間會經過財金公司(FISC)清算帳務,然後收款銀行必須處理此交易訊息,並為收款帳號入帳。[]
     

2 Responses to “流程與交易的整合(其一)”

  1. [...] 上次提到用服務層的概念整合業務流程與功能性交易,並指出因應交易流程整合的非同步呼叫考量的兩種技術實作方式,也就是 database sharing 與 message queue 的不同做法。兩種做法會殊途同歸,最後會依據處理狀態,呼叫後端的服務進行後續系統作業。 [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">