7

添付の画像に示されているシナリオを検討してください。

複数のアプリの複数のインスタンス。

  1. ポータル（プロデューサー）は、複数のアプリケーション（コンシューマー）（PAYROLLAPP、HELPDESKなど）で処理する必要のあるバスにメッセージを送信します。
  2. コンシューマーアプリケーションの複数のインスタンスが実行されている可能性があります。また、これらのインスタンスは動的に追加/削除できます。
  3. ここで、アプリケーションごとにメッセージが1回だけ処理されるようにすることが重要です。つまり、PAYROLLAPP -1がメッセージを処理する場合、PAYROLLAPP-2はメッセージを処理しないでください。もちろん、上の図では、HELPDESK –1がそれを処理する必要があります。つまり、複数のインスタンスの場合、メッセージを1回だけ処理する必要があります。
  4. 私が答えを検索したとき、ほとんどのものは「選択的コンシューマー」（何らかのロジックに基づいてメッセージを受け入れる/拒否するコンシューマー）を作成することでした-に示されているアプリケーションに対して変更/追加/ラッピングを行うことはできないことに注意してください図; ロジックは、バスを管理するプロバイダーのどこかに存在する必要があります

同じことについてご案内ください。

ペッターの答えの後に詳細を追加する：

私の現在の理解とアプローチ

  1. 左の点線の左側にある項目は「アプローチ」です-純粋なJMS、ESB、EAI
  2. 右点線の右側の項目は「実装」です

さて、大部分-クエリ：

  1. ソリューション（純粋なJMS、ESB、EAI）に関係なく、水平の点線の下の部分（アプリケーション固有のキュー）を実装する必要がありますか？
  2. 「純粋な」JMS（アクティブMQなど）の代わりにESB（JBoss ESBなど）を使用すると、どのように役立ちますか？ESBは、「javaのみ」（？）であるJMSよりも優れていますか？次のようなスレッドを参照した後でも、「ESBまたはJMS」は非常に混乱しています：JMSとESB-それらはどのように関連していますか？。「JMSは、これらのタイプをネイティブにサポートするESBでより適切に処理される、RESTサービス、ファイルシステム、S / FTP、電子メール、ヘシアン、SOAPなどの統合にはあまり適していません。たとえば、深夜に500MBのCSVファイルをダンプするプロセスがあり、別のシステムでファイルを取得し、CSVを解析してデータベースにインポートする場合、これはESBで簡単に実行できます。 JMSは悪くなります。同様に、複数のバックエンドインスタンスへの負荷分散/フェイルオーバーを伴うRESTサービスの統合は、HTTP/SをネイティブにサポートするESBを使用してより適切に行うことができます。」それは私の混乱を増しただけです!!!
  3. EAIフレームワーク（Apache Camelなど）の使用法は、純粋なJMSまたはESBアプローチとはまったく異なりますか？はいの場合、長所/短所はどのように、そして何ですか？
  4. ESBだけでは役に立たないと言われましたが、「ルーティング」ロジックを定義して保存するには、BPM（または他の何か？）を使用する必要があります。これは本当ですか？
4

2 に答える 2

3

要点がわかります。これは、「純粋な」JMS では少し難しいかもしれません。

基本的にやりたいことは、ポータルがトピックにメッセージを発行できるようにすることですが、PAYROLLAPP がそのトピックにサブスクライブできないようにすることです (すべての PAYROLLAPP がメッセージのコピーを取得するため)。そのため、トピック サブスクリプションからアプリケーション タイプごとに 1 つのキューにメッセージを配信するロジックが間に必要です。そのキューから、JMS を使用して通常の負荷分散 (競合するコンシューマー パターン) を実装できます。

さまざまな JMS プロバイダーには、このタスクを実行できる特別な実装があります。ActiveMQ には仮想宛先があり、WebSphere MQ には、トピックからキューにサブスクライブできるサーバー側のサブスクリプションがあります。JMS プロバイダーにこれを処理する方法がない場合は、ルーティング ミドルウェアをトポロジに追加することを検討してください。Apache Camel は優れた軽量なものですが、実際のアプリケーションに影響を与えずに途中でルーティングを設定できるものは他にもたくさんあります。

詳細な質問の更新

  1. 線の下のキューは必ずそこにある必要があります (アプリケーションがメッセージングを使用している場合)。「いくつかの配布ロジック」ボックスは必要ありません。「いくつかのルーティング ロジック」ボックスは ESB であるか、まさにこの場合、メッセージング サーバーに実装されます。

  2. 統合の領域には多くのバズワードがあります。単純化すると (質問者によっては、ESB はアーキテクチャ パターンと見なすこともできますが、単純にしましょう)、ESB はサーバー アプリケーション (または実際には複数のサーバーのトポロジ) であり、統合ランドスケープの中心的存在です。ESB サーバーには、1 つのアプリケーションからメッセージ (ファイルなど) を取得して多くのアプリケーションにルーティングし、他の形式に変換し、暗号化し、HTTP/SOAP などの 1 つのトランスポート プロトコルからファイルなどに変換するロジックと小さなメッセージ フローが含まれているだけです。 .

JMS はやや紛らわしく、誤用されている言葉です。ここ数年、Java はエンタープライズ メッセージング ドメインをある程度支配してきたため、JMS はメッセージングのほぼ同義語として使用されることがあります。ただし、メッセージング (またはメッセージ キューイング、非同期メッセージング、MOM = メッセージ指向ミドルウェアなど) は、中央中継サーバーを特徴とする同様のトランスポート プロトコルのファミリと単純に見なされます。Javaだけのものではありません。私が取り組んだ多くの成功した ESB セットアップは、実際に Messaging バックボーンを活用しています

  1. あなたの状況では、私は ESB と EAI ソフトウェアの学問的/哲学的な違いについて深く掘り下げません。彼らはおそらくあなたのためにほとんど同じことをするでしょう. 代わりに、価格、サポート、リソース フットプリント、監視、技術などの確かな事実に注目してください。機能、学習曲線など。Camel/ServiceMix、Mule、JBoss ESB、Microsoft BizTalk、IBM Message Broker、Tibco など。

  2. ハッ！もしかして店員だった？ESB は問題なく動作します。既に指摘したように、ActiveMQ などの Messaging サーバーもあなたの場合に適しています。BPM スーツは、半自動化されたビジネス プロセスのオーケストレーションや、統合レイヤーに主要なビジネス ロジックがある場合に適しています。それ以外の場合は、複雑さが増すのを避けてください。

于 2012-04-27T22:19:49.220 に答える
3
  1. 解決策（純粋なJMS、ESB、EAI）に関係なく、横の点線より下の部分（アプリケーション固有のキュー）は実装する必要がありますか？

コンシューマーは、選択したソリューションで動作するように実装する必要がありますが、コンシューマーごとのキューの作成や配布ロジックについて心配する必要はありません (コンシューマーが選択した技術から直接消費できると仮定します)。

  1. 「純粋な」JMS (Active MQ など) の代わりに ESB (JBoss ESB など) を使用すると、どのように役立ちますか? ESB は、「Java のみ」(?) である JMS よりも利点がありますか。JMS と ESB のようなスレッドを参照した後でも、'ESB または JMS' と混乱しています。「JMS は、REST サービス、ファイル システム、S/FTP、電子メール、ヘシアン、SOAP などの統合にはあまり適していません。これらのタイプをネイティブにサポートする ESB でより適切に処理できます。たとえば、真夜中に 500MB の CSV ファイルをダンプするプロセスがあり、別のシステムでファイルを取得し、CSV を解析してデータベースにインポートする必要がある場合、これは ESB によって簡単に実現できます。 JMSは悪いでしょう。同様に、REST サービスの統合、複数のバックエンド インスタンスへのロード バランシング/フェイルオーバーは、HTTP/S をネイティブにサポートする ESB を使用すると、より適切に実行できます。」それは私の混乱を増すだけでした!!!

私の意見では、ESB はこのソリューションを過度に複雑にします。さまざまなテクノロジーとの統合を支援するために (とりわけ) 設計されていますが、より単純なソリューションもこれを行います。

すべての JMS 実装が他の言語からの接続に対応しているわけではありませんが、ActiveMQ は STOMP コネクタを使用して対応しています。

  1. EAI フレームワーク (Apache Camel など) の使用は、純粋な JMS や ESB のアプローチとはまったく異なるアプローチですか? はいの場合、長所と短所は何ですか?

Apache Camel と JMS は、JMS と ESB と同様に補完的なテクノロジです。Camel (および Spring Integration) は、軽量でシンプルでポータブルです。ESB ははるかに重量が大きく、通常は ESB/アプリケーション サーバーとの結合が大きくなります。

  1. ESB だけでは役に立たないと言われました。「ルーティング」ロジックを定義して保存するには、BPM (または他の何か?) を使用する必要があります。これは本当ですか?

「ルーティング」ロジックが何であるかによって異なります。ルーティングロジックは必要ないように見えます。1つのpayrollコンシューマーと1つのヘルプデスクコンシューマーへの保証された配信が必要なだけです。BPM は、データを選択的に公開したり、そのデータの特性に基づいてサービスを呼び出したりする場合に便利です。

http://activemq.apache.org/virtual-destinations.htmlを読むことを強くお勧めします。これらを使用すると、次のようになります。

  1. メッセージを ActiveMQ ブローカの VirtualTopic (VirtualTopic.X など) に送信します。
  2. Payroll および Helpdesk コンシューマーを、ActiveMQ がトピックで動的に作成するキューのコンシューマーとして登録します (例: Consumer.Payroll.VirtualTopic.X)。両方の Payroll コンシューマを同じ文字列で登録する必要があります。
  3. ActiveMQ は、消費者の各セットが消費していないものを表すマーカーを自動的に保持します。これは、メッセージの 100% が Payroll コンシューマーによって処理されることを意味しますが、メッセージが 1 つ以上の Payroll コンシューマーに送信されることはありません。
  4. 自由に消費者を追加/削除します。

NBI は、Apache QPID などの他の製品も同様の機能を提供すると考えています。私は ActiveMQ を最もよく知っており、このアプローチで成功しています。

于 2012-05-01T22:35:13.850 に答える