| Oracle® WebLogic Communication Services 開発者ガイド 11g リリース 1 (11.1.1) B55506-01 |
|
 戻る |
 次へ |
この章では、OWLCS を使用して HTTP と SIP のコンバージド アプリケーションを開発する方法について説明します。以下の節で構成されています。
「コンバージド アプリケーション」では、SIP プロトコルの機能と HTTP または Java EE のコンポーネントを組み合わせることで、統合的な通信サービスを実現します。たとえば、オンラインの Push-to-Talk アプリケーションで、ユーザがショッピング カート内の商品について質問するために音声コールを開始するという機能を実現できます。この音声コールのために開始される SIP セッションは、ユーザの HTTP セッションに関連付けられています。そのため、音声コールに答える従業員は、ユーザのショッピング カートの中身や購入履歴を見ることができます。
アプリケーション アーカイブ (.EAR file) へ Java EE コンポーネント (EJB など) を利用するコンバージド アプリケーションをパッケージ化する必要があります。SIP および HTTP プロトコルを利用するコンバージド アプリケーションは、sip.xml および web.xml 両方のデプロイメント記述子ファイルを含む 1 つの SAR または WAR ファイルでパッケージする必要があります。オプションで、1 つの EAR ファイル内で別々の SAR および WAR コンポーネントにコンバージド アプリケーションの SIP および HTTP Servlet をパッケージできます。
コンバージド アプリケーションで使用される HTTP セッションと SIP セッションには、共通のアプリケーション セッション オブジェクトを通じてプログラム的にアクセスできます。HTTP セッションをアプリケーション セッションに関連付けるための SIP Servlet API が用意されています。
SIP Servlet 仕様では、コンバージド アプリケーションのアセンブルに関する要件と制約が詳しく規定されています。SIP Servlet 仕様の内容を簡潔にまとめると、次のようになります。
コンバージド アプリケーションでは標準的な SIP Servlet ディレクトリ構造を使用します。
SIP Servlet のファイルはすべて WEB-INF サブディレクトリの下に配置します。これにより、HTTP Servlet がこれらのファイルを静的ファイルとして提供することはなくなります。
アプリケーションの HTTP コンポーネントと SIP コンポーネントの両方に関するデプロイメント記述子が必要です。つまり、sip.xml と web.xml の両方のデプロイメント記述子が必要になります。OWLCS コンテナ内での Servlet 機能をコンフィグレーションするために、weblogic.xml デプロイメント記述子を用意することもあります。
デプロイメント記述子の要素には、次の制約があります。
distributable タグは、sip.xml と web.xml の両方に記述するか、どちらにも記述しません。
context-param 要素は、1 つのコンバージド アプリケーションで共有されます。sip.xml および web.xml 内に同じ context-param 要素を定義する場合は、どちらのパラメータ定義にも同じ値を指定します。
display-name または icons 要素が必要な場合は、その要素を sip.xml と web.xml の両方に定義し、どちらのデプロイメント記述子にも同じ値を指定します。
図 2-1 に示すように、OWLCS コンテナにデプロイされるコンバージド アプリケーションは必ずユニークな SipApplicationSession を持ち、その中に 1 つまたは複数の SipSession オブジェクトと ConvergedHttpSession オブジェクトを含めることができます。
javax.servlet.SipApplicationSession の API により、そのアプリケーションの SipApplicationSession 内のすべての使用可能セッションを反復処理することができます。コンバージド アプリケーションを開発する場合、ユニーク アプリケーション セッションで URL をエンコーディングするメソッドも用意されています。
以前のリリースでは、OWLCS は、以下の処理を行うためのメソッドを提供するように基本 SIP Servlet API を拡張します。
SIP Servlet から新しい HTTP セッションを作成するメソッド
SipApplicationSession 内の HTTP セッションを追加および削除するメソッド
呼び出し ID またはセッション ID を使用して SipApplicationSession オブジェクトを取得するメソッド
SIP Servlet 内からセッション ID を使用して HTTP URL をエンコードするメソッド
この機能は、SIP Servlet API バージョン 1.1 の一部として直接提供され、独自の API (com.bea.wcp.util.Sessions) は、非推奨になりました。表 2-0 は、非推奨になったメソッドの代わりに使用する SIP Servlet API を示します。 詳細については、SIP Servlet v1.1 API JavaDoc を参照してください。
表 2-1 非推奨 com.bea.wcp.util.Sessions のメソッド
| 非推奨になったメソッド (com.bea.wcp.util.Sessions) | 置き換えメソッド | 説明 |
|---|---|---|
|
getApplicationSession |
javax.servlet.sip.SipSessionsUtil. getApplicationSession |
指定したセッション ID に基づいて |
|
getApplicationSessionsByCallId |
なし。 |
指定した呼び出し ID に関連付けられている |
|
createHttpSession |
なし。 |
代わりに、 |
|
setApplicationSession |
javax.servlet.sip.ConvergedHttpSession. getApplicationSession |
HTTP セッションを既存の |
|
removeApplicationSession |
なし。 |
既存の |
|
getEncodeURL |
javax.servlet.sip.ConvergedHttpSession. encodeURL |
既存の HTTP セッション オブジェクトの |
|
注意 : com.bea.wcp.util.Sessions API は、下位互換性のためにのみ提供されています。すべての新しい開発に対して SIP Servlet API を使用します。OWLCS は com.bea.wcp.util.Sessions API および JSR 289 コンバージェンス API を混在するコンバージド アプリケーションをサポートしません。
具体的には、非推奨 |
Replicated ドメインを使用している場合は、SIP Servlet から SipApplicationSession オブジェクトを変更するときに、OWLCS によって自動的に同時実行制御が行われます。つまり、SIP Servlet から SipApplicationSession オブジェクトを変更するときに、そのオブジェクトが他のアプリケーションによって同時に変更されるのを防ぐために、SIP コンテナによって自動的にオブジェクトがロックされます。
HTTP Servlet などの非 SIP アプリケーションでは、アプリケーションの呼状態を変更する前に、その呼状態を明示的にロックする必要があります。また、単一の SIP サーブレットが他の呼状態オブジェクトを変更する必要がある場合 (会議開催サブレットは複数の呼を結合する場合など) にも必要です。
アプリケーション セッション オブジェクトへの同時アクセスの管理を容易にするために、OWLCS では、標準の SipApplicationSession オブジェクトを拡張した com.bea.wcp.sip.WlssSipApplicationSession が用意されています。さらに、セッションへの変更をカプセル化するために、2 つのインタフェース com.bea.wcp.sip.WlssAction および com.bea.wcp.sip.WlssAsynchronous Action が追加されています。これらの API を使用すると、SIP コンテナの働きにより、WlssAction および WlssAsynchronousAction オブジェクト内に含まれているすべてのビジネス ロジックが、関連付けられている SipApplicationSession インスタンスのロックされたコピーに対して確実に適用されます。以下の節で、それぞれのインタフェースについて説明します。
トランザクションおよび同期によってセッション属性の読み取りおよび更新を行う必要があるアプリケーションでは、WlssAction API を使用する必要があります。WlssAction は、アクション期間の明示的なロックをセッションで取得します。例 2-1「WlssAction API を使用するサンプル コード」は、この API を使用する例を示します。
例 2-1 WlssAction API を使用するサンプル コード
final SipApplicationSession appSession = ...;
WlssSipApplicationSession wlssAppSession = (WlssSipApplicationSession) appSession;
wlssAppSession.doAction(new WlssAction() {
public Object run() throws Exception {
// ここにすべてのビジネス ロジックを追加します。 appSession.setAttribute("counter", latestCounterValue);
sipSession.setAttribute("currentState", latestAppState);
// SIP コンテナはアプリケーション セッションが
// ロックされている間に実行メソッドが呼び出されることを確認します。
return null;
}
});
WlssAction API は関連するセッションで排他的なロックを取得するため、アクション内で別のアプリケーション セッション属性を変更しようとするとデッドロックが発生する可能性があります。
ロックされた SipApplicationSession のコンテキスト内で異なる SipApplicationSession を更新する必要があるアプリケーションでは、WlssAsynchronousAction API を使用して非同期的な更新を実行できます。この API は、複数のアプリケーションが同じ SipApplicationSession の属性を同時に更新する必要がある場合の競合を軽減します。例 2-2「WlssAsynchronousAction API を使用するサンプル コード」は、この API を使用する例を示します。
この API を使用してアプリケーションをコンパイルするには、MIDDLEWARE_HOME/server/lib/wlss/wlssapi.jar と MIDDLEWARE_HOME/server/lib/wlss/sipservlet.jar を含める必要があります。
例 2-2 WlssAsynchronousAction API を使用するサンプル コード
SipApplicationSession sas1 = req.getSipApplicationSession(); // SipApplicationSession1 はすでにコンテナでロックされています
// 処理をスケジューリングする別の SipApplicationSession を取得します
WlssSipApplicationSession wlssSipAppSession = SipSessionsUtil.getApplicationSessionById(conferenceAppSessionId);
// 処理はアプリケーション セッションで非同期的に実行されます
appSession.doAsynchronousAction(new WlssAsynchronousAction() {
Serializable run(SipApplicationSession appSession) {
// ここにすべてのビジネス ロジックを追加します。
int counter = appSession.getAttribute("counter");
++ counter;
appSession.setAttribute("counter", counter);
return null;
}
});
appSession に対する処理を非同期的に実行することで、ネストされたロックおよび関連するデッドロックのシナリオを防ぐことができます。
OWLCS には、com.bea.wcp.util.Sessions API を使用したサンプルのコンバージド アプリケーションが含まれています。すべてのソース コード、デプロイメント記述子、およびサンプルのビルド ファイルは、OWLCS_HOME\samples\sipserver\examples\src\convergence にインストールされています。サンプルをビルドして実行する方法については、サンプル ディレクトリの readme.html ファイルを参照してください。
