[訊息論壇]ICE
Messaging Forum 蔣居裕
<顧問篇> Gap Analysis，打通 Rich
Content 與 Simple Messaging 之間的渠道 (下)
先跟您說聲抱歉，間隔了一期，我們才接續出版這 Gap Analysis 顧問篇的下集。不像霹靂火的劇情，雖然隔了三週看也還接得起來
(我朋友說的！)。我們這種不是很有趣的文章，不利記憶，而想必大家也甚少是陳俊生老師的學生，無法 "Trust
me, you can remember."，所以只好先來個前情提要，幫助大家回想一下上集的重點。
本篇上集的重點，無非是鼓勵各位從事資訊行業的主管與工程師們，能夠培養團隊成員或自己的
IT 學養，從 AP function view 提昇至 System
architecture view。這樣再搭配專業的產業知識與豐富的經驗，必定可以成為一個躍升後的 IT
consultant，可以聰穎地明辨新技術優劣與特性應用價值的能力。
| 即時訊息技術應用分析面的
Gap Analysis |
這下集，讓我們回到即時訊息技術的重點來。
如果你相信 IT 應用的未來會走向分散式網路架構，而這個分散式網路架構下的軟體協同作業不會只有架構在
HTTP 之上的 Request-and-Reply 模式 (如 HTTP、紅火的 Web Services 等)，而還會同時讓具
Loosely-coupled 架構，以訊息為導向的應用蓬勃發展。
因此就可以理解，這兩者是用來解決不同的資訊應用問題，彼此無法相互取代，卻同時可因著分散式網路架構大潮流的確認，而取得充分的滋養空間。
我們已經知道，格式不管、大小不管，iPush®
Server 都可以幫客戶端傳遞即時訊息，這就是 Rich Content, Simple Messaging「以簡御繁」的真正意含。
但當一個 IT consultant 在架構規劃一個即時訊息應用系統時，一定要了解，或多或少，都會在
Rich Content 與 Simple Messaging 之間，存在一條溝渠，若不適當地搭起其中的橋樑，可能就會建構出一個鱉腳的應用。
我們在電子報第
4 期：你一秒幾次？中曾經提及，針對每一個單一訊息，若都能分析出下列
13 項標的，那即時訊息應用的導入，就可算成功了一半：
-
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：客戶端軟體的執行環境平台支援
這就是要串通 Rich Content 與 Simple Messaging
間，一件重要的 Gap Analysis 作業，且側重訊息技術分析面。
IT 新技術的浪潮一波接一波，不曾稍歇，也不會稍歇。有時候，一個 IT 的名詞
(term)，可能在不同的技術，或是不同的層面上，講的是不同的事情，具有不同的意義。
我們以下表為例：
| |
Synchronous |
Asynchronous |
Publish
/ Subscribe |
System
coupling |
| XML 文件交換 |
V* |
|
|
Tightly-coupled |
Web Services
服務架構 |
V* |
V* |
|
Tightly-coupled ~
Intermediately-coupled |
Real-time Messaging
(即時訊息傳遞) |
V^ |
V^ |
V |
Loosely-coupled |
同樣是 "Synchronous" 或 "Asynchronous"，但其實
XML 文件交換、Web Services 服務架構即與 Real-time Messaging (即時訊息傳遞)
所講的層面有所不同。前者 (V*) 屬連線層面 (connection level)，看是在一個連線期間
(Synchronous，同步作業) 還是多個連線期間 (Asynchronous，非同步作業)，完成
Request-and-Reply 的作業；而後者 (V^) 則屬程式設計模式層面 (programming
level)，說的是透過程式設計， 使用 Publish / Subscribe 訊息傳遞模式，達成以訊息事件觸發程序的非同步作業。
所以，如果不仰賴實事求是的精神去慎思明辨，那麼一句：「Web Services
與訊息中介軟體一樣，都可以達到非同步作業」，就要露餡囉！
像這樣的整合應用分析，也是串通 Rich Content 與 Simple Messaging
間，一件重要的 Gap Analysis 作業，側重的是 IT 多重技術分析面。
除非是全自動的系統，不然應該會有實際應用的使用者存在。而人的感受與問題，才是關乎一個應用系統成功與否的關鍵。
我們說 IT consultant 右手握著軟體平台，左手伸入產業，眼睛觀察案主目前的作業流程，口中振振討論著專案的需求。但如果這些需求，沒有關聯到使用者身上的話，那就永遠沒有辦法獲得真正的滿足。
不管是全新打造的系統，還是汰舊換新的系統，會被使用者拿來比較的基準，一定就是現在的作業情況。
有一位在艾揚的商務夥伴公司任職的軟體工程師告訴我，當他授命進駐到某個客戶那裡去進行一件與勤務系統相關的專案時，一開始當然找了很多現場的作業人員來進行需求訪談，然後依序進行系統分析、設計、撰寫的工作，一切似乎都很順利。但當他將第一版的軟體交給現場的作業人員使用時，各種意見旋即蜂擁而至，跟當初需求訪談的結果有甚大差異。
是的，原因就出在這位盡職的軟體工程師也是第一次接觸到這樣的勤務作業專案。所以很多自己想當然爾的分析與設計，導致與使用者訪談時的互動期待有所落差。
儘管這個專案過程有意外的插曲，但最終還是獲得圓滿的收場。這位軟體工程師很有成就感地對我說：「我們因為了解使用者而成長！」
相較之下，也許您早經過嚴格的鍛鍊，深知所屬領域的專業知識，能夠明確掌握 End-user
操作介面的需求要素，而不只是功能性的滿足。在此層面上，Consultant 要做到的，是要如何適當地將
Rich Content 鋪陳表示在 User Interface 上，發揚即時訊息應用最人性化的一面。這是另一種的
Gap Analysis。
| Rich
Content, Simple Messaging 結論 |
一晃眼，我們 Rich Content, Simple Messaging 此一套式主題的相關文章，至今已經累積了十篇又一，而本顧問篇即為我們的告別之作。
題材範圍含括了金融、水資源管理、C4ISR 國防戰術情資 、與影像即時監控，形式則兼及了立論、應用、實作、專訪、與顧問。一直以來，我們擺明了就是企圖要拉近一個即時訊息技術軟體平台與產業應用的距離，也努力進行各種的嘗試，以協助
Developer 釐清使用這個技術的現在需求性與未來發展性。
我們可以這樣肯定的說：即時訊息技術，會持續地為
Rich Content, Simple Messaging 「以簡御繁」的目標服務。
Developer 們，一起來吧
|
