檔案傳輸 • 企業整合模式

作者：Martin Fowler

脈絡：一家企業有多套獨立建造的應用程式，使用不同的語言與平台。

為什麼企業註定有一堆異質系統#

在理想世界裡，一個組織會運行在單一一套內聚的軟體上，從一開始就設計成統一而一致地運作。當然，即使最小的營運單位也不是這樣。多套軟體各自處理企業的不同面向，理由包括：

結果是：任何組織都得煩惱如何在差異極大的應用程式之間共享資訊。它們可能用不同語言寫成、基於不同平台，甚至對「生意怎麼運作」抱著不同的假設。

要把這樣的應用程式綁在一起，需要在業務層面與技術層面都懂得如何串接。想搞得定，你就必須把「需要知道每個應用程式如何運作」的份量降到最低。

我們需要的是一種共同的資料傳輸機制：能被各種語言與平台使用、對每一方又都自然；所需的專用軟硬體極少，盡量利用企業已有的東西。

檔案是通用的儲存機制——內建於任何企業級作業系統，任何企業級語言都能存取。最簡單的作法，就是設法用檔案來整合應用程式。

檔案的一個重要決策是格式。一個應用程式的輸出極少恰好就是另一個所需要的，所以中間總得做不少加工；而且不只所有使用該檔的應用程式得讀得懂它，你還得能對它套用處理工具。

於是標準檔案格式逐漸成形：

每一種格式周邊都長出了一整個由讀取器、寫入器與轉換工具構成的產業。

另一個議題是何時產出與消費檔案。由於產出與處理檔案都需要一定的工夫，通常你不會想太頻繁地操作它們。典型上會有某個固定的業務週期在驅動這個決定：每晚、每週、每季……應用程式習慣了新檔案何時就緒，就在那個時間處理它。

檔案傳輸的巨大優勢在於：整合人員完全不需要知道應用程式的內部。

檔案通常由應用團隊自己提供，內容與格式則與整合人員協商（若用的是套裝軟體，選擇往往有限）。整合人員接手處理其他應用程式所需的轉換，或者乾脆把「要怎麼操作與讀取這個檔案」留給消費端自己決定。

結果是各應用程式被相當漂亮地解耦：只要仍以相同格式產出相同資料，每個應用程式都能自由地做內部修改而不影響他人——檔案實際上成了各應用程式的介面。

讓檔案傳輸簡單的部分原因，正是它不需要額外工具或整合套件——但這也意味著開發者得自己扛下大量工作：

檔案傳輸最明顯的問題是更新頻率低，導致系統之間失去同步。客戶管理系統可以在每晚處理地址變更並產出萃取檔，但帳務系統可能在同一天把帳單寄到舊地址。

有時候不同步不算大事——即使有電腦，人們也預期資訊流轉本來就有一定的時間差。但有時候用到陳舊資訊的後果是災難性的。決定產檔時機時，必須把消費端對新鮮度的需求納入考量。

陳舊資料最大的麻煩往往落在軟體開發人員自己身上——他們得跟不太正確的資料共處，而這會導致難以化解的不一致。
假設某位客戶在同一天於兩套系統各改了一次地址，其中一套打錯了街名，你就有了兩份彼此矛盾的地址，還得想辦法決定哪份為準。檔案傳輸的間隔愈長，這個問題愈可能發生，也愈痛苦。

當然，沒有人規定你不能更頻繁地產出檔案。事實上，你可以把訊息傳遞想成「應用程式每發生一次變更就產出一個檔案」的檔案傳輸。

問題會轉移到「如何管理產出的大量檔案、確保它們都被讀取且沒有遺失」。這超出了檔案系統作法能處理的範圍——尤其處理一個檔案有昂貴的資源成本，若想快速產出大量檔案，成本會高到無法承受。
因此，一旦細到這種程度，把它們當成訊息來思考會更容易。