| Oracle Communication and Mobility Server管理者ガイド 10gリリース3（10.1.3） B50835-01 |
|
 戻る |
 次へ |
この章では、Oracle Communication and Mobility Server（OCMS）の概要について説明します。
プレゼンスは、エンドユーザーがコールを受け取る意思と状況を表します。クライアントのプレゼンスは連絡先管理リストとして表されることが多く、ユーザーの状況がアイコンで表示されます。これらのアイコンは、ユーザーの状況だけでなく、ユーザーのロケーション、連絡手段、または現在のアクティビティも表し、ユーザー間の効率的な通信を可能にします。
Presenceアプリケーションを使用することで、サービス・プロバイダはエンド・ユーザーまでプレゼンス・サービスを拡張できます。また、他のサービスでプレゼンス情報を利用できます。Presenceアプリケーションに登録されているMBeanを使用することで、プレゼンス情報の受付け、格納、配布を行うPresenceサーバーを構成できます。第1章「Oracle Communication and Mobility Serverの概要」の「Presenceサーバー」も参照してください。
PresenceアプリケーションMBeanを使用すると、次のものを管理できます。
プレゼンス・ステータスのパブリケーション
プレゼンティティは、プレゼンス状態を含むPIDF（Presence Information Data Format）ドキュメントをPresenceサーバーにパブリッシュできます。
プレゼンス・ステータスのサブスクリプション
Presenceサーバーは、ユーザーのステータスへのサブスクリプションをサポートします。ウォッチャ（サブスクライバ）がユーザーのステータスの表示を認可されると、Presenceサーバーはユーザーに通知します。また、Presenceサーバーは、新しいプレゼンス・ドキュメントのパブリケーションをすべてのアクティブで認可済のウォッチャに通知します。
Watcher-Infoのサポート
Presenceサーバーを使用すると、プレゼンス情報をパブリッシュしているユーザーは、ユーザーのプレゼンス情報を現在サブスクライブしているすべてのウォッチャの情報を受け取るために、watcher-infoイベントをサブスクライブできます。また、Presenceサーバーは、サブスクリプションの開始や終了など、ウォッチャのサブスクリプションの変更をユーザーに通知します。
サブスクリプションのプレゼンスXDMS認可
ウォッチャがユーザーのプレゼンスをサブスクライブするたびに、Presenceサーバーは、サブスクライバが必要な認可を持っているかどうかを調べるためにパブリッシャが設定している認可ポリシーをチェックします。
一致するルールが見つからない場合、サブスクライバは保留状態に置かれ、ウォッチャ情報通知がパブリッシャに送信されます。通常は、パブリッシャのクライアント（ユーザー・エージェント）がポップアップ・ボックスを表示し、保留中の新しいサブスクライバを受け入れるか拒否するかを尋ねます。返答は、このサブスクライバに対するルールの形式で、パブリッシャの認可ポリシー・ドキュメントに追加されます。その後、ドキュメントは、HTTPを使用してXDMS上でクライアントにより更新されます。ドキュメントが更新されると、Presenceサーバーは新しいポリシー・ドキュメントを読み込んで新しいルールを適用し、それに従ってサブスクリプション状態を変更します。
プライバシ・フィルタ処理
プライバシ・フィルタ処理ルールを作成して、ユーザーを許可またはブロックできます。
プレゼンスのハード状態
ハード状態機能を使用すると、他のドキュメントがないときにウォッチャに通知するドキュメントを、XDMSに残すことができます。通常、この機能は、「休暇中」などのオフライン・メモを残すために使用します。
複数のプレゼンス・ソースの結合
いずれもプレゼンス・ドキュメントをパブリッシュする複数のクライアント（PCと携帯電話など）がある場合、Presenceサーバーは複数のドキュメントを、複合ポリシーの指示に従って統合できます。Presenceサーバーは、デフォルトのポリシーと、OMA（Open Mobile Alliance）プレゼンス・イネーブラに従って統合を実行するポリシーという、2種類の統合ポリシーをサポートします。
デフォルトの統合ポリシーは、単純ですが堅牢なアルゴリズムです。<dm:timestamp>要素がない場合は<dm:person>要素と<dm:device>要素に追加し、<pidf:timestamp>要素がない場合は<pidf:tuple>要素に追加します。
Presenceサーバーは、候補ドキュメントを作成するとき、ソース・ドキュメントからすべての<pidf:tuple>要素と<dm:device>要素を取り込みます。ただ1つの<dm:person>要素を候補ドキュメントに追加し、<dm:timestamp>要素に基づいてパブリッシュされている最新の要素を使用します。他のすべての<dm:person>要素は無視されます。
次のMBeanを構成すると、プレゼンスが有効になります。
PresenceApplicationDeployer
次のMBeanを使用すると、XDMS（XML Document Management Server）を構成できます。
|
注意: 次のMBeanの属性を変更した場合は、OCMSを再起動して変更を有効にする必要があります。
|
Bus MBeanは、スレッド・プール、ジョブ・キューの高位と低位の水位標、および通知がディスパッチされる前にジョブがキューに留まる期間を設定することで、プレゼンスをサポートします。表7-1では、Bus MBeanの属性について説明します。
表7-1 Bus MBeanの属性
| 属性 | 値の型 | 説明 |
|---|---|---|
|
HighWatermark |
int |
Busの不足しきい値レベルに達するまでの保留ジョブ数の上限。デフォルト値は20です。 |
|
KeepAlive |
long |
削除する前にアイドル状態のスレッドをアライブに維持する秒数（現在のスレッド数がMinThreadsに指定されている値を超えている場合）。デフォルト値は60です。 |
|
LogDuration |
long |
イベントがキューに保持されている期間（秒単位）。キューのイベントの保留期間が、バスにブロードキャストされるまでの指定期間を超えると、システム・ログに警告が記録されます。この警告は、古いジョブがバスに送信された後に、サーバーがオーバーロード状態になろうとしていることを示します。デフォルト値は60です。 |
|
LowWatermark |
int |
保留中のジョブ数の低位しきい値レベルを指定します。低い値からこのしきい値に達した場合は、まもなく一杯になるということを示す警告が記録されます。この時点では、高位水位標レベルに達するまで、それ以上の警告は記録されません。デフォルト値は15です。 |
|
MinThreads |
int |
スレッド・プールに保持するスレッドの最小数。使用中のスレッドがない場合、将来のジョブに対応できるように、指定されている数のスレッドがアイドル状態になります。デフォルト値は15です。 |
|
MaxThreads |
int |
スレッド・プールに保持するスレッドの最大数。指定されている数のスレッドがジョブで使用されている場合、それ以降のジョブはキューに格納され、スレッドが利用できるようになってから処理されます。デフォルト値は10です。 |
PresenceEventPackage、PresenceWInfoEventPackage、UA-ProfileEventPackageの各MBeanを使用すると、通知者がウォッチャ（サブスクライバ）に報告する状態情報を定義しているイベント・パッケージを構成できます。ほとんどのリクエストがこれらのパッケージを通過するため、これらのパッケージはPresenceサーバーの中核を形成します。
通知者はユーザー・エージェント（UA）であり、リソース（ウォッチャが状態情報を要求するエンティティ）の状態をサブスクライバに警告するNOTIFYリクエストを生成します。通知者は、通常、サブスクリプションを作成するSUBSCRIBEリクエストを受け取ります。ウォッチャは別の種類のUAであり、通知者が発行するNOTIFYリクエストを受け取ります。このようなリクエストには、ウォッチャが関心を持っているリソースの状態に関する情報が含まれます。ウォッチャは、通常、SUBSCRIBEリクエストも生成し、それを通知者に送信してサブスクリプションを作成します。
PackageManager MBeanは、PresenceEventPackage、WatcherinfoPackage、UA-ProfileEventPackageの各MBeanの構成を設定します。表7-2では、PackageManger MBeanの属性について説明します。
表7-2 EventPackages MBeanの属性
| 属性 | 説明 |
|---|---|
|
CaseSensitiveUserPart |
この属性をtrueに設定すると、SIP URIのユーザー部分の処理で、大文字と小文字の区別が有効になります。このパラメータをfalseに設定すると、URIのユーザー部分は大文字と小文字が区別されません。たとえば、fooはFoOと同じものとみなされます。URIのドメイン部分は、常に大文字と小文字が区別されません。 |
|
EventPackageNames |
イベント・パッケージ名のカンマ区切りリスト。たとえば、presence,presence.winfo,ua-profileなどです。 |
|
WaitingSubsCleanupInterval |
サブスクリプション・クリーンアップ・チェックを実行する間隔（秒単位）。スレッドは、この期間だけスリープしてから起動し、タイムスタンプがMaxWaitingSubsTimeHoursパラメータより古い待機中のサブスクリプションをチェックします。古いサブスクリプションはすべて、サブスクライブされているリソースから削除されます。 |
|
Max WaitingSubsTimeHours |
サブスクリプションが削除前に待機状態を維持できる最大期間（時間単位）。このパラメータは、サブスクリプション・クリーンアップ・チェック・スレッド（ |
Presence MBeanは、Presenceサーバーが、プレゼンス・サービスにプレゼンス情報を提供するパブリッシュ・ユーザー・エージェント（PUA）であるプレゼンティティと対話する方法を制御します。属性（表7-3で説明）には、ユーザーが複数のクライアントからプレゼンス・ドキュメントをパブリッシュしている場合に統合ドキュメントを作成するための複合ポリシーの設定、ブロッキングの設定、フィルタリング、およびプレゼンスのハード状態などに関するものが含まれます。
表7-3 Presence MBeanの属性
| 属性 | 説明/値 |
|---|---|
|
CompositionPolicyFilename |
複合ポリシー・ドキュメントのファイル名。値には、OCMS複合ポリシーの場合は |
|
DefaultSubHandling |
認証済ユーザーに対するプレゼンス・ルールが見つからない場合にサーバーが下すデフォルトのサブスクリプション認可の決定。次の値が定義されています。
認証済ではないユーザーは、ルールが見つからない場合は常にブロックされます。詳細は、プレゼンス・ルールのIETF SIMPLEドラフトの「Chapter 3.2.1: Subscription Handling」を参照してください（ |
|
DocumentStorageFactory |
|
|
DocumentStorageRootUrl |
ドキュメント・ストレージのシステムID。ファイル・ストレージの場合は、ドキュメントが格納されているルート・ファイルのURLパスです。このディレクトリの内容は、サーバーの再起動時に削除する必要があります。デフォルト値はfile:/tmp/presencestorage/です。 |
|
DocumentStorageType |
プレゼンス・ドキュメント用に使用するストレージの種類。ユーザーの数が多い場合は、プレゼンス・ドキュメントをファイルに格納することをお薦めします。有効な値は次のとおりです。
デフォルト値はmemoryです。 |
|
HttpAssertedIdentityHeader |
PresenceサーバーからXDMSへのすべてのHTTPリクエストで使用されるAsserted Identityヘッダーの種類。この属性には、XDMSで期待される値を設定します。有効な値は次のとおりです。
|
|
PidfManipulationAuid |
PIDF（Presence Information Data Format）の操作に対するアプリケーションの使用状況のID。デフォルト値はpidf-manipulationです。 |
|
PidfManipulationDocumentName |
pidf操作のアプリケーション使用状況のドキュメント名。たとえば、hardstateなどです。ルールが見つからない場合、認証済でないユーザーはブロックされます。URIにIPアドレスではなくドメイン名が含まれる場合は、DNSサーバーを構成する必要があります。デフォルト値はhardstateです。 |
|
PidfManipulationEnabled |
true（デフォルト値）に設定すると、PIDF操作が有効になります。 |
|
PidfManipulationXcapUri |
pidf操作のアプリケーション使用状況に対するXDMSのSIP URI。デフォルト値はsip:127.0.0.1;transport=TCP;lrです。サーバーが正しく機能するためには、SIP URIにloose route（lr）パラメータが含まれる必要があります。 |
|
PoliteBlockPendingSubscription |
保留中のサブスクリプションを丁重にブロックする必要がある場合は、trueに設定します。この機能は、保留中のサブスクリプションのあるプレゼンス・ウォッチャからプレゼンティティを隠し、かわりに偽のプレゼンス・ドキュメントを送信するために使用します。falseに設定すると、サブスクリプションは保留のまま残ります。 |
|
PresRulesAuid |
presrulesに対するアプリケーション使用状況のID。デフォルトはpres-rulesです。 |
|
PresRulesDocumentName |
presrulesアプリケーション使用状況のドキュメント名。デフォルト値はpresrulesです。 |
|
PresRulesXcapUri |
プレゼンス・ルール・アプリケーション使用状況に対するXDMSのSIP URI。デフォルト値はsip:127.0.0.1;transport=TCP;lrです。サーバーが正しく機能するためには、SIP URIにloose route（lr）パラメータが含まれる必要があります。 |
|
PrivacyFilteringEnabled |
trueに設定すると、プライバシ・フィルタ処理が有効になります。falseに設定すると、フィルタ処理は無効になります。プライバシ・フィルタ処理を無効にすると、ユーザーのプレゼンスを見ることを許可されたすべてのサブスクリプションが、そのプレゼンティティに対してパブリッシュされているすべてのものを常に見ることができます。 |
|
TransformerFactory |
|
表7-4では、PresenceEventPackage MBeanの属性について説明します。プレゼンス・イベント・パッケージには、publishとsubscribeという2つのサブグループがあります。各サブグループにはminexpiresおよびmaxexpiresというパラメータがあり、Presenceサーバーによって受け付けられたパブリケーションまたはサブスクリプションの有効期限を設定します。クライアントは、パブリケーションまたはサブスクリプションの有効期限がいつまでかを示します。クライアントが構成済のminexpiresより短い有効期限を送信すると、サーバーは423（サブスクリプションが短すぎる）のレスポンスを返します。クライアントが構成済のmaxexpiresより長い有効期限を送信すると、サーバーはレスポンスでmaxexpiresの時間を返します。パブリケーションまたはサブスクリプションのアライブ状態を維持するには、クライアントは有効期限内にrepublishまたはresubscribeをサーバーに送信します。クライアントは、パブリケーションまたはサブスクリプションのライフサイクルの期間中、このタスクを繰り返し実行する必要があります。
表7-4 PresenceEventPackageの属性
| 属性 | 値/説明 |
|---|---|
|
説明 |
PresenceEventPackageの説明。たとえば、「The event package that enables presence」などです。 |
|
DocumentFactory |
|
|
EscMaxDocumentSize |
パブリケーションのコンテンツの最大サイズ（バイト単位）。指定されているサイズより大きいドキュメントをクライアントがパブリッシュしようとすると、サーバーは413のレスポンス（リクエスト・エンティティが長すぎる）を送信します。デフォルト値は10000です。 |
|
ESCMaxExpires |
パブリケーションの有効期限の最大値（秒単位）。デフォルト値は3600です。 |
|
ESCMaxPubPerRes |
リソースごとに許されるパブリケーションの最大数。新しいパブリッシュを受け取ったときにリソースの最大数に達している場合、サーバーは503のレスポンス（サービス使用不可）を送信します。 |
|
ESCMinExpires |
パブリケーションの有効期限の最小値（秒単位）。デフォルトは60です。 |
|
EventStateCompositor |
|
|
Name |
イベント・パッケージの名前。デフォルト値はPresenceです。 |
|
Notifier |
|
|
NotifierMaxDocumentSize |
SUBSCRIBEの最大サイズ。 |
|
NotifierMaxExpires |
SUBSCRIBEの有効期限の最大値（秒単位）。デフォルトは3600です。 |
|
NotifierMaxNoOfSubsPerRes |
リソースごとに許されるサブスクリプションの最大数。リソースの最大数に達した場合、サーバーは、新しいプレゼンス・サブスクライブを受け取ると、503のレスポンス（サービス使用不可）を送信します。 |
|
NotifierMinExpires |
SUBSCRIBEの有効期限の最小値（秒単位）。 |
|
ResourceManagerClassName |
ResourceManagerクラスの名前。デフォルト値は |
RFC 3857で記述されているように、ウォッチャ情報イベント・パッケージは、別のイベント・パッケージのリソースを監視して、そのリソースに対するすべてのサブスクリプションの状態を確認します。その後、この情報は、ウォッチャ情報イベント・パッケージのサブスクリプションに送信されます。その結果、サブスクライバは監視対象のリソース・サブスクリプションでの変化を認識します。
PresenceWInfoEventPackage MBean（表7-5で説明）は、ウォッチャ情報イベント・パッケージに対するサブスクリプション状態情報を設定します。
表7-5 WatcherinfoEventPackageの属性
| 属性 | 説明/値 |
|---|---|
|
説明 |
PresenceWInfoEventPackageの説明。たとえば、「The event package that enables watcherinfo」などです。 |
|
DocumentFactory |
|
|
Name |
イベント・パッケージの名前。デフォルト値はpresence.winfoです。 |
|
Notifier |
|
|
NotifierMaxDocumentSize |
SUBSCRIBEの最大ドキュメント・サイズ。 |
|
NotifierMaxExpires |
SUBSCRIBEの有効期限の最大値（秒単位）。デフォルトは3600です。 |
|
NotifierMaxNoSubsPerRes |
リソースごとに許されるサブスクリプションの最大数。リソースの最大数に達した場合、サーバーは、新しいプレゼンス・サブスクライブを受け取ると、503レスポンス（サービス使用不可）を送信します。デフォルト値は100です。 |
|
NotifierMinExpires |
SUBSCRIBEの有効期限の最小値（秒単位）。 |
|
ResourceManagerClassName |
|
表7-6では、UA-ProfileEventPackage MBeanの属性について説明します。
表7-6 UA-Profileイベント・パッケージの属性
| 属性 | 説明/値 |
|---|---|
|
説明 |
UA-ProfileEventPackageの説明。デフォルト値は、「The event package that enables the ua-profile」です。 |
|
Document Factory |
|
|
Name |
イベント・パッケージの名前。デフォルト値はua-profileです。 |
|
Notifier |
|
|
NotifierMaxDocumentSize |
SUBSCRIBEの最大ドキュメント・サイズ。 |
|
NotifierMaxExpires |
SUBSCRIBEの有効期限の最大値（秒単位）。デフォルトは6000です。 |
|
NotifierMaxNoOfSubsPerRes |
リソースごとに許されるサブスクリプションの最大数。リソースの最大数に達した場合、サーバーは、新しいプレゼンス・サブスクライブを受け取ると、503レスポンス（サービス使用不可）を送信します。デフォルト値は100です。 |
|
NotifierMinExpires |
SUBSCRIBEの有効期限の最小値（秒単位）。デフォルト値は60です。 |
|
ResourceManager |
ResourceManagerクラスの名前。デフォルト値は次のとおりです。
|
UserAgentFactoryService MBeanは、ユーザー・エージェント・ファクトリ・サービスに対するコマンドを設定します。Presenceサーバーは、ユーザー・エージェント・ファクトリを使用して、プレゼンス用のXDMSに格納されているXMLドキュメントの変更をサブスクライブします。
表7-7 UserAgentFactoryService MBeanの属性
| 属性名 | 説明/値 |
|---|---|
|
DNSNames |
ユーザー・エージェントが使用するDNS（Domain Name System）のIPアドレスのカンマ区切りリスト。 |
|
IpAddress |
ユーザー・エージェント・クライアントのIPアドレス。現在のシステムのデフォルト・ネットワーク・インタフェースの場合は、空の文字列（デフォルト設定）を使用します。 |
|
PreferredTransport |
PresenceサーバーとXDMSの間の通信を可能にする優先転送プロトコル。デフォルト値はTCPです。有効値はTCPとUDPです。 |
|
Port |
ユーザー・エージェント・クライアントのIPポート。デフォルト値は5070です。 |
Command Service MBeanは、XDMSに対するユーザー・プロビジョニングを有効にします。詳細は、「CommandService」を参照してください。
XCapConfig MBeanは、XDMSの構成、ユーザー・プレゼンス・ルール（pres-rules）を含むXCAP（Extensible Markup Language Configuration Access Protocol）ドキュメントのリポジトリ、およびハード状態情報を制御します。XDMSがOCMSの外部にある場合は、XCapConfig MBeanの設定は無視できます。
表7-8 XCapConfig MBeanの属性
| 属性名 | 説明/値 |
|---|---|
|
CreateNonExistingUserstore |
ドキュメントを格納するときにユーザー・ストアが存在せず、ユーザー・ストアを作成する場合は、trueに設定します。それ以外の場合は、falseに設定します。このパラメータがfalseに設定されている場合、存在しないユーザーのドキュメントをクライアントが格納しようとすると、格納は失敗します。このパラメータがtrueに設定されている場合は、まずXDMSにユーザーを作成してから、ドキュメントを格納します。デフォルト値はtrueです。 |
|
MaxContentLength |
XDMSドキュメントの最大サイズ（単位はバイト）。XDMSドキュメントのデフォルトの最大サイズである1 MB（約1 KBの連絡先1000件）を推奨しますが、ドキュメントのサイズは増減できます。ドキュメント・サイズを増やす場合、（XDMSドキュメント）×（ユーザー数）×（アプリケーション数）に見合う十分なディスク容量があることを確認してください。ドキュメント当たりのサイズを小さくする場合は、この計算は、（ リソース・リスト・ドキュメントのデフォルト・サイズも1 MBです。 |
|
PersistenceRootUrl |
永続記憶域の場所。単一ノード・インスタンスを実行している場合は、デフォルト値jpa:oc4を使用します。これにより、デフォルトのキャッシングが提供されます。 単一インスタンスで実行しているPresenceサーバーを含む、複数ノードによるプレゼンス・トポロジを実行している場合は、値jpa:multinodeを使用します。 |
|
PidfManipulationAuid |
PIDF（Presence Information Data Format）の操作に対するアプリケーションの使用状況のID。デフォルト値はpidf-manipulationです。 |
|
PidfManipulationDocname |
pidf操作のアプリケーション使用状況のドキュメント名。たとえば、hardstateなどです。ルールが見つからない場合、認証済でないユーザーはブロックされます。URIにIPアドレスではなくドメイン名が含まれる場合は、DNSサーバーを構成する必要があります。 デフォルト値はhardstateです。 |
|
PresRulesAU |
pres-rulesアプリケーションの使用状況の名前。デフォルト値はpres-rulesです。 |
|
PresRulesDocName |
pres-rulesドキュメントの名前。デフォルト値はpresrulesです。 |
|
PublicContentServerRootUrl |
パブリック・コンテンツ・サーバー・ルートに対するURLです。URLには、コンテンツ・サーバーのパブリックURLを設定する必要があります（つまり、認証HTTPプロキシ・サーバーのURL）。 |
|
PublicXCAPRootUrl |
パブリックXDMSルートのURLです。http://<your.xdms.domain.com>/services/と入力します。たとえば、http://127.0.0.1:8080/servicesなどです。このパラメータに定義されているURLは、コンテンツ・サーバー（XDMSとは異なるサーバーに存在してもかまいません）のロケーションをクライアントに提供します。XDMSは、このURLを、発信NOTIFYメッセージのContent-Typeヘッダーに設定します。たとえば、XDMSからPresenceサーバーに送られる次のNOTIFYメッセージのContent-Typeヘッダーでは、pres-rulesドキュメントの本体が外部に格納されていることが示され、ドキュメントを取得するための指示もURL内に含まれています。 CSeq: 1 NOTIFY From: <sip:bob_0@144.22.3.45>;tag=66910936-0e31-41b2-abac-10d7616d04ef To: <sip:bob_0@144.22.3.45>;tag=ffa3e97bd77f91e6ca727fbf48a5678b Content-Type: message/external-body;URL="http://127.0.0.1:8888/contentserver/pres-rul es/users/bob_0@144.22.3.45/presrules";access-type="URL" ... Event: ua-profile;document="pres-rules/users/sip:bob_0@144.22.3.45/presrules";profile -type=application;auid="pres-rules" |
|
RequireAssertedIdentity |
すべてのHTTP/XDMSリクエストでAsserted Identityヘッダーが必要な場合は、trueに設定します。それ以外の場合は、このパラメータをfalseに設定します。この属性をtrueに設定すると、すべてのXCAPトラフィックがAggregation Proxyによって認証を受ける必要があります。この属性をtrueに設定した場合は、Asserted Identityのない着信XCAPリクエストはアクセスを拒否されます。 |
OCMSを使用すると、Webサービス・クライアントは、『Open Service Access, Parlay X Web Services』、Part 14、Presence ETSI ES 202 391-14で定義されているParlay X Presence Web Serviceのサポートを通して、プレゼンス・サービスにアクセスできます。Parlay X Web Serviceにより、HTTP Webサービス・クライアントは、プレゼンス情報をパブリッシュおよびサブスクライブするプレゼンス・サービスにアクセスできます。Parlay X Presence Web Serviceを使用すると、開発者は、SIPプロトコルのことをよく知らなくても、このようなWebベースのクライアントを開発できます。Parlay Xを使用することで、開発者はWebサービスの知識を使用してこのクライアントを作成できます。
Presence Web Servicesアプリケーションは、Presenceアプリケーションの子アプリケーションとしてデプロイされ、Webサービス・デプロイメント・サーバーの構成を可能にする次のMBeanを含みます。
Presence Web ServicesアプリケーションにはPresenceSupplierWebServiceおよびPresenceConsumerWebServiceのMBeanも含まれます。これらには、プレゼンス・コンシューマおよびプレゼンス・サプライヤ・インタフェースのOCMS実装を通して可能になるプレゼンス・パブリケーションおよびウォッチャ・サブスクリプションを管理するための属性が含まれます。
Presence Web ServicesアプリケーションのJMXフレームワークを起動し、すべてのモデルMBeanをデプロイします。PresenceWebServiceDeployer MBeanの操作を使用することで、Presence Web ServiceによってこのMBeanに公開されているオブジェクトの情報を取得できます。
PresenceSupplierWebService MBean（表7-10で説明）を使用すると、ウォッチャに対してパブリッシュされたプレゼンス・データを管理できます。
表7-10 PresenceSupplierWebService MBeanの属性
| 属性 | 説明 |
|---|---|
|
Expires |
プレゼンス・ステータスのPUBLISHに対するデフォルトの有効期限（秒単位）。この属性に入力する値は、SessionTimeout属性に対する入力に合せて最適化する必要があります。 |
|
PIDFManipulationAU |
PIDF（Presence Information Data Format）操作に対するアプリケーション使用状況の名前。デフォルト値はpidf-manipulationです。 |
|
PidfManipulationDocname |
pidf操作のアプリケーション使用状況のドキュメント名。たとえば、hardstateなどです。ルールが見つからない場合、認証済でないユーザーはブロックされます。URIにIPアドレスではなくドメイン名が含まれる場合は、DNSサーバーを構成する必要があります。 デフォルト値はhardstateです。 |
|
PresRulesAU |
pres-rulesアプリケーションの使用状況の名前。デフォルト値はpres-rulesです。 |
|
PresRulesDocname |
pres-rulesドキュメントの名前。デフォルト値はpresrulesです。 |
|
PublicXCAPRootUrl |
パブリックXDMSルートのURLです。http://<your.xdms:domain.com>/services/と入力します。たとえば、http://127.0.0.1:8080/servicesなどです。 |
|
SessionTimeout |
HTTPセッションのタイムアウト（秒単位）。この属性に入力する値は、Expires属性に対する入力値に合せて最適化する必要があります。このタイムアウトは、新しいセッションに対してのみ有効です。 |
|
SIPOutboundProxy |
すべてのリクエストが最初のホップで送信されるアウトバウンド・プロキシ・サーバーのIPアドレス。このアドレスは次の形式で入力します。 sip:<IP address>;lr;transport=TCP このアドレスにはデフォルト・ポート（5060）を入力することもできます。たとえば、sip:127.0.0.1:5060;lr;transport=TCPなどと入力します。このアドレスを入力する最も短い形式は、sip:127.0.0.1;lrです。 この属性を定義しない場合は、アウトバウンド・プロキシは使用されません。 |
PresenceConsumerWebService MBean（表7-11で説明）を使用すると、ウォッチャのサブスクリプションの期間を設定できます。
表7-11 PresenceConsumerWebService MBeanの属性
| 属性 | 値 |
|---|---|
|
Expires |
ウォッチャ・サブスクリプションのデフォルトの有効期間（秒単位）。この属性に入力する値は、SessionTimeout属性に対する入力値に合せて最適化する必要があります。 |
|
SessionTimeout |
HTTPセッションのタイムアウト（秒単位）。この属性に入力する値は、Expires属性に対する入力値に合せて最適化する必要があります。このタイムアウトは、新しいセッションに対してのみ有効です。 |
|
SIPOutboundProxy |
すべてのリクエストが最初のホップで送信されるアウトバウンド・プロキシ・サーバーのIPアドレス。このアドレスは次の形式で入力します。 sip:<IP address>;lr;transport=TCP このアドレスにはデフォルト・ポート（5060）を入力することもできます。たとえば、sip:127.0.0.1:5060;lr;transport=TCPなどと入力します。このアドレスを入力する最も短い形式は、sip:127.0.0.1;lrです。 この属性を定義しない場合は、アウトバウンド・プロキシは使用されません。 |
Aggregation Proxyは、IDアサーションを提供することでXCAPトラフィックおよびWebサービス・コール（SIPではなくHTTPを通して実行されます）を認証するOMAクライアントのサーバー側エントリ・ポイントです。このコンポーネントは、PresenceサーバーとXDMSを含む信頼できるドメインに対する門番の役割を果します。
Parlay X Web Serviceは、Aggregation ProxyがWebサービスのユーザーを認可する信頼できるドメインの内部で動作します。Parlay Xクライアントから発生するXCAPトラフィックおよびWebサービス・コールを、Webサービスのユーザーを識別するIDヘッダーを挿入することで認証します。その後、Aggregation Proxyは、HTTP経由で送信されるこのトラフィックをParlay X WebサービスおよびXDMSにプロキシします。
Aggregation Proxy MBean（表7-12）の属性を使用すると、XDMSに適したIDアサーションの種類を設定できます。また、Aggregation Proxyからプロキシされるトラフィックを受け取るWebサーバーおよびXDMSのホストとポートを設定できます。
表7-12 Aggregation Proxyの属性
| 属性 | 説明 |
|---|---|
|
AssertedIdentityType |
プロキシされるHTTPリクエストに挿入される、XDMSに適したIDヘッダーに対応する番号を入力します。
|
|
ContentHost |
Aggregation Proxyがプロキシされたリクエストを送信するコンテンツ・サーバーのホスト名。 |
|
ContentPort |
Aggregation Proxyがプロキシされたリクエストを送信するコンテンツ・サーバーのポート番号。 |
|
ContentRoot |
コンテンツ・サーバーのルートURL。 |
|
IgnoreUserpartCase |
大文字と小文字を区別してユーザー名を処理する必要がない場合は、trueに設定します。 |
|
JAASLogingContext |
JAAS（Java Authentication and Authorization Service）の |
|
JAASRoles |
認証のためのJAASロールのカンマ区切りリスト。値が「*」の場合は、すべてのJAASロールが許可されます。 |
|
PresenceConsumerEndpoint |
注意: この属性は非推奨です。下位互換性を確保する場合のみ使用されます。 プレゼンス・コンシューマWebサービスのエンドポイントへのパス。プレゼンス・コンシューマ・インタフェースのメソッドを使用して、ウォッチャはプレゼンス・データを取得できます。 |
|
PresenceSupplierEndpoint |
注意: この属性は非推奨です。下位互換性を確保する場合のみ使用されます。 プレゼンス・サプライヤWebサービスのエンドポイントへのパス。プレゼンス・サプライヤ・インタフェースのメソッドを使用して、プレゼンティティはウォッチャによってアクセスされるデータの管理をプレゼンスに提供できます。 |
|
TrustedHosts |
信頼できるホストのIPアドレスのカンマ区切りリスト。このリストにアドレスが含まれないリクエストからは、Asserted Identityヘッダーが削除されます。 |
|
WebServiceHost |
注意: この属性は非推奨です。下位互換性を確保する場合のみ使用されます。 Aggregation ProxyがリクエストをプロキシするWebサービス・デプロイ・サーバーのホスト名。 |
|
WebServicePort |
注意: この属性は非推奨です。下位互換性を確保する場合のみ使用されます。 Aggregation ProxyがリクエストをプロキシするWebサービス・デプロイ・サーバーのポート。 |
|
XCAPHost |
Aggregation ProxyがリクエストをプロキシするXDMSのホスト名。 |
|
XCAPPort |
Aggregation ProxyがリクエストをプロキシするXDMSのポート。 |
|
XCAPRoot |
XDMSのルートURL。 |
1つ以上のレルムと連動するようにAggregation Proxyを構成できます。
次の手順を実行します。
「aggregationproxy」→「管理」→「セキュリティ・プロバイダ」→「OCMSLoginModule」→「編集」を選択します。
5つの属性が表示されます。この中で最も重要な属性はrealmです。
次の形式のカンマ区切りリストでレルムを構成します。
<domain>=<realm>,<domain>=<realm>,...
Aggregation Proxyの背後にデプロイすることで、XDMSを保護します。XDMSに対するアクセスを、Aggregation ProxyとPresenceサーバーのみに制限する必要があります。さらに、XDMSを保護するには、Presenceサーバー・アプリケーションのXCapConfig MBean、Aggregation Proxy、およびOracle Communicatorを次のように構成する必要があります。
PresenceサーバーのXCAPConfig MBeanのRequiredAssertedIdentity属性の値をtrueに設定することで、Asserted Identityヘッダーのない着信XCAPリクエストに対するアクセスを拒否します。この属性をtrueに設定すると、すべてのXCAPトラフィックがAggregation Proxyによって認証を受ける必要があります。
Aggregation Proxy MBeanの属性XCAPHost、XCAPPort、XCAPRoot、ContentHost、ContentPortおよびContentRootに、XDMSに関する適切な値を設定します。
customize.xmlで、Oracle CommunicatorのXDMSの設定を、XDMSではなくAggregation Proxyを指し示すように構成します。そのためには、<RootContext>要素をaggregationproxy（Aggregation Proxyのコンテキスト・ルート）と定義し、<host>要素と<port>要素に、Aggregation ProxyのホストおよびそのホストのHTTPSポート（443など）を設定します。
Aggregation Proxyは、Subscriber Data Servicesの子アプリケーションとしてデプロイする必要があります。HTTPに対するdefault-web-siteにバインドできます。HTTP over SSLを有効にするには、Aggregation Proxyが稼働するOC4Jコンテナを、HTTPSを提供するように構成する必要があります。HTTPSの構成方法については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。HTTPS経由でAggregation Proxyにアクセスできるようにするには、Aggregation Proxyとsecure-web-siteをバインドします。PresenceサーバーがAggregation Proxyと同じサーバー上に存在する場合は、Presenceサーバーとdefault-web-siteをバインドします。Presenceサーバーはpresence.earファイル内に存在するため、このEARファイルのすべてのHTTPサーブレットがdefault-web-siteにバインドする必要があります。
非分散環境では、ステートフルなアプリケーションは、単一ノードからリクエストを受信するため、適切に機能します。分散環境では、トラフィックに対応するように複数のノード間でアプリケーションのスケール調整を行う必要があり、いずれかのノードがリクエストを処理できるため、ステートフルなアプリケーションに障害が発生する可能性があります。これは、リクエストのセッション状態を維持するアプリケーションを実行するノードに対してだけではありません。User Dispatcherにより、SIPおよびHTTPのユーザー・リクエストは、そのリクエストを正常に処理するために必要なセッション状態を維持するノードにディスパッチされることが保証されます。つまり、ユーザー・リクエストがUser Dispatcherに送られると、そのリクエストは一貫して同じ宛先に送信されます。
フェイルオーバーは、Presenceサーバーの高レベルの可用性を実現するためにUser Dispatcherで使用できる技術です。Presenceサーバーは状態（確立したサブスクリプションなど）をレプリケートしないため、新しいサブスクリプションを設定することにより、新しいサーバー・ノード上のクライアントで状態を再作成する必要があります。また、サブスクリプションはSIPダイアログであり、User Dispatcherはレコード・ルーティングではないため、あるノードから別のノードへサブスクリプションをフェイルオーバーすることができません。すべての後続リクエストはルート・セットに続き、古いノードで終わります。
これは、障害が発生したサーバーからフェイルオーバーするときの問題ではありません。該当ノードはいずれにしてもトラフィックを処理しておらず、ダイアログ内のリクエストは最終的に障害レスポンスまたはタイムアウトを取得して、ダイアログが終了するためです。ただし、バックアップ・ノードから元のノードにユーザーを戻す作業は（元のノードが修復された場合）、障害発生後に均等に分散するように実行する必要がありますが、これはプレゼンス機能の不具合を引き起こす可能性のある問題となります。ある実行中のサーバーから別のサーバーにサブスクリプションを移動するには、クライアントまたはサーバーのいずれかを再起動するしかありません。
ただし、サブスクリプションを保持するサーバーでは、終了のNOTIFYを送信してサブスクリプション状態を破棄することで、サブスクリプションをアクティブに終了させることができます。これにより、クライアントでは新しい最初のSUBSCRIBEが発行されて新しいダイアログが確立されます。ある動作中のノードから別のノードにサブスクリプションを移行する場合、User Dispatcherはトラフィック（最初のリクエストにのみ影響を与える）をフェイルオーバーして、現在のサーバーに対してサブスクリプションを終了するように指示する必要があります。
ノード・セットを変更した場合、プレゼンティティを移行する必要があります。移行するには、Presenceアプリケーションで一部または全部のサブスクリプションを終了する必要があります。
最も基本的な方法として、すべてのノード上のPresenceアプリケーションにアクセスし、そのサブスクリプションをすべて終了させます。この場合の問題は、一定期間に大量のトラフィックが突発的に生成されて、拡散することです。終了期間が長いほど、すべてのユーザーが正しいプレゼンス状態を取得するまでに時間がかかるため、この期間に不適切なプレゼンス状態が生じます。
この問題を最適化するには、実際に終了する必要のあるサブスクリプション（移行したサブスクリプション）のみを終了できます。問題は、どのユーザーがこれらに該当するのかをUser Dispatcherが把握しておらず（アルゴリズムに基づくステートレスな分散であるため）、Presenceアプリケーションでも把握していない（どのユーザーがサブスクリプションを保持しているかのみを把握しているため）点です。ただし、Presenceアプリケーションがそのすべてのサブスクリプションを繰り返し、各サブスクリプションについて、このユーザーはこのPresenceノードに移動するかどうかをUser Dispatcherに尋ねる場合、Presenceサーバーは、そのサーバー自体に戻らないサブスクリプションのみを終了できます。これは動作の重い操作になる可能性がありますが、各PresenceサーバーがUser Dispatcherと一緒に使用される状態では、このような各コールバックは同じJVM内にあります。
別のソリューションとして、指定した時間でユーザーが1つのPresenceノードにのみ存在することをPresenceサーバーで保証するという方法があります。これを実行するには、Presenceアプリケーションで、新しいプレゼンティティ（まだ状態がないプレゼンティティ）のPUBLISHまたはSUBSCRIBEを受信すると、その近隣すべてにメッセージをブロードキャストするようにします。他のPresenceノードがこのブロードキャスト・メッセージを受信して、そのノードがこのプレゼンティティのアクティブなサブスクリプションをすでに保持している場合、そのサーバーは、クライアントが新しいサーバーで新しいサブスクリプションを確立できるようにそのサブスクリプションを終了する必要があります。
Presenceアプリケーションでこの機能を使用する場合、User Dispatcherは、追加の手順を実行して、ある動作中のノードから別のノードにユーザーを移行する必要はありません。
障害の発生したノードからトラフィックを引き継ぐ準備のできたサーバーのスタンバイ・プールを保持する方法もあります。アクティブ・ノードに障害が発生した場合、User Dispatcherはそのすべてのトラフィックをスタンバイ・プールの1つのサーバーに再分配します。これで、このノードがアクティブになります。障害の発生したノードが最終的に修復されると、そのノードはスタンバイ・プールに追加されます。そのため、障害が発生したノードが再開したときに動作中のノードからユーザーを戻す必要がなくなります。
この方法では、ハードウェアを追加する必要があるため、ハードウェア・リソースの使用が最適ではなくなります。
Presenceサーバーでは、いくつかの種類の障害が発生する可能性があります。様々な種類の障害に対して、User Dispatcherから異なるアクションを実行する必要があります。
障害が致命的である場合、すべての状態情報は失われ、確立したセッションが失敗します。ただし、障害レスポンスに応じて、新しいSIPダイアログを使用することで、サブスクリプション（プレゼンス・サブスクライブ・セッション）は存続できます。レスポンス・コードが481の場合、プレゼンス・クライアントは、RFC 3265に従って新しいSUBSCRIBEダイアログを確立する必要があります。これはプレゼンスの観点では障害とみなされません。その他の障害レスポンスはすべて、（クライアント実装に応じて）クライアントによってエラーとして処理されるため、障害とみなされます。
致命的障害の発生後、サーバーには障害発生前の時間のダイアログ状態は存在しません。これは、この地点に達するすべての後続リクエストに対して481レスポンスが戻されることを示します。障害時は、（最初および後続の）すべてのトランザクションが481以外のエラー・コードで終了します。発生する可能性が高いのは、500、内部503または408です（これはルート・パスにプロキシがあるかどうか、および障害の性質によって異なります）。
通常、致命的障害が発生すると、サーバー・プロセスまたはマシン全体が再起動されます。
User Dispatcherは、Presenceサーバー・ノードで障害を検出した際にいくつかのアクションを実行できます。アクションの目的は、失敗したサブスクリプションとパブリケーションの数、および回復にかかる時間の観点から、障害の影響を最小限に抑えることです。User Dispatcherは、この他にもアクティブ・サーバーに対してできるだけ分散を均等に保持する必要があります。
このバージョンのUser Dispatcherで使用するフェイルオーバー・アクションは、プールのノードを無効にする方法です。これは、追加操作と削除操作が確定的ではないため、ResizableBucketServerPoolを使用する場合、ノードを削除するよりも適切な方法です。つまり、ノードを追加した場合の結果は、それより前に実行した追加と削除の一連の操作によって異なります。アクティブなノードと無効なノードのセットがある場合に、無効な操作を実行しても分散に生じる変化は常に同じになります。
オーバーロード・ポリシーを有効にすると、数種類の障害を示すことがありますが、その主な目的はシステムが処理するトラフィックの負荷が大きくなりすぎないようにすることです。このような状況が障害として検出されると、トラフィックが完全に均等に分散されている場合、すべてのノードがオーバーロード状態になるか、それに近い状態になるため、フェイルオーバー・アクションが原因でクラスタ全体が停止する可能性があります。ディスパッチャがクラスタから1つのノードを削除し、そのノードのトラフィックを残りのノードに再分散させる場合、残りのノードは連鎖反応を引き起こして確実にオーバーロード状態に陥ります。
システムに負荷がかかっていない場合でも、このオーバーロード状態と、オーバーロード・ポリシーのアクティブ化の一因となるソフトウェア障害とを区別することが難しいため、オーバーロード・ポリシーが無効である場合を除いて、フェイルオーバー・アクションの実行が適切な方法になります。システムが実際にオーバーロード状態にある場合、システムの機能は制限される可能性があるため、フェイルオーバーは無効になります。
User Dispatcherは、503レスポンス（オーバーロード・ポリシーがアクティブであることを示す）が検出された場合、フェイルオーバーしません。ただし、サーバーが503で応答せずにメッセージを失ってしまうような最大のオーバーロード・ポリシー状態の場合、User Dispatcherモニターは、内部408を受信します。内部408と反応のないサーバーとを区別することはできず、フェイルオーバーが発生します。
障害検出メカニズムに応じて、フェイルオーバー・イベント（または結果として生じる状態）を異なるディスパッチャ・インスタンス間で同期化する必要があります。これは、検出メカニズムがクラスタにまたがって一貫していることが保証されない場合（エラー・レスポンスなど）に必要です。たとえば、1つのサーバー・ノードが1つのリクエストに対して503レスポンスを送信しますが、その後は正常に機能するとします（この原因はオーバーロード・ポリシーでの障害である可能性があります）。1つの503のみが送信された場合、それを受信するのは1つのディスパッチャ・インスタンスのみです。そのイベントがフェイルオーバーをトリガーする場合、そのディスパッチャ・インスタンスはクラスタの残りのインスタンスと同期しなくなります。さらに、ある一定期間にいくつかの503レスポンスを受け取ってフェイルオーバーをトリガーするように猶予期間が実装されている場合でも、障害期間が猶予期間と同じである場合、競合状態のリスクがあります。
次の方法を使用すると、フェイルオーバー後の状態が、ディスパッチャ・インスタンスのクラスタ間で確実に同期するようにできます。
すべてのユーザーが複数の（数は増加する可能性がある）他のユーザーをサブスクライブすることが原因で、Presenceアプリケーションが急激に増加する負荷を生成することがあるため、混乱を起こさずにクラスタを動的に拡張する必要があります。たとえば、標準的な電気通信アプリケーションでは、トラフィックが少ない時間にクラスタをアップグレードするためにすべてのサーバーを停止することが許容されますが、これと比較すると、Presenceシステムでは、これよりも高い可用性が必要になります。
クラスタを拡張するには、PresenceノードとUser Dispatcherノードの両方を追加する必要があります。
新しいPresenceサーバーをクラスタに追加する場合、分散を完全に均等にするために、一部のプレゼンティティを古いノードから新しいノードに移行する必要があります。クラスタ変更時にシステム上のトラフィックが大量にならないように、移行を最小限に抑える必要があります。
新しいUser Dispatcherをクラスタに追加する場合、User Dispatcherノードは他のディスパッチャ・ノードと同じディスパッチ状態を取得する必要があります。これはプールの実装によって異なりますが、他のディスパッチャ・ノードの状態と同期する必要があります（たとえば、永続性のあるバケット・プール実装を使用する場合など）。
これらの使用例では、User Dispatcherが1つまたは複数のPresenceサーバー・ノードでの様々な障害状況に対してどのように対処するかを示しています。
クラスタは4つのPresenceサーバーで構成され、各ノードはUser DispatcherとPresenceアプリケーションがデプロイされた1つのOCMSインスタンスで構成されています。100.000ユーザーが4つのサーバーに均等に分散されます（各ノードに25.000）。この中の1つのサーバーで異常に長いGCによる中断が原因で、メッセージの処理がガベージ・コレクタによってブロックされるため、取得中のSIPキューがいっぱいになり、オーバーロード・ポリシーが有効になります。60秒後、処理が再開され、サーバーは引き続きメッセージを処理します。
User Dispatcherはフェイルオーバーを行いませんが、障害が発生したノードへのトラフィックの送信を続けます。この場合、すべてのPUBLISHリクエストと最初のSUBSCRIBEリクエストは、障害が発生したノードに送信されるため、別のノードに移行されるセッションはありません。障害時に達する最初のSUBSCRIBEは失敗し、481以外のエラー（503など）が発生します。障害が発生したノードの期限が切れるか、障害が報告される場合、新しいサブスクリプションを試して設定するかどうかはクライアント次第です。すべてのPUBLISHリクエストと最初のSUBSCRIBEリクエストは、失敗を生成します。
障害が発生したノードが通常操作に戻る場合、すべてのトラフィックは再度処理され、失敗するリクエストはありません。すべてのプレゼンス状態が再度正常になるまでにかかる時間は、セッションがフェイルオーバーされないため、最小限で済みます。
この状況のノードを停止として検出する方法で監視機能が実装される場合、一部のユーザーは別のノードに移行され、このノードが復旧すると、これらのユーザーは再度戻されます。このため、一定期間にある程度の負荷が増加します。トラフィックの負荷がきわめて高いためにオーバーロード・ポリシーが有効になった場合、この移行は適切ではありません。この状態は再度発生する可能性が高く、その他のサーバーもオーバーロードに近い状態になるためです。これにより、連鎖反応が生じるため、クラスタ全体が停止したり、サービスが完全に失われたりします。
この使用例では、短期間（たとえば5秒間）でオーバーロード状態とそうではない状態を行き来するPresenceサーバーについて説明します。これは、システムの機能が制限され、かろうじてトラフィックの負荷を処理できる場合によく発生します。ただし、特定のノード上の他の障害のみが原因で発生することもあります。User Dispatcherは、「1つのPresenceサーバーが60秒間オーバーロードする」の場合とまったく同様に動作します。障害の期間がより短いために、失敗したセッション数とフェイルオーバー・セッション数が少ないことを除けば、同じ結果になります。
OCMSソフトウェアまたはその上位にデプロイされたアプリケーションに障害が発生すると、すべてのスレッドがロックされます（デッドロック）。これにより、最終的にキュー内がいっぱいになるため、実際にシステムがオーバーロード状態ではない場合でも、オーバーロード・ポリシーが有効になります。これは永続的なエラーのため、解決するにはサーバーを再起動するしかありません。
監視機能が実装されているかどうか、および監視機能の実装方法に応じて、影響を受けるユーザー数を最小限に抑えることができます。ただし、この状態を実際のオーバーロード状態と区別することはできません。この場合、フェイルオーバーの実行は最適な方法ではありません。
クラスタは4つのPresenceサーバーで構成され、各ノードはUser DispatcherとPresenceアプリケーションがデプロイされた1つのOCMSインスタンスで構成されています。100.000ユーザーが4つのサーバーに均等に分散されます（各ノードに25.000）。これらのプレゼンス・サーバーのうちの1台がハードウェア障害が原因で停止します。故障したサーバーを新しいサーバーと交換するには手動による操作が必要です。2時間が経過したら、サーバーを起動し、再実行します。障害の種類に応じて、障害が発生したノードにプロキシされるトランザクションに対して戻されるレスポンスは、408または503になります。
この場合、障害の期間がサブスクリプションの満了期間よりも長いため（ほとんどの場合）、このノード上のすべてのセッションは失敗します。監視サーバーがフェイルオーバーで実装される場合、障害時間は検出時間（秒）に対して最小限で済みます。ユーザーは移行機能によって移行されます。これにより、期間中の負荷が増加します。
User Dispatcherも障害が発生したノードで実行していたため、サーバーを新しいマシンに交換する際に、User Dispatcherに関して維持されていたデータはすべて失われます。
クラスタは3つのPresenceサーバーで構成され、各ノードはUser DispatcherとPresenceアプリケーションがデプロイされた1つのOCMSインスタンスで構成されています。100.000ユーザーが4つのサーバーに均等に分散されます（各ノードに33.000）。新しいノードがインストールされ、クラスタに追加されます。新しいノードを追加するには、次の一連の操作を実行します。
新しいノード上のUser DispatcherとPresenceアプリケーションは、クラスタの残りのノードと同じ設定で構成されます。この設定では、永続性のあるプール実装の場合、新しいUser Dispatcherに分散状態を同期する必要があります。
addServer JMX操作は、クラスタのUser Dispatcher MBeanに対して新しいノードで起動されます。これにより、すべてのUser Dispatcherノード（新しいノードを含む）に対してaddServer操作が起動されます。
ロード・バランサは、最初のリクエストが新しいUser Dispatcherノードに送信されるように、新しいノードで再構成されます。
移行方法に応じて、Presenceアプリケーションに対して（クラスタMBeanサーバーを使用して）さらにJMX操作を起動できます。
この結果、8.000ユーザーが移行され、ユーザーの新しい分散は各ノードで25.000になります。移行方法に応じて、一定期間でシステムにかかるトラフィックの負荷が増加します。
クラスタは4つのPresenceサーバーで構成され、各ノードはUser DispatcherとPresenceアプリケーションがデプロイされた1つのOCMSインスタンスで構成されています。100.000ユーザーが4つのサーバーに均等に分散されます（各ノードに25.000）。1つのPresenceノードがクラスタから削除されます。ノードを削除するには、次の一連の操作を実行します。
削除するノードを含めないように、ロード・バランサを再構成します。
クラスタのすべてのUser Dispatcherからノードを削除するために、removeNode JMX操作が起動されます。クラスタMBeanを使用して、操作を委任します。
移行方法に応じて、削除するノードに対してさらにJMX操作を起動できます。
削除するノードからすべてのユーザーを移行すると（この期間は移行方法によって異なる）、ノードは最終的に中断され、クラスタから削除されます。
この結果、8.000ユーザーが移行され、ユーザーの新しい分散は各ノードで33.000になります。
