[訊息論壇] ICE Messaging Forum 郭漢丞
<應用篇>
時間價值
無論對於個人或是企業，時間價值至少具備三種特性：相對、成本、與客觀，在建立企業資訊系統時，時間永遠是新系統所要達成的目標之一，而整個資訊工業的發展，也是因為追求時間的最有效應用，而不斷發展至今，從
IBM 發展專業計算機、個人電腦興起、一直到網際網路的興起，電子郵件、與即時傳訊軟體進入個人與企業應用當中，沒有一項發展與時間無關。
為了縮短會計處理帳務繁雜的計算時間，所以有許多試算表軟體應運而生；為了提升溝通的效率，所以有即時傳訊軟體，讓我們可以在同一時間與多人對話；時間價值在這裡是一種相對的概念：會計處理最繁複的部分，並不限於計算，會計人員在傳票處理與會計原則的使用，更需要花費時間與腦力，因此將大量計算的工作交給電腦，會計人員就可以把更多的時間拿來仔細考量帳務歸類的問題，並且可以透過電腦立即運算的能力，計算出不同的方案所產生的結果，以尋求最佳解。
即時傳訊軟體也是這樣的概念，電話已經是非常有效率的溝通工具了，隨時想到誰，只要你有對方的電話號碼，拿起話筒輕鬆一撥，馬上可以與對方連上線，不過，電話的時間觀念是一直線、是同步作業
(synchronization)，你必須與對方在線上專心一致地把一件事情談完，即使你可以執行多方談話的線上會議，在一個時間裡，也是只能商談一件事，換句話說，電話很直接，但是無法同時多線進行處理不同的事情。
但使用 ICQ 或 Messenger 這一類的即時傳訊軟體就不一樣了，你可以隨時知道誰在線上，誰不在線上；可以單獨找一個人溝通，也可以同時對多人發話，商討不同的事情，如與A談明天開會的要點，與B聊最近的八卦；線上多人同時以「鍵盤對話」，也不會覺得混亂，運用即時傳訊軟體時，你的時間變成非同步
(asynchronization) 多工。相對地，你可以在同一時間處理多項溝通事務，而可資運用的時間也就倍增了。
時間的成本概念那就更容易理解了，哪一個老闆不會唸：「你有沒有時間成本概念啊？」建構新的計畫時，投入的人力乘以時間就是人力時數，這是大家都經常使用到的估算數字，老闆的算盤就是在最後打上每小時的人力成本，這就是所有的時間成本了。
時間的客觀因素，起因於全球通用的計時單位，一天二十四小時，每小時六十分鐘，每分鐘六十秒，計算下來每人每天都公平的擁有
86,400 秒，這是絕對的時間標準，沒有人可以逃出這樣的規範。不同的是，有效率的人可以在客觀的時間限制當中，完成更多的任務，這是成功的要素之一。企業更是如此，具備高度效率的企業，很難看到最後以破產收場，經常是有效率的企業，經歷高成長與高獲利以後，忘記了過往的效率是獲利的成功因素，漸漸因為組織擴大或行政官僚化的因素，漸漸失去效率，導致企業獲利下降，終至不可收拾。
既然時間價值具備相對、成本、與客觀三種特性，建構企業應用的訊息傳遞系統就是要在這幾項時間的特性上，發揮時間的最大價值。
「即時」就是把時間價值發揮到極致的目標，無論您是否認為「即時」是您建構訊息系統最重要的考慮因素，您都無法否認「即時」的訊息傳遞系統是將時間價值最大化的手段，至於是否必須建立「即時」系統，那是必要性的問題，無關乎「即時」訊息系統的價值。
為了瞭解及「即時」訊息傳遞系統的要旨，我們回顧前一期電子報的內容，分析訊息系統，您必須找出下列 13 項標的（targets），建立各項標的相互之間的訊息傳遞流向與通道（pipeline）：
- Role：訊息系統相關角色設定 (人或系統)
- Flow：訊息流程
- Meaning：訊息傳遞的意義為何
- Msg. Producer / Msg. Consumer：誰是訊息的產生者或訊息的消費者
- Number of Msg. Producers and Msg. Consumers：訊息產生者與訊息消費者的數量為何
- Real-time：即時性的最低要求為何
- Msg. Size：訊息的大小
- Msg. Frequency：訊息的頻率 (一秒幾次)
- Scalability：系統短、中、長期的服務規模 (連線使用數) 落點描繪
- One-way or Bi-directional：各種客戶端的訊息流通是單向還是雙向
- Computation：商業邏輯的運算效能需求
- Carrier/Protocol：訊息通訊載體或通訊協定的支援需求
- Platform：客戶端軟體的執行環境平台支援
這裡所提及的 13 項分析因素，您必須把企業內的訊息傳遞內容逐一拿出來仔細分段研究，從這當中您可以發現企業訊息傳遞系統的問題所在，並且更進一步的瞭解您是否需要一套「即時」的企業訊息架構平台。
| 從 DB-centric 走向 MOM-centric
|
上述的 13 項分析因素可以讓您瞭解企業訊息系統的需求與改進方向，不過接下來您還必須面對另一個建構新世代訊息系統的關鍵因素，就是選擇
DB-centric 或 MOM-centric 的訊息架構。
DB-centric 是目前一般企業採用的應用模式，以資料庫為中心執行所有的資料匯總與整理，資料庫是企業智慧財產的中心，許多針對資料庫的加值應用也都是大家耳熟能詳的，例如
ERP、CRM、Data Mining 等等。
資料庫作為龐大資料的匯總與分析是相當有價值的，不過把資料庫當作企業訊息傳遞的應用伺服器，那就很難達成「即時」的需求，因為資料庫並不是設計來解決訊息傳遞的問題，而是解決資料整理歸納與分析加值應用，訊息傳遞不是其原始設計的初衷。想要把資料庫當作訊息傳遞的核心，經常無法有效解決問題，反而是問題的所在。選擇
MOM-centric 的架構，您將可以把訊息傳遞的問題，放心的交給專用的訊息伺服器來解決。
 |
| 圖例：MOM-centric
搭配 DB 的即時資訊架構 |
MOM 無法取代資料庫，它是用來解決訊息傳遞問題，所以 MOM 與資料庫之間是伙伴關係，您可以把所有需要執行即時傳遞的訊息全部透過專屬頻道
（channel） 規劃，建立起企業內外訊息傳遞的通道，而資料庫也是其中的一環。
即時的訊息以即時的方式傳送至使用者，資料庫是接收資訊的一個端點（message consumer），透過 Trigger
+ Stored Procedure，資料庫也是送出資訊的一個端點（message producer），這樣子就可以建立「即時」訊息系統，您再也不用憂慮資料庫存取即時資料的速度與效率了，因為主動觸發的即時訊息可以取代許多重複或不必要的被動查詢（polling
query），整個 MOM + DB 的訊息傳遞架構就是這麼簡單好用，您經過實作後更會發現它在實際應用上的的優點與特性。
歡迎進入「即時」訊息傳遞的世界，您會發現時間的價值，其實就在彈指之間。
|
