2

最初に、あなたの注意をそらす前に、私の問題を解決するためのプロセスがどうあるべきかを書きます。私の問題と既存のセットアップはさらに下にあります。これは、将来の柔軟性を可能にするために起こるべきだと私が思うことです。お知らせ下さい：

  1. データベース トリガーは、レコードが作成または変更されると、SQL Service Broker および Oracle Advanced Queuing に入力します。
  2. プロセスは、SQL および Oracle メッセージ キューを監視し、ESB に送信します。
  3. 次に、ESB (UltraESB?、セットアップと理解が容易) はメッセージを真のメッセージ キュー (RabbitMQ? セットアップと理解が容易) に送信します。ESB は、エンリッチ、ルーティングなどを行う場合があります。
  4. 最後に、他のプロセスが 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 を既に通知しています。

うわー！どう思いますか？

4

1 に答える 1

3

免責事項: 私は、質問で言及されている UltraESB を構築する AdroitLogic の CTO です。

新しいアクションを実行するために、ESB 自体が MS SQL および Oracle データベースをポーリングするように簡単に設定できます。これは、cron スケジュールなどを指定して ESB でスケジュールすることも、単純な遅延 (たとえば、1 時間ごと) を指定することもできます。ESB はエンリッチ、変換、ルーティングなどを行うことができますが、どのレコードが正常に処理されたかを追跡する方法が必要になります。おそらく、ポーリングされたテーブルの新しい列でしょうか? ESB は未処理のレコードをポーリングし、期待どおりの処理を行い、それらを DMS にポストし、ステータスを成功または失敗として更新できるため、永続的なメッセージ キューは必要ありません。DMS が拒否するか使用できなくなる場合を除き、再試行する意味はありませんが、再試行することもできます。それも可能です。DMS がレコードを受け入れる場合、ESB はテーブルの列を直接更新できます。

于 2013-09-02T05:55:28.817 に答える