私は、SOA 開発が最盛期にある私のオフィスで開発者をしています。IBM MQ、IBM Message Broker、および Java/J2EE テクノロジーを使用しています。
私は現在、Message Broker を使用して 2 つのアプリケーション間でやり取りするミドルウェアを開発するプロジェクトに参加しています。Java は同じ作業を非常に効率的な方法で行うことができるため、Message Broker がそのような種類のプロジェクトに適したオプションであるかどうかはよくわかりません。
Message Broker を使用してメッセージを変換、ルーティング、および拡張するさまざまなサイトを読みましたが、これは Java を使用して効率的に行うことができます。これにより、「いつ Java を使用し、いつ Message Broker を開発に使用するのか?」という質問に行き着きました。誰かが2つを使用する利点について私を助けることができれば素晴らしいでしょう.
-RDJ
メッセージ ブローカーを使用すると、運用担当者などはすべての統合を 1 か所で監視できます。また、データ形式が変更された場合、どの統合が変更の影響を受けるかを判断するのは簡単です。
個々の統合はおそらく Java (またはその他の言語) で実装できますが、最終的には多数のポイント ツー ポイント統合が必要になります。これは、メッセージ ブローカーが解決しようとする問題の 1 つです。
Java で一般化された変換/ルーティング ソリューションを設計する場合は、メッセージ ブローカーを設計することになります :) これは興味深いことですが、実際には必要ではありません。商用およびオープン ソースのメッセージ ブローカーはすでに数多く利用可能です。
私が理解しているように、たとえば、すぐに使えるメッセージブローカーや同様のSOA関連テクノロジーを使用する代わりに、コアJavaに機能を実装しようとしています。私の提案は-車輪の再発明をしないでください。重要なのは、そうしようとしても、最終的には同じ技術的な問題に直面し、同様の解決策につながるということです。おそらくもっとテストされ、信頼されている、すでにそこにあるものと同等のものを開発しようとするのではなく、ビジネスロジックに焦点を合わせてみませんか。
より実用的な観点から言えば、Websphere Message Broker は、Java では実現が難しいことが多い非 Java アプリケーション (C、COBOL、PHP、VB ...) を統合する方法を提供します。
また、Java は XML の処理にはあまり適していません。ESQL と XSLT はどちらも、Java よりもはるかに優れた XML 変換の手段です。
Webshpere メッセージ ブローカーは、JMS の制限を超えてメッセージングを処理することもできます (JMS も実行できます)。
メッセージ ブローカーの Java 実装のようなものである Websphere ESB を見ることができます。この製品は、外部の非 Java アプリケーションが Java の世界に適応することを期待しているため、統合機能は少なくなりますが、Java ユーザーは快適に作業できると思います。
Websphere Message Broker は ESB ですが、Java はプログラミング言語です。Axis や Fuse のように実装言語として Java を使用する ESB がありますが、それらは XML の解析、サービスの編成、メインフレーム システムとの統合に十分強力です。Message Broker での Web サービスの設計と開発は簡単でユーザーフレンドリーです。は XML 変換に強力であり、処理は Message Broker で使用される実装言語です。ここでも、MQ、HTTP、ファイル ノードとの統合は、MB 単位でシームレスかつ効率的です。
最初に理解しておくべきことは、Broker の Java-API は C-API の上にあり、利用可能なすべての機能に完全にアクセスできるわけではないということです。
2 つ目は醜いことです。単純なマッピング変換には使用しません。もちろん、最近ではビジュアル マッパーもあります。
とはいえ、特別な状況では依然として有用です。これを使用した例の 1 つは、いくつかのメッセージ コンテンツを照合することでした。基本的にシナリオは、2000 以上の要素を含む Msg1 を受信し、追加の詳細を提供する 2000 以上の要素を含む対応するメッセージ Msg2 を取得するというものでした。
したがって、ESQL では、Msg1.element[1] から開始し、次に Msg2 をスキャンして一致するものを探します。最適化のために、Msg2 から要素が使い果たされたら削除できます。それでも、特に 2000+ から 5000+ にスケールアップし始めると、CPU の点で非常に高価でした。また、非常に大きなメッセージの場合は 5 分以上かかりました。
もう 1 つの方法は、Java 計算ノードを使用して、2 番目のメッセージの内容を Java Tree オブジェクトにロードすることでした。これにより、処理時間が約 3 秒に短縮されました。
したがって、変換を行っているだけの場合は、Java 計算ノードを避けてください。ただし、より複雑なことや CPU を集中的に使用することを行っている場合は、Java 計算ノードを試してみてください。