私は ESB や Biztalk にあまり詳しくありません。既に Biztalk を所有している場合、EAI の観点から何が最も理にかなっているのかを理解しようとしています。私が理解しているように、Biztalk はメッセージ ブローカー (ハブ アンド スポーク) であり、ESB パターンはアンチ ブローカーであり、概念的な「バス」は何らかの形で相互に通信する個々の分散コンポーネントで構成されています。メッセージ ブローカは本質的に、1 つのコンポーネントが故障しても「バス」全体がダウンしない ESB とは対照的に、単一障害点を表します。また、私の理解では、Biztalk は、メッセージング、オーケストレーションが緊密に結合され、スケーリングに問題があるという意味でモノリシックです。
当面のシナリオが次の場合:
- Biztalk は、主に、外部から受け取ったさまざまなファイルに基づいてさまざまなオーケストレーションを実行するために使用されています。
- 現在、CRM や給与計算などのシステムに密接に結合されている一連の社内カスタム アプリケーションは、これらの依存関係を抽象化するためにリファクタリングする必要があります。
ESB 機能を実現するために Biztalk を直接使用するか、Biztalk ESB ツールキットを使用するのが理にかなっているでしょうか。それとも、NServiceBus や Azure Service Bus に基づく Windows 用 Service Bus などの適切な ESB 実装を使用するのが理にかなっていますか? Biztalk を直接使用して EAI を実現する場合と、適切な ESB を使用する場合の長所と短所は何ですか。各アプリケーションが Biztalk に大きく依存するかどうか、またそれが望ましいかどうか。
正しい答えも間違った答えもないので、これはオープンエンドの議論として残します。
@スチュアートLC: ご返信ありがとうございます。あなたが投稿したいくつかのリンクを読みましたが、Biztalk が ESB ソリューションとして、または NServiceBus のようなものを使用するのに適しているかどうかについては、まだはっきりとはわかりませんでした。どちらも何らかの方法で「ESB」パターンを実装しているようです。問題は、実装がよりクリーンで、開発エクスペリエンスが向上し、立ち上げ時間が短いのはどれかということです。これまでの私の評価 (純粋な調査のみ) では、Biztalk は使用できますが、非常に専門的な開発者が必要であり、苦痛を伴います。スキルセット。遅延とスケーリングが問題であり、Biztalk が最終的に (Azure?) Service Bus に同化され、Biztalk SKU が存在しなくなるという事実。一方、NService バスのようなフレームワークは、立ち上げ時間が比較的短く、開発者が簡単に取り上げることができます。良いです。NET プログラミング スキルがあり、Biztalk と簡単にやり取りできます。上記を踏まえると、現在 Biztalk を社内に持っている場合でも、Biztalk ルートを使用することは理にかなっていますか?それとも、将来的には NService Bus などの適切な ESB を使用することを証明できますか?