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