到目前為止，我們大多假設每個發佈的資料項帶有一個由 n 個（屬性, 值）對組成的向量，行程透過對這些屬性值指定述詞（predicates）來訂閱。這種命名方案一般都能直接套用，只是各系統在屬性型別、值、以及可用的述詞上有所差異：

• JavaSpaces 基本上只支援相等比較，雖然可以用應用程式特定的方式相對容易地擴充。
• 許多商業發佈／訂閱系統也只支援相當原始的字串比較運算子。

前面提過的一個問題是：許多情況下不能假設每個資料項都標好了所有屬性的值。特別是，當資料項只帶一個（屬性, 值）對時，它也被稱為事件（event）。對事件——尤其是複合事件（composite events）——訂閱的支援，大致主導了發佈／訂閱系統的命名議題討論；先前談的內容應視為支援協調的較原始手段。

處理複合事件時要考慮兩個不同的議題：

1. 如何描述組合——這些描述構成訂閱的基礎。
2. 如何收集（原始）事件並與訂閱比對。

Pietzuch et al. (2003) 為分散式系統中的事件組合提出了一個通用框架，以下以此框架為討論基礎。

描述複合事件#

先看幾個複合事件的例子，感受可能要應付的複雜度。以 R4.20 為一間有空調且受管制的電腦機房，訂閱可以由簡到繁：

• S1：單一狀態變化（可由一個原始的離散事件處理）。
• S2：兩個離散事件的簡單組合。
• S3：更複雜——要求系統還能回報與時間相關的事件。
• S4：涉及聚合值以計算梯度（gradients）。
• S5：計算平均值——此時系統必須被持續監控，才能及時送出通知。

分散式系統事件組合語言的基本構想是：讓訂閱能以原始事件的組合來表述。Pietzuch 等人的框架提供了一個相對簡單的語言，描述一種擴充型有限狀態機（finite-state machine, FSM）：擴充之處在於可以指定狀態的停留時間（sojourn times），以及產生新的（複合）事件。語言的精確細節不重要，重要的是訂閱可以被翻譯成 FSM。

以 S3 為例，其 FSM 的特別之處是一個計時狀態（timed state），標示「t = 10s」：若門在 10 秒內未上鎖，就轉移到最終狀態。

更複雜的訂閱也能描述。一個重要面向是：這些 FSM 常可分解為多個較小的、透過互傳事件溝通的 FSM——這種事件通訊通常會在接收方 FSM 觸發狀態轉移。例如：想在確定 R4.20 已無人且門已上鎖後 2 秒自動關燈，可以重用 S3 的 FSM，讓它產生一個事件給第二個負責觸發燈光的 FSM。

關鍵觀察是：這兩個 FSM 可以實作為分散式系統中各自獨立的行程。控制燈光的 FSM 訂閱「R4.20 無人且門已上鎖」這個複合事件即可。這就引出了分散式偵測器（distributed detectors）。

比對事件與訂閱#

考慮一個支援複合事件的發佈／訂閱系統：每個訂閱以可翻譯成 FSM 的運算式提供，狀態轉移基本上由發生的原始事件（如離開房間、上鎖）觸發。

• 樸素實作：每個訂閱者自己跑一個行程，實作其訂閱對應的 FSM。此時所有與該訂閱相關的原始事件都得轉發給訂閱者——通常很沒效率。
• 較好的做法：考慮訂閱的整體集合，把訂閱分解為互相溝通的 FSM，並讓其中一些 FSM 在不同訂閱之間共享（如前述關燈例子中的共享）。這種處理訂閱的方式產生所謂的分散式事件偵測器（distributed event detectors）。

事件偵測器的分散，本質上類似各種命名系統中名稱的分散式解析：原始事件在相對簡單的 FSM 中引發狀態轉移，進而觸發複合事件的產生；複合事件又可能在其他 FSM 引發狀態轉移，再產生更多事件。當然，事件會轉換成透過網路送給訂閱行程的訊息。

把訂閱拆成互相溝通的 FSM，除了透過共享來最佳化，還有最佳化網路使用的潛在優點：

• 以前述機房監控為例，假設只有行程對複合事件感興趣，那麼把事件組合放在靠近機房的地方是合理的——如此可避免把原始事件送過網路。
• 而且，只有在偵測到「房間無人 10 秒且門未上鎖」時才需要送出警報；比起（例如）門的上鎖／解鎖，這種事件一般少見得多。

把訂閱分解為分散式事件偵測器、再把偵測器最佳地佈署到分散式系統各處，仍是大量研究的課題。訂閱語言的定論未出，表達力與實作效率之間的取捨尤其受關注：語言的表達力越強，越不可能有高效的分散式實作。Demers et al. (2006) 與 Liu 與 Jacobsen (2004) 的提案都證實了這點。這些技術要應用到商業發佈／訂閱系統，還需要一些年。