JP5649840B2 - Ｓｉｐサーブレットアプリケーションコホスティング - Google Patents

Description

本発明は、一般的には通信に関連し、より明確には、ＳＩＰアプリケーションに関連する。

セッションイニシエーションプロトコル（ＳＩＰ）は、多数の種類のリアルタイムの通信セッションを確立するためのオープンシグナリングプロトコルである。ＳＩＰを使用して確立される通信セッションのタイプの例は、音声、画像、又は、インスタントメッセージングを含む。これらの通信セッションは、パーソナルコンピュータ、ラップトップコンピュータ、個人情報端末（ＰＤＡ）のような、いかなるタイプの通信デバイス上でも実行される。ＳＩＰの1つの重要な特徴は、全ての通信のために、単一の統合した公衆アドレスとして、エンドユーザーのアドレスオブレコード（ＡＯＲ）を使用する能力である。このように、ＳＩＰ機能強化通信の世界では、ユーザーのＡＯＲはそのユーザーに関連する全ての通信デバイスにユーザーをリンクする単一のアドレスとなる。このＡＯＲを使用して、発呼者は、各々の固有のデバイスアドレスや電話番号を知る必要はなく、ユーザーエージェント（ＵＡ）としても参照されて、ユーザーのいずれか１つの通信デバイスに到達することができる。

アプリケーションルータ（Ａｐｌｉｃａｔｉｏｎ Ｒｏｕｔｅｒ）という概念は、Ｊａｖａ（登録商標）Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ（ＪＳＲ）２８９仕様とともに導入された。アプリケーションルータは、アプリケーション構成（ｃｏｍｐｏｓｉｔｉｏｎ）に責任を持つ。この文章の中では、アプリケーション構成は、多数のアプリケーションをまとめて、論理的な順序に「連鎖させる（ｃｈａｉｎｉｎｇ）」プロセスである。多数のアプリケーションがまとめて連鎖させられたときに、1つのアプリケーションが与えられたＳＩＰメッセージを処理し、必要とされる処理を完了したなら、そのアプリケーションは、そのＳＩＰメッセージを次のアプリケーションに連鎖的に渡していく。

アプリケーション構成の中に含まれるＳＩＰアプリケーションの例としては、プレゼンスアプリケーション（ｐｒｅｓｅｎｃｅ ａｐｐｌｉｃａｔｉｏｎ）、コンタクトレゾリューションアプリケーション（ｃｏｎｔａｃｔ ｒｅｓｏｌｕｔｉｏｎ ａｐｐｌｉｃａｔｉｏｎ）、コールセットアップアプリケーション（ｃａｌｌ ｓｅｔｕｐ ａｐｐｌｉｃａｔｉｏｎ）、ブラックリストアプリケーション（ｂｌａｃｋｌｉｓｔ ａｐｐｌｉｃａｔｉｏｎ）、ボイスメールアプリケーション（ｖｏｉｃｅｍａｉｌ ａｐｐｌｉｃａｔｉｏｎ）、及びＳＩＰアーキテクチャー内のある種のフィーチャー（ｆｅａｔｕｒｅ）を備えるその他のアプリケーションを含む。アプリケーション構成の一例として、到着する（ｉｎｃｏｍｉｎｇ）ＳＩＰメッセージは、通常のコールセットアップアプリケーションに渡される前に、まず、ブラックリストアプリケーションでフィルターされ、その後、Ｎ個のリングの後で、ボイスメールアプリケーションへと渡される。

ＪＳＲ２８９は、アプリケーションルータの実行を提供することによって、アプリケーション構成を定義することは、デベロパー（ｄｅｖｅｌｏｐｅｒ）の役割であると述べている。この意味での１つのアプリケーションは、単一のＳＩＰ アーカイブ（Ａｒｃｈｉｖｅ）（ＳＡＲ）またはＳＡＲファイルを表し、ここで、ＳＡＲファイルはサーブレット（ｓｅｒｖｌｅｔ）を含んでいる。しかし、現実には、１つのアプリケーションが、しばしば、いくつかのＳＡＲファイルといくつかのサーブレットを有することがある。（このことは、これまでマルチＳＡＲアプリケーションとして知られていた。）各々のＳＡＲファイルは、そのアプリケーションのいくつかのフィーチャーのラッパー（ｗｒａｐｐｅｒ）を表している。デベロパーはしばしばそれ自身のＳＡＲファイルをコーディネート（ｃｏｏｒｄｉｎａｔｅ）することのみを可能にする、特別のアプリケーションルータの実行を含んでいる。サーブレットはまた、ウェブアーカイブ（Ｗｅｂ Ａｒｃｈｉｖｅ）（ＷＡＲ）またはＷＡＲファイルにも含まれている。

ＪＳＲ２８９は、ＳＩＰサーブレットコンテナ（ｃｏｎｔａｉｎｅｒ）が多数のアプリケーションルータをいかに管理すべきかについては定義していない。それゆえ、マルチＳＡＲを、同一のＳＩＰサーブレットコンテナ上で、信頼度高くデプロイ（ｄｅｐｌｏｙ）する、どんなメカニズムも今のところ存在しない。このことは、アプリケーションサーバは極端に限定されたアプリケーションをデプロイすることのみができるのだということを意味している。そしてそれは、非効率で、かつ、ＳＩＰアプリケーションサーバを使用するための主な理由への、反論である。この技術分野の当業者は理解するであろうが、このことは、サーバはしばしば、マルチＳＡＲをサポートするための十分な処理作業の又はメモリーのリソースを持っているから、極めて不便で、かつリソースの浪費である。事実、そのことは、同時に多数のウェブサイトやサービスのホスト（ｈｏｓｔ）をしうるかわりに、１セットのページまたはアプリケーションにサーブするためだけに、ＷＡＳやウェブロジック（Ｗｅｂｌｏｇｉｃ）のようなウェブサーバを使用することに類似している。

例えば、その各々が多数のＳＡＲからなり、ＳＩＰアプリケーションサーバへとデプロイされる、２つの複雑なアプリケーションを考える。第１のアプリケーションがＰＢＸ形式のアプリケーション、第２アプリケーションがコールルーティング（ｃａｌｌ ｒｏｕｔｉｎｇ）アプリケーションであったとする。コールルーティングアプリケーションの複雑さにより、各々のアプリケーションのためにカスタムのアプリケーションルータ（ｒｏｕｔｅｒ）を書く必要がある。これらの論理的アプリケーション及び関連するアプリケーションルータは、これまで別々に開発されていた。しかし今やそれらを同じアプリケーションサーバ上で、ホストしたいとの要求がある。この問題に関する先行技術の解決策は、単一のカスタムのアプリケーションルータをデプロイできることだけに規制することであった。それゆえ、２つのアプリケーションルータを単一のアプリケーションルータに書き換え（ｒｅｗｒｉｔｅ）し、またはマージする（ｍｅｒｇｅ）ことが、必要となるであろう。それらのプロセスは、時間を消費し、かつ、困難でもある。

そのようなアーキテクチャは、図１に示す。ここで、通信システム１００は、通信ネットワーク１０４を介してアプリケーションサーバ１１２につながる、いくつかの通信デバイス１０８を含んでいる。図１でわかるように、アプリケーションサーバ１１２は、到着するＳＩＰメッセージをアプリケーションサーバ１１２が通信ネットワーク１０４から受け取ることを許可する、ネットワークインタフェース１１６を有する。

ネットワークインタフェース１１６で受け取られたメッセージは、ＳＩＰサーブレットコンテナ１２０に渡される。ＳＩＰサーブレットコンテナ１２０は、イニシャルメッセージリクエストを扱い、それらのリクエストをアプリケーションルータ１２４に渡すことの責務を負う。ＳＩＰサーブレットコンテナ１２０は、バックトゥバックユーザーエージェント（Ｂａｃｋ−ｔｏ−Ｂａｃｋ Ｕｓｅｒ Ａｇｅｎｔ）（Ｂ２ＢＵＡ）またはプロキシ（ｐｒｏｘｙ）としても機能する。一旦、メッセージがアプリケーションルータ１２４に渡されると、アプリケーションルータ１２４は、ＳＩＰリクエストを調べて、どのアプリケーション（すなわち、ＳＡＲファイル１２８ａ−Ｎ）がリクエストの処理を完了するのに実行されるべきかを選択する。アプリケーションルータは一般的にはどんなリクエストも改変しないことに注意すべきである。従って、アプリケーションルータ１２４は、適切なＳＡＲファイル１２８を識別（ｉｄｅｎｔｉｆｙ）し、その決定をＳＩＰサーブレットコンテナ１２０に伝える。ＳＩＰサーブレットコンテナ１２０は、それから、ＳＡＲの中の（ＪＳＲ２８９に述べられたメカニズムによって決定される）適切なサーブレットを呼び出し（ｉｎｖｏｋｅ）、そのリクエストはそのサーブレットに従って処理される。一旦、あるリクエストが適正に処理されると、ＳＩＰサーブレットコンテナ１２０は、そのリクエストをネットワークインタフェース１１６へ返送し、そこではそれは、更なる処理のために通信ネットワーク１００の別のデバイスへと転送されることができる。これは、そのリクエストを別のアプリケーションサーバへ渡すこと、または、そのリクエストをユーザの通信デバイス１０８に渡すことを含む。

ＪＳＲ２８９に従って多数のアプリケーションをコホスト（ｃｏ−ｈｏｓｔ）するための２つの共通のアプローチがある。第１は、単純に、アプリケーションサーバ１１２の多数のインスタンス（ｉｎｓｔａｎｃｅ）を動作させることである。ここでは、各々のサーバが単一のマルチＳＡＲアプリケーションをホストする。これは、単一の物理的マシンをパーティション（ｐａｒｔｉｔｉｏｎ）するバーチャライゼーション（ｖｉｒｔｕａｌｉｚａｔｉｏｎ）テクノロジ−を含んでいる。第２アプローチは、デプロイヤ（ｄｅｐｌｏｙｅｒ）がこれらのアプリケーションを同じサーバ上でコーディネートするためのカスタムのアプリケーションルータをインプリメント（ｉｍｐｌｅｍｅｎｔ）することである。

現在の商業的なやり方では、通常、前述のように、個々のマルチＳＡＲアプリケーションをホストするために、多数のサーバインスタンスをデプロイするが、サーバ当たり１つのアプリケーションというアプローチは、追加のハードウェア及びアドミニストレーションコストを課すことになる。第２アプローチは、デプロイヤに、ホストされるべき各々のアプリケーションのために、ルーティングの論理を、理解し、再びインプリメントすることを要求する。このプロセスは、エラーと開発及びデプロイの時間の増加を引き起こしがちである。更に、マシンの上に存在するアプリケーションの数とともに、マシンの複雑さが増していく。

それゆえに、個々のＳＡＲよりもその他のサブアプリケーションルータとコーディネートする、ルート（ｒｏｏｔ）アプリケーションルータの概念を導入することが、本発明の１つの態様である。これらのサブアプリケーションルータは、それ自身の権利を持った完全に一人前のアプリケーションルータであるが、制御するルートアプリケーションルータのことを意識していない。

ここで用いられるように、１つのＳＡＲは、１つのアプリケーションの特定の機能またはフィーチャーを実行するためのアプリケーションであるが、１つのアプリケーションは、普通は、いくつかのＳＡＲを有している（例えば、マルチＳＡＲアプリケーション）。1つのＳＡＲファイル、ＷＡＲファイル、ＥＡＲ、または同様のものは、ＳＩＰメッセージまたはＳＩＰリクエストについて、オペレーションを実行することと関連して使用される、１つのサーブレットを収容していることの責務を負う。そのＳＡＲ／ＷＡＲファイルは、特定の機能を実行するための現実のビジネス／アプリケーション論理またはルーティング論理を収容しているアーカイブ（ａｒｃｈｉｖｅ）である。

サブアプリケーションルータは、ＪＳＲ２８９で定義されているアプリケーションルータインタフェースをインプリメントする。また、ＪＳＲ２８９対応のそれ自身のコンテナ内で、デプロイされうる。しかしながら、本発明の少なくともいくつかの実施の形態によれば、これらのサブアプリケーションルータは、ＳＩＰサーブレットコンテナではなくてルートアプリケーションルータによって、ロード（ｌｏａｄ）され、管理される。

ＳＩＰサーブレットコンテナは、ルートアプリケーションルータを意識するようにのみ準備される。ＳＩＰサーブレットコンテナで受け取られた、到着するＳＩＰメッセージは、ルートアプリケーションルータに渡される。その後、ルートアプリケーションルータは、到着したＳＩＰメッセージを、（選択のアルゴリズムに従って）１つのサブアプリケーションルータのインスタンスへと委託（ｄｅｌｅｇａｔｅ）する。そのサブアプリケーションルータは、ＳＩＰメッセージの後続の処理をコーディネートする責務を負い、そのことによって、このソリューションを、ＪＳＲ２８９に従った単一のアプリケーションルータとして見えるようにする。

本発明の少なくともいくつかの実施の形態によれば、アプリケーションルータのベースで定義されるルーティングの規則（すなわち、メッセージをサブアプリケーションルータへとルート（ｒｏｕｔｅ）する、ルートアプリケーションルータによって使用される規則）は、サブアプリケーションルータにとって重要ではない。むしろ、このコンフィグレーション（ｃｏｎｆｉｇｕｒａｔｉｏｎ）は、システムデプロイヤの責任である。一例を以下に示す。
〈ｐａｔｔｅｒｎ〉
〈ｏｒ〉
〈ｅｑｕａｌ〉
〈ｖａｒ〉ｒｅｑｕｅｓｔ．ｒｏｕｔｅ．ｕｒｉ．ｕｓｅｒ〈／ｖａｒ〉
〈ｖａｌｕｅ〉ｖｏｉｃｅｍａｉｌ〈／ｖａｌｕｅ〉
〈／ｅｑｕａｌ〉

〈ｅｑｕａｌ〉
〈ｖａｒ〉ｒｅｑｕｅｓｔ．ｕｒｉ．ｕｓｅｒ〈／ｖａｒ〉
〈ｖａｌｕｅ〉ｖｏｉｃｅｍａｉｌ〈／ｖａｌｕｅ〉
〈／ｅｑｕａｌ〉

〈／ｏｒ〉
〈／ｐａｔｔｅｒｎ〉

これは、次のように解釈される。もし、ルート（ｒｏｕｔｅ）ＵＲＩまたはリクエストＵＲＩのユーザー部分が、”ｖｏｉｃｅｍａｉｌ”というテキストとマッチした場合には、メッセージをこのサブアプリケーションルータへ送れ。基本的には、このことが、メッセージのコンテンツを基礎とした、識別力のあるサブアプリケーションルータの選択を許容する。ＳＩＰメッセージの受信時に、ルートアプリケーションルータは規則のセットを順次評価する。評価の順序は重要で、デプロイヤ（通常、顧客のネットワークアドミニストレータ）が、このリストに関する完全なコントロールを有している。例えば、前面に置かれるワイルドカード規則は、その背後のアプリケーションが決してどんなＳＩＰメッセージも見ないことを意味する。もし、サブアプリケーションルータが、どんなマッチングの規則も規定しないならば、それはワイルドカードであり、全てのメッセージを処理することを望むものとみなされる。

上記の課題を解決するために、本発明の少なくともいくつかの実施の形態によれば、一般的に、
−第１のアプリケーションサーバのネットワークインタフェースで、第１メッセージを受信するステップと、
−その第１メッセージを、その第１のアプリケーションサーバ内のルートアプリケーションルータへ渡すステップと、
−そのルートアプリケーションルータによって、その第１メッセージを受け取り、引き続いて分析するためのサブアプリケーションルータを決定するステップと、
−その第１メッセージを、その第１のアプリケーションサーバ内に存在する、そのサブアプリケーションルータへと渡すステップと
ことからなる方法（ｍｅｔｈｏｄ）を提供する。

本発明の少なくともいくつかの実施の形態によれば、ＳＩＰサーブレットは、個々にデプロイされるまたはデプロイされないこともある、ＳＡＲファイル、ＷＡＲファイル、ＥＡＲファイルなどのような、セルフコンテンド（ｓｅｌｆ−ｃｏｎｔａｉｎｅｄ）なジャーファイル（ｊａｒ ｆｉｌｅ）の中へパッケージされる。ＳＩＰサーブレットは、ＳＩＰ機能をサポートするためにその中にロードされたインターフェースを強化する点で、他のタイプのサーブレットに似ている。別のタイプのサーブレットの例は、ｈｔｔｐサーブレットであり、これは、ウェブサーバまたはアプリケーションサーバの中で動作し、典型的にはデータベースにアクセスする、またはｅ−コマース処理を実行するような、サーバサイド（ｓｅｒｖｅｒ−ｓｉｄｅ）の処理を提供する、Ｊａｖａアプリケーションである。それは、ＣＧＩスクリプト（ＣＧＩ ｓｃｒｉｐｔｓ）、アクティブサーバページ（Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅ、ＡＳＰｓ）及びＣ及びＣ＋＋で書かれたプロプライアトリプラグイン（ｐｒｏｐｒｉｅｔｒｙ ｐｌｕｇ−ｉｎｓ）の、Ｊａｖａベースの置き換えである。サーブレットはＣＧＩコンセプトに類似するが、分離したプロセスを使う代わりに、メッセージはサーバ内部のバーチャルマシンの中で動作するクラス（ｃｌａｓｓ）に伝達される。
多数のサーブレットは、サーバとオペレーティングシステムの間で可搬性を許容するように、特定のプログラム言語（例えばＪａｖａ）で書かれる。Ｊａｖａは、サーブレットまたは拡張モジュールを創作するために使用されるプログラム言語の一例であるが、本発明の実施の形態はそれに限定されないことを、この技術分野の当業者は理解するであろう。より明確には、本発明の実施の形態は、拡張モジュールがサーバとオペレーティングシステムの間で可搬性を持つことを許容するような、いずれかのタイプのプログラム言語での、拡張モジュールの創作を意図している。本発明の実施の形態は、また、サーバ（例えば、企業サーバで、特にＳＩＰサーバ）上のバーチャルマシンの内部で動作することができる拡張モジュールを意図している

従来技術の実施の形態による通信システムを示したブロック図。 本発明の少なくともいくつかの実施の形態による通信システムを示したブロック図。 本発明の少なくともいくつかの実施の形態による、ＳＩＰメッセージを処理する方法を示したフロー図。

図２を参照すると、例示の通信システム２００が、本発明の少なくともいくつかの実施の形態により、表現されている。より明確には、通信システム２００は、通信デバイス１０８をアプリケーションサーバ２０４と接続するようになっている、通信ネットワーク１０４を含んでいる。

通信ネットワーク１０４は、いかなるタイプの既知の通信手段またはそれらの集合であってもよく、エンドポイント間のメッセージの伝達のためのいかなるタイプのプロトコルも含んでもよい。通信ネットワーク１０４は、有線又は無線の通信技術を含む。インターネットは通信ネットワーク１０４の一例であり、それを構成する、世界中に置かれた多数のコンピュータやその他の通信デバイスからなるＩＰネットワークは多数の電話システムやその他の手段を介して接続されている。通信ネットワーク１０４の他の例は、標準の従来型単純電話システム（ＰＯＴＳ）、サービス総合デジタル網（ＩＳＤＮ）、公衆交換電話網（ＰＳＴＮ）、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、セッションイニシエーションプロトコル（ＳＩＰ）ネットワーク、いかなるタイプの企業ネットワーク、この技術分野で知られているいかなるその他のタイプのパケット交換またはサーキット交換ネットワークを含み、これに限定されない。更に、通信ネットワーク１０４は1つのネットワークタイプに限定されず、いくつかの異なるネットワーク又はネットワークタイプから構成されてもよい。

通信デバイス１０８は、パーソナルコンピュータ、ラップトップ、個人情報端末（ＰＤＡ）、携帯電話、スマートフォン、電話、アナログフォン、ＤＣＰフォン、またはそれらの組み合わせのような、周知のどんなタイプの通信または処理デバイスであってもよい。1つの通信デバイス１０８は、単独のユーザーに制御され、または関連づけられていてもよいし、多数のユーザーの使用に供されてもよい。（すなわち、企業の通信デバイスが、企業のユーザーに、有効なユーザー名とパスワードの提示による使用を許可するような場合である。）

通信デバイス１０８の各々は同一ユーザーと関連づけられてもよい。言い換えれば、通信デバイス１０８は単独のユーザーに属してもよく、また、異なるタイプの通信デバイスに対応してもよい。一例として、ユーザーが、それぞれが単一ユーザーの個人電話、業務電話、パソコン、Ｅメール検索デバイスに対応するような、４つの通信デバイス１０８を持ってもよい。代替として、通信デバイス１０８の各々が、異なるユーザーに所有され、操作され（すなわち関連づけられ）ていてもよい。

一般的に、通信デバイス１０８は、他の通信デバイス１０８との、ビデオ、オーディオ、テキスト、又はデータの通信をサポートするように適合されている。通信デバイス１０８によって他の通信デバイス１０８と通信するために使用される媒体のタイプは、通信デバイス１０８において利用できる通信アプリケーションに依存する。

本発明の少なくともいくつかの実施の形態によれば、通信デバイス１０８が、アプリケーションサーバ２０４へ、ＳＩＰメッセージのようなメッセージを送信し、そのサーバのネットワークインタフェース２０８において、それが受信される。ネットワークインタフェース２０８は、通信ポート又はネットワークアダプタを含む。一例として、ネットワークインタフェース２０８が、イーサネット（登録商標）のポートとイーサネットカード／アダプタを持つ。別の例では、ネットワークインタフェース２０８が、アンテナと８０２．１１またはブルートゥース（Ｂｌｕｅｔｏｏｔｈ）アダプタを持つ。このように、この技術分野の当業者は理解するであろうが、ネットワークインタフェース２０８は、アプリケーションサーバ２０４と通信ネットワーク１０４の間の、有線又は無線の接続をサポートし、更に、多数の通信プロトコルもサポートする。

アプリケーションサーバ２０４は、更に、最初にこのアプリケーションサーバ２０４で受け取られたメッセージを取り扱うための、ＳＩＰサーブレットコンテナ２１２を有する。追加として、ＳＩＰサーブレットコンテナ２１２は、そのアプリケーション２２４の機能性に従ってリクエストが処理されうるアプリケーションサーバ２０４の上に記憶されている、アプリケーション２２４に、ＳＩＰリクエストを転送する責務を負う。

図２及び図３を参照すると、ネットワークインタフェース２０８からの、ＳＩＰサーブレットコンテナ２１２で受け取られたメッセージ（ステップ３０４）は、ルートアプリケーションルータ２１６に渡される（ステップ３０８）。ルートアプリケーションルータ２１６は、アプリケーションサーバ２０４の多数のサブアプリケーションルータ２２０の間で、ＳＩＰメッセージのディスバースメント（ｄｉｓｂｕｒｓｅｍｅｎｔ）をコーディネートする責務を負う。より明確には、ルートアプリケーションルータ２１６は、どのように特定のメッセージまたはリクエストがサブアプリケーションルータ２２０の間でルートされるべきか、を定義したビジネス規則または論理を有し、そのような規則を適用して（ステップ３１２）、ターゲットとなるサブアプリケーションルータ２２０を識別する（ステップ３１６）。更により明確には、ルートアプリケーションルータ２１６は、サブアプリケーションルータ２２０にとって、階層上のマスター、または、メッセージゲートキーパー（ｇａｔｅ ｋｅｅｐｅｒ）として機能する。このように、サブアプリケーションルータ２２０が受け取るいかなるメッセージも、ルートアプリケーションルータ２１６を介して受け取られる。

しかしながら、本発明の少なくともいくつかの実施の形態によれば、サブアプリケーションルータ２２０は、ルートアプリケーションルータ２１６及びルートアプリケーションルータ２１６で実行されるいかなるアルゴリズムも、意識しない。その代わりに、サブアプリケーションルータ２２０の見方によれば、メッセージはＳＩＰサーブレットコンテナ２１２から受け取られ、サブアプリケーションルータ２２０で処理され、ＳＩＰサーブレットコンテナ２１２に返送され、そしてそれは、マルチＳＡＲアプリケーション２２４の中に、リクエストを世話すべき別のＳＡＲ２２８があるかどうかを判断するために、再びルートアプリケーションルータ２１６を呼び出すようになっている。１つのリクエストが、複数のサブアプリケーションルータ２２０ａ及び２２０ｂのための規則とマッチすることがありうることも注意すべきである。このような状況では、ルートアプリケーションルータ２１６が、リクエストはサブアプリケーションルータ２２０ａ及び２２０ｂにルートされるべきであると判断した場合、ルートアプリケーションルータ２１６は、第１のサブアプリケーションルータ２２０ａにリクエストを渡すことができ、一旦、対応する第１のアプリケーション２２４ａがメッセージの処理を終わったら、ルートアプリケーションルータ２１６が自動的にそのリクエストを次のサブアプリケーションルータ２２０ｂに渡すようにすることができる。

サブアプリケーションルータ２２０がメッセージを受け取ると（ステップ３２０）、サブアプリケーションルータ２２０は、メッセージを分析し、実際にどのアプリケーションがメッセージを処理するかを判断する（ステップ３２４）。従って、サブアプリケーションルータ２２０は、実際にはそれ自身ではメッセージを処理しない。どのアプリケーション２２４がメッセージを処理するのに使われるべきかを判断するために、メッセージの中の情報を分析するだけである。

このような判断を行うと、サブアプリケーションルータ２２０は、ＳＩＰサーブレットコンテナに、メッセージを処理するアプリケーション２２４の識別情報とともに、メッセージを返送する。ＳＩＰサーブレットコンテナ２１２は、メッセージを受け取り、アプリケーション識別情報を分析し、メッセージを適切なアプリケーション２２４へ転送する。図２でわかるように、アプリケーション２２４は、複数のＳＡＲファイルを有し、その各々が、ＳＩＰサーブレットのようなサーブレットを含んでいる。

メッセージが特定のアプリケーション２２４に指定されると、ＳＩＰサーブレットコンテナ２１２は、実際にメッセージを処理するために、そのアプリケーション２２４のＳＡＲファイル２２８内の適切なサーブレットを呼び出す（ステップ３２８）。この技術分野の当業者は理解するであろうが、アプリケーション２２４は、それぞれ、３及び２のＳＡＲファイル２２８ａ、２２８ｂを有するように示されているが、１つのアプリケーション２２４は、アプリケーション２２４の機能により、より多いまたは少ない数のＳＡＲファイル２２８を有してもよい。例えば、本発明の技術範囲から外れることなく、１つのアプリケーション２２４が、１、２、３、４またはそれより多いＳＡＲファイル２２８を有してもよい。複数のＳＡＲファイルを有するアプリケーション２２４を、ここでは、マルチＳＡＲアプリケーション２２４と呼ぶ。本発明の実施の形態は、特に、ルートアプリケーションルータ２１６を使用して、共通のサーバ２０４上で、多数のマルチＳＡＲアプリケーション２２４をコホストする能力を提供する。

本発明の少なくともいくつかの実施の形態によれば、アプリケーション２２４は、ＳＩＰメッセージに関する一般的な機能及びフィーチャーを提供する。アプリケーション２２４の中に含まれるＳＡＲファイル２２８は、アプリケーション２２４の機能を提供するために必要とされるステップを実行するプロセスであるサーブレットを含んでいる。一例として、あるアプリケーション２２４は、ボイスメール機能に対応している。ボイスメールアプリケーション２２４内のＳＡＲファイルは、次のようなプロセスを実行するサーブレットを含んでいる。すなわち、あるコールがボイスメールの範囲であると判断すること、適切なボイスメールサーバのロケーションを識別すること、コールをボイスメールサーバへ転送すること、ＩＶＲ機能を発呼者に提供すること、発呼者からのメッセージを記録すること、及びボイスメールサーバ内のメッセージを記憶すること。もちろん、前記のボイスメール機能のいくつかは、別のアプリケーション２２４の分離したＳＡＲファイルとして実行されることもある。更に、ボイスメールはアプリケーション２２４によって提供される典型的な機能の、単に一例に過ぎない。アプリケーション２２４によって提供される、別のタイプの機能は、次のものを含むが、これに限定されない。コール転送機能、コールルーティング機能、カバレージ（ｃｏｖｅｒａｇｅ）機能、記録機能、コールセットアップ機能、ブラックリスト機能、ホワイトリスト機能、到着コール通知機能、コール終了機能、顧客請求（ｂｉｌｌ ｃｕｓｔｏｍｅｒ）機能。アプリケーション２２４を介して使用可能なその他の機能は、この技術分野の当業者には明白であり、それもまた、本発明の技術範囲と見なされる。

メッセージが、ＳＡＲファイル２２８内のサーブレットで処理されているときに、そのサーブレットが、第２メッセージまたはＳＩＰリクエストを生成することがある（例えば、前記のボイスメールアプリケーションの例では、コール転送メッセージ）。このように、ステップ３３２では、最初に受け取ったメッセージを処理することで、サーブレットによって、新たなリクエストまたはメッセージが生成されたか、否かが判断される。もし、この質問が肯定的な答えであれば、メッセージは、アプリケーションサーバ２０４の中にあるかどうかを問わないが、別のコンピュータ操作の要素（ｃｏｍｐｕｔａｔｉｏｎａｌ ｃｏｍｐｏｎｅｎｔ）へと転送できるように、ＳＩＰサーブレットコンテナ２１２に返送される（ステップ３３６）。もし、そのようなメッセージがサーブレットで生成されていた場合には、第２ＳＩＰメッセージが、ルートアプリケーションルータ２１６によって評価されることなく、コンピュータ操作の要素に送られる。

一旦、アプリケーション２２４が、ＳＡＲファイル２２８内の全てのサーブレットを呼び出し、メッセージがそれらのサーブレットで処理されたか、または、ステップ３３２の質問が否定的な答えであるならば、最初のメッセージが追加の処理を要求しているかどうかを判定することで、その方法が継続する（ステップ３４０）。もし、そのメッセージが、おそらく他のアプリケーション２２４での追加の処理を要求しているのであれば、その方法は、ステップ３０４に戻り、メッセージはＳＩＰサーブレットコンテナ２１２に転送され、そしてＳＩＰサーブレットコンテナ２１２が、引き続き、メッセージをルートアプリケーションルータ２１６へ戻すように準備する。もし、追加の処理が要求されなければ、その方法は終了する（ステップ３４４）。もちろん、メッセージ処理を完結させることの一部として、メッセージが、ネットワークインタフェース２０８を介してアプリケーションサーバ２０４から外へ転送されることもある。

この技術分野の当業者は理解するであろうが、図２に示すアプリケーションサーバ２０４は、２つのサブアプリケーションルータ２２０ａ、２２０ｂを含むが、本発明の実施の形態によれば、アプリケーションサーバ２０４は、より多い、またはより少ない数のサブアプリケーションルータ２２０を有してもよい。

同様に、アプリケーションサーバ２０４は、２つのアプリケーション２２４ａ、２２４ｂのみを持つように示されているが、本発明の実施の形態によれば、アプリケーションサーバ２０４は、より多い、またはより少ない数のアプリケーション２２４を有してもよい。更に、サブアプリケーションルータ２２０の数は、アプリケーションサーバ２０４内のアプリケーション２２４の数とは、通常、合致することはない。従って、単一のサブアプリケーションルータ２２０が、多数のアプリケーション２２８の間のメッセージのルーティングの決定を行うようになっていることもある。言い換えると、サブアプリケーションルータ２２０は、メッセージが、処理のために、第１の、第２、第３の、第４の、などのアプリケーション２２４に送られるべきかどうかを決定するようになっており、サブアプリケーションルータ２２０で受け取られた異なるメッセージに対して異なる決定をすることもある。更に、このような実施の形態は他の多くの考慮に依存するが、２つのサブアプリケーションルータ２２０は、共通のアプリケーション２２４へメッセージをルートするようになっていることもある（すなわち、複数のサブアプリケーションルータ２２０が１つのアプリケーション２２４をシェアする）。

用語「コンピュータで読み取り可能な媒体」とは、コンピュータが実行するプロセスを記憶する媒体或いは伝送媒体を意味する。媒体とは、非揮発性媒体、揮発性媒体、伝送媒体を意味する。非揮発性の媒体とは、ＮＶＲＡＭ、磁気ディスク又は光学ディスクである。揮発性媒体とは、ＤＲＡＭ、メインメモリを意味する。このコンピュータで読み取り可能な媒体の一般的なものとしては、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気ディスク、他の磁気媒体、磁気光学媒体、ＣＤ−ＲＯＭ、パンチカード、ペーパーテープ等、更にＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、メモリカード、メモリチップ、或いはカートリッジ等がある。ｅ−ｍａｉｌ或いは他の自己保存型の情報アーカイブに付属したデジタルファイルは、記憶媒体に等価な分配型の記憶媒体であり、本発明でいう記憶媒体と見なすことができる。コンピュータで読み取り可能な媒体がデータベースとして構築された場合には、このデータベースは、あらゆる種類のデータベース、例えば関連型、階層型、オブジェクト志向型のいずれをも含む。
用語「モジュール」「エージェント」「ツール」とは、ハードウエア、ソフトウエア、ファームウエア、人工知能、ファジーロジック、それらの組み合わせを言う。
上記したイベント、事象の発生順は、本発明の動作／効果に影響を与えずに変更可能である。特に断りのない限り、実施例の順にはこだわらない。
ここで議論したフローチャートは、特定のイベントのシーケンスを例に説明するが、本発明の操作に影響を及ぼすことなく、これ等のシーケンスの変更、追加、一部省略も可能である。本発明のシステムと方法は、特殊コンピュータ、プログラムされたマイクロプロセッサ、マイクロコントローラ、ＡＳＩＣ、他の集積回路ＤＳＰ、ハードワイヤド電子素子、論理素子、例えばディスクリートな要素回路、プログラム可能な論理回路、ゲートアレイ、例えばＰＬＤ、ＰＬＡ、ＦＰＧＡ、ＰＡＬ、特殊目的コンピュータ或いは他の手段で実現できる。
他の実施例に於いては、ここに開示された方法は、オブジェクト指向のソフトウエア開発環境を用いたソフトウエアと組み合わせて実現できる。このソフトウエア環境は、様々なコンピュータ又はワークステーションで使用されるポータブルなソースコードを提供する。別の構成として、開示されたシステムは、標準の論理回路又はＶＬＳＩデザインを用いて一部又は全部のハードウエアで実現できる。本発明のシステムを実行するのにハードウエア又はソフトウエアを用いるかは、システムに要求される速度と効率に依存する。特に使用される特定のソフトウエア、ハードウエアのシステム、マイクロプロセッサ又はマイクロコンピュータシステムに依存する。
他の実施例に於いては、開示された方法は、コンピュータで読み取り可能な記憶媒体に記憶されたソフトウエアで実行され、コントローラとメモリとを有するプログラムされた汎用コンピュータ、特殊目的コンピュータ、マイクロプロセッサ等で実施される。これ等の実施例に於いては、本発明のシステムと方法は、パソコンに組み込まれたプログラムで実行できる。例えばアプレット、ＪＡＶＡ、ＣＧＩスクプリト、サーバ或いはコンピュータ、ワークステーションに記録された資源或いは専用の測定システムに組み込まれたルーチン等で実施できる。
本発明のシステムは、本発明のシステムと方法をソフトウエア又はハードウエアのシステムに物理的に組み込むことにより実施することもできる。 本発明は、特定の標準及びプロトコルを例に説明したが、本発明はこのような標準とプロトコルに制限されるものではない。他の類似の標準とプロトコルも本発明で用いることができる。これ等の標準とプロトコルは、今後開発されるより効率的な標準とプロトコルで置換されるかも知れないが、このような置換も本発明の一態様（一実施例）と考えられる。

以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。用語「又は」に関して、例えば「Ａ又はＢ」は、「Ａのみ」、「Ｂのみ」ならず、「ＡとＢの両方」を選択することも含む。特に記載のない限り、装置又は手段の数は、単数か複数かを問わない。

１００ 通信システム
１０４ 通信ネットワーク
１０８ 通信デバイス
１１２ アプリケーションサーバ
１１６ ネットワークインタフェース
１２０ ＳＩＰサーブレットコンテナ
１２４ アプリケーションルータ
１２８ ＳＡＲファイル
２００ 通信システム
２０４ アプリケーションサーバ
２０８ ネットワークインタフェース
２１２ ＳＩＰサーブレットコンテナ
２１６ ルートアプリケーションルータ
２２０ サブアプリケーションルータ
２２４ アプリケーション
２２８ ＳＡＲファイル
３０４ ＳＩＰメッセージをＳＩＰサーブレットコンテナで受け取る
３０８ ＳＩＰメッセージをルートアプリケーションルータへ渡す
３１２ ルーティング規則セットを評価する
３１６ ターゲットのサブアプリケーションルータを識別する
３２０ ルートアプリケーションルータが識別されたサブアプリケーションルータへメッセージを委託する
３２４ サブアプリケーションルータがＳＩＰメッセージを処理することを決定する
３２８ 適切なＳＡＲファイルを呼び出す
３３２ サブアプリケーションルータから第２リクエストが出現するか？
３３６ 第２リクエストをルートアプリケーションルータのあたりに送る
３４０ 追加の処理は？
３４４ 終了

Claims (7)

1. ネットワークインタフェース（２０８）と、ＳＩＰサーブレットコンテナ（２１２）と、ルートアプリケーションルータ（２１６）と、複数のサブアプリケーションルータ（２２０）と、サーブレット（２２８）をそれぞれ有する複数のアプリケーション（２２４）と、を有する第１アプリケーションサーバ（２０４）において、
   （Ａ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記ネットワークインタフェース（２０８）を介して、ＳＩＰメッセージを含む第１メッセージを受け取るステップ（３０４）と、
   （Ｂ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記第１メッセージを、前記ルートアプリケーションルータ（２１６）へ送るステップ（３０８）と、
   （Ｃ）前記ルートアプリケーションルータ（２１６）が、メッセージをルーティングする規則に従って、前記複数のサブアプリケーションルータ（２２０）の中で、前記第１メッセージを受領すべき第１サブアプリケーションルータ（２２０ａ）を決定するステップと、
   （Ｄ）前記ルートアプリケーションルータ（２１６）が、前記第１メッセージを、前記ステップ（Ｃ）で決定された第１サブアプリケーションルータ（２２０ａ）へ送信するステップ（３２０）と、
   （Ｅ）前記第１サブアプリケーションルータ（２２０ａ）が、前記メッセージをルーティングする規則に従って、前記複数のアプリケーション（２２４）の中でどのアプリケーションが前記第１メッセージを処理すべきかを決定するステップ（３２４）と、
   （Ｆ）前記ステップ（Ｅ）で第１メッセージを処理すべきと決定されたアプリケーション（２２４ａ）の識別情報を、前記ＳＩＰサーブレットコンテナ（２１２）へ送るステップと、
   （Ｇ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記第１サブアプリケーションルータ（２２０ａ）から返送されてきた前記第１メッセージを、前記ステップ（Ｅ）で第１メッセージを処理すべきと決定されたアプリケーション（２２４ａ）へ転送するステップと、
   （Ｌ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記ネットワークインタフェース（２０８）を介して、前記第１メッセージとは異なる第２メッセージを受け取るステップと、
   （Ｍ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記第２メッセージを、前記ルートアプリケーションルータ（２１６）に渡すステップと、
   （Ｎ）前記ルートアプリケーションルータ（２１６）が、前記メッセージをルーティングする規則に従って、前記第２メッセージを受け取るべき第２サブアプリケーションルータ（２２０ｂ）を決定するステップと、
   前記ステップ（Ｎ）において、前記第２メッセージを受け取ると決定された前記第２サブアプリケーションルータ（２２０ｂ）は、前記第１メッセージを受け取ると決定された前記第１サブアプリケーションルータ（２２０ａ）でなく、
   （Ｏ）前記第２メッセージを、前記第２サブアプリケーションルータ（２２０ｂ）へ渡すステップと、
   前記第２サブアプリケーションルータ（２２０ｂ）もまた、前記第１アプリケーションサーバ（２０４）内に存在し、
   （Ｐ）前記第２サブアプリケーションルータ（２２０ｂ）が、前記規則に従って、複数のアプリケーションの中でどのアプリケーションが前記第２メッセージを処理すべきかを決定するステップと、
   （Ｑ）前記ステップ（Ｐ）で第２メッセージを処理すべきと決定されたアプリケーション（２２４ａ）の識別情報を、前記ＳＩＰサーブレットコンテナ（２１２）へ送るステップと、
   （Ｒ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記第２サブアプリケーションルータ（２２０ｂ）から返送されてきた前記第２メッセージを、複数のアプリケーションの中で前記ステップ（Ｐ）で第２メッセージを処理すべきと決定されたアプリケーションへ転送するステップと、
   を有する
   ことを特徴とする方法。
2. （Ａ）ルートアプリケーションルータ（２１６）と、
   前記ルートアプリケーションルータ（２１６）は、前記複数のサブアプリケーションルータ（２２０）にＳＩＰメッセージを含むメッセージを分配し、
   （Ｂ）前記ルートアプリケーションルータ（２１６）と通信する複数のサブアプリケーションルータ（２２０）と、
   （Ｃ）サーブレット（２２８）を含む複数のアプリケーション（２２４）と、
   （Ｄ）ＳＩＰサーブレット・コンテナ（２１２）と
   を有するアプリケーションサーバ（２０４）において、
   前記各々のサブアプリケーションルータ（２２０）は、前記ルートアプリケーションルータ（２１６）からメッセージを受け取り、メッセージをルーティングする規則に従って、前記複数のアプリケーション（２２４）の中から前記メッセージを処理するために使用されるアプリケーション（２２４）を決定し、
   前記サブアプリケーションルータ（２２０）は、前記メッセージを処理すべきと決されたアプリケーション（２２４）の識別情報を、前記ＳＩＰサーブレット・コンテナ（２１２）に送り、
   前記ＳＩＰサーブレット・コンテナ（２１２）は、前記サブアプリケーションルータ（２２０）から返送されてきた前記メッセージを、前記メッセージを処理すべきと決定されたアプリケーションに転送し、
   前記各アプリケーション（２２４）は、前記サーブレット（２２８）で前記メッセージを処理し、前記アプリケーション（２２４）は、特定の機能を提供し、前記サーブレットは、決定されたアプリケーション（２２４）の特定の機能に従って、前記メッセージで操作を実行する
   ことを特徴とするアプリケーションサーバ。
3. （Ｈ）前記ステップ（Ｃ）でメッセージを処理すべきと決定されたアプリケーションが前記第１メッセージを前記サーブレットで処理するステップを更に有し、
   前記ステップ（Ｈ）で、前記メッセージを処理すべきと決定されたアプリケーションが、特定の機能を提供し、前記サーブレットが、前記決定されたアプリケーションの前記特定の機能に従って、前記第１メッセージの操作を実行する、
   ことを特徴とする請求項１に記載の方法。
4. 前記特定の機能が、ボイスメール機能、コール転送機能、コールルーティング機能、カバレージ機能、記録機能、コールセットアップ機能、ブラックリスト機能、ホワイトリスト機能、到着コール通知機能、コール終了機能、顧客請求書機能の内のいずれかを含む
   ことを特徴とする請求項３に記載の方法。
5. （Ｉ）前記サーブレットが、第２応答ＳＩＰメッセージを生成するステップと、
   前記第２応答ＳＩＰメッセージは、前記第１メッセージの処理に応じて生成され、
   （Ｊ）前記サーブレットが、前記第２応答ＳＩＰメッセージを、前記ＳＩＰサーブレットコンテナ（２１２）へ送るステップと、
   （Ｋ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記第２応答ＳＩＰメッセージを、コンピュータの要素へ転送するステップと、
   を更に有し、
   前記ステップ（Ｋ）は、前記メッセージを前記ルートアプリケーションルータ（２１６）に送ることなく行われる、
   ことを含む請求項３に記載の方法。
6. 前記コンピュータの要素が、前記第１アプリケーションサーバ内に存在しない
   ことを特徴とする請求項５に記載の方法。
7. ネットワークインタフェース（２０８）と、ＳＩＰサーブレットコンテナ（２１２）と、ルートアプリケーションルータ（２１６）と、複数のサブアプリケーションルータ（２２０）と、サーブレット（２２８）をそれぞれ有する複数のアプリケーション（２２４）と、を有する第１アプリケーションサーバ（２０４）に使用されるコンピュータで読み取り可能な記憶媒体において、
   （Ａ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記ネットワークインタフェース（２０８）を介して、ＳＩＰメッセージを含む第１メッセージを受け取るステップ（３０４）と、
   （Ｂ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記第１メッセージを、前記ルートアプリケーションルータ（２１６）へ送るステップ（３０８）と、
   （Ｃ）前記ルートアプリケーションルータ（２１６）が、メッセージをルーティングする規則に従って、前記複数のサブアプリケーションルータ（２２０）の中で、前記第１メッセージを受領すべき第１サブアプリケーションルータ（２２０ａ）を決定するステップと、
   （Ｄ）前記ルートアプリケーションルータ（２１６）が、前記第１メッセージを、前記ステップ（Ｃ）で決定された第１サブアプリケーションルータ（２２０ａ）へ送信するステップ（３２０）と、
   （Ｅ）前記第１サブアプリケーションルータ（２２０ａ）が、前記メッセージをルーティングする規則に従って、前記複数のアプリケーション（２２４）の中でどのアプリケーションが前記第１メッセージを処理すべきかを決定するステップ（３２４）と、
   （Ｆ）前記ステップ（Ｅ）で第１メッセージを処理すべきと決定されたアプリケーション（２２４ａ）の識別情報を、前記ＳＩＰサーブレットコンテナ（２１２）へ送るステップと、
   （Ｇ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記第１サブアプリケーションルータ（２２０ａ）から返送されてきた前記第１メッセージを、前記ステップ（Ｅ）で第１メッセージを処理すべきと決定されたアプリケーション（２２４ａ）へ転送するステップと、
   （Ｌ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記ネットワークインタフェース（２０８）を介して、前記第１メッセージとは異なる第２メッセージを受け取るステップと、
   （Ｍ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記第２メッセージを、前記ルートアプリケーションルータ（２１６）に渡すステップと、
   （Ｎ）前記ルートアプリケーションルータ（２１６）が、前記メッセージをルーティングする規則に従って、前記第２メッセージを受け取るべき第２サブアプリケーションルータ（２２０ｂ）を決定するステップと、
   前記ステップ（Ｎ）において、前記第２メッセージを受け取ると決定された前記第２サブアプリケーションルータ（２２０ｂ）は、前記第１メッセージを受け取ると決定された前記第１サブアプリケーションルータ（２２０ａ）でなく、
   （Ｏ）前記第２メッセージを、前記第２サブアプリケーションルータ（２２０ｂ）へ渡すステップと、
   前記第２サブアプリケーションルータ（２２０ｂ）もまた、前記第１アプリケーションサーバ（２０４）内に存在し、
   （Ｐ）前記第２サブアプリケーションルータ（２２０ｂ）が、前記規則に従って、複数のアプリケーションの中でどのアプリケーションが前記第２メッセージを処理すべきかを決定するステップと、
   （Ｑ）前記ステップ（Ｐ）で第２メッセージを処理すべきと決定されたアプリケーション（２２４ａ）の識別情報を、前記ＳＩＰサーブレットコンテナ（２１２）へ送るステップと、
   （Ｒ）前記ＳＩＰサーブレットコンテナ（２１２）が、前記第２サブアプリケーションルータ（２２０ｂ）から返送されてきた前記第２メッセージを、複数のアプリケーションの中で前記ステップ（Ｐ）で第２メッセージを処理すべきと決定されたアプリケーションへ転送するステップと、
   上記のステップ（Ａ）−（Ｒ）を実行する為に、プロセッサーが実行可能なインストラクションを含むことを特徴とするコンピュータで読み取り可能な記憶媒体。

Images