JMSとESB-それらはどのように関連していますか？
私にとって、JMSとESBは非常に関連しているように見え、それらがどのように正確に関連しているかを理解しようとしています。
JMSをESBのトランスポートとして使用できるという文を見たことがありますが、そのようなESBにはトランスポート以外に何が存在する必要がありますか？ JMSは単純なESBですか、そうでない場合は、実際のESBに欠けているものは何ですか？
JMSは、メッセージング用のAPIのセットを提供します。メッセージをキューに入れます。誰か他の人が、後で、おそらく地理的に遠く離れた場所でメッセージをキューから取り出して処理します。メッセージプロバイダーとコンシューマーの時間と場所を切り離しました。メッセージコンシューマーが一時的にダウンした場合でも、メッセージを生成し続けることができます。
JMSは、プロデューサーがメッセージを「トピック」に配置し、関係者がそのトピックにサブスクライブして、メッセージが作成されたときにメッセージを受信できるパブリッシュ/サブスクライブ機能も提供しますが、現時点ではキュー機能のみに焦点を当てます。
プロバイダーとコンシューマーの関係のいくつかの側面を切り離しました。ただし、いくつかの結合が残っています。まず、現状では、すべてのメッセージが同じ方法で処理されます。さまざまな種類のメッセージに対してさまざまな種類の処理を導入するとします。
if ( message.customer.type == Platinum )
do something special
明らかに、そのようなコードを書くことはできますが、別の方法として、3つのキューを設定したさまざまな場所にさまざまなメッセージを送信できるメッセージングシステムを用意することもできます。
Request Queue, the producer(s) puts their requests here
Platinum Queue, platinum consumer processing reads from here
Standard Queue, a standard consumer reads messages from here
そして、必要なのは、キューシステム自体を少し巧妙にして、メッセージをリクエストキューからプラチナキューまたはスタンダードキューに転送することです。
つまり、これはコンテンツベースのルーティング機能であり、ESBが提供するものです。 ESBは、JMSが提供する基本的なキューイング機能を使用することに注意してください。
2番目の種類の結合は、コンシューマーとプロデューサーがメッセージ形式について合意する必要があることです。単純なケースではそれで問題ありません。しかし、多くのプロデューサーがすべて同じキューにメッセージを配置し始めると、バージョン管理の問題が発生し始めます。新しいメッセージ形式が導入されましたが、既存のすべてのプロバイダーを変更する必要はありません。
Request Version 1 Queue Existing providers write here
Request Version 2 Queue New provider write here, New Consumer Reads here
また、ESBはバージョン1キューメッセージを取得してバージョン2メッセージに変換し、バージョン2キューに配置します。
メッセージ変換は、別の可能なESB機能です。
ESB製品を見て、何ができるかを見てください。私はIBMで働いているので、 WebSphere ESB に最も精通しています。
ESBは、多くのプロトコルへのファサードのようなものだと思います。JMSはその1つです。
- 上記のリストに加えて、最新のオープンソースESB - ltraESB
JMSは、RESTサービス、ファイルシステム、S/FTP、電子メール、ヘッセ行列、SOAPなど）の統合にはあまり適していません。これらのタイプをネイティブにサポートするESB。たとえば、深夜に500MBのCSVファイルをダンプするプロセスがあり、別のシステムでファイルを取得し、CSVを解析してデータベースにインポートする場合、これは次の方法で簡単に実行できます。 ESB-一方、JMSだけのソリューションは悪いでしょう。同様に、RESTサービスの統合、複数のバックエンドインスタンスへのロードバランシング/フェイルオーバーは、HTTP/SをネイティブにサポートするESBを使用するとより適切に実行できます。
ESBは、JMSに加えて、さまざまなプロトコルとの統合を提供します。
ほとんどの場合、メッセージの転送、保存、移動にはバックグラウンドでJMSを使用します。そのようなソリューションの1つであるOpenESBは、XML形式のメッセージを使用します。
チェックアウトできるオープンソースのESBがあります-
ActiveMQ のようなJMS実装には、Camelが組み込まれています。
この変換は自動的には行われません。マッピングまたは書き込み変換サービスを構成する必要があります
よろしくお願いいたします。RajaNagendraKumar、C.T.O www.tejasoft.com
JMSとESBは両方とも通信の方法を提供します異なるアプリケーション間。 ただし、JMSとESBのコンテキストは異なります。 JMSは単純なニーズのためのものです。 JMSはJMSプロバイダーによって実装されます。 Java固有です。
JMSプロバイダーの例は次のとおりです：Apache Active MQ、IBM MQ、HornetQなど
ESBは複雑なニーズに対応しています。 ESBはEAIのコンポーネントですさまざまなアプリケーションに通信機能を提供します。 これは汎用であり、Javaに固有ではありません。 JMSは、サポートされているプロトコルの1つです。
ESBプロバイダーの例：MuleESB、Apache Camel、OpenESB
ユースケース：すべての通信アプリケーションがJavaであり、同じメッセージ形式を使用している場合、ESBを使用することはオーバーヘッドになる可能性があります。ここではJMSで十分な場合があります。
JMSは、基盤となるメッセージング層と通信するためのプロトコルです。 ESBはより高いレベルで動作し、複雑なフローの管理をはるかに簡単にする統一された方法で、複数のテクノロジーおよびプロトコル（そのうちの1つはJMS）との統合を提供します。
ESBで簡単に構成できるJMSメッセージブローカーがあります。 https://docs.wso2.com/display/ESB470/JMS+Transport