問題タブ [integration-patterns]

クライアントから送信された 1 つの JMS メッセージを 2 つのシステムに確実に (1 回だけ) 配信する必要があります。これら 2 つのシステムは HA 対応ではないため、私が思いついた最良の提案は次のとおりです。

1. クライアントが投稿する単一のキューを作成する

2. 2 つの「中間」キューを設定する

3. クライアント キューからメッセージを読み取り、同じトランザクション内の 2 つのキューにポストするカスタム "DuplicatorMDB" を使用します。

そのような既存の機能はありますか？1 つまたは両方のバックエンド システムがダウンした場合に、システムのバランスをとってシステムを安定させる適切な方法は何ですか?

アプリケーション サーバーは WebLogic 10 です。

これにはトピックを使用できません。これは、クラスター内でトピックがメッセージの重複を引き起こしすぎるためです。2 つのインスタンスがある場合、トピックを使用すると、次のようになります。

したがって、すべてのメッセージは System1 に 2 回、System2 に 2 回配信されます。クラスター内に 8 つのサーバーがある場合、各メッセージは 8 回配信されます。これは本当に避けたい…

最後に、テストする時間ができました。これが私が観察したことです。クラスター内に2つのノードがあります。2 つの JMS サーバー: ノード 1 の jms1、ノード 2 の jms2。分散トピック dt. 永続サブスクリプションと jms-client-id=durableSubscriber を持つ MDB。システムを開始しました: 0 メッセージ、mdb@node1 は稼働中、mdb@node2 は定期的に接続しようとしていますが、「クライアント ID、durableSubscriber が使用中」のため接続できません。予想通り。

100 個のメッセージで送信: jms1@dt メッセージの現在の = 0、メッセージの合計 = 100、現在のコンシューマー = 1 ノード 1 が 100 個のメッセージを処理したことがわかります。
jms2@dt メッセージの現在の = 100、メッセージの合計 = 100、消費者の現在の = 1 つまり、「重複した」メッセージがトピックで保留中です。

さらに 100 件のメッセージが送信され、100 件がノード 1 で処理され、200 件がノード 2 で保留されています。

node1 が再起動され、mdb@node2 が dt に再接続され、「保留中」メッセージの処理が開始されました。node2 で 200 件のメッセージが処理されました。

node1 が起動した後、mdb@node2 が接続されている間、mdb@node1 は dt に接続できません。

jms1@dt メッセージ現在 = 0、メッセージ合計 = 0、消費者現在 = 0
jms2@dt メッセージ現在 = 0、メッセージ合計 = 200、消費者現在 = 1

さらに 100 個のメッセージを送信します。100 個のメッセージすべてが node2 で処理され、node1 で破棄されていることがわかります。

jms1@dt メッセージの現在の値 = 0、メッセージの合計 = 100、消費者の現在の値 = 0
jms2@dt メッセージの現在の値 = 0、メッセージの合計 = 300、消費者の現在の値 = 1

node2 を再起動すると、mdb@node1 が dt に再接続します。再起動後、mdb@node2 は dt に再接続し、mdb@node1 は dt から切断されます。

jms1@dt メッセージ現在 = 0、メッセージ合計 = 100、消費者現在 = 1
jms2@dt メッセージ現在 = 0、メッセージ合計 = 0、消費者現在 = 1

100 個のメッセージを送信します。すべてが node2 で処理され、node1 のトピックに保存されます。

jms1@dt メッセージ現在 = 100、メッセージ合計 = 200、消費者現在 = 1
jms2@dt メッセージ現在 = 0、メッセージ合計 = 0、消費者現在 = 1

その後、node2 をシャットダウンすると、mdb@node1 がトピックに再接続した後、node1 で 100 個の「保留中のメッセージ」が処理されていることがわかります。

結果は次のとおりです。400 件のメッセージを送信し、700 件が MDB によって処理され、そのうち 300 件が重複していました。

MDB の再接続は期待どおりに機能しているように見えますが、「アクティブな」MDB をホストしているノードがダウンすると、メッセージが重複する可能性があります。

これは、weblogic JMS 実装のバグまたは機能である可能性があります。

私はnservicebushttp : //docs.particular.net/のドキュメントを考えに行きましたが、それでも私がやりたいことをどのように行うことができるか混乱しています。

私の目的は、Windowsサービスを利用してタスクを生成し、それらをキューに入れることです。一方、空きがあるときはいつでも、キューからタスクを取得し、メッセージで指定されたジョブを実行するコンシューマーが必要です。

誰かが私にいくつかのヒントを与えることができます、どうすれば続行できますか？

ありがとう

それぞれが数百のメッセージ（金融取引）を含むファイルを生成するレガシーシステムがあります。これらのメッセージを別の形式に変換し、ターゲットシステムに（個別に）送信する必要があります。問題は、ESBがこれらのファイルを直接処理するために受け入れるべきか、それともレガシーシステムとESBの間に、受信したファイルを個々のメッセージに分割し、ESBが（ファイル全体を処理するのではなく）メッセージを個別に処理できるようにするアダプターアプリケーションがあるべきかということです。 ）？

最初のソリューションでは、2つのESBフローが必要です。1つ目は、ファイルを新しい形式に変換し、メッセージに分割して、これらのメッセージを一時的な場所に保存します。ファイルには個々のメッセージの変換に必要ないくつかの共通セクションが含まれているため、変換ではファイル全体を処理する必要があります。2番目のフローは、変換された個々のメッセージを（それぞれ個別のDBトランザクションで）取得し、それらをターゲットシステムに渡し、その応答を（同期的または非同期的に）待機します。

2番目のソリューションは、最初のフローを、ファイルを変換し、変換された個々のメッセージに分割して一時的な場所（ローカルファイルシステム）に保存する外部アプリケーションに置き換えます。2番目のフローはESBに残ります。

私たちの目には、最初のソリューションの欠点は、ESBが（最初のフローで）巨大なファイルを処理する必要があることです。これは一般にアンチパターンと見なされます。一方、ESBは、ESBの目的の1つである、レガシーシステムのインターフェイスに直接適応します。

2番目のソリューションでは、アダプターアプリケーションに変換ロジックが含まれます。これは、ESBのもう1つの目的と責任です。

この状況（パターン）に対して一般的に提案される解決策は何ですか？私が見つけたこれらの2つのリンクよりも説明的な参考資料をいくつか提供していただけますか？

http://publib.boulder.ibm.com/infocenter/esbsoa/wesbv7r5/index.jsp?topic=%2Fcom.ibm.websphere.wesb.programming.doc%2Ftopics%2Fesbprog_patterns.html

https://www.ibm.com/developerworks/wikis/display/esbpatterns/File+Processing

別の参照を 編集します： http ：//www.ibm.com/developerworks/webservices/library/ws-largemessaging/

こんにちは、GregorHohpeとBobbyWoolfによるエンタープライズ統合パターンを経験しました。

http://www.eaipatterns.com/toc.html また、CamelとMuleがこれらの統合パターンに準拠していることも確認しました-

http://www.mulesoft.org/documentation/display/current/Understanding+Enterprise+Integration+Patterns+Using+Mule

http://camel.apache.org/enterprise-integration-patterns.html

MuleとCamelの両方で、SOAPやRESTなどのWebサービスを介してアプリケーションをデプロイおよびアクセスできるようになっています。SOAPはよりRPCスタイルです。これらは、CXFやJerseyなどのオープンソースユーティリティを使用した大規模な統合サポートを可能にします。実際、MuleはRMIエンドポイントもサポートしています。これにより、リモートメソッド呼び出し機能も提供されます。これは、広く受け入れられている統合形式です。ESBは他のプロトコルの追加サポートを備えたメッセージバスを中心に構築されていることを理解していますが、ESBはEIPにのみ準拠しており、EIPはESBだけではありません。

質問は、SOAP / RESTまたはそれらのトランスポートプロトコルが「統合スタイル」と見なされない理由であり、エンタープライズ統合であるため「メッセージ指向」であるのはなぜですか？

私はこれらのパターンを設計した偉大な頭脳と比較して初心者ですが、統合パターンの偏ったメッセージのような性質を理解しようとしています。スタックオーバーフローのQnA形式ではないことは認めますが、人々が意見を共有できるように、Modにしばらくの間それを存続させるように要求します。

パイプとフィルターの eip パターンをApache Camelで実装するために、PoC を実行しようとしています。

Camel documentationから、各フィルターをエンドポイントとして実装する必要があると想定しています（「Camelを使用すると、処理を複数の独立したエンドポイントインスタンスに分割して、チェーン化できます。」）

したがって、私の理解が正しければ、Authenticate フィルター (例から) はEndpoint インターフェイスを実装する必要があります。

「問題」は、「車輪の再発明」をしたくないということです。そのため、最初からインターフェースを実装する代わりに、すでに実装されているものを使用できるとほぼ確信しています。そして1つはBeanEndpointです。

そうですか？

パイプとフィルターのパターンの例をいくつか見つけました (このようなもの) が、いずれも Bean の実装方法を示していません。

誰かが Bean の実装例を提供できますか?

ティア、

ボブ

camel を使用するクラウド アプリケーションを開発しています。Web サービスによって消費される SQS キューにメッセージを送信します。アプリケーションのスケーリング時に各キャメル プロデューサー サービスを制御できるソリューションはありますか? つまり、ルートの開始/停止です。

.from("direct:A")Java メソッドのように動作します。つまり、それを呼び出すスレッドは継続しprocess()ます。

では、上記の場合はどうなるでしょうか?

スレッドが次に t1呼び出すとしましょうfrom("direct:A")

t1これからもprocess()

そしてt1入りますrecipientList()

ここから、wards がt1呼び出さfrom("direct:B")れ、from("direct:C")同期的に呼び出されます

また

direct:bdirect:c2 つの新しいスレッドで非同期に呼び出されます。

.from("direct:A")Java メソッドのように動作します。つまり、それを呼び出すスレッドは継続しsplitます。

では、上記の場合はどうなるでしょうか?

Ley say Threadt1呼び出しfrom("direct:A")

ここに入ると、メッセージは 2 つの新しいメッセージと.split()に分割されます。M1M2

ここから先は、同期的に ?をt1呼び出します。process()M1M2

また

process()2つの新しいスレッドで非同期に呼び出されM1ますか?M2

ヘッダーに特定の値 (100、101 など) を持つメッセージがあり、その値に応じて特定のアクションを実行する必要があります。

コンテンツベースのルーティング用に when/otherwise ブランチを使用してルートを記述できることはわかっています。私の質問は、約 400 の異なるケースがある場合はどうなるかということです。このような場合、ルーティングを管理するためのベスト プラクティスはありますか?

私は次のPOJOを持っています:

そして、次のルート (Spring XML):

どこmyPOJOFactoryにある：

( BeanMyPOJO内で作成された) インスタンスをその構成要素とプロパティに分割し、一方向と別の方向にルーティングする方法が必要です。myPOJOFactoryFizzBuzzFizzBuzz

スプリッターについての私の理解では、それは交換の本体を取り、それを 2 つ以上のオブジェクトのコレクションに分割するだけです。しかし、これは私が望んでいることではないと思います。構成要素とフィールドにMyPOJO「分割」したいのですが、それらを別の宛先にルーティングしたいからです。おそらく行き、行きます。FizzBuzzFizzdirect:fizzFarmBuzzdirect:buzzFarm

Content-Based Router ( )についての私の理解では、条件ロジックをルート<choice/>に追加できるということです。しかし、私が必要としているのは条件付きではないため、これも必要だとif-else-ifは思いません。MyPOJO#Fizzdirect:fizzFarmMyPOJO#Buzzdirect:buzzFarm

動的ルーターについての私の理解では、メッセージをさまざまな宛先に動的にルーティングしますが、その方法はまだよくわかりません。これが私が望むものだと思いますmyPOJOFactoryが、 Beanから出てくると、交換にはMyPOJOオブジェクトが含まれます。MyPOJO動的ルーターに送信する前に、最初に分割する必要があるように感じます。そうすれば、動的ルーターはメッセージが か かを明確に認識しFizz、Buzz正しくルーティングできます。

したがって、動的ルーターと組み合わせてスプリッターを使用する必要があると思います。木を通して森を見ているのではありません。このようなもの：

これをどのように達成できるかについてのアイデアはありますか (#1 と に分割MyPOJOしFizz、Buzz#2 ルーターをルーティングFizzしBuzzて別の宛先に設定する)?