1日あたり約200万件のメッセージを処理するJMSベースのメッセージングアプリケーションがあります。
現在、全メッセージの60％、つまり1日あたり120万メッセージに影響を与える追加機能をリリースする必要があります。計画では、この追加機能のメッセージを転送する内部キューを作成します
これまでに考えられた2つの設計オプションは次のとおりです。
a）すべてのメッセージをメッセージドリブンBean（MDB）が処理する2番目のキューに転送します。これにより、最初のアプリケーションがこの機能が必要かどうかを知ることができなくなります。
b）元のアプリケーションでは、60％のボリュームのみをフィルターで除外し、それらを必要なキューに転送します。これにより、内部で不要なトラフィックを削減します。
つまり、基本的にデザインとボリュームのバランスをとる-どちらの方向に進むべきでしょうか？
オプションB.は将来あなたに頭を悩ますかもしれません。このようなフィルタリングロジックを2つのビジネスアプリケーション内に保持することは、めったに良い考えではありません。将来、2つのアプリケーションの新しいバージョンをトリガーするフィルタリングルールの変更について考えてください。
メッセージが小さくなければ、120万メッセージ/日はかなりの数です。システムがボリュームに対応できる場合、ソリューションA）は、時間の構築と処理が最も簡単です。私はいくつかの負荷テストを行い、すべてがうまくいけば、b）に進みます。
構築しているプラットフォームなどに応じて、多くのミドルウェアおよびメッセージング製品は、実際のアプリケーションではなく、ミドルウェアに適用できるロジックおよびフィルタリング機能を提供します。
[First Queue] -> Middleware, Copy All -> [Orig Appl. input queue]
, Filter -> [New application input queue]
たとえば、これは数行のXMLでApacheCamelを介して簡単に構成できます。