使用BizTalk代替NServiceBus或MassTransit的優點/缺點

Question

我很好奇它是否考慮使用BizTalk實現發佈/訂閱消息架構（基本上，您可以使用NServiceBus或MassTransit完成所需的工作）。我的經理傾向於堅持直接從微軟提供的框架，所以作爲我的盡職調查的一部分，我需要爲雙方提供一套良好的利弊。任何指導將不勝感激！

Answer 1

Biztalk是一家經紀商，更適合在不同商業服務範圍內的EAI。服務總線是根本不同的。比較可以在這裏找到：

http://docs.particular.net/nservicebus/architecture/nservicebus-and-biztalk

如果你能分享一些您的要求我也許能夠提供一些更多的指導。

Answer 2

我與Andreas就此 - BizTalk通常更適合'增值'集成和業務流程管理，而不是ESB類型的活動。的BizTalk擅長：

• BPEL
• 長時間運行/補償交易
• EAI
• 經紀/映射
• 協議改變（MQ到WCF，平面文件SAP等）
• EDI ，RFID

但是，已經努力使用BizTalk作爲服務總線，nota bly ESB Toolkit

Answer 3

經紀人的一個主要缺點是版本和升級非常困難。您將不得不停止消息流以升級特定端點。服務總線允許端點自治並獨立升級。

然後在規模上有所不同。對於經紀商來說，趨勢是將這些向上（垂直）的比例與爲擴大規模（水平）而構建的服務總線進行比較。您還必須通過某種HA設置（通常是集羣）使Broker高度可用。這與軟件的成本相結合可能會使成本過高。

NSB尤其會提供付費支持模式，因此如果您的經理在發生問題時不讓另一端的人遇到問題，您可以購買支持。

Answer 4

重要的是要注意BizTalk是企業應用程序集成（EAI的服務器產品 - 如Andreas所述）。它比框架更復雜，更復雜。

Microsoft確實可以在BizTalk中使用企業服務總線工具包，以便您可以將您的BizTalk環境稱爲您的ESB。他們認爲「ESB」可能不是您認爲ESB。你可以看看他們的ESB工具包頁面（http://msdn.microsoft.com/en-us/biztalk/dd876606.aspx），但它包含的東西，如：

• 動態（即在運行時）消息 轉型與翻譯。
• 消息路由可以是基於內容的，基於行程的或基於上下文的，並且在運行時確定。

當然，發佈 - 訂閱模式與使用服務總線不同。

BizTalk does做pub-sub，不管你是否使用ESB Toolkit。將單個消息發佈到BizTalk「消息框」非常簡單，並將消息路由到任何和所有訂閱者。 pub-sub解決方案意味着BizTalk充當代理，但這有助於保證消息不會丟失，並且所有消息都會被跟蹤。 BizTalk pub-sub解決方案具有內置的擴展點，可以讓我們在不影響解決方案其他部分的情況下添加，更改或刪除端點。所有這些說法，您的要求可能不會決定廣泛的消息可靠性，監視和跟蹤，所以可能是BizTalk並不適合您。這是一項巨大的投資，而且由於該產品可以同時完成許多不同的事情，因此乍一看可能會令人望而生畏。

剛剛發佈的一本新書叫微軟平臺上的應用體系結構模式，其中涵蓋了大部分內容。該書的作者之一Richard Seroter也使用BIzTalk Server 2009發佈了SOA模式，如果您決定與BizTalk一起爲貴公司使用，這將是必不可少的。