2017-06-23 73 views
-1

我正在尋找一個符合以下情形的Java服務器技術:郵件路由基於規則

客戶端X發送消息 - >某些服務器組件決定的基礎上,例如某些規則if message from client X and content equals Y, forward message to Client Z (or a group of clients)

客戶端Z(或讀取該消息的組中的第一個)確認消息並採取進一步的(物理)操作。

消息應該可靠地發送到客戶端並記錄/存儲在某個地方,以便能夠回溯客戶端發送了什麼類型的消息以及客戶端是否確認了它。

有最大。 200個客戶端,每小時大約200-300個消息,因此性能/吞吐量不是那麼重要。

可能的技術:

  • 服務器:Java EE的(如Wildfly羣)或vert.x ...
  • 客戶端:Android平板電腦JavaScript的Web應用程序(網絡插座可用)
  • 存儲:MySQL,NoSQL,...

對我來說,看起來MQTT Broker可能適合在服務器端......您怎麼看?對我來說最大的問題是如何/在哪裏實現路由邏輯(if message from client X then forward to...)和日誌記錄/存儲。

回答

2

設置基於內容的路由類型會打敗MQTT所依賴的整個publisher-> broker-> subscriber模型,這讓我感到震驚。我的理解是,大多數MQTT經紀人都假定處理將發生在客戶端,而不是經紀人本身。我假設你可以實現它,但這將是我的(語言不可知的)建議。

  1. 客戶端X內部解析該消息,如果有內容Y,將其發送到話題A.

  2. 由於客戶ž知道,在主題進行的任何消息都有它想要的內容,客戶端ž訂閱話題A和接收內容Y.

如果該處理不被客戶端X來處理,你可以做這樣的事情,而不是一些絕對的要求:

  1. 客戶端X發送

  2. 客戶端A訂閱主題X郵件主題X.和解析消息尋找Y.

  3. 如果Y被發現客戶端A發佈的消息主題ž 。

  4. 客戶Z的訂閱話題Z和接收內容Y.

這種做法是有點笨重但它適合MQTT的邏輯和結構。

+0

淫蕩。這完全是我正在尋找的,有沒有準備好使用實現這種消息路由邏輯的解決方案? – WeSee