アーキテクチャ パターン、エンタープライズ サービス バス (ESB) を正確に調べています。この記事エンタープライズ統合を読んだとき、経験がほとんどないため、BizTalk は ESB なのか、それとも単なる EAI (ハブ/スポークまたはバス) なのか疑問に思っています。
このNServiceBus and Biztalkを見つけ、BizTalk を中心的なメッセージ ブローカーとして説明しています。
他の ESB フレームワークを考慮に入れる (NServiceBus および Rhino Service Bus)。これらのフレームワークには、メッセージを処理するための中心点がありません。
Biztalk は ESB ではなく EAI ですか?
どうもありがとう
BizTalk は ESB 機能を備えているとして Microsoft によってパントされています - BTS ESB ツールキットを参照してください
ただし、「ESB」という用語は非常に広い分野をカバーしており、ESB の正確な定義については多くの主観があります。私見では、ESB として包括的であるという BizTalk の主張には弱点があります (用語の 2010 年以降の定義では)。
FWIW は、BTS が以下に適していることを発見しました。
更新、さらにいくつかの比較経験とともに
BizTalkは、ESBの動作と機能を構築できるメッセージングおよびワークフローオーケストレーションプラットフォームです。これを簡単にし、BizTalkでのESB実装を標準化するために、MicrosoftはBizTalk ESB Toolkit（一連のガイドライン、パターン、およびコード）をリリースしました。
EAIとBPMの概念はしばらく前から存在しているため、BizTalkを活用してこれらの問題の解決策を作成している企業はたくさんあります。BizTalkサーバーで完全なESBをホストする企業ははるかに少なく、WCF / WF / NServiceBus、そしてもちろんAzureServiceBusの出現により採用は確実に遅れています。
したがって、要約すると、BizTalkはEAIまたはESBのどちらでもありませんが、問題に適用された多くの開発者が両方を実行できます。
「EAI または ESB」によって、BizTalk がハブ & スポークまたはバス アーキテクチャに従っているかどうかを知りたいと思っていると思います。
アーキテクチャ パターンの観点から、統合ソリューションは大まかに次の 2 つのパターンのいずれかに該当します。
ハブ アンド スポーク: これには、集中化されたメッセージ ブローカーがさまざまな受信者にメッセージを送信し、すべての送信者がメッセージをこのブローカーにのみ送信します。したがって、送信者も受信者もお互いを認識する必要はありません。これは通常、多くの人が EAI と呼んでいるものです (ただし、BUS パターンに従う EAI ソリューションを実装することは絶対に可能です)。このパターンに従うソリューションは、開発と管理が容易です。すべてのルーティング ロジックは、ハブ内の 1 か所で集中管理されます。しかし、ご想像のとおり、これには明らかな欠点があります。つまり、単一障害点です。ハブがクラッシュすると、すべてが停止します。また、このモデルはあまりうまくスケーリングしません。
BUS : このパターンに基づいて開発されたエンタープライズ統合ソリューションは、一般に ESB と呼ばれます。ここにはインテリジェントな中央機関はありません。すべての送信者は、バス上でメッセージを発行します。受信者は、どのメッセージが受信者に向けられているかを判断し、それらをバスから切り離すのに十分なほどインテリジェントである必要があります。したがって、送信者と受信者はバスを認識するだけで済みます。ただし、ここではルーティング ロジックがレシーバー全体に分散されているため、単一障害点はありません。また、このモデルは非常にスケーラブルです。ただし、このようなソリューションは非常に複雑であり、管理が困難です。
BizTalk が従うパターンはどれかという質問になりますが、これはこれら両方のパターンのハイブリッドです。
ハブのような外観は、集中型メッセージング エンジンと集中型メッセージボックス データベースを備えているため、非常に明白です。これにより、ハブ アプローチの典型であるシンプルさと管理のしやすさが得られます。
しかし、BizTalk アーキテクチャを見ると、複数のサーバーにまたがるホスト インスタンスを持つホストを持つことができます。MessageBox、Tracking、Ent SSO などのさまざまな BizTalk データベースをさまざまなサーバーで構成することもできます。これにより、BizTalk ソリューションは、ありふれたハブの実装よりもスケーラブルで、障害に対する耐性が高くなります。これは通常、バス アプローチに起因する動作です。
これがあなたの質問に答えることを願っています。
BizTalk は確かに ESB です。EAI はより緩やかな概念です。BizTalk を展開して EAI をサポートすることはもちろん、さらに多くのことを行うこともできます。
BizTalk は単なる ESB ではありませんが、確実に目的に適合します。このリンクは少し古いですが、正確な質問に答えます。
編集: これは、実装の詳細に入る最新の MS リンクです。
絶対！BiztalkはEISのバックグラウンドに由来します。これは、ハイブリッド技術プラットフォームにまたがるサービス指向アーキテクチャーのインフラストラクチャバックプレーンとしてのESBにとって完全に理にかなっています。
以前の会社では、機能と低コストの理由から、IBMESB製品よりもBiztalkを選択しました。
それはマイクロソフトなので、あなたはあなたが支払うものを手に入れますが、それでも調べる価値があります。
BizTalk は、EAI と ESB の両方として使用できます。
ESB に関しては、BizTalk サーバー アーキテクチャはパブリッシュ/サブスクライブであり、単一のメッセージをメッセージング バックボーン バスとして機能するメッセージボックスにパブリッシュできます。そのメッセージは、そのメッセージにサブスクライブしている 1 つ以上の宛先システムで受信できます。もちろん、マッパー ツールやパイプライン コンポーネントの使用など、BizTalk サーバーを使用することで得られる機能は他にもあります。
EAI として使用するために、BizTalk は、ビジネス ロジックを管理するオーケストレーション、システム (レガシー) に接続するための LOB (基幹業務) アダプター、マッパー ツール、ルール エンジン、およびさまざまな機能を統合するために必要なものの多くを提供します。社内外のシステム。
「ESB ツールキット」を使用した Biztalk サーバーは ESB ではありません。次の理由により:
あなたの質問に関して、はい、BizTalk Server は EAI 製品です
BizTalk は ESB と EAI の両方を実行できますが、これは、biztalk アプリケーションの設計方法によって異なります。