BizTalkはESBですか？
私はアーキテクチャパターン、エンタープライズサービスバス（ESB）を正確に調べています。この記事を読んだとき エンタープライズ統合 、そしてほとんどまたはまったく経験がないので、BizTalkがESBなのか、それとも単なるEAI（ハブ/スポークまたはバス）なのか疑問に思います。
私はこれを見つけました NServiceBusとBiztalk 、BizTalkを中央のメッセージブローカーとして説明しています。
他のESBフレームワーク（NServiceBusおよびRhino Service Bus）を考慮に入れます。これらのフレームワークには、メッセージを処理するための中心的なポイントがありません。
BiztalkはESBではなくEAIですか？
どうもありがとう
BizTalkは、ESB機能を備えているとしてMicrosoftによってパントされています BTS ESBツールキット を参照してください
ただし、「ESB」という用語は非常に 広いフィールド をカバーしており、ESBの正確な定義については多くの主観があります。私見では、ESBとして包括的であるというBizTalkの主張には弱点があります（2010年を超える用語の定義）。
- BTSは、ESBが普及する前のハブアンドスポークEAI時代に始まりました。
- BTSは、同期プロセスよりも非同期プロセスに適しています。遅延は、システムの負荷、スロットル状態などによって異なります。
- BTSは、サービスとスキーマのバージョン管理を容易にすることになると面倒です（新しい展開が必要です）
- BTSは、多くのサービスの管理に関しては面倒です（たとえば、企業の5000すべてのファサードとしてBizTalkを使用するSOA/Webサービスは苦痛になります）
FWIW私たちはBTSが以下に適していることを発見しました：
- すべての同期および非同期EAI（つまり、主要なLOBシステム間および取引先との正式な統合契約）、および多数のアダプターが、多数のプロトコルの統合を支援します。
- ビジネスプロセスおよびビジネス監視機能の場合
- トランザクションと配信の信頼性への対応-Biztalkには、中断されたメッセージの再試行、追跡、再開の機能があります。これは、信頼性の低いネットワーク上で、または信頼性の低いシステムとの統合に関して役立ちます。
更新、さらにいくつかの比較経験
- BTSは非常に集中化されており、最終的には、マルチサーバーのBizTalkクラスター/グループでさえSQL-Serverに依存しています。キューベースのESB製品は、（論理的および物理的に）より分散化される傾向があるため、いくつかのエンドポイントまたはキューサーバーが失われても、企業全体がダウンすることはありません。
- 多くのキューベースのESBは、単一ベンダーのロックインを回避することを目的として、オープンソーステクノロジーに基づいて構築されています。
- 多くの現代のESBは、スケールアウトするために コモディティコンピューティング アプローチを採用しているようです。 BizTalkのような製品でスケールアウトすると、コストが高くなる可能性があります。
- プラス面として、BTSなどの商用製品の監視および管理機能を過小評価してはなりません-検討しているESBに適切な監査、計測、再試行、および診断（WMI/SNMP/SCOMなど）機能があることを確認してください-バスの状態を監視するためのダッシュボードが必要です。メッセージの送信先がわからないことほど悪いことはありません。ここでは、集中管理と診断がプラスになります。
BizTalkは、メッセージングおよびワークフローのオーケストレーションプラットフォームであり、ESBの動作と機能を構築できます。これを簡単にし、BizTalkでのESB実装を標準化するために、MicrosoftはBizTalk ESB Toolkit（一連のガイドライン、パターン、およびコード）をリリースしました。
EAIとBPMの概念はしばらく前から存在しているため、BizTalkを利用してこれらの問題の解決策を作成している企業はたくさんあります。 BizTalkサーバーで完全なESBをホストする企業ははるかに少なく、WCF/WF/NServiceBus、そしてもちろんAzure ServiceBusの登場で採用は確実に遅くなっています。
したがって、要約すると、BizTalkはEAIまたはESBのどちらでもありませんが、問題に適用された多くの開発者が両方を実行できます。
「EAIまたはESB "」によってBizTalkがHub＆Spokeまたはバスアーキテクチャのどちらに準拠しているかを知りたいと思います。
アーキテクチャパターンの観点から、統合ソリューションは大まかに2つのパターンのいずれかに分類されます-
ハブアンドスポーク：これには、中央のメッセージブローカーがさまざまな受信者にメッセージを送信する一方で、すべての送信者がメッセージをこのブローカーにのみ送信することが含まれます。したがって、送信者も受信者もお互いを認識する必要はありません。これは通常、多くの人がEAIと呼んでいるものです（ただし、BUSパターンに従うEAIソリューションを実装することは絶対に可能です）。このパターンに従ったソリューションは、開発と管理が簡単です。すべてのルーティングロジックは、ハブ内の1か所で一元管理されます。しかし、ご想像のとおり、これには明白な欠点があります。単一障害点です。ハブがクラッシュすると、すべてが停止します。また、このモデルはあまり拡張性がありません。
[〜＃〜] bus [〜＃〜]：このパターンに基づいて開発されたエンタープライズ統合ソリューションは、一般にESBと呼ばれます。ここにはインテリジェントな中央機関はありません。すべての送信者は、バス上でメッセージを公開します。受信者は、どのメッセージが受信者向けであるかを判断し、それらをバスから離すのに十分なインテリジェントである必要があります。したがって、送信者と受信者はバスを認識するだけで済みます。ただし、ここではルーティングロジックがレシーバー全体に分散しているため、単一障害点はありません。また、このモデルは非常にスケーラブルです。ただし、このようなソリューションは非常に複雑で、管理が困難です。
BizTalkはどちらのパターンに従うのかという質問に答えると、これら両方のパターンのハイブリッドです。
ハブのような外観は、一元化されたメッセージングエンジンと一元化されたMessageBoxデータベースで非常に明白です。これにより、ハブアプローチに典型的な管理の単純さと容易さが得られます。
ただし、BizTalkアーキテクチャを見ると、ホストとそのホストインスタンスを複数のサーバーに分散させることができます。 MessageBox、Tracking、EntSSOなどのさまざまなBizTalkデータベースをさまざまなサーバーに構成することもできます。これにより、BizTalkソリューションは、通常のハブ実装よりもスケーラブルでフォールトトレラントになります。これは通常、バスアプローチに起因する動作です。
これがあなたの質問に答えることを願っています。
BizTalkは確かにESBです。 EAIは、より緩い概念です。BizTalkは、EAIをサポートするために確実に展開でき、さらに多くのことを実行できます。
BizTalkはESB以上のものですが、確かに法案に適合します。 このリンク 少し古いですが、あなたの正確な質問に答えます。
編集：ここに より最近のMSリンク 実装の詳細に入ります。
私はここで言われていることのほとんどに同意します。 EBSツールキットを使用しても、BizTalkを包括的なEBSソリューションとして売り込むのは簡単ではありません。
ここで行われたいくつかのポイントに対処するには...
•BTSは、同期プロセスよりも非同期プロセスに適しています。レイテンシは、システムの負荷、スロットル状態などによって異なります。
デフォルトが変更されていないBizTalkホストは、低遅延には理想的ではありません。ただし、これらのホストは調整することを目的としています。すぐに使用できる構成は、スループットが必要な状況には適していません。 BizTalkが敬遠されている組織に足を踏み入れた私の経験では、その真ん中には常に調整されていない単一のホストセットアップがあります。これは、インデックスのないdbmsでテーブルを作成し、パフォーマンスの問題を取得し、dbms自体がダメだと言うことにいくぶん似ています。
•サービスとスキーマのバージョン管理の容易さに関しては、BTSは面倒です（新しい展開が必要です）
他の開発プラットフォームと同様に、展開戦略が必要です。スキーマの名前空間にバージョンがある場合は、何も再デプロイする必要はありません。新しいバージョンは、何も削除せずに展開される可能性があります。
サービスエンドポイントに関する限り、BizTalkはIISを使用せずにWebサービスをホストできます（BizTalkはIISと同じように）HTTP.SYSを使用してホストできます） 。BizTalkでインプロセスサービスをホストするには、BizTalkで何も停止せずに実行できるバインディングをインポートするだけです。これらのエンドポイントでは、バージョン管理も実装できます（http：.../things/v1、http： .../thing/v2など）。
とにかく〜5年が経過しましたあなたは今までに結論に達したと確信しています:)
「ESBツールキット」のないBiztalkサーバーはESBではありません。次の理由により：
- 最初に契約です。最初にメッセージタイプを作成する必要があります。
- 変更の影響を最小限に抑えるために、最初にシナリオ全体を計画する必要があります。
- 変更には展開が必要であり、ダウンタイムが増加します。
あなたの質問に関しては、はいBizTalkServerはEAI製品です
絶対に！ BiztalkはEISのバックグラウンドに由来します。これは、ハイブリッド技術プラットフォームにまたがるサービス指向アーキテクチャのインフラストラクチャバックプレーンとしてのESBにとって完全に理にかなっています。
以前の会社では、機能性と低コストの理由から、IBMESB製品よりもBiztalkを選択しました。
それはマイクロソフトなので、あなたはあなたが支払うものを手に入れますが、それでも調べる価値があります。
BizTalkは、EAIとESBの両方として使用できます。
ESBの場合、BizTalkサーバーアーキテクチャは公開サブスクライブされており、メッセージングバックボーンバスとして機能するメッセージボックスに単一のメッセージを公開できます。そのメッセージは、そのメッセージにサブスクライブしている1つ以上の宛先システムで受信できます。もちろん、マッパーツールやパイプラインコンポーネントの使用など、BizTalkサーバーを使用して取得できる機能は他にもあります。
BizTalkは、EAIとして使用するために、ビジネスロジックを管理するオーケストレーション、システムに接続するためのLOB（基幹業務）アダプター、マッパーツール、ルールエンジン、およびさまざまなものを統合するために必要な多くのものを提供します。社内外のシステム。
BizTalkは、biztalkアプリケーションの設計方法に応じて、ESBとEAIの両方を実行できます。