BizTalk是ESB嗎？

Question

我正在研究架構模式，企業服務總線（ESB）。在閱讀這篇文章Enterprise Integration，並且幾乎沒有任何經驗時，我在想BizTalk是ESB還是僅僅是EAI（Hub/Spokes或Bus）？

我發現這個NServiceBus and Biztalk，描述BizTalk作爲一箇中央消息代理。

考慮其他ESB框架（NServiceBus和Rhino服務總線）。這些框架沒有處理消息的中心點。

Biztalk是EAI而不是ESB嗎？

非常感謝

Answer 1

BizTalk肯定是一個ESB。 EAI更像是一個鬆散的概念 - BizTalk當然可以部署來支持EAI，而且它還可以做更多事情。

Answer 2

BizTalk不僅僅是一個ESB，但肯定符合法案。 This link已有點舊，但回答您的確切問題。

編輯：這裏是a more-recent MS link進入具體實施。

Answer 3

的BizTalk是由微軟踢具有ESB功能 - 看到BTS ESB toolkit

然而，術語「ESB」涵蓋面非常broad field，並有一個關於ESB的確切定義很大的主觀性。恕我直言，BizTalk聲稱作爲ESB是全面的（在該術語的> 2010年定義中），存在薄弱環節。

• BTS始於Hub-and-Spoke EAI時代，在ESB普及之前。
• BTS比同步過程更適合於異步過程 - 根據系統負載，節流狀態等不同，等待時間會有所不同。
• BTS對於易於版本化服務和模式而言非常麻煩（新部署是需要）
• BTS是繁瑣的，當涉及到的許多服務管理（例如使用BizTalk爲您的企業SOA的所有5000個門面/ Web服務將是痛苦的）

FWIW我們發現BTS的好適用於：

• 我們所有的同步和異步EAI（即主要LOB系統與貿易伙伴之間的正式整合合同），大量適配器協助整合大量協議。
• 業務流程和業務監控能力
• 解決事務性和交付reliablity - Biztalk的有能力重試，跟蹤和恢復掛起的消息，這是在不可靠的網絡非常有用，也涉及到不可靠的系統集成。

更新，有一些進一步的比較經驗

• BTS非常集中 - 最終，即使是多服務器集羣的BizTalk /組依賴的SQL Server上。基於隊列的ESB產品傾向於更加分散（邏輯上和物理上），因此，少數端點或隊列服務器的損失不應導致整個企業失敗。
• 許多基於隊列的ESB都建立在開源技術基礎之上，注意避免單一供應商鎖定
• 許多當代ESB似乎都採取commodity-computing的方式向外擴展。用BizTalk等產品擴展可能會變得非常昂貴。
• 另一方面，BTS等商業產品的監控和管理功能不應低估 - 確保您正在考慮的任何ESB具有足夠的審計，儀表，重試和診斷（WMI/SNMP/SCOM等）功能 - 你需要一個儀表板來監測你的公交車的健康狀況，沒有什麼比不知道信息去哪裏更糟的了。在這裏，集中管理和診斷是一個優點。

Answer 4

BizTalk是一個消息傳遞和工作流協調平臺，您可以在其上構建ESB行爲和功能。爲了簡化這一點，並在BizTalk上實現ESB實現的標準化，Microsoft發佈了BizTalk ESB工具包 - 一組指導原則，模式和代碼。

EAI和BPM的概念已經存在了一段時間，所以有很多公司利用BizTalk來爲這些問題創建解決方案。在BizTalk服務器上託管完整ESB的公司數量要少得多，而且WCF/WF/NServiceBus以及Azure Service Bus的出現肯定會降低採用率。

因此，總而言之，BizTalk開箱即用的是EAI或ESB，但可以與許多應用於該問題的開發人員一起完成。

Answer 5

BizTalk可以同時用作EAI和ESB。

對於ESB，BizTalk服務器體系結構是發佈訂閱的，可以將一條消息發佈到充當消息傳遞骨幹總線的消息箱。該消息可以由訂閱該消息的一個或多個目的地系統接收。當然，使用BizTalk服務器可以獲得更多的功能和特性，例如mapper工具以及使用管道組件。

爲了用作EAI，BizTalk爲您提供管理業務邏輯的業務流程，LOB（業務線）adatpers連接到系統（也是遺留系統），映射器工具，規則引擎以及您需要的許多功能在公司內外集成不同的系統。

Answer 6

絕對！ Biztalk來自EIS背景，這對ESB作爲跨越混合技術平臺的面向服務架構的基礎架構背板非常有意義。

在以前的公司，我們選擇了Biztalk，而不是IBM ESB產品，這是出於功能和成本的考慮。

這是微軟，所以你得到你所支付的，但仍然值得研究。

Answer 7

Biztalk Server withot「ESB Toolkit」不是ESB。 由於以下原因：

1. 合同第一，需要先建立你的消息類型。
2. 需要首先規劃整個方案以最小化變更的影響。
3. 更改需要部署，這會增加停機時間。

關於你qustion，是的BizTalk Server是EAI產品

Answer 8

我最什麼的在這裏說的認同。即使使用EBS工具包，也可以將BizTalk作爲全面的EBS解決方案進行推廣。

爲了解決這裏做了幾個點......

•BTS更適合朝比同步 進程異步進程 - 延遲將根據系統負載的不同而不同， 節流狀態等

具有未更改默認值的BizTalk主機對於低延遲並不理想。但這些主機是爲了調整。開箱即用的配置不適合需要吞吐量的任何情況。在我走進一個BizTalk被拒絕的組織中的經歷中，總是有一個未被調整的單一主機設置位於它的中間。這有點類似於在沒有索引的dbms中創建表，獲得性能問題並說dbms本身很糟糕。

•BTS是繁瑣的，當涉及到減輕服務和 架構的版本中（需要新的部署）

想與大家需要有一個部署策略的任何開發平臺。如果模式在名稱空間中有版本，則不需要重新部署任何內容。可以部署新版本而不需要採取任何措施。

就服務端點而言，BizTalk可以在不使用IIS的情況下託管Web服務（BizTalk可以像IIS一樣使用HTTP.SYS來託管）。在BizTalk中託管進程服務僅僅是導入可以在不停止BizTalk中的任何事情的情況下完成的綁定的問題。在這些端點上，您也可以實現版本控制（如http：.../thing/v1，http：.../thing/v2等）。

反正〜5年過去了，我相信你已經打了一個結論之前，現在:)

Answer 9

通過「EAI或ESB」我假設你想知道的BizTalk如下集線器&輻條或巴士體系結構。

從架構模式的角度來看，集成解決方案大致落在兩個patterns-

• 集線器中的一個之下，輻條： 這涉及到集中消息中介發出消息以各種接收機，而所有發件人只會將其郵件發送給該經紀人。因此發送者和接收者都不需要知道對方。 這通常被許多人稱爲EAI（儘管完全可以實現遵循BUS模式的EAI解決方案）。 遵循此模式的解決方案易於開發和管理。所有的路由邏輯集中在一個地方進行管理 - 集線器。但是正如你所猜測的那樣，這有一個顯着的缺點 - 單點故障。如果集線器崩潰，一切都會停止。此外，這種模式不能很好地擴展。

• BUS： 圍繞此模式開發的企業集成解決方案通常稱爲ESB。這裏沒有智能的中央權威。所有發件人都在公交車上發佈消息。接收器需要足夠的智能以確定哪些消息是針對他們的，並將它們從總線上取下。 因此發送者和接收者只需要知道總線。但是這裏路由邏輯分佈在接收器中，所以沒有單點故障。此外，這種模式具有高度可擴展性。然而，這樣的解決方案相當複雜且難以管理。

即將到來的問題是BizTalk的模式是什麼 - 它是這兩種模式的混合體。

集線器一樣的外觀是其集中消息引擎非常明顯，而中央MessageBox數據庫。這給予了集線器方法典型的簡單和易管理性。

但是，如果你看一下在BizTalk架構，可以有一個主機其主機實例跨多個服務器蔓延。也可以在不同的服務器上配置像MessageBox，Tracking，Ent SSO等不同的BizTalk數據庫。這使得BizTalk解決方案比普通的集線器實現更具可擴展性和容錯性 - 這是通常歸因於總線方法的行爲。

希望這回答你的問題。