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