この章では、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
ファイルを参照してください。