選擇一個消息傳遞解決方案

Question

所以我建立一個客戶端服務器應用程序，我必須選擇他們如何互相交談。我可以：

1. 具有客戶機和服務器之間建立TCP連接
2. 過使用TIBCO RV，EMS或IBM MQ REST或SOAP
3. 發送消息。 。

是否有矩陣可以顯示我在哪裏可以使用這些技術之一。性能，可靠性等方面的東西將會有所幫助。

Answer 1

如果您有純.NET到.NET應用程序，請轉到WCF。當談到TCP/IP時，它會讓你的生活變得簡單，但爲你的消息傳遞保留一個很好的面向對象設計層。它也使得它非常容易地單元測試你的消息代碼，這是我認爲最大的好處。

WCF將在本地機器上執行TCP/IP管道，並且它還支持許多基於HTTP的解決方案。在大多數情況下，您還可以免費獲得安全性，並且代碼會爲通信層執行很多錯誤處理。

如果您需要MQ解決方案，請盡情享受。支持MSMQ，但是它又是MSMQ。

使用其他解決方案將受益於更多功能，但功能帶來複雜性和風險。我個人將.Net應用程序與websphere MQ集成在一起，我對解決方案的成本和收益並不感到滿意。更不用說MQ在非P系列硬件上的性能至少沒有說明了。

Answer 2

在.NET上構建通信應用程序時，答案几乎總是WCF。 WCF確實

• SOAP - 包括WS- *
• REST - XML，JSON，其他
• 插座
• 管
• 的二進制格式
• 的Tibco RV
• IBM MQ
• MSMQ
• SAP
• 其它更多

WCF背後的想法是這樣的：這是一個普遍的通信框架，它映射着你希望使用任何通訊基板。這意味着編程模型是一致的，概念是一致的，並且操作/管理是一致的。如果您選擇WCF並且您想要記錄日誌，則無論您選擇哪種基底，它都以同樣的方式工作。而且，如果您選擇WCF，則可以在雙方當地時使用命名管道，並且在分發它們時切換到TCP。它不需要更改代碼，只需要更改配置。哪個可以很好。

至於選擇基材 - 那麼，這取決於你。取決於您需要的功能和功能，您的要求。

Answer 3

排隊還是不排隊？

你從你的郵件解決方案需要什麼？

1. 互通性？你需要能夠將你的解決方案暴露給其他應用程序嗎？然後，你需要去的格式和協議支持一個在那裏和的情況下，99％表示REST或SOAP
2. 可用性？即使在服務器關閉，無法使用或進行維護時，您的客戶端是否也需要發送消息，那麼您肯定需要排隊的解決方案（MSMQ，MQ，SSB）
3. 安全？客戶端和服務器是否需要跨信任域進行身份驗證？然後，您需要確保您的解決方案具有用於身份驗證的非基於域的故事（例如證書）。
4. 可靠性？如果客戶端崩潰，是否需要重新發送待處理的消息？再次，只有排隊的解決方案將在這裏幫助。
5. 相關？您是否需要按順序處理相關消息，您是否需要獨佔訪問相關消息，您是否需要發回回覆？並非所有解決方案都提供會話語義。
6. 可擴展性？你需要支持一個客戶還是一百萬？再次，只有排隊的解決方案將在一定的規模後發揮作用。
7. Spikes？您的流量是否會出現峯值，例如某些小時或數天的漲幅？必須規劃一個耦合的解決方案來接受它可能遇到的最高峯值，否則它將毫不客氣地拒絕客戶。如果您的硬件無法應對您的常規高峯，那麼您將不得不使用排隊的解決方案。

如果you like WCF那麼你會得到很多免費的。但基本上有兩種消息傳遞模式：排隊和不排隊。 WCF提供了一個巨大的可互換通道矩陣，綁定，格式，協議和身份驗證方法，可以通過簡單更改.config文件來切換和切換。但他們都是爲非排隊模式。如果你的解決方案對於一個耦合的通信通道是可以的，那麼對於CLR應用來說，目前可能沒有比WCF更好的了。如果你的要求強加了一個基於排隊的解決方案，那麼你將失去所有的可互換的綁定玩具，你可以利用WCF的序列化，也許你的服務的激活模型。

最後但並非最不重要的90％的任何消息解決方案發送的消息最終都在一個數據庫中，不少也是從數據庫來源。如果您希望與提供性能的SQL Server數據庫緊密集成，同時保證可靠的交付，請致電is a solution for that in SSB。