前職では、「Enterprise Service Bus」（ESB）について多くの話題がありました。私はそれについて概念的な本の一部を読みましたが、具体的な用語でそれを実装/統合する方法を本当に理解していませんでした。私はSOA /キューイング/ディレクトリサービス/その他に精通しています。しかし、ESBとは正確には何なのかわかりません。
すべてのアプリをさまざまな方法で接続するのが具体的なこと（サービス/サーバー/ブローカーなど）ですか、それともシステムを設計するためのより概念的な方法ですか？
良い例への説明やリンクは大歓迎です。ありがとう。
回答:
それは抽象化のかなり高いレベルの概念です。中心的な概念は、ESBがミドルウェアとインターフェースを提供し、企業がコードを記述せずにアプリケーションを接続できるようにすることです。
これには、互換性のないプロトコル、データ、および相互作用を調整するメディエーションが含まれる場合があります。
すべてが通過する中央バスのアイデアは、抽象化の追加レイヤーの機会を与えます。業界標準を使用して他のアプリケーション、クライアントなどをこのバスに「プラグイン」すると、新しいサービス、データソース、異なるニーズを持つクライアントの接続が比較的簡単になります。
実際の実装に関しては、これは非常に大規模なエンタープライズサポートビジネスの領域です。それは非常に流行語ですが、目標は、インターネットとの比較を通じて理解できる小さなレベルの理想です：
用途とデータが大きく異なる1つの大きな通信バスですが、すべてが標準化プロトコルを実行しています。
実際、HTTPからFTPへのコネクターを記述して、ブラウザーがFTPクライアント（通常は現在ブラウザーに組み込まれている）を呼び出さずにFTPサイトにアクセスできるようにすることができます。
マッシュアップは興味深い実装を示しています-サンフランシスコ当局からバス路線データをいくつか取得し、Googleからマップし、評価付きのyahooから寿司バーの場所を取得し、最も近い寿司バーを提供する単純なクエリを実行して重み付けしますより良いバーのためにもう少し進んで喜んで。
すべてが完全に異なるサービスであり、それ自体は互換性がありませんが、標準コネクタ（たとえば、yahooパイプ）を使用すると、それらを1つにまとめて、まとまりのある有用な全体にすることができます。
-アダム
免責事項：私はIBMで働いており、ESBを構築するために設計されたIBM製品であるWebSphere ESBについて相談しています。以下は私の意見であり、必ずしもIBMの立場を反映するものではありません。
ESBは、残念ながら人によって異なります。
私にとってESBは、SOA（サービス指向アーキテクチャー）に挿入できるあらゆるテクノロジーであり、異種システムを接続することができます。多くの場合、プロトコル変換、メッセージ変更、ルーティング、ロギング、セキュリティゲートウェイとしての機能などの機能を実行します。たとえば、ESBを使用して、以前はWebサービスとしてのみ利用可能であったサービスをJMSベースのサービスとして公開することもできます。
この点で、ESB実装（より正確には、ESBを構築するために販売されているソフトウェア-私が相談しているようなもの）は、以前はメッセージングまたはキューイングブローカーとして知られていたものと技術的によく似ていますが、目的は多少異なります（頭字語が示すように）メッセージをある場所から別の場所に移動するのではなく、サービスを中心とするためです。区別が技術的にどれほど重要であるかは、意見の問題です。
私の商用ESBでの経験は、それが解決するのと同じくらい多くの問題を引き起こすのは、誇張された高価なテクノロジーであるということです。ESBは新しいシステムとレガシーをリンクし、メッセージはバス上を飛行し、すべてが他のすべてとシームレスに通信できるようになります。弾力性とオーケストレーションを投入すると、非常に強力なエンタープライズアプリケーションソフトウェアが手に入ります。
問題を実際に使用しようとすると、バスの書き込み、メッセージ構造の作成などのオーバーヘッドがメリットを上回る可能性があります。ESBはコストの高いアイテムとして、すべての技術的な問題の万能薬と見なされており、接続されているアプリケーション/データではなく、バスに多くの時間が費やされています。多くの場合、これらのシステムが実際に修正する必要のある、従来の技術が支配するサイロにつながる、同じ組織内での優位性のために複数の競合する標準が戦います。
IMHO少数の特定のインターフェースを作成して使用する方がはるかに良いです。通常、それを必要とするシステム間でのみWebサービスを使用します。
これは基本的にシステムを設計するための概念的な方法です。ソフトウェア会社はシステムに「ESB」ステッカーを貼り付けることで売り上げを伸ばそうとします。
ESBは基本的に、データモデルと構造定義管理が追加されたMOM（メッセージ指向ミドルウェア）です。そのバス上のすべてのアプリケーションとアダプターに共通のデータ定義があります（共有XSDを使用したXMLにすることもできます）。接続するものはすべて、このデータ定義に準拠した情報を送信する必要があります。ESBは、この共通データ定義のロード、共有、バージョン管理をサポートしています。ESBに新しいコンポーネントを接続する場合、MOMに接続する場合よりも、箱から出してより多くの「互換性」を期待できます。そのバス上の各コンポーネントは、概念的には「リソース」として扱われるため、送信側と受信側を分離するために導入された追加の抽象化があります。
例：標準のメッセージ指向ミドルウェアでアプリケーションAをアプリケーションBに接続したいとしましょう。JMSを取り上げましょう。アプリケーションBで作業している同僚と話し、トピック、メッセージタイプ、フィールドに同意して送信します（疑似コード）：sendJms（ "TRADE.MSFT"、{MapMessage trader = "pete" price = 101.4 vol = 100}）
サービス指向アーキテクチャーで同じことを行う場合は、
初めてそれはおそらく少し苦痛ですが、EJBに慣れることができるのと同じように、それに慣れることができると思います;-)
MOMシステムは「型なし」（動的構造）であり、ESBは「型付き」（静的構造）と言えます。生のメッセージングとESBのトレードオフは、他の型なし/型付きの選択と似ています。
小規模なプロジェクトの場合は機能をすばやくハッシュ化するのがいいですが（Groovyコードなど）、大規模なプロジェクトの場合はデバッガ（Javaなど）を用意し、問題が発生したときに事前に警告し、コミットする前に標準を用意することをお勧めします。事業。
したがって、未検証の変更をチェックインしてシステムを壊す人が多すぎてプロジェクトが影響を受ける場合は、より多くの構造（MOMではなくESB）に移動してください。プロジェクトが時間内に十分な処理を行わないことに苦しんでいる場合は、より単純で型なしのソリューションを選択してください。それが両方の場合-コンサルタントに連絡してください（冗談です;-)
まあ、それはあなたが誰に尋ねるかに依存します...多くの人は、それがこれらのモジュール間のメッセージングからコーディングを取り除くために「ビジネスロジック」のさまざまな部分を一緒に接続する「ミドルウェア」の部分であると言うでしょう。これは十分に一般的な定義だと思いますが、ウィキペディアなどで既に理解していると思います。
優れたESBで世界を救う人は、それが最も一般的に提示されている、すべてを行うためのハブであると考えています。ほとんどのESB実装は、ビジネスソフトウェアで見られるすべての反復的なタスクをカプセル化しようとしています。つまり、ほとんどのESBは、データ転送、セキュリティ、ロギング、プロトコル変換、イベントシステム、Webサービスを介したAPI公開などを処理します。
それは私ができる限り明確であると思います...それが役に立てば幸いです。
私のプレゼンテーション「Spoiled for Choice-How to select the right ESB」をご覧ください。
ESB、Integration Suite、または単に統合フレームワーク（Apache Camelなど）をいつ使用するかを説明します。また、オープンソースと独自のESBの違いについても説明します。