キュー処理の利点

新しいアプリケーションを設計する場合、開発者は、リアルタイム (同期) 処理とキュー (非同期) 処理に対するコーディング コンポーネントの影響を考慮する必要があります。 選択は、基になるビジネス ロジックによって決定される特定のアプリケーションの要件によって異なります。 キュー処理のガイドラインとして、リアルタイム処理よりも優れた次の利点があります。

• コンポーネントの可用性に対する依存関係の低減
• コンポーネントの有効期間の短縮
• 切断されたアプリケーションを使用する場合の中断されることのない生産性
• メッセージの信頼性
• 効率的なサーバーのスケジューリング

コンポーネントの可用性

リアルタイム処理アプリケーションでは、たとえばサーバーの過負荷やネットワークの問題が原因で、トランザクションのコンポーネントが 1 つでも使用できない場合、プロセス全体がブロックされて完了することができません。 これに対し、COM+ キューに登録されたコンポーネント サービスを使用するアプリケーションは、トランザクションを、今すぐ完了する必要があるアクティビティと、後で完了できるアクティビティに分離します。 たとえば、メッセージを後で処理するためにキューに入れることで、要求コンポーネントを他のタスクに対して解放することができます。

コンポーネントの有効期間

キューに登録されたコンポーネント サービスを使用するアプリケーションでは、サーバー コンポーネントがクライアントから独立して動作することができます。 その結果、サーバー コンポーネントはより迅速に完了できます。 リアルタイムのシステムには、サーバー コンポーネントは、作成されてからオブジェクトが最終的に解放されるまで存在しています。 サーバーは、クライアントがメソッド呼び出しを行い、結果が返されるのを待ちます。このため、サーバー オブジェクトの迅速な循環が阻害され、サーバーのスケーラビリティが制限されます。

切断されているアプリケーション

ノート PC、ノートブック、小型コンピューターの利用が増え、時折切断されることがあるクライアントやモバイル ユーザーにサービスを提供するアプリケーションに対するニーズが生まれています。 キューに登録されたシステムでは、これらのユーザーは、切断されたシナリオやサーバーに接続されていない場合に作業を続けることができ、後でデータベースまたはサーバーに接続して要求を処理することができます。 たとえば、営業担当者は顧客から注文を受け取り、後で出荷部門に接続してそれらの注文を処理できます。

接続した状態か切断した状態のいずれかで実行できるコンポーネントがある場合、メッセージは 1 方向に移動するため、切り替えを行う必要はほとんどありません。 たとえば、受注シナリオでは、出荷コンポーネントはメッセージを受信して処理します。 課金または監査用に別のコンポーネントが生成される場合があります。 クライアントは、サーバーが起動する前にコミットします。 メッセージは、アプリケーションがコミットするまで送信されません。

次の図は、切断されたシナリオでの情報のフローを示しています。

メッセージの信頼性

メッセージ キューは、データベース手法を使用して堅牢な方法でデータを保護する強力なツールです。 サーバーの障害が発生した場合、メッセージ キューによってトランザクションがロールバックされ、メッセージが失われたり、データが破損したりするのを防ぎます。

サーバー のスケジュール設定

キュー コンポーネントを使用するアプリケーションは、重要でない作業をオフピーク期間にずらす、時間シフトのあるコンポーネントの実行に適しています。 これは、従来のバッチ モード処理に適用されたのと同じ便利な概念です。 同様の要求は、サーバーがさまざまな要求に直ちに対応することを要求するのではなく、サーバーによって連続して実行されるように延期させることができます。