サービス品質 (QOS) 機能

サービス品質機能は CASA エディタから設定します。サービス品質機能には、再試行 (再配信) と制限の設定に使用されるプロパティーが含まれます。

この節の内容は次のとおりです。

• 「サービス品質プロパティーの設定」

• 「メッセージ制限: 設定と使用 」

• 「再配信: 設定と使用」

サービス品質プロパティーの設定

QOS 属性は QoS プロパティー設定エディタから設定します。このエディタには複合アプリケーションサービスアセンブリ (CASA) エディタからアクセスします。QoS プロパティー設定エディタへのアクセス方法の例については、「HTTP バインディングコンポーネントのエンドポイントの制限を設定する」を参照してください。

メッセージ制限: 設定と使用

制限を使用することにより、特定のエンドポイントで同時に処理されるメッセージの最大数を設定できます。メッセージ負荷やメッセージペイロードが増加すると、メモリー使用量の急増をまねき、パフォーマンスを低下させる可能性があります。制限によってリソースの消費が制限され、一貫したパフォーマンスが維持されます。

HTTP バインディングコンポーネントは、Grizzly HTTP Web サーバーで提供される機能を使用してメッセージのフローを管理します。つまり、エンドポイントを評価することにより、要求を中断すべき場合や通常どおり処理を再開すべき場合を判定します。

HTTP BC および制限の詳細については、HTTP BC Throttling を参照してください。

HTTP バインディングコンポーネントのエンドポイントの制限を設定する

HTTP バインディングコンポーネントの場合、制限は CASA エディタから設定される QOS 機能です。

HTTP/SOAP WSDL ポートの制限を設定する

1. NetBeans IDE の「プロジェクト」ウィンドウから、複合アプリケーションの下にある「サービスアセンブリ」ノードを右クリックし、ポップアップメニューから「編集」を選択します。

   CASA エディタが開き、ユーザーの複合アプリケーションが表示されます。

   

2. CASA エディタで、ユーザーの JBI モジュールと設定する WSDL ポートの間のリンク上にある QOS アイコンをクリックします。

   QoS プロパティーエディタが表示されます。

3. QoS プロパティーエディタで、ThrottlingExtension の下の maximumConcurrencyLimit のプロパティーフィールドをクリックし、このエンドポイントで同時に許可されるメッセージの最大数を表す整数を入力します。

   

4. 「閉じる」をクリックします。

   サービスアセンブリの構築時に、プロジェクトの jbi.xml ファイル内に接続の制限設定が適切に生成されます。

再配信: 設定と使用

再配信は、初回の配信が失敗した場合のメッセージ配信を処理するサービス品質機構です。再配信を使用することにより、システムでメッセージ配信を試行する回数、試行間隔、およびメッセージが配信不能な場合やエンドポイントが応答していない場合の最終結果を定義できます。

再配信は特定の接続に対して設定されます。設定するには、複合アプリケーションサービスアセンブリ (CASA) エディタからその接続の QoS アイコンをクリックします。これにより、その接続の「QoS プロパティー設定」が開きます。エディタの RedeliveryExtension セクションから、再配信のプロパティーを設定します。

再配信の設定パラメータは次のとおりです。

• maxAttempts: プロジェクトでメッセージの再配信を試行する回数を指定します。試行が失敗するたびに、JBI コンポーネントにエラー状態が返されます。

• waitTime: プロジェクトでメッセージの再配信を試行する間隔をミリ秒単位で指定します。

• on-failure: 再配信の試行が指定回数に達したときに実行するアクションおよびメッセージの送信先を指定します。このパラメータには、delete、redirect、suspend、および error の 4 つのオプションがあります。

  on-failure パラメータには、delete、redirect、suspend、および error の 4 つのオプションがあります。

  • delete: メッセージ再配信の最後の試行が失敗すると、QoS ユーティリティーはメッセージを削除し、JBI コンポーネントに Done 状態を返します。その時点で JBI コンポーネントは次のプロセスに進みます。delete オプションは In-Only メッセージ交換でのみサポートされます。

  • redirect: メッセージ再配信の最後の試行が失敗すると、QoS ユーティリティーは dead-message フォルダなどのユーザー定義のエンドポイントにメッセージをリダイレクトします。リダイレクトエンドポイントに正常に配信できた場合、QoS ユーティリティーは JBI コンポーネントに Done 状態を返します。その時点で JBI コンポーネントは次のプロセスに進みます。redirect オプションは In-Only メッセージ交換でのみサポートされます。

  • suspend: メッセージ再配信の最後の試行が失敗すると、JBI コンポーネントはプロセスインスタンスを中断します。このオプションは、JBI コンポーネントで監視が有効になっている場合のみサポートされます。これは、ユーザーが監視ツールを使用して中断されたインスタンスを再開する必要があるからです。このオプションは、In-Only と In-Out の両方のメッセージ交換でサポートされます。

  • error: メッセージ再配信の最後の試行が失敗すると、JBI コンポーネントは例外をスローします。このオプションは、JBI コンポーネントで監視が有効になっている場合のみサポートされます。これは、ユーザーが監視ツールを使用して中断されたインスタンスを再開する必要があるからです。このオプションは、In-Only と In-Out の両方のメッセージ交換でサポートされます。

注: on-failure の delete オプションと redirect オプションは、In-Out メッセージ交換には利用できません。In-Out メッセージ交換では、処理を進めるためにプロセスインスタンスから特定の応答が必要ですが、これらのオプションへの戻り値では十分ではないからです。

再配信の詳細については、Redelivery を参照してください。