| Oracle® WebLogic Server SIP Container開発者ガイド 11g リリース1(11.1.1) B61430-01 |
|
 前 |
 次 |
この章では、Oracle WebLogic Server SIP Containerを使用してHTTPとSIPのコンバージド・アプリケーションを開発する方法について説明します。内容は次のとおりです。
コンバージド・アプリケーションでは、SIPプロトコルの機能とHTTPまたはJava EEのコンポーネントを組み合せることで、統合的な通信サービスを実現します。たとえば、オンラインのPush-to-Talkアプリケーションで、ユーザーがショッピング・カート内の商品について質問するために音声コールを開始するという機能を実現できます。この音声コールのために開始されるSIPセッションは、ユーザーのHTTPセッションに関連付けられています。そのため、音声コールに答える従業員は、ユーザーのショッピング・カートの中身や購入履歴を見ることができます。
アプリケーション・アーカイブ(.EARファイル)へJava EEコンポーネント(EJBなど)を利用するコンバージド・アプリケーションをパッケージ化する必要があります。SIPおよびHTTPプロトコルを利用するコンバージド・アプリケーションは、sip.xmlおよびweb.xml両方のデプロイメント記述子ファイルを含む1つのSARまたはWARファイルでパッケージする必要があります。オプションで、1つのEARファイル内で別々のSARおよびWARコンポーネントにコンバージド・アプリケーションのSIPおよびHTTPサーブレットをパッケージできます。
コンバージド・アプリケーションで使用されるHTTPセッションとSIPセッションには、共通のアプリケーション・セッション・オブジェクトを通じてプログラム的にアクセスできます。HTTPセッションをアプリケーション・セッションに関連付けるためのSIP Servlet APIが用意されています。
SIP Servlet仕様では、コンバージド・アプリケーションのアセンブルに関する要件と制約が詳しく規定されています。SIP Servlet仕様の内容を簡潔にまとめると、次のようになります。
コンバージド・アプリケーションでは標準的なSIP Servletディレクトリ構造を使用します。
SIPサーブレットのファイルはすべてWEB-INFサブディレクトリの下に配置します。これにより、HTTPサーブレットがこれらのファイルを静的ファイルとして提供することはなくなります。
アプリケーションのHTTPコンポーネントとSIPコンポーネントの両方に関するデプロイメント記述子が必要です。つまり、sip.xmlとweb.xmlの両方のデプロイメント記述子が必要になります。Oracle WebLogic Server SIP Containerコンテナ内での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に示すように、Oracle WebLogic Server SIP Containerコンテナにデプロイされるコンバージド・アプリケーションは必ず一意のSipApplicationSessionを持ち、その中に1つまたは複数のSipSessionオブジェクトとConvergedHttpSessionオブジェクトを含めることができます。
javax.servlet.SipApplicationSessionのAPIにより、そのアプリケーションのSipApplicationSession内のすべての使用可能セッションを反復処理できます。コンバージド・アプリケーションを開発する場合、ユニーク・アプリケーション・セッションでURLをエンコーディングするメソッドも用意されています。
以前のリリースで、Oracle WebLogic Server SIP Containerは次の処理を行うメソッドを提供するために、基本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を使用します。com.bea.wcp.util.Sessions APIとJSR 289コンバージェンスAPIが混在するコンバージド・アプリケーションはサポートされていません。
具体的には、非推奨の |
replicatedドメインを使用している場合は、SIPサーブレットからSipApplicationSessionオブジェクトを変更するときに、Oracle WebLogic Server SIP Containerによって自動的に同時実行性制御が行われます。つまり、SIPサーブレットからSipApplicationSessionオブジェクトを変更するときに、そのオブジェクトが他のアプリケーションによって同時に変更されるのを防ぐために、SIPコンテナによってオブジェクトが自動的にロックされます。
HTTPサーブレットなどの非SIPアプリケーションでは、アプリケーションの呼出し状態を変更する前に、その呼出し状態を明示的にロックする必要があります。また、単一のSIPサーブレットが他の呼出し状態オブジェクトを変更する必要がある場合(会議開催サブレットが複数の呼出しを結合する場合など)にも必要です。
アプリケーション・セッション・オブジェクトへの同時アクセスの管理を容易にするために、Oracle WebLogic Server SIP Containerでは、標準の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は、このAPIの使用例を示しています。
例2-1 WlssAction APIを使用するサンプル・コード
final SipApplicationSession appSession = ...;
WlssSipApplicationSession wlssAppSession = (WlssSipApplicationSession) appSession;
wlssAppSession.doAction(new WlssAction() {
public Object run() throws Exception {
// Add all business logic here.
appSession.setAttribute("counter", latestCounterValue);
sipSession.setAttribute("currentState", latestAppState);
// The SIP container ensures that the run method is invoked
// while the application session is locked.
return null;
}
});
WlssAction APIは関連するセッションに対して排他的なロックを取得するため、アクション内で別のアプリケーション・セッション属性を変更しようとするとデッドロックが発生することがあります。
ロックされたSipApplicationSessionのコンテキスト内で異なるSipApplicationSessionを更新するアプリケーションは、WlssAsynchronousAction APIを使用して非同期更新を実行できます。このAPIは、複数のアプリケーションが同じSipApplicationSessionの属性を同時に更新する必要がある場合の競合を軽減します。例2-2に、この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 is already locked by the container
// Obtain another SipApplicationSession to schedule work on it
WlssSipApplicationSession wlssSipAppSession = SipSessionsUtil.getApplicationSessionById(conferenceAppSessionId);
// The work is done on the application session asynchronously
appSession.doAsynchronousAction(new WlssAsynchronousAction() {
Serializable run(SipApplicationSession appSession) {
// Add all business logic here.
int counter = appSession.getAttribute("counter");
++ counter;
appSession.setAttribute("counter", counter);
return null;
}
});
appSessionに対する処理を非同期的に実行することで、ネストされたロックおよび関連するデッドロックを防ぐことができます。
Oracle WebLogic Server SIP Containerには、com.bea.wcp.util.Sessions APIを使用したサンプルのコンバージド・アプリケーションが含まれています。すべてのソース・コード、デプロイメント記述子およびサンプルのビルド・ファイルは、WEBLOGIC_HOME\samples \sipserver\examples\src\convergenceにインストールされています。サンプルをビルドして実行する方法については、サンプル・ディレクトリのreadme.htmlファイルを参照してください。
