リモート システムが、ミドルウェア (MQ) を介してアプリケーションにメッセージを送信します。
ミドルウェアでは、(xslt を使用した) 変換がこのメッセージに適用されます。再フォーマットされただけで、強化も検証もありません。私のシステムは、この変換されたメッセージの唯一のコンシューマーであり、xslt は私のチームによって維持されます。
このすべての元の作成者はとうの昔に亡くなっており、なぜ彼が私のアプリではなくミドルウェアで変換を行うのが良い考えだと思ったのか疑問に思っています。これをミドルウェアに移行することの価値がわかりません.
また、xslt はコンシューマーではなくメッセージ プロデューサーによって維持されると考えていたでしょう。
この種のアーキテクチャに関するガイドラインはありますか? 彼はここで正しいことをしましたか？
ミドルウェアでメッセージ本文を変更することはお勧めできません。これは、保守性とパフォーマンスに悪影響を及ぼします。
これを行う唯一の理由は、互換性のない 2 つのエンドポイントを変更せずに接続しようとすることです。これには、ソース コンテンツの変換が宛先エンドポイントによって理解される必要があります。
変換の実行をミドルウェアに委譲する動機は、政治的なものである可能性があります (エンドポイントはさまざまなチームによって維持されている、経営陣はエンドポイントのコードに触れることに消極的であるなど)。
さまざまなユーザーにさまざまな形式でデータを提供し、おそらくさまざまな形式でデータを受信する必要があるアプリケーション アーキテクチャを作成しようとしている場合 (天気予報やスポーツ ニュースを考えてください)、変換を実行できるハブを作成します。多くの異なるフォーマット間での使用は非常に理にかなっています。(それを「ミドルウェア」と呼ぶかどうかはあなた次第です。)おそらく、前任者はこの種のアーキテクチャを念頭に置いていましたが、設計を正当化するほど大きくも複雑にもなりませんでした。
アーキテクチャの観点から、バイナリ形式を使用することでパフォーマンスが大幅に向上しない限り、xslt などの人間が読める形式のメッセージまたはコンテンツのコンシューマを提供することをお勧めします。
人間が読める形式の場合、メッセージを見て、メッセージが正しいことを確認するだけです。バイナリの場合、バイナリ メッセージを人間が読める形式に変換するユーティリティを開発する必要があります。このようなユーティリティのさまざまな実装者は、常にバイナリ形式を意図したとおりに解釈するとは限らず、誰が、または何が正しいかについて、責任追及の練習になる可能性があります。
また、キューに何が入っているかを調べる場合、メッセージが人間が読める形式であれば、より簡単に理解できます。
人間が読める形式から始めて、最初にアプリを動作させることは問題ありません。次に、アプリのプロファイリングを行い、全体像で変換ルーチンが遅延の重大な原因であるかどうかを確認します。はいの場合は、バイナリ形式に進みます。
元のメッセージ プロデューサに xslt 形式でメッセージを提供してもらうことが望ましいと思われますが、それを行ったときに行ったことを行うには十分な理由があったに違いありません。たとえば、潜在的に他のコンシューマー、xslt が存在しなかった、リソースの制約など。
adaptor設計パターンについて読むと、現在のシステム アーキテクチャの意図が理解できます。