前職では「Enterprise Service Bus（ESB）」の話が盛りだくさんでした。私はそれについての概念的な本の一部を読みましたが、具体的な用語でそれをどのように実装/統合するかを本当に理解していませんでした. 私は SOA/queueing/directory services/etc に精通しています。しかし、ESBが正確に何であるかはわかりません。
すべてのアプリをさまざまな方法で接続するのは具体的なこと (サービス/サーバー/ブローカー/など) ですか、それともシステムを設計するための単なる概念的な方法ですか?
良い例への説明やリンクは大歓迎です。ありがとう。
これは、かなり高レベルの抽象化の概念です。中心的な概念は、ESBが、企業がコードを記述せずにアプリケーションを接続できるようにするミドルウェアとインターフェースを提供することです。
これには、互換性のないプロトコル、データ、および相互作用を調整するためのメディエーションが含まれる場合があります。
すべてが通過する中央バスのアイデアは、抽象化の追加レイヤーの機会を提供します。業界標準を使用して他のアプリケーションやクライアントなどをこのバスに「プラグイン」することで、新しいサービス、データソース、さまざまなニーズを持つクライアントを比較的簡単に接続できます。
実際の実装に関しては、それは非常に大規模なエンタープライズサポートビジネスの領域です。非常に流行語ですが、目標は、インターネットとの比較を通じて、ある程度のレベルで理解できる理想です。
用途とデータが大きく異なる1つの大きな通信バスですが、すべて標準化プロトコルを実行しています。
実際、ブラウザがFTPクライアント（通常は現在ブラウザに組み込まれている）を呼び出さずにFTPサイトにアクセスできるようにするHTTPtoFTPコネクタを作成できます。
マッシュアップは興味深い実装を示しています。サンフランシスコ当局からバスルートデータを取得し、Googleから地図を取得し、yahooから寿司バーの場所を評価とともに取得し、最も近い寿司バーを提供する簡単なクエリを実行して、次のように重み付けします。より良いバーのためにもう少し旅行することをいとわない。
すべて完全に異なるサービスであり、それ自体は互換性がありませんが、標準のコネクタ（たとえば、yahooパイプ）を使用すると、それらをまとめて、まとまりのある便利な全体にすることができます。
-アダム
商用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})
サービス指向アーキテクチャで同じことを行う場合は、
初めての時は少し辛いかもしれませんが、EJBに慣れるのと同じように慣れると思います;-)
MOM システムは「型なし」(動的構造) であるのに対し、ESB は「型付き」(静的構造) であると言えます。raw Messaging と ESB のトレードオフは、他の型なし/型付きの選択肢と似ています。
小規模なプロジェクトの場合、機能をすばやくハッシュ化するのは良いことですが (例: Groovy コード)、大規模なプロジェクトの場合は、デバッガー (例: Java) を用意し、問題が発生したときに事前に警告を受け、人々がコミットする前に標準を用意することをお勧めします。事業。
したがって、検証されていない変更をチェックインしてシステムを壊す人が多すぎることにプロジェクトが苦しんでいる場合は、より多くの構造 (MOM ではなく ESB) に移行してください。プロジェクトが時間内に十分な作業を完了できないことに苦しんでいる場合は、よりシンプルで型指定のないソリューションを選択してください。両方の場合 - コンサルタントを取得します (冗談です ;-)
ええと、それはあなたが誰に尋ねるかによります...多くの人は、これらのモジュール間のメッセージングからコーディングを取り除くために、さまざまな「ビジネスロジック」を接続する「ミドルウェア」の一部だと言うでしょう。これは一般的な定義だと思いますが、ウィキペディアなどですでにそこに到達していると思います。
素晴らしいESBを世界に救ってもらう人は、ESBが最も一般的に提示され、すべてを行うためのハブであると考えています。ほとんどのESB実装は、ビジネスソフトウェアで見られるすべての反復タスクをカプセル化するように努めています。つまり、ほとんどのESBは、データ転送、セキュリティ、ロギング、プロトコル変換、イベントシステム、Webサービスを介したAPI公開などを処理します。
それは私ができる限り明確だと思います...それがお役に立てば幸いです。
標準的な定義を超えて、ウィキペディアから入手できます。複数のプラットフォームやテクノロジーにまたがって多数のレガシーシステムを接続するための優れたツールだと思います。また、分散ワークフローや状態管理システム（総勘定元帳など）を構築するための優れたツールでもあります。
ただし、保守と拡張にはかなりの費用がかかり、複雑で不便であるため、アプリケーションを拡張するための汎用ツールとしてはテクノロジーの選択肢としては不十分です。