0

それぞれが数百のメッセージ（金融取引）を含むファイルを生成するレガシーシステムがあります。これらのメッセージを別の形式に変換し、ターゲットシステムに（個別に）送信する必要があります。問題は、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/

4

2 に答える 2

0

SOA には、コマンド、イベント、ドキュメントの 3 つのメッセージ タイプがあることに注意してください。

その「ドキュメント」ビットは、データのチャンク用です。おそらく、'Order' や 'Invoice' などの '実際の' ドキュメント タイプにより適していますが、'TransactionBatch' を使用することを妨げるものは何もありません。

そうは言っても、多くのサービスバスが実際にそれに関するものを実装していないという点で、それはかなり使用されていないメッセージタイプです。

  • あなたは本当にそれを必要としません
  • 多くのメッセージ キューイング テクノロジでは、メッセージ サイズに制限があり (4kb 程度)、大きなメッセージを転送することが難しくなっています (チャンクで送信する必要があります)。

したがって、あなたのシナリオで私が行うことは、ファイルを処理するエンドポイントを用意することです。したがってProcessTransactionFileCommand、処理エンドポイントに送信されたようなもので、実際のファイルへの参照しかありません（ファイルシステムのどこかに保存されているか、ダウンロード元のURLさえあります）。その処理エンドポイントは、ファイルを処理し、個々のメッセージを (すべてトランザクション内で) 統合エンドポイントに送信できます。統合エンドポイントは、メッセージを外部システムに送信します。あなたはそれをSendTransactionCommandする必要があります。

このように、処理エンドポイントがバッチを処理して個々の統合コマンドに分割できる一方で、統合エンドポイントがソリューションの一部から個々の統合コマンドを受信できるという点で、システムは非常に柔軟です。

.NET スペースにいる場合は、私の FOSS サービス バス プロジェクトを参照してください: http://shuttle.codeplex.com/

ただし、どのサービス バスでもうまく機能します (MassTransit、NServiceBus など)。

于 2012-10-30T04:35:38.910 に答える
0

最初のケースでは ESB を使用できますが、それがアンチパターンになるとは思いません。ESB の目的は、ユース ケースのように出力としてファイルを作成するレガシー アプリケーションを他のアプリケーションと統合することでもあります。

Mule ESB を試すことができます。ストリーミングを使用して (ファイル トランスポートを介して) ファイルを消費し、DataMapper と呼ばれる GUI を使用してファイルのコンテンツを目的の出力にマップし、最終的にこれらのメッセージを VM キューに入れることができます。VM キューは ESB 内の永続的なキューにすることができます。 . このキューはトランザクション対応であるため、1 つのファイルから作成されたすべてのメッセージが VM キューに置かれたか、まったく置かれていないかを保証できます。次に、別のフロー (実際、ESB 内で処理されるフローはミュールではフローと呼ばれます) から、これらのメッセージをそれぞれ読み取って処理できます。

HTH、パブロ。

于 2013-05-17T17:59:33.180 に答える