本期內容大綱

• <編輯手札> ─ 越來越成熟 

• <訊息論壇> ─ 新世代訊息技術深度剖析 – 細說 iPush Server V2 (上)

• <訊息先生信箱> ─ 舊版 API 與 AP 對於 iPush Server V2 的相容性問題

• <艾揚快訊> ─ 艾揚科技 2004 年教育訓練課程表正式公佈，歡迎儘早報名 (01.12)

越來越成熟

iPush^® Server V2 在 2003 年底誕生，即將在 2004 年大展身手了！

基於相信「未來的資訊將會在網際網路上自由流動」的信念，艾揚發展出 iPush^® Server，以 Publish/Subscribe 讓各種訊息可以即時互通。在過去幾年當中，我們在金融資訊、線上遊戲、電子製造、工業控制、國防、GIS、與其他對於即時訊息交換有關鍵需求的產業，成功地以 iPush^® Server V1 與 V1.5 提供新的價值。

從主觀上而言，iPush^® Server 做為純粹的訊息傳遞中介軟體，本身僅具備即時訊息的意義，但在客觀上，當我們與各種產業應用結合起來，新的實用價值便不斷浮現，這些除了艾揚本身的努力之外，我們要感謝許多技術與商務夥伴發現即時訊息的使用需求，並且與艾揚攜手與時俱進，共同創造出即時訊息的應用價值。

iPush^® Server V2 的發展與過去艾揚在各種專業領域上的應用息息相關。在特定的應用條件下，我們發現訊息不僅僅需要傳送即時化，還必須具備「持續傳遞、保證送達」的性質；透過網際網路的環境傳遞雖然方便，但是加解密的技術必須更加嚴謹；各種訊息傳遞的存續時間、訊息傳遞層級、優先順序還要能夠更進一步詳細區分。以上種種都是我們在過去幾年當中學習到的寶貴經驗。在 iPush^® Server V2 當中，我們針對這些實際應用上發現的需求，對產業界提出正面的回應。

在農曆年過後開始的新主題，編輯群將逐步為 Developer 們解說 iPush^® Server V2 新增的各種技術特色，希望藉此收拋磚引玉之效，讓大家一起發現 V2 所能開創的新應用價值。如果您有任何疑問或新的創見，也歡迎使用 Mr. Message 訊息先生信箱，讓編輯群為您提供諮詢服務。

在去年年底，艾揚正式推出了新一代的 iPush^® Server V2。除了傳承 iPush^® Server V1.x 以來，一貫的 Publish/Subscribe 即時訊息鉅量連線服務能力之外，在訊息核心引擎中，又添加了許多新的功能特性，我們將會分兩期，與讀者細說分明。

總的來說，iPush^® Server V2 此新一代產品的目標，是在既有的鉅量連線能力基礎之上，追求更高品質的訊息傳遞功能，讓 Developer 可以善用新增的各種訊息性能，更細緻地規劃各類的訊息應用系統。

回應訊息技術的運作原理，我們繪出這一張 iPush^® V2 訊息通訊層級基本圖：

　

圖一、iPush® V2 訊息通訊層級基本圖

文字顏色說明

紫紅：為 iPush^® V2 新增之特性功能。
藍色：為 iPush^® V1.x 已有之特性功能，但 V2 又加以修改延伸。
黑色：為 iPush^® V1.x、V2 所共同擁有之特性功能。

若您在未閱讀下面詳細說明之前，就能夠對上圖有一定的了解，那就表示您的訊息技術知識，已經累積到某種程度了喔！

以下就讓我們由下而上，針對基本圖來層層細說。而每一個下層的說明，都是在為其上層打下知識的基礎。

適用訊息傳遞模式：Pub/Sub 與 P2P

iPush^® 的通訊基礎是 IP (Internet Protocol)，在 IP 之上，除了原先 iPush^® V1.x 即支援的 TCP 之外，iPush^® V2 又新增了 UDP 通訊協定來讓 Developer 選用。

關於 TCP 與 UDP 的不同通訊特性，我們不在此多做解釋，有興趣知道的，可以參考電子週報第 19 期的訊息技術說文解字：TCP / UDP。

Developer (或 AP) 選擇要使用 TCP 或是 UDP 的時機，是在 Client AP 要與 iPush^® Server 建立連線時。在 ActiveX 與 Java Class API 上，使用 TCP 或是 UDP，都有一樣的函式名稱：

• ipushTCPConnect()：建立 TCP 連線。

• ipushUDPConnect()：建立 UDP 連線。

一旦連線建立之後，該 TCP 或 UDP 的有效性會一直持續，直到呼叫 ipushDisconnect() 中斷連線為止。

在一般情況下，我們建議您儘量使用 TCP 來進行連線。

在一個 TCP 或 UDP 連線期間，Developer 可以隨時視需要，啟用 Pub/Sub 或是 P2P 模式，來傳遞一個特定訊息。

我們就花一點篇幅來說明 Pub/Sub 與 P2P 的不同意含。

<Pub/Sub 訊息傳遞模式>

適用訊息定址方式：Channel Addressing 與 Subject Addressing

在以 iPush^® Server 為核心的 Pub/Sub 訊息傳遞模式 (全名為 Publish/Subscribe；我們認為，這是比較重要的一種傳遞模式) 中，訊息傳送者 (Sender) 被稱為 Publisher，訊息接收者 (Receiver) 則被稱為 Subscriber。

使用 Pub/Sub，非常輕易就可以實作出各種的一對多 (1-to-n) 的即時訊息應用系統。如下圖二所示：

圖二、Pub/Sub 一對多訊息傳遞模式示意圖

• Pub/Sub 可以使用 Channel 或 Subject 來進行訊息定址 (Message Addressing)。

• Publisher 與 Subscriber，是以單一訊息的觀點來切分。也就是說，當一個 Client AP 與 iPush^® Server 建立連線的期間，它可能同時兼具 Publisher 與 Subscriber 兩種身分 (即雙向收發訊息)。

我們以圖二的三動，配合 API 來說明 (ActiveX 與 Java Class 皆適用)：

1. Subscribe Channel / Subject

On-line Subscribers 需先向 iPush^® Server 訂閱 (Subscribe) 有興趣的訊息頻道 (Channel) 或主題 (Subject)；iPush^® Server 會負責紀錄所有 On-line Subscribers 的 Channel/Subject 訂閱資料 (Subscription Mapping，即哪些 Subscribers 訂閱了哪些 Channel/Subject)。

API 呼叫可為：

• ipushSubChannel()：訂閱 Channel。

• ipushSubSubject()：訂閱 Subject。

• ipushSubDSubject()：持久性訂閱 Subject (Durable Subscription；容後文說明)。

2. Publish Message

On-line Publisher 將訊息依規劃送至 iPush^® Server 的特定 Channel/Subject。

API 呼叫可為：

• ipushSendChannelData()：送訊息給指定的 Channel。

• ipushSendNPSubjectData()：送非持續性 (Non-persistent) 訊息給指定的 Subject (Non-persistent Message；容後文說明)。

• ipushSendPSubjectData()：送持續性 (Persistent) 訊息給指定的 Subject (Persistent Message；容後文說明)。

3. Push Message

iPush^® Server 即會根據 Subscription Mapping，將訊息即時推播給這些對應的 On-line Subscribers，即使有多個。而 Client 端在收到訊息之後，即會由 Client API 觸發各類對應的：

• Event：ActiveX API

• Interface 與 Exception：Java Class API 

交由 Client AP 去接手後續的訊息處理邏輯，進而達到事件觸發 (Event-driven) 的即時系統目標。

<P2P 訊息傳遞模式>

適用訊息定址方式：Subject Addressing

iPush^® Server 的另一種訊息傳遞模式，稱之為 Point-to-Point (簡稱為 P2P)；而由於其運作最重要的標的為 Message Queue，所以又可稱為 Queuing。

相對於 Pub/Sub 的一對多訊息傳送，P2P 可以達到點對點，即一對一 (1-to-1) 的訊息傳送。

如前所提，P2P 的運作，乃是透過 Queue 達成的；被 Sender 指定為 Queue 的訊息，只會被 iPush^® Server 傳送給一個 Receiver。也就是說，即使有多個訊息使用者都去訂閱同一個 Subject，但最終只會有一個訊息使用者接收到該則 Queue 的訊息。如下圖三所示：

圖三、P2P 一對一訊息傳遞模式示意圖

• P2P 只可以使用 Subject 來進行訊息定址。

• 在 P2P 模式下，iPush^® Server 會以 Round-robin 原則，依次循環傳遞同一個 Subject 的不同訊息給當時在線上的 Subscribers。

我們以圖三的三動，配合 API 來說明 (ActiveX 與 Java Class 皆適用)：

1. Subscribe Subject

On-line Subscriber 需先向 iPush^® Server 訂閱 (Subscribe) 有興趣的主題 (Subject)；iPush^® Server 會負責紀錄所有 On-line Subscribers 的 Subject 訂閱資料 (Subscription Mapping，即哪些 Subscribers 訂閱了哪些 Subject)。

API 呼叫可為：

• ipushSubSubject()：訂閱 Subject。

• ipushSubDSubject()：持久性訂閱 Subject (Durable Subscription；容後文說明)。

2. Publish Message

On-line Publisher 將訊息依規劃送至 iPush^® Server 的特定 Subject。

API 呼叫可為：

• ipushSendNPQueueSubjectData()：指定這是一個屬於 P2P 的非持續性 (Non-persistent) 訊息，並將之送給指定的 Subject。

• ipushSendPQueueSubjectData()：指定這是一個屬於 P2P 的持續性 (Persistent) 訊息，並將之送給指定的 Subject。

3. Push Message

iPush^® Server 即會根據 Subscription Mapping，將訊息即時推播給這些 On-line Subscribers 其中的一個。而該 Client 端在收到訊息之後，即會由 Client API 觸發對應的：

• Event：ActiveX API

• Interface 與 Exception：Java Class API 

交由 Client AP 去接手後續的訊息處理邏輯，進而達到事件觸發 (Event-driven) 的即時系統目標。

由以上之說明，針對 Subject 之訊息傳遞，以 Subscriber、Publisher、iPush^® Server 三個角色對訊息模式之處理，可分別歸結如下：

對於 Subscriber 而言

• 他只依 Subject 來進行訂閱，所以從 iPush^® Server 收到的，可能是一個 Pub/Sub 訊息，也有可能是一個 P2P 訊息。若是 Pub/Sub 訊息，則可能有其他的 Subscribers 也會收到；若是  P2P 訊息，則只有他會收到該訊息。

對於 Publisher 而言

• 在他要將訊息送給 iPush^® Server 時，才決定要用 Pub/Sub 還是 P2P (Queue) 專屬的 API 函式來進行傳遞，進而被 iPush^® Server 視為一個 Pub/Sub 訊息或是 P2P 訊息來處理。

對於 iPush^® Server 而言

• 若是 Pub/Sub 訊息，則 iPush^® Server 會送給所有的 On-line Subscribers 接收；若是  P2P 訊息，則 iPush^® Server 只會在 On-line Subscribers 中挑一個接收者傳送。

Channel 訊息安全保護：Packing
Subject 訊息安全保護：Scrambling

甚麼是訊息定址方式 (Message Addressing)？

訊息定址就好像是郵政信箱號碼一般：寄信的人，朝某個已知的郵政信箱號碼 (如 Post Box 100, Taipei) 送信；而收信的人，則是到該郵政信箱，就可以拿到屬於他的信了。

相同的道理，發訊息的人，只要朝某個已知的訊息位址 (如 abcd, 或 ice.marketing.fred) 送訊息給 iPush^® Server；則該訊息位址的訂閱者，就能夠即時地收到該訊息了。

在 iPush^® Server V2 中，有兩種給定訊息位址的方式，一為 Channel ID，一為 Subject Name，即分別稱為 Channel Addressing 與 Subject Addressing。以下我們就來看看這兩者的定義規則。

<Channel ID>

一個 Channel ID，則是由 4-Byte 來表示，它可以由 4 個 ASCII 字元所組成，也可以是 8 個 16 進位碼 (HEX) 來表示的 4 個字元組。例如：1234 與 0x31323334 表示的即是同一個 Channel。

字元 0x00 與 0x0a，不得做為 Channel ID 的任一字元；保留 ASCII 字元 x，不得做為 Channel ID 之首。

若 Channel ID 單獨定義為 '-'，即表示沒有權限。例如將 Write Permission 設定成 '-'，即表示該使用者沒有權限將訊息發送至任何 Channel。

在 Channel ID 的四個字元中，具有階層式的概念。如 abc 表示所有以 abc 開頭的 Channels。 當要定義的權限包含有多個 Channels 時，可以逗號 ',' 區隔即可。若是連續的 Channels，如 abcd,abce,abcf 則也可以使用 '-' 特殊字元作連接表示，如 abcd-f。

<Subject Name>

一個 Subject Name 則是一段較易為人所理解的字串，例如 ICE.testing.subject，最大可接受長度為 224 字元。Subjects 同樣有階層的概念，並以 '.' 字元作為階層區隔字元，如 ICE.A 表示所有以 ICE.A. 開頭的 Subjects。

• 禁用字元：共有 9 個禁用的字元，'*'、'%'、','、'.'、space、tab、0x0D、0x0A、與 0x00 (此處是指在一個對定義者來說有意義的連續字串中，不允許出現這些字元)。

• 不建議使用字元：'-' 與其他非英文字元。

• 不像 iPush^® Server V1.5 – Subject Edition，在 iPush^® Server V2 BackOffice 中的 Subject Name，已經不須在前面加寫 %T 了。

• 以整體應用規劃而言，在 Pub/Sub 模式下，到底一個字串是 Channel ID 還是 Subject Name？將交給 Developer 選用的是 Channel 還是 Subject 相關函式呼叫來決定，如 ipushSendChannelData() 或是 ipushSendNPSubjectData()；至於其有效性與正確性，則是交由 iPush^® Server 中的 Channel Management 與 Subject Management 來決定。

若單獨定義 '*' 則表示為所有的 Subjects。

<舉例>

• Abcd,* ：表示 Channel Abcd 與所有的 Subjects。

• 0x01-0xff,ICE.A ：表示第一個字元介於 0x01 至 0xff 間所有的 Channel， 以及以 ICE.A 開頭的 Subjects。

好，暫且打住，我們下期繼續向上發展。

[訊息先生信箱] Ask Mr. Message    Mr. Message  

<Developer Sam 來信詢問>

我們公司已經使用 iPush^® Server V1.5 SE 開發了一些應用程式，現在聽說艾揚新一代的 iPush^® Server V2 已經推出，那我先前使用 V1.5 SE API 開發的應用程式，能不能將伺服器直接改換成 iPush^® Server V2，但原應用程式還可以繼續使用 ？

<Mr. Message 的答覆>

從 Server 的角度來看，從 iPush^® Server V1.5 SE 到 iPush^® Server V2，值得關注的 API 變與不變項目有：

• Channel 的運作方式不變。

• Subject 的運作方式改變了，包含加密的方式、增加多種屬性。

影響所及，結論是：

• 若您既有 AP 只用到 V1.5 SE API 裡的 Channel 函式呼叫，完全沒有 Subject 者，那使用既有 AP + V1.5 SE API，不必任何修改，是可以直接連接 iPush^® Server V2 的。

• 若您既有 AP 有用到 V1.5 SE API 裡的 Subject 函式呼叫，則一定要搭配 V2 API 的規格來修改 AP，才能連接 iPush^® Server V2。

歡迎來函詢問 Mr. Message 任何與訊息有關的技術、產品、應用、實作、商務問題，Mr. Message 必將竭誠答覆。

<快訊 1>

艾揚科技 2004 年教育訓練課程表正式公佈，歡迎儘早報名 (01.12)

艾揚科技在 2003 年舉辦 iPush^® Server V2 應用實務課程，受到學員熱烈響應，不僅座無虛席，並接受到許多熱情的建議。在 2004 年，艾揚科技推出一系列教育訓練課程的計畫，針對不同需求的 Developer 規劃不同的訓練課程。

目前規劃之課程包括金融界資訊人員期待已久的 Financial Suite SDK Workshop、艾揚最受歡迎的 iPush Server V2 Basic Programming Workshop、為已接受過基礎訓練之學員量身訂做的 iPush Server V2 Advanced Programming Workshop。

課程詳細情形，請參考艾揚教育訓練網頁 >> Go !

上一期精采內容：讓資訊即時流動的趨勢提早實現：專訪艾揚科技 CTO 陳俊霖博士

若您覺得本期內容值得參考，請轉寄給認識的朋友或同事，為國內的訊息技術社群發展盡一份力。感謝您。　

回艾揚即時訊息技術電子週報主頁 | 上一期 | 下一期

Copyright 2002-2004, 艾揚科技股份有限公司版權所有；歡迎轉寄。 關於電子報發送有任何問題，或是欲轉載內容，請連絡 icedc@icetech.com.tw 台北市 100 羅斯福路二段 9 號 12 樓之 1 ，TEL: +886-2-2396-1880，FAX: +886-2-2396-1881

Unsubscribe >>
欲取消訂閱艾揚即時訊息技術電子週報 (ICE Messaging Weekly)，請 Mail 至 icedc@icetech.com.tw，
主旨註明：取消訂閱艾揚即時訊息技術電子週報 即可。