この章では、SIPサーブレット・アプリケーションのプログラミングのガイドラインを示します。内容は次のとおりです。
JSR 116 SIPサーブレット・アプリケーション・プラットフォームとしてのOCMSの利点をフルに活用するアプリケーションを作成するには、次の推奨事項に従ってください。
ステートフル・アプリケーション、つまりSipSessionsまたはSipApplicationSessionsに状態を保存するアプリケーションの場合、SIPアプリケーション・サーバー・クラスタでの可用性を高めるには、sip.xmlファイルとweb.xmlファイルに<distributable>要素が含まれている必要があります。アプリケーションを分散可能にすると、アプリケーションとセッションの状態がクラスタ・ノードにレプリケートされ、クラスタ・ノードで障害が発生した場合もセッションの実行を再開できます。
分散可能な環境でセッション状態がどのようにレプリケートされるかは、パフォーマンスに大きく影響します。セッション・オブジェクトでsetAttribute()コールが発生するたびにレプリケーションがトリガーされるため、サーブレットでこのコールが大量に発生すると、パフォーマンスが低下することがあります。
OC4Jで、アプリケーションがエンタープライズ・アーカイブとしてパッケージ化されている場合は、さらに要件があります。詳細は、『Oracle Communication and Mobility Server管理者ガイド』を参照してください。
セッションの間持続させる必要があるすべてのデータを、SIPアプリケーション・セッションで明示的に保存し、シリアライズ可能にする必要があります。
前述の推奨事項の当然の帰結として、アプリケーションでは静的変数を使用せずに、EJBやデータベース記憶域などの標準J2EEメカニズムを使用してデータを永続的に保存できるようにし、障害時に別のクラスタ・ノードでデータを使用できるようにします。
SIPサーブレット・アプリケーションの起動にブロッキング・コールを使用しないでください。ブロッキング・コールには、同期リモートプロシージャ・コールや同期データベース・コールが含まれます。
アプリケーションの終了時にメモリーをできるだけ早く解放できるよう、SipApplicationSessionを必ず無効化してください。SIPセッションごとに、セッションの終了とともにこれらを無効化する必要があります。SIPアプリケーション・セッションを無効化すると所有SIPセッションも無効化されるので、アクティブなSIPセッションがないことを確認してください。
セッション・オブジェクトに格納するデータ用のメモリーの使用状況を監視します。セッションのタイムアウトが発生する前に、作成した数のセッションに十分なメモリーがあることを確認してください。
セッション・オブジェクトに格納されるオブジェクトは、セッションがタイムアウトになる(または無効化される)まで解放されません。再使用する前にプールに明示的に解放する必要がある共有リソース(JDBC接続など)を保持していると、これらのリソースはプールに正しく戻されず、再使用できない可能性があります。
使用可能なメカニズムを使用して、スレッドを作成するかわりに、アプリケーションにイベント駆動型モデルを作成し、コンテナのアクティブ化モデル外で動作させます。
B2BUAアプリケーションでは、元のリクエストの関連フィールドのクローンを作成するcreateRequestを使用します。
SipFactory.createRequest(SipServletRequest origRequest, boolean sameCallId)
次の変更により、リクエストが複製されます。
新しいリクエストのFromヘッダー・フィールドには、コンテナによって選択された新しいタグが入ります。
新しいリクエストのToヘッダー・フィールドにはタグはありません。
Call-IDは新しくなります(sameCallIdがtrueの場合は複製)。
Record-RouteおよびViaヘッダー・フィールドはコピーされません。リクエストが実際にアプリケーション・サーバー外に送信されるときに、コンテナにより独自のViaヘッダー・フィールドが追加されます。
REGISTERリクエスト以外の場合、Contactヘッダー・フィールドはコピーされませんが、コンテナによって移入されます。