Containerアプリケーションの構成機能を使用する方法を説明します。内容は次のとおりです。Containerに完全に実装されています。新規の開発についてはすべて、このドキュメントで説明されているSIPサーブレットv1.1の手法を使用します。Containerの前のバージョンで説明されているアプリケーション構成手法は非推奨になっています。Containerでは、次の場合にかぎって、バージョン1.0の構成手法を使用してアプリケーションに下位互換性を提供します。カスタム・アプリケーション・ルーターを構成しない場合、およびデフォルトのアプリケーション・ルーター・プロパティを構成しない場合。アプリケーション構成モデルアプリケーション構成は、SIPリクエストにサービスを適用するための複数のSIPアプリケーションを論理パスにチェーンする処理です。SIPサーブレットv1.1仕様は、SIPアプリケーションの構成に重要な役割を果たすアプリケーション・ルーター(AR)デプロイメントを導入します。アプリケーション・ルーターは、初期のSIPリクエストを調べて、カスタム・ロジックを使用して、リクエストを処理するSIPアプリケーションを決定します。Containerでは、初期リクエストが、まずリクエストを処理するのに使用するアプリケーションを決定するARに送信されます。Containerでは、テキスト・ファイルを使用して構成できるデフォルト・アプリケーション・ルーターを提供します。ほとんどのインストールでは、SipApplicationRouterインタフェースを実装することでカスタム・アプリケーション・ルーターを開発およびデプロイします。カスタム・アプリケーション・ルーターを使用すると、リクエストを処理するSIPアプリケーションを決定するときデータ・ストアを調べることができます。アプリケーション・ルーターと違って、メッセージを処理するために使用可能なSIPアプリケーションの情報を必要としません。個々のSIPアプリケーションがお互いに独立しています。個別のアプリケーションは、システムにデプロイされている他のアプリケーションを認識する必要がなく、SIPリクエストに対して特定のサービスを実行します。(アプリケーション・ルーターにはデプロイされているアプリケーションの認識が必要で、SipApplicationRouterインタフェースによって自動的にアプリケーションのデプロイメントおよびアンデプロイメントが通知されます。Server)としてリクエストを終了します。初期リクエストがプロキシまたはリレーされていた場合、SIPコンテナによってリクエストが再びアプリケーション・ルーターに転送され、リクエスト用のサービスを提供する次のSIPアプリケーションが選択されます。このように、ARはリクエストを処理するのに必要である複数のSIPアプリケーションをチェーンすることができます。チェーン処理が次の場合に、終了されます。選択したSIPアプリケーションはチェーンを終了させるUASとして動作する場合、またはそのリクエストに対して選択できるアプリケーションがない場合(この場合、リクエストが出力されます。)チェーンが終了され、リクエストが送信された場合、SIPコンテナは、後続のリクエストを処理するためにアプリケーションの定義されたパスを使用します。ARは調べられません。図5-1は、アプリケーション・ルーターを使用してSIPリクエストに複数のサービスを適用する方法を示します。Containerコンテナに配置する必要はありません。Router」に説明されています。DARは、SipApplicationRouterインタフェースのメソッドをすべて実装し、v1.1仕様で説明されている単純なJavaプロパティ・ファイルを使用して構成されます。DARプロパティ・ファイルの各行に1つ以上のSIPメソッドが指定され、カンマで区切った形式でSIPルーティング情報も指定されます。起動時にDARは最初にプロパティ・ファイルを読み込みます。SIPアプリケーションがコンテナにデプロイまたはアンデプロイされるたびにもプロパティ・ファイルを読み込みます。Containerインスタンスを起動するときに次のパラメータを含めます。-Djavax.servlet.sip.ar.dar.configuration(プロパティ・ファイルを指定するには、URIではなく、file:///という接頭辞を含めます)。このJavaパラメータはコマンド・ラインで指定されるため、サーバー起動スクリプトに含めることができます。デフォルト・アプリケーション・ルーターで使用されるルーティング情報の形式の詳細は、SIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の付録Cを参照してください。ニュートラル」のほかにルート・リージョン文字列を受け入れます。新しい各文字列値は、拡張されたルート・リージョンとして扱われます。DARでは、構成ファイルのプロパティの順序を使用してルート・エントリ・シーケンスを判定します。state_info値は、DAR構成で指定される場合効果がありません。Containerは、独自のDAR実装を使用します。カスタム・アプリケーション・ルーターを開発する場合、ARの実装をドメイン・ホーム・ディレクトリの/approuterサブディレクトリに保存する必要があります。ARのサポートティング・ライブラリは、/approuter内の/libサブディレクトリに保存できます。(SipApplicationRouterの複数の実装があれば、どちらを使用するかを指定するには、起動時に-Djavax.servlet.sip.ar.spi.SipApplicationRouterProviderのオプションを使用します)。注意:クラスタ環境の場合、カスタムARはドメインの全体のエンジン層インスタンスにデプロイされます。同じドメインに別のAR実装がデプロイできません。AR機能の詳細は、SIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の15項を参照してください。APIを参照してください。セッション・キーに基づくリクエストのターゲットSIPサーブレット・バージョン1.1の仕様では、初期リクエストを既存のSipApplicationSessionオブジェクトに関連付けるためのメカニズムも提供します。このメカニズムはセッション・キー・ベースのターゲットと呼ばれます。セッション・キー・ベースのターゲットを使用して、特定のサブスクライバ(リクエストURI)、地域またはその他の機能を持つ初期リクエストを、新しいセッションを生成することなく、既存のSipApplicationSessionに送ります。アプリケーションにおいてこのターゲットのメカニズムを使用するには、一意のキーを生成するメソッドを作成し、このメソッドに@SipApplicationKeyアノテーションを付けます。SIPコンテナがアプリケーションを選択する場合(たとえば、初期リクエストに対してARによって選択されたアプリケーション)、アノテーション付きのメソッドを使用してキーを取得します。SipApplicationSessionが存在するかどうかを判別するには、キーおよびアプリケーション名を使用します。存在する場合、コンテナは、新しいセッションを生成ではなく、既存のセッションに新しいリクエストを関連付けます。注意:ターゲットのメカニズムを使用してスパイラル・プロキシ・アプリケーションを開発し、アプリケーションによって複数回にレコード・ルーターが変更される場合は、レコード・ルーター・ホップの実行時に、必要に応じて、初期リクエストに対して異なるキーが生成される必要があります。生成されない場合、アプリケーションは後続リクエスト用のレコード・ルーター・ホップを差別できません。セッション・キー・ベースのターゲットの使用の詳細は、SIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の15項を参照してください。reserved.法律上の。