[訊息論壇] ICE Messaging Forum 蔣居裕
<總論> Rich
Content, Simple Messaging
Rich Content, Simple Messaging，若按照字面直接翻譯，應該是「豐富的內容，簡單的傳訊」。而其真正的精神，即在「以簡御繁」。
是的，在資訊科技的世界中，「以簡御繁」的例子所在多有，如：簡單的兩個 '0' 與
'1'，構築出氣象萬千的數位宇宙；千千萬萬種檔案的類型，都變化源於 Text 與 Binary 這兩種基本格式；HTTP、FTP、Telnet、SMTP、POP3、NNTP、Gopher......
等應用層的通訊協定，都建構在 TCP、UDP 之上；而 TCP、UDP，又都根基於
IP 通訊協定。
以本篇為首的套式主題 ─ Rich Content, Simple Messaging，就是要闡釋相同的「以簡御繁」精神，一樣潛藏在以訊息中介軟體為中心的即時訊息應用系統中。而本篇，將為讀者說明這個主題所涵括的範圍。
現在就上路。
iPush® Server 有七大特色：
其中通用，指的是不管為哪一種資訊格式， iPush® Server
都可以幫您傳遞。這種與訊息格式無關的通用特性，我們又可以稱之為 Content-independent。
Content-independent 是 iPush® Server 的一個重要設計理念，即現在或未來，將各種不同的資訊加入此一訊息平台的強大延伸性。這對於資訊屬性變化多端的
Internet 服務，或是不斷面臨各種資訊管理挑戰的 Intranet 來說，均是一項很重要的特性。
傳統的 < 資訊來源 > ─ < 傳送機制 > ─ < 接收端 >，是一套、一套各自獨立的系統，但訊息中介軟體所帶來的傳訊革命，是要達到：
< n 種資訊來源 > ─ < 通用傳送機制 > ─ < m
種接收端 >
讓一套共用的傳送機制，可以將現在或未來不可預知的 n 種資訊來源，傳送給現在或未來不可預知的 m 種接收軟體或設備，以降低網路服務或企業在訊息資訊系統上的建置與維護成本。
於連通現在或未來不可預知的 m 種接收軟體或設備此事，即所謂的 Accessibility
(存取性) 上，必須要考量通用傳送機制是否至少對主流的客戶端平台均有支援。以 iPush® Server
來做為通用傳送機制，其多樣化的 API 種類，絕對可以滿足 High Accessibility 的要求。
讓我們回到訊息平台的通用特性來。
如 iPush® Server 這樣的訊息平台，其能夠傳送的訊息種類，只有一個限制：必須是要能夠被封裝在
IP 通訊封包中的數位資訊。
所以不管是純文字資料 (Plain Text)，還是二進位資料 (Binary)，只要它能夠以檔案 (File)、字串 (String)、或位元串
(Ticker) 的型態存在，就可以透過通用的訊息平台來遞送。
另外，即時訊息的通用傳遞考量，還有一大要素，就是訊息的大小 (Size)。
我們曾經說過，無論訊息(或檔案)是 100KB，還是 10MB，發送端的 API，會自動為訊息進行切割、傳送；然後再由訂閱接收端的
API，自動重組還原該訊息。所以，對於 Developer 來說，除了叫用專門處理 Block 訊息的函式外，對於大型訊息(或檔案)
的收發處理流程，並不會與短小的訊息有所不同，都是同樣地直覺與容易。
註一：詳情請參見第
10 期：與 Developer 息息相關的 iPush API (上)
我們整理一下可以透過 iPush® Server 遞送的資訊格式以及存取介質
(意指資訊的儲存場所，或是資訊流通的介面) 成下表：
| 資訊格式 |
存取介質 |
舉例 |
| 文字檔 |
檔案系統 |
.txt, .ini, .csv, .java, .html, .pl, .jsp, .asp |
| 二進位檔 |
檔案系統 |
.exe, .com, .class, .ocx,
.doc, .xls, .ppt, .jpg, .gif, .bmp,
.wav, .avi, .mp3, .jar, .pdf, .mdb |
| 字串 |
程式碼
使用者輸入 |
"Hello World!", "0xAB3372B3CFD9"
純文字串、十六進位元串、或二進位元串 |
| 位元串 |
COM port
Ethernet |
"Hello World!"
純文字串或二進位元串 |
| 資料表欄位 |
資料庫 |
包含 DBMS 所有的欄位資料型態 |
其中，要讓位元串與資料表欄位資訊透過訊息平台傳遞，通常必須有一個居中的資訊轉送或處理機制，如：
-
來自證券交易所的 COM port (序列埠) 金融即時行情位元串，可以透過解析資訊格式的
Preprocessor 前置處理後，再餵入 iPush® Server。
-
來自資料庫資料表欄位的資訊，可以透過 DBMS 的 Trigger /
Stored Procedure 功能，結合 iPush® Client API，寫成一個當資料表欄位資料有異動時，即可主動發送即時資訊至
iPush® Server 的機制。
稍後，我們會再來詳談 Trigger / Stored Procedure 這部分。
iPush® Server vs. Video/Audio Streaming
很多人都對 iPush® Server
是否能夠進行多媒體影音串流 (Video/Audio Streaming) 感到興趣。剛好趁此一隅，做一說明。
我們的看法是，因為影音串流在運作時，伺服端與客戶端必須進行動態的
Handshaking，視連線當時的頻寬、以及可能改變的傳輸狀況，隨時調整串流資料的傳送速度，同時又要盡可能地兼顧影像的可觀賞度與聲音的聆聽清晰度。
影響所及，同一時間內，即使想要接收的是相同的影音內容
(如一場 Live 演唱會)，但因每一個客戶端與影音串流伺服器間的協定互異，且會動態改變，所以在資訊內容的提供上，會造成準備上的困難度增加，不容易善用到
iPush® Server
對同一份資訊具大量即時傳送的能力。
不過話說回來，如果您想要建立的，是一個「非典型的多媒體影音串流系統」，那還是可以在清楚
iPush® Server
特性的情況下，利用 Channel 來規劃影音串流伺服器
(一般即稱 Media Server) 與影音串流客戶端 (一般即稱 Player) 間 Handshaking
的通訊協定 (即控制信號)，然後再視適當與否，看是否連影音訊息內容，都透過 iPush® Server
來傳送。
|
| High Accessibility vs. Rich
Content, Simple Messaging |
格式不管、大小不管，iPush® Server 都可以幫客戶端傳遞即時訊息，這就是
Rich Content, Simple Messaging「以簡御繁」的真正意含。
所以，Rich Content, Simple Messaging 實際的應用方向，當然沒有限制。不過在我們為文說明時，自然不能任憑讀者的思緒狂奔至無邊無際，必須實際舉出例子來，以昭公信。
如果讀者曾經造訪過艾揚科技的網站，就知道我們在 ICE Developer Center 裡頭，闢有 On-line Workshop
一區 (http://www.icetech.com.tw/icedc/workshop.shtml)，現在內有屬於
ITS (智慧型運輸系統) 與 e-Automation (工業自動化) 兩個產業範疇的線上展示 (Demonstrations)
與實作步驟 (How-to: Step by step)。
我們歸納一下其中應用可以傳送的資料格式成下表：
請注意以上灰底的第二列，同樣是傳送壓力、溫度等文字串之即時資料，但卻可同時送達在多樣化的客戶端與資訊設備上，善用各種使用者介面的特性，用相同一份資料來做不同的呈現，如：
-
直接顯示收到的文字、數值資料。
-
用收到的數值資料進行最高點、最低點的紀錄與警示
(Record & Alarm)。
-
用收到的數值資料進行趨勢圖的描繪 (Chart)。
-
用收到的數值資料在 Excel 裡做更多統計圖表的即時展現 (Chart)。
-
以上應用可從一般的 PC、NB 延伸至 Java 手機或 Pocket
PC。
這可不是設計 On-line Workshop 的艾揚同仁偷懶，而就是 High
Accessibility (高存取性) 與 Rich Content,
Simple Messaging 結合的明顯好處。結合起來的應用目標，即能達到：「一個訊息，同一時間，可以傳送給不同設備、不同使用者的不同加值應用接收」。
除上述 ITS 與 e-Automation 之外，現在還有許多的產業，正紮紮實實地在使用訊息中介軟體，享受 Rich Content,
Simple Messaging 所帶來的好處，如：
-
金融服務業：利用訊息中介軟體來傳送即時行情、即時新聞、投顧通報、下單交易、交易回報、風險管控、營業資訊等訊息。
-
線上遊戲業：利用訊息中介軟體來做為眾遊戲伺服器間 (Inter-server)，以及遊戲伺服器與遊戲客戶端
(Server-client) 的即時互動橋樑。另外，像是遊戲大廳 (Game Lobby)、社群媒合 (Matching)、聊天
(Chatting) 等附屬的互動服務，也很適合用如 iPush® Server
這樣的軟體來開發。
-
電子製造業：在生產製造的 MES / CIM 資訊系統中，搭配訊息中介軟體，改造出具
Loosely-coupled、Content-independent、High Accessibility 特性的新世代架構，在
HMI (Human-Machine Interface) 上能有更豐富的呈現，甚至可進一步做到「機隨人走」的行動化 HMI。
| Database
vs. Rich Content, Simple Messaging |
我們曾經說過，Database 與 MOM (訊息中介軟體) 天生的任務目標不同。Database 是資訊的留存所，重點是資訊的庫存管理；MOM
是資訊的流通管道，重點是要做到訊暢其流。
註二：詳情請參見第
4 期：你一秒幾次？
既然目標不同，那 Database 可否與 MOM 攜手，共同打造一個能靜能動的資訊系統呢？
答案是肯定的。艾揚的 PS 技術服務團隊，早已經自行，或與商務夥伴攜手，在許多案例中，充分地驗證了這一點。
這些實例驗證的需求，起因不外有兩：
在任一種情況下，由於對 Database 的 Request-and-Reply 存取為 Synchronization (同步作業)，DBMS
為消化同時湧入的服務要求，必須持續執行大量的運算，造成 CPU 負載過重。更可怕是，若服務要求的湧入不曾稍歇，終將導致 DBMS
停止運轉。
那我們的解決之道是甚麼呢？與上對應，分別是：
|
|
|
| |
|
| 圖例
1. 使用訊息中介軟體來為大量即時資訊，同時湧入 Database 進行典範的轉移。重點在簡化 Database
的 Connection 數量。 |
圖例
2. 使用訊息中介軟體來為大量同時對 Database 進行 Request-and-Reply 服務要求進行典範的轉移。重點在讓
Database 化被動為主動。 |
前者之所以能夠改善大量資訊同時湧進 Database 的擁塞現象，即是其在架構上有所不同。有了訊息中介軟體居中，讓大量即時資訊來源與
Database 分離，從 Tightly-coupled 變成了 Loosely-coupled，再藉由 DB Agent 的轉介與緩衝，讓原本的繁重的
N-to-1 Database connection 轉變成單純的 1-to-1 Database connection。
而後者，除了也是轉變成 Loosely-coupled 架構外，更是在資訊流上起了根本的變化。原本客戶端對 Database 資訊存取是
Pulling 式的 Request-and-Reply，現在即改為運用 DBMS 具有的 Trigger / Stored Procedure
能力，透過呼叫加掛的 DB Agent (其就是一個活脫的 iPush® Client)，當
Database 有事先設定的事件發生時，即啟動運算，然後將結果餵入 iPush® Server，再由
iPush® Server 推播給有訂閱的客戶端。這一串下來，資訊流已經改為 Push 的傳送方式，更加地即時而不做虛功。
不管是將資訊送入 Database，還是從 Database 將資訊撈出來，資訊進出之間，都必須要能符合
Database-Table 的欄位資料型別。以 MS SQL Server 這個 DBMS 為例，就包含有 BINARY、CHAR、DATA&TIME、DECIMAL、INT、BIT、TEXT、MONEY、TIMESTAMP、IMAGE
等欄位資料型別，而屬於這些資料型別的即時資訊，都可透過如 iPush® Server
這樣的訊息中介軟體收發。
這又是一個典型的 Rich Content, Simple Messaging
應用實例，且因為各行各業都用得到 Database，所以適用性更廣，沒有產業上的區別。
在本篇總論中，我們已經透過下列諸面向，詳細說明了 Rich Content, Simple Messaging「豐富的內容，簡單的傳訊」的內涵：
|
