terminology - ESBとEAIの違い

Question

ほとんどの記事で、ESB と EAI の主な違いは「EAI の単一点障害」であると見てきました。

私の質問は次のとおりです。

EAI では、ハブに障害が発生した場合、これが単一障害点であると言っています。ESB でも、バスに障害が発生した場合、単一点障害と言えます。これは正しいですか？そうでない場合は、これについて簡単に説明してください。

Answer 1

ESB と EAI の主な違いは、単一障害点ではありません。

そうは言っても、ESB バスに障害が発生した場合、はい、それは障害点です。最終的に、これらはインフラストラクチャ内の単なるアプリケーションであり、それらが単一障害点であるかどうかは、基盤となる概念的な統合パターンではなく、展開 (クラスタリングなど) に依存します。

個人的には、ESB (Enterprise Service Bus) を EAI (Enterprise Application Integration) の一種として分類します。コンセプトではなく製品を売り込もうとする多くの企業は、異なる主張をするでしょう。

ESB は、ハブスポークに代わる EAI の新しいパターンです。私は違いにあまり巻き込まれません。あなたがそれを掘り下げるとき、それらはほとんどありません。

Answer 2

このコメントを参照

ESB は次世代のエンタープライズ統合テクノロジであり、EAI (ハブスポーク) が廃止された場所を引き継ぎます。

• よりスマートなエンドポイント: ESB は、アプリケーションが外部とのインターフェイスとなるポイントに、より多くのインテリジェンスを配置するアーキテクチャを可能にします。ESB を使用すると、各エンドポイントが WSDL などの標準を使用してサービスとして表示できるようになり、アプリケーションごとに独自のインターフェイスを作成する必要がなくなります。統合インテリジェンスは、エンドポイント (クライアントとサーバー) 自体にネイティブに展開できます。ペイロードを対象の形式に直接フォーマットすることを優先して、正規の形式はバイパスされます。このアプローチにより、EAI 製品に固有の複雑さの多くが効果的に取り除かれます。
• 分散アーキテクチャ: EAI が純粋なハブ アンド スポーク アプローチであるのに対し、ESB は軽量の分散アーキテクチャです。プログラム間の各対話を正規の形式に変換する必要がある場合、集中型ハブは理にかなっています。ESB は、より多くの処理ロジックをエンドポイントに分散します。
• 統合スタックがない: 顧客が EAI 製品を使用してより多くの問題を解決するにつれて、各ベンダーは EAI 製品に組み込まれた独自の機能のスタックを追加しました。時間が経つにつれて、これらの統合スタックはモノリシックになり、使用するには深い専門知識が必要になります。対照的に、ESB はソフトウェアの比較的薄いレイヤーであり、オープン スタンダードを使用して他の処理レイヤーを適用できます。たとえば、ESB ユーザーが特定のビジネス プロセス管理ツールを展開したい場合、ビジネス プロセスを調整するための BPEL などの業界標準インターフェイスを使用して、ESB と簡単に統合できます。

ESB アプローチの当面の短期的な利点は、EAI (ハブスポーク) アプローチと同じ全体的な効果を達成できることですが、総所有コストははるかに低くなります。これらの節約は、ハードウェアとソフトウェアの費用の削減だけでなく、分散型で柔軟なフレームワークを使用することによって実現される労力の節約によっても実現されます。

Answer 3

クラスター化されたセットアップで単一障害点になることを避ける必要があります。それは、HA クラスターまたは FO クラスターの可能性があります。