0

これに対する私の最初のアプローチは、アプリケーション A のデータベースでストアド プロシージャを使用し、挿入時にトリガーされて追加のデータを収集し、アプリケーション B によってホストされている Web サービスを呼び出して、そこで必要なマッピングと永続化を行うことでした。アプリケーション A とアプリケーション B が同じマシン上にない可能性があります。最初の要件は、アプリケーション A 側で SQL Server データベースをサポートすることです。CLR ストアド プロシージャが思い浮かびました。ただし、Web サービスを呼び出すと、SQL Server エンジンのパフォーマンスに深刻な影響が及ぶだけでなく、DBA が好まない手順のために権限の昇格が必要になると考えられていました。

データベースAになんらかの形で参照テーブルを作成し、そのデータをポーリングアプリケーションで消費し、アプリケーションBで一度処理したものをクリーンアップするという手順を考えています。データのポーリング。

アプリケーション A は Windows のみです。アプリケーション B は Windows、UNIX、または LINUX である可能性があるため、Java は当然の選択です。

4

1 に答える 1

0

あなたは私たちにあなたが検討したアプローチのリストを与えましたが、あなたはこの質問の1文のタイトル以外に、あなたが達成しようとしていること、あなたの目標は何かなどを正確に概説していません。要件を正確に明確にできますか？

アプリケーション間の非同期メッセージングの標準的な答えは、JMSを使用することです。アプリケーションAは、監査する必要のあるイベントがキュー内で発生するたびにメッセージをキューに配置し、アプリケーションBは、キューからのメッセージを特定の速度で消費するように作成されます（「リアルタイム」が必要な場合は、キューを頻繁にポーリングできます）。アプリケーションBは、これらのメッセージに対して必要なことをすべて実行できます。つまり、メッセージをデータベースに書き込んだり、別のWebサービスに送信したりできます。

このようにして、アプリケーションAのアクション（監査する対象）とアプリケーションBの動作（メッセージの監査方法）は、互いに完全に分離されます。これにより、反対側を変更せずに、どちらかの側で変更（新しいタイプのイベントの監査、メッセージのペイロードの変更、別の場所へのメッセージの出力など）を行うことができます。

また、両方のアプリケーションを互いに独立してスケーリングできます。Bに影響を与えることなくAのインスタンスを追加でき、AはBが消費するよりもはるかに高いレートでメッセージを生成でき、AはBがメッセージの消費を終了するのを待ちません。ユーザーのアクションに応答できるようになる前。

于 2010-08-12T13:14:01.870 に答える