最初に、あなたの注意をそらす前に、私の問題を解決するためのプロセスがどうあるべきかを書きます。私の問題と既存のセットアップはさらに下にあります。これは、将来の柔軟性を可能にするために起こるべきだと私が思うことです。お知らせ下さい：
- データベース トリガーは、レコードが作成または変更されると、SQL Service Broker および Oracle Advanced Queuing に入力します。
- プロセスは、SQL および Oracle メッセージ キューを監視し、ESB に送信します。
- 次に、ESB (UltraESB?、セットアップと理解が容易) はメッセージを真のメッセージ キュー (RabbitMQ? セットアップと理解が容易) に送信します。ESB は、エンリッチ、ルーティングなどを行う場合があります。
- 最後に、他のプロセスが RabbitMQ を使用し、新しいポリシー フォルダーの作成、ポリシー メタデータの更新などを DMS に指示します。
トリプル キューイング、MSSQL、Oracle、RabbitMQ はやり過ぎのように見えますが、一方で、それらはすべて異なることを実行します。
既存のセットアップ:
私はグリーンフィールド メッセージング/ESB/ミドルウェア/SOA 環境を持っており、最初に以下の問題を処理するために適切にセットアップしたいと考えています。
- LOB-A: MS SQL 2008 データベース上に Java で記述された保険アプリケーション
- LOB-B: Oracle 10.2 データベース上の Visual Basic 6 で作成された保険アプリケーション
- DMS: Microsoft SharePoint 2010
- 両方の LOB アプリは、今後 18 か月以内に置き換えられる可能性が高い
- 将来的には、CRM だけでなく、より多くの保険アプリが登場する可能性があります。
問題：
両方の LOB アプリは、新しいポリシーや顧客などが作成されたときと変更されたときに通知することによって、ドキュメント管理システムと対話する必要があります。変更のために LOB-A ソース コードにアクセスすることはできません。LOB-B のソース コードにはアクセスできますが、開発者は他のプロジェクトで忙しくしています。とにかく、レコードが変更された可能性があるアプリのソース コード内のすべての場所を見つけて、アプリケーション層を介してアラートを実行するよりも、レコードが変更されたときにデータベースが DMS にアラートを出す方が簡単だと考えています。
Database-as-IPC がアンチパターンであることは知っていますが、少なくとも SQL Server でこれを達成するための最良の方法に関する推奨事項を読みました: DB テーブルをメッセージ/ジョブ キューおよびhttp:/ として使用する最良の方法:/ /rusanu.com/2010/03/26/using-tables-as-queues/ . SQL Service Broker External Activationをポイント ツー ポイント方式で使用して、LOB-A から DMS を既に通知しています。
うわー！どう思いますか？