Subject Addressing
雖然 Subject Addressing 訊息定址方式 (相對於 Channel Addressing)，在先前的
iPush® Server V1.5 – Subject Edition 就已經被提出，但在
iPush® Server V2 中，我們賦予它更多的附加特性，如稍後會一一提到的：
- Subject Message Scrambling
- Point-to-Point (Queue) Messaging Model
- Store-and-Forward
- Persistent Message
- Durable Subscription
- Once-and-only-once
- Quality of Service (QoS)
- Time-To-Live (TTL)
- Connection ID
一個 Subject Name 是一段以 ‘.’ 連接，並較易為人所理解的字串，例如 ICE.testing.subject，最大可接受之總長度為
223 字元。
- 禁用字元：共有 9 個禁用的字元，’*’、’%’、’,’、’.’、space、tab、0x0D、0x0A、與
0x00 (此處是指在一個對定義者來說有意義的連續字串中，不允許出現這些字元)。
- 建議使用字元：’-’ 與其他非英文字元。
- 不像 iPush Server V1.5 – Subject Edition，在 iPush Server
V2 BackOffice 中的 Subject Name ，已經不須在前面加寫 %T。以整體應用規劃而言，到底一個字串是
Channel ID 還是 Subject Name ？將交給 Programmer 選用的是 Channel
還是 Subject 相關函式呼叫來決定；至於其有效性與正確性，則是交由 iPush Server 中的
Subject Management 功能來決定。
單獨定義 ‘*’ 則表示為所有的 Subjects。
Subjects 同樣有階層的概念，並以 ‘.’ 字元作為階層區隔字元。如 ICE.A 表示 ICE.A
以及所有以 ICE.A.開頭的Subjects，例如 ICE.A.B、ICE.A.Test 等。
Subject
Message Scrambling
Queue
for Point-to-Point
- Point-to-Point Messaging
Model 點對點訊息傳遞模式
可簡寫為 P2P 或 PTP。與 Publish/Subscribe (Pub/Sub，出版與訂閱)
同為訊息傳遞模式 (messaging model 或 messaging domain) 之一，其主要特性有以下幾點︰
- 訊息透過稱為佇列 (queue) 的虛擬通道來進行交換。佇列是訊息產生者送出訊息的目的地，也是訊息接收者收取訊息的來源地。
- 詢息在佇列內等待發送時，該訊息是可以被監控並可視情況由伺服器系統將其移除的。
- 一個訊息只能有一個接收者。許多接收者可以同時連到同一佇列，但是佇列中的每一個訊息，只能被送給其中一個接收者。
- 佇列中的訊息是有次序的。佇列傳遞訊息給接收者，必須依照訊息伺服器所安排的次序，越是排在佇列前面的訊息，會越早被接收走。
- iPush Server V2 中的 P2P 訊息傳遞模式，只支援 Subject Addressing，也就是說，Channel
Addressing 並無 P2P 的能力。
- Queue 佇列
Queue 其實就是 iPush Server V2 在訊息引擎內的P2P實作。通過訊息引擎佇列管道所發送出來的資料，只能由單一的接收者接收，而不像
Pub/Sub 的訊息，同一訊息可讓多人訂閱，各自接收一份；所以 Queue 適用在訊息的 1-to-1
傳遞。 另外，佇列中的訊息是有次序的，佇列傳送訊息給消費者，必須依照訊息伺服器所安排的次序，越是排在佇列前面的訊息會越早被接收走。
因此，使用 Pub/Sub 所傳送的訊息，通常是要滿足大量訂閱者對一相同資訊的需求性，如股票的即時行情報價。而
Queue 則是針對某一特定的訊息，要指派給單一的接收者進行處理，如線上購物的訂單。 雖說一家公司可能有一個訂單處理
(order process) 部門的多位業務人員在接收同一個 Order Queue，但一張訂單只需一位業務人員處理即可，並不需要一個以上的人員來同時處理，所以該訂單只會被一位業務人員接收去；至於何時該由何人來接收，則是公司內部的訂單接收處理規則，屬於商業邏輯的範疇，不在訊息技術討論之列。
Guaranteed
Delivery
Persistent Message / Durable Subscription / Store-and-Forward
/ Once-and-only-once
- Guaranteed Message
Delivery 訊息保證送達
當資訊經由 iPush Server 傳遞給各個接收端時，發送者所關心的一個重點，就是所發出去的資訊是否已被使用者接收，也就是要如何有效地得知該訊息發送的狀況；訊息保證送達的機制因而產生了。這項需求是為了能夠讓訊息經由
iPush Server 處理後，為 100% 的送達率提出保證。
而為實際達到此一保證目標， iPush Server 實作了包含 Persistent Message、Durable
Subscription、Store-and-Forward、以及 Once-and-only-once
等功能特性，以做為手段。
訊息保證送達的運作模式，是當 iPush Server 接收到訊息發送者所傳來的資訊後，即將它暫存起來，然後才告知發送者資訊已確定收到了
(Acknowledgement)；如此保證了訊息前段的傳遞 (此即 Persistent Publishing)。而後段的保證，是來自於接收者的回應；如果
iPush Server 沒有收到來自接收者的回應 (Acknowledgement)，則存於伺服器的訊息，將被再次發送出去，直至接收者確實收到為止
(此即 Durable Subscription)。
- Persistent Message
持續性訊息
在保障訊息確實被傳遞的方法中，只要是資料被標示了 “Persistent”，理論上這筆資料就一定會被送達。其運作的模式是應用程式開發界面
(API) 在傳送端將該訊息標注上 “Persistent” 的標頭 (Header)，當 iPush
Server 接收到含有 “Persistent” 標頭的訊息時，系統會將資料先儲存起來，然後向傳送端發出回應訊息以示收到；同時系統也將該資料傳送至訂閱接收端，並等待它的回覆，之後才將儲存的資料刪除。
在這傳遞過程中，如有任何意外發生 (如連線突然中斷，或是當機)，系統或傳送端皆不會收到回覆。於此同時，系統／程式會自動檢視訊息的表頭是否有含“Persistent”
的要求。如果是，系統或傳送端將此訊息再次發送出去，直至收到回覆訊息為止。 iPush Server
有了 “Persistent”，將使得訊息的傳遞更為穩健安全。
- Durable Subscription
持久性訂閱
持久性訂閱是訊息中介軟體 (MOM) 於訊息保證送達規範的其中一項特性。Durable Subscription
只可實施在 Subject Addressing Pub/Sub 訊息傳遞模式的應用上。 訂閱者在
Pub/Sub 的模式下，可針對某一特定的 Subject，選擇成為持久性的訂閱者。當 iPush
Server 在處理屬於該一特定 Subject 的訊息時，如果訂閱者處於離線的狀態，系統會自動查詢訊息的訂閱者是否為持久性的訂閱者。如果是，系統會將該訊息儲存起來，並等待下一次該訂閱者上線或恢復連線狀態，iPush
Server 再將此一訊息傳送給該訂閱者。有了這樣的機制，訂閱者將不會因為暫時離線的關係，而錯失接收訊息。
- Store-and-Forward 先儲存再傳遞
在前面提及的 Persistent Message (持續性訊息) 與 Guaranteed Message
Delivery (保證訊息傳達)。要達成這兩點訊息特性，iPush Server 就必須先執行 "先儲存再傳遞"
的動作。 無論是 Persistent Message 還是 Guaranteed Message
Delivery，訊息系統講求的是訊息在發送之後，要能保證不會因為任何原因遺失。所以 iPush Server
會先將從發送者傳來的訊息，先儲存起來，然後再送給接收者。iPush Server 在尚未收到接收者回應確認
(Acknowledgement) 的情況下，將會再次嘗試將該訊息發送出去，直至確認接收者收到為止，之後才會將儲存在系統中的訊息刪除。
- Once-and-only-once 一次且唯一性傳遞
有了這個 Store-and-Forward Messaging (訊息留存後轉送)的特性，在使用者斷線、伺服器終止服務等異常情況下，
iPush Server 還是會將留存的持續性訊息，在使用者恢復連線後，傳送給他們。並且在使用者程式不結束的情況下，達成
Once-and-only-once 訊息傳送的唯一性。 也就是說，Once-and-only-once
保證一個 Persistent Message 只會送給 Durable Subscriber 一次。這個特性可避免訂閱者重複接收到同一訊息，以致重複處理資訊。
Quality
of Service (QoS)
Message Priority
- Message Priority 訊息優先順序
其實這個機制與上面所提到的 QoS 非常相似，也是為每一筆訊息標示它的優先等級，Priority
等級越高者，訊息伺服器將優先處理和發送。
為什麼會有兩個類似的機制存在於新一代的智慧型訊息伺服系統 iPush Server V2 中呢？它們不會起衝突嗎？
答案是這樣的：雖然 Message Priority 與 QoS 都被拿來定義一筆訊息的重要性，以做為伺服器優先處理的準則，但是這兩者作用的範圍不同。Message
Priority 容許訊息在待發區中插隊，而 QoS 則否。
當接收者的訊息待發區出現壅塞時，QoS 分級作業會先被執行。伺服系統接獲訊息排送任務時，會先檢查該訊息的
QoS 等級，等級較高的訊息會被排入訊息待發區中，如上所述。之後，系統會再依該訊息被標示的 Message
Priority 等級，越過待發區中 Priority 等級較低的訊息，將其排在同一 Priority
等級的最後。
綜合以上 Quality of Service 與 Message Priority 的運作，很重要的兩個觀念要再提醒的是：
- 如果說訊息接收者專屬的訊息待發區根本就收發順暢，完全沒有訊息排隊的情況出現，那麼，系統根本就不會也不必啟動
QoS 與 Message Priority 分級作業。
- 在實際應用時，每一個訊息的 QoS 等級與 Priority 等級，都是由訊息發送者指定的。也就是說，訊息發送者必須根據應用的性質，先行為每一個訊息決定當接收者的訊息待發區發生擁塞的狀況時，訊息伺服器該如何處理該訊息：是要捨棄，還是將另一個訊息取代掉；要不要讓它具有插隊的權力？賦予它插隊的權力等級是多高？而訊息伺服器，只不過是聽從這些等級指示做事罷了。
Time-To-Live
(TTL)
- Time-to-Live ( TTL
) 有效期限
在訊息傳遞的環境中，TTL 表示了訊息可以在系統內存活的時間。通常每一筆 Subject 訊息產生時都會有一個相對應的
Header (標頭)，Header 內記載各種資訊並分散在不同的欄位中，而該訊息的有效期限資訊，就寫在
TTL 的欄位內。
為什麼訊息為什麼一定要有存活期限？又為什麼訊息系統需要知道每一筆訊息的有效期限呢？
其實是這樣子的︰當訊息通過訊息 iPush Server 時，系統會將訊息儲存起來 (即以上 Store-and-Forward
所述之作業)，並等收到回應確認後，即將該訊息刪除。但是，如果系統永遠都無法接到回應確認，或是接收者根本就很長一段時間未上線時，訊息不就會一直停留在系統中了嗎。有鑑於此，TTL
就是被設計來讓系統判斷何時可將訊息刪除之用，而不需痴痴地等待接收者的回應確認了。
Connection
ID
As
a Service in Windows System
Messaging Kernel
