システム統合とは何かは理解していますが、すべての最新のアプローチには少し慣れていません。私は Web サービスと JMS に精通していますが、ESB の概念には完全に戸惑っています。
私はいくつかの研究を行いましたが、私はまだそれを本当に理解していません。私は理論よりも実例を示す方がはるかに優れています。
では、単純な例を示して、なぜ Enterprise Service Bus と Queue 、Web サービス、ファイル システムなどを使用するのかを示すことができますか?
この例では、他の従来の統合方法では達成できなかったか、少なくとも同じ効率では達成できなかった ESB の機能を増幅してほしいと思います。
すべての返信は大歓迎です。
ありがとう、ボブ
これは少し耳障りに聞こえるかもしれませんが、基本的に ESB が必要な場合は、ESB が必要であることがわかります。
ほとんどのユースケースでは、ESB は問題を探すソリューションです。これは、ほとんどのシナリオ向けに設計されたソフトウェアのスタックです。ほとんどの人は、それを正当化するのに十分な種類の処理を行っていません。「エンタープライズ」の「E」はここで注目に値します。
簡単なケースでは:
tail -F server.log | grep SEVERE >> severe.log
これは、ESB シナリオのインスタンスの簡単な例です。
「しかし、それは単なる UNIX コマンド パイプラインです!」
はい、正確に。
「ESB」の部分は「|」です。そして>>"
ESB は、モジュールをリンクしたり、トラフィックを監視したり、ファンアウトや結合などのあらゆる種類の奇抜なシナリオを設計したりできるランタイムです。
ESB は、多数のソースを読み取り、多数の宛先を書き込むための多数のコネクタを備えていることで注目に値します。それらは、かなり粗い論理ブロックを使用して処理するためのより複雑なグラフとワークフローを織り込むことで有名です。
しかし、ほとんどの人が通常行うことは次のとおりです。
input -> DO_STUFF -> output
ESB を使用すると、次のことが得られます。
ESB[input -> DO_STUFF -> output]
実際、ほとんどのパイプラインはそれほど複雑ではありません。再利用できない 1 回限りのロジックを持つ傾向があり、人々はそれを 1 つのロジック モジュールにまとめる傾向があります。
ええと、Perl スクリプトでそれを行うことができます。
ESB の長いパイプラインは、非効率よりも非効率になる傾向があります。汎用モジュールとの間でデータを大量にマーシャリングします (バイナリ ペイロードを使用することはめったにないため)。
たとえば、CSV が入力され、XML に変換され、処理され、別のステップへの入力用に XML が XML として出力されます。XML はそれをマーシャリングし、処理し、さらに別のステップのために XML に変換します。CPU が 400% (マルチコア FTW) に達するまで、すすぎと繰り返しを繰り返します。
次に、「ねえ、これらのモジュールを 1 つのルーチンにまとめてドロップすると、この XML ジャンクはすべてスキップされます!」という人がいて、「入力 -> DO_STUFF -> 出力」という結果になります。
カジュアルなアドホックな統合を行う必要がある Web サービスが多数ある大規模なシステムの場合は、問題ありません。あなたがそれをたくさん行うビジネスにいるなら、彼らは本当にうまくいくことができます. 数十のパイプラインがある場合、それらを管理する運用面で役立ちます。
しかし、複雑なパイプラインの場合、多くのステップがある場合、特に実際のボリュームが関係している場合は、プロトタイピングを超えてあまり良いアイデアではないかもしれません. 統合するシステムによっては、選択の余地がないことに注意してください。
そうでない場合は、立ち上がる必要がある単一のインターフェイスがある場合は、それを実行してください。Perl、Java、C# など、あらゆる方法で実行してください。100MB の奇妙なインフラストラクチャと複雑さを使い果たしてスプールし、学習、習得、維持する必要はありません。
繰り返しになりますが、ESB が必要な場合は、ご存知でしょう。本当。異種のものを組み合わせて構築したシステムが何であれ、それと戦い、これらすべてがどれほど苦痛であるかについて同僚と話し、あるベンダーへのサイトへのリンクに出くわして読むでしょう。ホワイト ペーパーを読んで「それだ！」と言ってみてください。
ESB は、Web サービスとキューとファイル システムがすべて同じシステムにあり、それらを統合する必要がある場合に使用します。ESB製品は通常、次のことを解決します
これらはすべて他のツールでも実行できます。これらの機能の 1 つまたは 2 つだけが必要な場合は、おそらく ESB なしで実行できます (複雑さが増すため)。ただし、それらのいくつかが必要な場合は、次の形式の統合ソリューションESB の方が優れたソリューションになる可能性があります。
@WillHartung が結論付けたように、ESB は大規模で複雑な状況で適切に使用される傾向があります。そのため、Enterprise Service Bus という名前が付けられています。
さて、実際にあなたの質問に答えるために、ESB は通常:
入力と出力の両方で、いくつかのプロトコル (HTTP、Message Queue など) を介して通信します。
共通のメッセージ形式を確立し、多くの場合、他の形式から「正規の」形式に変換します
エンドポイントの透明性を提供します (たとえば、メッセージをバスに送信して応答を返しますが、バスに接続されているどのサービスが要求を処理したかを明示的に知りません。
監視および管理機能を提供する
サービスとメッセージのバージョン管理を容易にする
必要に応じてセキュリティを強化します。
つまり、ご覧のとおり、大量のポイント ツー ポイント通信 (「実行するだけ」) が巨大で手に負えないスパゲッティの山になる場合に使用します。実際、SOA が実装されているのを見たほとんどの場所で、すでに存在する巨大なスパゲッティの山が SOA に取って代わられています。
ESBは、エンタープライズサービスバスであり、サービス指向アーキテクチャが必要な場合はインフラストラクチャバックプレーンです。何百ものサービスがお互いを楽しく再利用するという混乱を想像してみてください。そのような環境をどのように管理しますか？サービス間に柔軟で分離されたルーティングをどのように提供しますか？ポイントツーポイントのスパゲッティアーキテクチャをどのように回避しますか？ハイブリッドテクノロジーランドスケープ全体でトランザクションとセキュリティをどのように管理しますか？複数のシステムにわたる複雑なフローのどこにメッセージがあるかをどのように追跡しますか？
ESBを使用します。
ESBを使用すると、通常、XML構成言語で複数のシステムにまたがるフローを設計でき、EISアダプター、変換、およびメディエーション・プラグインなどのホストを提供します。フローの設計に役立つIDEを提供するものもあります。一部のESBは非常に高価であり、一部はオープンソースです。
ESBの感触を知りたい場合は、どちらも優れたオープンソース製品であるMuleまたはWSO2、あるいは非クラスター化ソリューションであるがJavaを基盤となる外部インターフェースポイントから切り離すのに優れたSpringIntegrationをチェックしてください。