JBossESB 内では、すべてが任意の障害によって影響を受けます。ご想像の通り、任意の障害を検出するのは本質的に大変困難です。任意の障害に対する耐性をシステムに持たせるプロトコルは存在しますが、何段階もの調整やデジタル署名が必要になる場合がほとんどです。JBossESB の今後のリリースでは、こうした方法の一部がサポートされる見込みです。

値、タイミング、脱落の障害にはアプリケーションに関するセマンティック情報が必要となることが多いため、JBossESB が直接このような障害タイプに対応できることは限られています。しかし、メッセージヘッダー内で RelatesTo や MessageID などの JBossESB の機能を正しく使用すると、アプリケーションによって、受信したメッセージが受信待ちのメッセージであるか遅延のメッセージであるかを判断することができます。一方向要求に対する非同期の一方向応答など、サービスによる提供が早すぎたメッセージは、基礎のトランスポート実装が原因で損失する可能性があります。たとえば、HTTP などのプロトコルを使用する場合、応答がアプリケーションに渡されるまで応答を保持できる有限のバッファーがあります (オペレーティングシステムレベルで設定される)。このバッファーの容量を越えると、新しいメッセージを保持するためバッファ内の情報が失われることがあります。この制限によって FTP や SQL などのトランスポートが必ずしも影響を受けるとは限りませんが、同様の動作を生じるような他のリソース制限を受ける可能性があります。

遅延のメッセージに対して耐性を持たせる方が早着のメッセージに対して耐性を持たせるより簡単な場合があります。しかし、アプリケーションの観点では、早着のメッセージが失われると (バッファーのオーバーフローなどにより)、無限に遅れるメッセージとの区別がつかなくなります。そのため、メッセージ損失の際に再試行のメカニズムを使用するようアプリケーション (コンシューマーとサービス) を構築する場合、コンシューマーが順序を無視して早い応答を受け取って不適切に処理するという例外 (これにより値の障害が発生します) にてタイミングと脱落の障害に対応できるようにします。メッセージヘッダー内で RelatesTo と MessageID を使用すると、ペイロード全体を処理しなくても不適切なメッセージシーケンスを見つけることができます (別のオプションを使用することもできます)。

同期された要求と応答の対話パターン内では、応答が一定の時間内に受信されないと RPC で構築されたシステムの多くは自動的に要求を再送信します。しかし、現在の JBossESB は自動的に再送信を行わないため、Couriers または ServiceInvoker 内でタイムアウトのメカニズムを使用し、いつメッセージを再送信するか（または再送信する必要があるか）を判断しなければなりません。高度なトピックの章にある通り、メッセージの配信に影響するようなサービスの障害発生が疑われる場合、そのメッセージを再送信します。

トランザクションの使用 (JBossTS で提供されるものなど) やレプリケーションプロトコル (JGroups のようなシステムで提供される) はこうした障害モデルの多くに対して耐障害性を持たせるのに役立ちます。さらに、障害が原因で先に進めない状態の場合、 トランザクションを使用するとアプリケーションのロールバックが可能になり、 基礎となるトランザクションシステムはまるでその作業がまったく試行されなかったかのように表示してデータの整合性を保証します。現在の JBossESB は JBoss Application Server 内にデプロイされると JBossTS を通じてトランザクション的なサポートを提供します。

理想的な障害検出機能とは、分散システム内でエンティティ (プロセスやマシンなど) の活発さをはっきりと判定できる機能のことです。しかし、障害が発生したシステムと応答が遅いシステムを区別することは不可能なため、一定時間内に障害の検出を保証するのは不可能です。

現在の障害検出機能は、エンティティが使用できるかを判断するためにタイムアウト値を使用します。たとえば、マシンが指定時間内に「are-you-alive?」というメッセージに応答しない場合、障害が発生したと想定します。こうしたタイムアウトに割り当てられる値が正しくない場合 (ネットワークの混雑などが原因で)、正しくない障害が想定され、一部のマシンが別のマシンの障害を「検出」するのに他のマシンは検出しないなど矛盾を招く可能性があります。したがって、ネットワークの混雑やマシンの負荷が最悪な場合など、使用される分散環境内で想定できる最悪の事態に対して、通常こうしたタイムアウトが割り当てられます。しかし、分散システムやアプリケーションが実行の度に予期した通りに動作することはまずありません。したがって、想定する最悪の事態が変化することも考えられる上、障害検出に対して間違った判断をする可能性は常にあります。

障害の検出を保証することは不可能ですが、既知のアクティブなエンティティは相互に通信することができるため、通信できないエンティティは障害が発生していると合意することができます。これが障害推測機能の動作になります。あるエンティティが別のエンティティに障害が発生していると予測した場合、残りのエンティティー間でプロトコルが実行され、障害発生の合意を問います。エンティティの障害発生に合意した場合、障害が発生していると見られるエンティティはシステムから除外され、その後このエンティティによる動作は許可されません。1 つのエンティティが障害の発生を予測しても、すべてのエンティティが同じような判断をするとは限りません。障害が発生していないエンティティがシステムから除外された場合は、別のプロトコルを実行して活動状態であることを認識させなければなりません。

障害推測機能の長所は、分散環境内で正しく機能しているすべてのエンティティが、障害の発生が疑われる別のエンティティの状態について合意することです。短所は、障害推測のプロトコルは重く、一般的に複数回の合意が必要となることです。また、タイムアウト値に基づいて障害が推測されるため、障害のないエンティティが除外されることもあり、(重大となる可能性のある) リソースの利用や可用性が低下します。

障害検出のメカニズムが時折、誤った答えを返す可能性があるという事実に耐性を持つことができるアプリケーションもあります。ただし、これ以外の他のアプリケーションの場合、エンティティが機能しているとの誤った判定はデータ破損などの問題を招くおそれがあり、ミッションクリティカルなアプリケーション (航空機制御システムや原子炉監視など) の場合などは人命に関わる結果となる可能性があります。

現在の JBossESB は障害検出または障害推測をサポートしていません。この短所については今後のリリースで対応していきたいと考えています。現在のところ、前述のような特定のサービスに障害が発生しているのかどうかを判定試行する技術 (MessageID およびタイムアウト／再試行) を使用するコンシューマー側とサービスは利用側で開発して頂く必要があります。アプリケーションに障害の検出から疑わしい障害の処理まで行わせた方がより効率的な場合もあります。

メッセージの紛失や遅延がどのようにアプリケーションに対して悪影響を与える可能性があるのかについては既に見てきました。また、JBossESB 内でどのようにメッセージがなくなってしまうのかについても例をいくつか見てきました。このセクションではメッセージ紛失についてもう少し詳しく見ていくことにします。

多くの分散システムがポイントツーポイント (1 コンシューマー側と 1 プロバイダー) またはグループベース (複数のコンシューマー側と 1 プロバイダ) で信頼できるメッセージ配信をサポートしています。一般的に信頼性に課されるセマンティックとは、たとえ障害が存在していてもメッセージが配信されるまたはメッセージが受信者に届かなかったことを確実に送信者が知ることができるということになります。信頼できるメッセージング実装を採用しているシステムは受信者にメッセージが配信されるのとそのメッセージが受信者によって処理されるのとは区別する場合が多く、たとえば、単にサービスにメッセージが届くというのと、サービスがメッセージの内容を処理する時間を確保する前にクラッシュが続けて発生した状況とは区別されます。

メッセージの配信や処理で前述の障害セマンティックを提供するトランスポートで、JBossESB 内で使用できるのは JMS のみです。トランザクション処理されるセッションでは (JMSEpr のオプション部分)、障害が存在していてもメッセージの受信や処理を保証することが可能です。サービスによる処理中に障害が発生した場合、メッセージが後で再処理されるよう JMS キューに戻されます。しかし、トランザクション処理されるセッションはトランザクション処理されないセッションより大幅に遅くなることがあるため、使用には注意が必要です。

JBossESB によってサポートされる他のトランスポートは、トランザクションや確実な配信についての保証がないため、メッセージが損失する可能性はあります。しかし、ほとんどの場合でメッセージ損失の可能性は低くなります。送信側と受信側の両方で同時に障害が発生しない限り (このような障害が発生することはまずありませんが、起こり得ます)、送信側は JBossESB によってメッセージ配信の障害に関する通知を受けます。処理中に受信側に障害が発生し、応答が予期されていた場合、受信側は最終的にタイムアウトするため再試行できます。

こうした理由から、高度なトピックの章に説明がある再配信プロトコルとメッセージフェールオーバーが最良のアプローチであると言えます。サービスの障害を予測すると、代替の EPR (1 つが利用可能と仮定) を選択して使用します。しかし、予測した障害が発生していなかった場合は、複数のサービスが同じメッセージで同時に動作する可能性があります。そのため、フェールオーバーにはロバストなアプローチですが、使用する場合は注意が必要です。このアプローチは、同じメッセージを複数回実行することと 1 回実行することが同じ場合など、サービスがステートレスで冪等である場合に最適なアプローチです。

多くのサービスおよびアプリケーションに対してこのタイプの再配信メカニズムは適切に動作します。単一の ERP 全体にわたり提供される堅固さは大きな利点となるでしょう。クライアントとサービスが失敗するまたはサービスに誤って障害が発生したとみなされるなど、動作しない状況の障害モードはかなり珍しいことになります。サービスをべき等にできない場合は、JBossESB がメッセージのトランザクション的配信か維持される結果のなんらかの形式をサポートするまで、 JMS を使用するかサービスが再送信を検出して同じ作業を同時に実行している複数のサービスに対処できるコードを使用してください。

これまで、障害の検出や予測を判断する難しさについて説明してきました。実際、クラッシュしたマシンと非常に動作の遅いマシンを区別するのは、障害が発生したマシンが回復するまで不可能です。ネットワークを分割して効果的に複数の個別のネットワークとして動作させるため、ネットワークをパーティション化することができます。しかし、ネットワークが分割されると、ネットワークの異なる部分に存在するコンシューマはその部分で利用可能なサービスしか見えなくなります。このような状態は「スプリットブレインシンドローム」とも呼ばれます。

JBossESB は、トランザクションまたは JMS などの、信頼性の高いメッセージ配信プロトコルを使用している場合、システム全体がシャットダウンするという突発故障からも回復できます。

トランザクションや確実なメッセージ配信プロトコルを使用しない場合、関係するエンドポイントの可用性が保証される場合のみ JBossESB は障害に対応できます。

本セクションでは JBossESB 内の特定のコンポーネントおよびサービスについて説明します。