(57)【要約】【課題】インテリジェント・ネットワーク向けのアプリケーション実行環境を提供すること。【解決手段】アプリケーション実行環境は、サービス論理層にサービス論理実行環境（ＳＬＥＥ）を含む。特に、ＳＬＥＥは、ＪＡＩＮ準拠のＳＬＥＥとすることができる。ＳＬＥＥは、サービス論理層のサービス・コンポーネントと、プロトコル層およびアプリケーション層のクライアント・コンポーネントの間でイベントをルーティングするためのイベント・ルーティング・バスを含むことができる。アプリケーション実行環境は、また、プロトコル層に少なくとも１つのクライアント・コンポーネントを含むことができ、この少なくとも１つのクライアント・コンポーネントは、コネクタ／ラッパ・インターフェースを介して、ＳＬＥＥに通信可能にリンクする。最後に、アプリケーション実行環境は、ＳＬＥＥ内で実行される少なくとも１つの電話サービス・コンポーネントを含むことができ、この電話サービス・コンポーネントは、ＳＬＥＥ内のイベント・ルーティング・バスを介して、プロトコル層のクライアント・コンポーネントおよびサービス論理層の他のサービス・コンポーネントと通信するように構成することができる。【選択図】図２
2004537886.tif 000002
【特許請求の範囲】
【請求項１】
インテリジェント・ネットワーク向けのアプリケーション実行環境であって、
サービス論理層にあり、サービス論理層のサービス・コンポーネントとプロトコル層およびアプリケーション層のクライアント・コンポーネントの間でイベントをルーティングするためのイベント・ルーティング・バスを含むサービス論理実行環境（ＳＬＥＥ）と、
前記プロトコル層にあり、コネクタ／ラッパ・インターフェースを介して前記ＳＬＥＥに通信可能にリンクされた少なくとも１つのクライアント・コンポーネントと、
少なくとも１つが前記ＳＬＥＥ内で実行され、前記プロトコル層のクライアント・コンポーネントおよび前記サービス論理層の他のサービス・コンポーネントと、前記ＳＬＥＥ内の前記イベント・ルーティング・バスを介して通信するように構成された電話サービス・コンポーネントと
を含む、アプリケーション実行環境。
【請求項２】
少なくとも１つが前記ＳＬＥＥ内で実行され、前記ＳＬＥＥ内の他のサービス・コンポーネントおよび前記アプリケーション層の特定の外部サービスと通信するように構成された総称サービス・コンポーネントをさらに含む、請求項１に記載のアプリケーション実行環境。
【請求項３】
少なくとも１つが前記ＳＬＥＥ内で実行され、前記イベント・ハンドラを介して前記ＳＬＥＥ内の他のサービス・コンポーネントとの間でメッセージの送受信を行うように構成され、前記ＳＬＥＥの外部のサーバ側プログラムと通信可能なリンクを備えるインターネット対応サービス・コンポーネント（ＩＥＳＣ）をさらに含む、請求項１または２のいずれかに記載のアプリケーション実行環境。
【請求項４】
前記コネクタ／ラッパ・インターフェースが、
前記プロトコル層のクライアント・コンポーネントに抽象インターフェースを提供するクライアント・コンポーネント・ラッパと、
前記ＳＬＥＥに関連付けられ、前記クライアント・コンポーネント・ラッパに対応し、前記クライアント・コンポーネント・ラッパによって提供される前記抽象インターフェースを介して前記クライアント・コンポーネントと通信するように構成されたコネクタと
を含む、請求項１ないし３のいずれかに記載のアプリケーション実行環境。
【請求項５】
前記ＳＬＥＥがコネクタ／ラッパ・インターフェースを介して通信するように構成することができる、少なくとも１つのクライアント・コンポーネントを指定するＳＬＥＥディスクリプタをさらに含む、請求項１ないし４のいずれかに記載のアプリケーション実行環境。
【請求項６】
それぞれが前記プロトコル層の特定のクライアント・コンポーネントに対応し、特定のイベントを指定し、そのイベントについて、前記ＳＬＥＥ内の前記イベント・ルーティング・バスによって前記特定のクライアント・コンポーネントに通知することができる、少なくとも１つのクライアント・コンポーネント・ディスクリプタをさらに含む、請求項１ないし５のいずれかに記載のアプリケーション実行環境。
【請求項７】
前記クライアント・コンポーネントがプロトコル・スタックである、請求項１ないし６のいずれかに記載のアプリケーション実行環境。
【請求項８】
前記クライアント・コンポーネントが、コール制御コンポーネント、シグナリング・プロトコル・コンポーネント、接続管理プロトコル・コンポーネント、およびセキュア・ネットワーク・アクセス・プロトコル・コンポーネントからなる群から選択される、請求項１ないし６のいずれか一項に記載のアプリケーション実行環境。
【請求項９】
前記ＳＬＥＥがＪＡＩＮ準拠のＳＬＥＥである、請求項１ないし８のいずれかに記載のアプリケーション実行環境。
【請求項１０】
前記ＳＬＥＥが、
サービス・コンポーネントを前記ＳＬＥＥ内にロードするためのクラス・ローダをさらに含み、
前記ＳＬＥＥが、ロードされた各サービス・コンポーネントを、特定の登録済みサービス・コンポーネント向けのイベントを受信するために登録し、前記イベント・ルーティング・バスが、前記受信済みイベントを、前記ＳＬＥＥ内で実行される前記特定の登録済みサービス・コンポーネントにルーティングする、
請求項１ないし９のいずれかに記載のアプリケーション実行環境。
【請求項１１】
前記ＳＬＥＥが、
スレッド・プールと、
スレッドを前記ロードされたサービス・コンポーネントが使用できるように割り振るためのスレッド・プール・マネージャと
をさらに含む、請求項１ないし１０のいずれかに記載のアプリケーション実行環境。
【請求項１２】
サービス論理実行環境（ＳＬＥＥ）内のイベント・ルーティング・バスにおいて、コネクタ／ラッパ・インターフェースを介してクライアント・コンポーネントからプロトコル層イベントを受信するステップと、
前記ＳＬＥＥ内で実行されるサービス・コンポーネントからサービス論理層イベントを受信するステップと、
前記特定のプロトコル層イベントおよび前記サービス論理層イベントを、前記特定のプロトコル層イベントおよび前記サービス論理層イベントを受信するために登録されたサービス・コンポーネントおよびクライアント・コンポーネントに転送するステップと、
前記ＳＬＥＥ内で実行される前記サービス・コンポーネントのうちの少なくとも１つにおいて、
少なくとも１つのサービス論理層イベントを前記イベント・ルーティング・バスに送信するステップを含み、
前記イベント・ルーティング・バスは、前記送信されたサービス論理層イベントを、前記送信されたサービス論理層イベントを受信するために登録された別のサービス・コンポーネントに転送することができる、
電話サービス提供方法。
【請求項１３】
前記サービス・コンポーネントのうちの少なくとも１つにおいて、特定の外部サービスと通信リンクを確立するステップと、
別のサービス・コンポーネントから外部サービスを要求するサービス論理層イベントを受信するステップと、
前記別のサービス・コンポーネントから前記サービス論理層イベントを受信したことに応答して、前記リンクされた特定の外部サービスによって提供される機能への少なくとも１つの特定の呼び出しを介して、前記要求された外部サービスを提供するステップと
をさらに含む、請求項１２に記載の電話サービス提供方法。
【請求項１４】
電話サービスを提供するためのコンピュータ・プログラムを格納する機械可読記憶装置であって、前記コンピュータ・プログラムが、機械に請求項１２または請求項１３のいずれかに記載のステップを実施させるために、前記機械で実行可能なプログラム・コードを含む、機械可読記憶装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、高度インテリジェント・ネットワークの分野に関し、より詳細には、統合ネットワーク・サービス・プロバイダ向けのサービス・アプリケーション・アーキテクチャに関する。
【背景技術】
【０００２】
オープン・ネットワーク・アプリケーション・プログラミング・インターフェース（ＡＰＩ）は、公衆交換電話網（ＰＳＴＮ）アーキテクチャをオープンにするための従来方法からの重要な脱却を意味している。こうしたオープン・ネットワークＡＰＩの１つである、高度インテリジェント・ネットワーク（ＡＩＮ）ＡＰＩおよびアーキテクチャでは、スイッチ環境外での遠隔通信サービス・アプリケーションの生成を可能にするコール・モデルが定義される。遠隔通信サービス・アプリケーションは、二者以上の間で確立される遠隔通信セッション向けの高度サービスを実施することができる選択可能な遠隔通信アプリケーションである。こうしたサービス・アプリケーションの例には、キャッチホン、発信者番号通知、自動転送、音声ダイヤル、および参加型電話会議がある。
【０００３】
ＡＩＮが初めて導入されたとき、ＡＩＮアーキテクチャはサービス・アプリケーション生成プロセスの面での重要な進歩を意味していた。スイッチングから切り離されたＡＩＮのサービス開発では、サービス論理コンポーネントを、より迅速に開発し、データベースに接続された特定のネットワーク要素内に配置することができる。スイッチは、その結果、すべてのサービス論理から解放され、速度および効率についてその最適化を図ることができる。しかし、ＡＩＮ仕様で開発された通常のサービス・アプリケーションは、特別なサービス生成環境を用いて、特別に訓練されたプログラマによって、特別な言語で記述されている。
【０００４】
重要なことに、今後の遠隔通信ネットワークは新しい進化するネットワーク・アーキテクチャを特徴とし、このアーキテクチャでは、パケット交換、回線交換、および無線のネットワークが統合され、一連の革新的なマルチメディアのマルチパーティ・アプリケーションが加入者に提供されるようになる。同様に重要なことに、遠隔通信アプリケーション開発のプロセスが変化し、単に遠隔通信ネットワーク・プロバイダまたはサービス・アプリケーション・プロバイダの分野ではなくなると予想される。実際、新規で強力なアプリケーションの幅広いポートフォリオを迅速に提供するために、サービス・アプリケーション・プロバイダは、第三者のアプリケーション開発者およびソフトウエア・ベンダにますます依存するようになる。したがって、遠隔通信分野のアプリケーション開発は、一般にソフトウエアおよび情報技術のそれとますます類似するようになり、それが開発されるに伴って、顧客は競争の激化、製品化までの時間短縮および新技術の利用の恩恵を享受することになる。
【０００５】
こうしたビジョンを実現するために、新しいサービス・アプリケーション・コンポーネント開発パラダイムが優先され、ＡＩＮの原理は切り捨てられてきた。特に、今後の統合ネットワークは、あるベンダのシステムとの互換がとれるように作成されたアプリケーションが他のベンダのシステムで実行できるように、アプリケーション開発者に１組の標準、すなわちオープンＡＰＩを提供する必要があることが認識されてきた。その結果、アプリケーション開発コストが償却され、顧客への最終コストを削減することができる。統合ネットワーク向けＪＡＶＡ（Ｒ）ＡＰＩ（ＪＡＩＮ）はこの新しいサービス・アプリケーション・コンポーネント開発パラダイムの要件を満たすものである。現在、ＪＡＩＮは、統合インターネット・プロトコル（ＩＰ）または非同期転送モード（ＡＴＭ）ネットワーク、ＰＳＴＮ、および無線ネットワークからなる次世代システム向けの公開された標準のオープンなＪＡＶＡ（Ｒ）ＡＰＩを含んでいる。ＪＡＩＮ  ＡＰＩは、メディア・ゲートウェイ制御プロトコル（ＭＧＣＰ）、セッション初期化プロトコル(ＳＩＰ）、トランザクション機能アプリケーション部（ＴＣＡＰ）、ならびに遠隔通信プロトコル・スタックの上位層に常駐するプロトコルなど様々なプロトコル用に、プロトコル・レベルのインターフェースを含んでいる。
【０００６】
ＪＡＩＮは、ＪＡＩＮコンポーネントを構築し、ＰＳＴＮ、パケットおよび無線ネットワークにわたって機能するサービスまたはアプリケーションに統合するためのＪａｖａ（Ｒ）プラットフォーム向けの１組の統合ネットワークＡＰＩおよび環境を含んでいる。ＪＡＩＮ手法では、サービス・ベースの論理をネットワーク・ベースの論理から切り離すことによって有線、無線、およびパケット・ベースのネットワークを統合する。図１に従来型のＪＡＩＮ実装を示す。図１に示すように、従来型のＪＡＩＮ実装は、プロトコル層１０２を含むことができ、このプロトコル層はＩＰ、有線、無線のシグナリング・プロトコルとのインターフェースを含むことができる。ＴＣＡＰ、ＪＣＣ、およびＨ．３２３プロトコル１１０だけが示されているが、ＪＡＩＮ仕様によってサポートされるプロトコルは、特定のプロトコルに限定されず、たとえばＴＣＡＰ、ＩＳＵＰ、ＩＮＡＰ、ＭＡＰ、ＳＩＰ、ＭＧＣＰおよびＨ．３２３を含むことができる。さらに、ＪＡＩＮ実装は、ＪＣＣなどの接続管理およびコール制御プロトコルとのインターフェースを含むことができる。
【０００７】
従来型のＪＡＩＮ実装では、プロトコル層１０２に加えて、セキュア・ネットワーク・アクセスおよび他の外部サービス１２０を処理するためのアプリケーション層１０４を含むこともできる。従来型のＪＡＩＮ実装では、サービス論理層１０６も含むことができ、このサービス論理層はサービス生成およびキャリア・グレードのサービス論理実行環境（ＳＬＥＥ）１０８を含むことができる。サービス・コンポーネント１１２は核となるＪＡＩＮコンポーネントであり、ＳＬＥＥ１０８内で実行することができる。より具体的には、サービス・コンポーネント１１２は電話およびネットワーク・サービスを実装することができ、標準のコンポーネント・モデルに従って構築することができる。サービス・コンポーネント・アセンブリのインスタンスは、ＳＬＥＥ１０８と協調して実行される。
【０００８】
動作中、サービス・コンポーネント１１２は、ＳＬＥＥ１０８に組み込むことができるプロトコル層１０２に関する情報を使用して、プロトコル・スタック１１０に関する特定の知識がなくても基本となるプロトコル・スタック１１０と対話することができる。さらに重要なことに、ＳＬＥＥ１０８では、トランザクション、持続性、ロード・バランシング、セキュリティ、およびオブジェクトならび接続インスタンス・プーリングのための移植可能なサポートを提供することによって、サービス・コンポーネント１１２が負う従来のライフサイクルにわたる責任を軽減することができる。このようにして、サービス・コンポーネント１１２は、電話サービスまたはネットワーク・サービスあるいはその両方の提供に集中することができる。特に、ＳＬＥＥ１０８は、外部アプリケーション１１６、プロトコル・スタック１１０、サービス・コンポーネント１１２などのクライアント・コンポーネントに直接、通信可能にリンクすることができる。
【０００９】
たとえば、ＳＬＥＥ１０８のサービス論理層１０６で実行されるサービス・コンポーネント１１２は、ＳＬＥＥ１０８のプロトコル・アダプタを介して、プロトコル層のプロトコル・スタック１１０と通信することができる。プロトコル・アダプタは一般にクラス・メソッド、コールバック、カプセル化インターフェース、またはイベント・ハンドラを含むことができる。多くの場合、基本となるプロトコル・スタック１１０は、ＳＬＥＥ１０８のイベント・テーブル１１４を介して、ＳＬＥＥ１０８と直接に通信することができ、このイベント・テーブルは基本となるプロトコル・スタック１１０にとって特別なイベントを固有に処理するように構成することができる。その結果、ＳＬＥＥ１０８は、特別なイベントを認識することができ、基本となるプロトコル・スタック１１０からこうしたイベントを受信すると、ＳＬＥＥ１０８は登録しているサービス・コンポーネント１１２にそのイベントを渡すことができる。また、サービス・コンポーネント１１２は、リレーショナル・データベースやディレクトリ・サービスなどの特定の外部サービス１２０と対話するように個別にプログラムすることができる。
【００１０】
しかし、一見すると有利なＪＡＩＮ仕様であるが、従来型のＪＡＩＮ仕様の実装は、特にリアル・タイム電話の応用例においていくつかの欠点を含んでいる。まず、従来型のＪＡＩＮ実装のＳＬＥＥは、たとえばライフサイクルにわたる責任などの不要なシステム・ハウスキーピングの雑用を伴うEnterprise Java bean（登録商標）（ＥＪＢ）手法を取り入れている。しかし、ライフサイクルにわたる責任は、リアル・タイム電話分野にとっては、他の通信分野ほどに重要ではない。したがって、ＥＪＢを使用すると、待ち時間が多すぎてリアル・タイム操作の要求を満たすことができない。さらに、ＳＬＥＥと基本となるプロトコル・スタックの間の通信を容易にするために使用することができる対応イベント・テーブルから明らかであるように、サービス・コンポーネント上のプロトコル・スタックの複雑さを緩和するには、ＳＬＥＥに、基本となるプロトコル・スタックの特定の知識が必要になる。しかし、ＳＬＥＥに特定のクライアント・コンポーネント情報を含めると、ＳＬＥＥに不必要な複雑さが加わることがある。ライフサイクル・メンテナンスの点からするとこれは問題になり得る。また、ＳＬＥＥにクライアント・コンポーネント情報を含めると、特定のクライアント・コンポーネントにＳＬＥＥを不必要に直接バインドすることにもなる。最後に、ＳＬＥＥを特定のクライアント・コンポーネントに直接バインドするには、アプリケーション層、プロトコル層およびサービス論理層をコンピューティング上で互いにきわめて近接して配置しなければならないことがある。
【００１１】
ＳＬＥＥ内のサービス・コンポーネントとの通信も外部アプリケーションにとって問題になることがある。特に、外部アプリケーションは、それが通信することができるＳＬＥＥ内のサービス・コンポーネントとプログラム上でバインドされなければならない。外部アプリケーションが、インターネットなどのコンピュータ通信ネットワーク全体にわたって分散されている場合は、この問題が複雑になることがある。したがって、ワールド・ワイド・ウェブを含めたインターネットを介して利用可能なサービスまたは他の機能を統合しようとするいずれの試みも、別個のプロプラエタリ・システムを使用して実装しなければならない。
【００１２】
特に、ＪＡＩＮ仕様によれば、無線サービス・アプリケーションの開発には、無線サービスにアクセスするための多数の異なる通信インターフェースおよびプロトコルに関する知識が必要である。たとえば、現在、無線ネットワークの使用をサポートする様々な異なる通信プロトコルが存在している。こうしたプロトコルには、移動通信向けグローバル・システム（ＧＳＭ）、総称パケット無線サービス（ＧＰＲＳ）、拡張データＧＳＭ環境（ＥＤＧＥ）、ユニバーサル移動電話システム（ＵＴＭＳ）、無線アプリケーション・プロトコル（ＷＡＰ）、移動アクセス・プロトコル（ＭＡＰ）、およびｉ−Ｍｏｄｅが含まれる。
【００１３】
無線サービス・アプリケーションを開発するために、開発者は、開発する無線サービス・アプリケーションに組み込まれる無線サービスまたは機能に対応する特定の無線プロトコル・インターフェースを熟知しなければならない。たとえば、ＷＡＰは、無線装置による通信を標準化する１組の通信プロトコル用の仕様である。したがって、ハンドヘルド装置の無線サービス向けのサービス・アプリケーションの開発者は、こうしたサービス・アプリケーションを首尾よく開発するためには、ＷＡＰについて少なくとも全般的に熟知している必要がある。
【００１４】
同様に、無線のハンドヘルド装置を介したウェブ・サイトのインタラクティブな使用を可能にするアプリケーション・サービスを提供しようとするサービス・アプリケーション開発者は、おそらく、ＷＡＰより高いデータ速度を提供することができるＧＰＲＳを熟知する必要があろう。ＧＰＲＳやＷＡＰなどのソリューションは様々な装置およびサービスの相互運用性を高め、またプロプライエタリ・ソリューションの使用を最小限に抑えることができる。しかし、様々な無線サービス・アプリケーションを開発するためには、開発者は多種の無線プロトコルおよびインターフェースを熟知しなければならない。したがって、様々な無線通信プロトコルおよびインターフェースを使用するのに必要な専門知識を有する人の数が限られることがある。
【００１５】
無線サービス・アプリケーションの開発に際して直面する問題と同様に、遠隔通信サービス・アプリケーションの開発もまたサービス・アプリケーションおよび機能にアクセスするための多くの異なる通信インターフェースおよびプロトコルに関する知識を必要とする。たとえば、コール・ブロッキングや自動転送などのサービス・アプリケーションでは、コール・モデルにアクセスするためのサービス・コンポーネントに加えて、コール・モデルを実装するための情報にアクセスするためにディレクトリ・サービスまたは他のプロプラエタリ・データベースへのアクセスが必要となることがある。しかし、ディレクトリ・サービスにアクセスするには、簡易ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）に関する特定の知識が必要となることがある。一方、どんな特定のデータベースにアクセスするにも、ＤＢ２、ＭＱＳｅｒｉｅｓ、または別のプロプライエタリ・データベース・アクセス・プロトコルに関する知識が必要となることがある。
【００１６】
通常、特定のプロトコルを用いて無線アプリケーションを実装するために必要な知識は、極めて専門的なため、必要な専門知識を有する人が所与の組織内で１人しかいないことがある。こうした人事上のジレンマは、しばしば、特定の無線フォーマットについてソリューションが開発されるたびに、そのソリューションを異なる無線フォーマットまたはプロトコルに容易には移植できないという形で現れる。さらに、プログラミングの専門知識は極めて専門的なことがあるので、サービス・アプリケーションを別のフォーマットまたはプロトコルに移植するには、一般に、対象のフォーマットまたはプロトコルの専門知識を有する追加の要員が必要になる。
【００１７】
したがって、電話サービス・アプリケーションの開発が極めて専門的な性質のものであるため、開発費用が増大し、設計サイクルが長くなることがある。さらに、それに伴う複雑さにより、システム、機能およびアプリケーションのリサイクリングおよびメンテナンスが極めて難しくなる。たとえば、特定のサービス機能にアクセスするために必要なプロトコルおよび論理が開発中のサービス・アプリケーションに含まれているので、基本となるプロトコルに対してどんな変更を行うにも、サービス・アプリケーション全体の再プログラミングが必要になることがある。要するに、無線サービス・アプリケーションの開発が極めて専門的な性質のものであるため、開発費用が増大し、設計サイクルが長くなることがある。さらに、それに伴う複雑さにより、システム、機能およびアプリケーションのリサイクリングが極めて難しくなる。
【発明の開示】
【発明が解決しようとする課題】
【００１８】
したがって、統合ネットワーク・サービス・プロバイダ向けのより柔軟なサービス・アプリケーション・アーキテクチャが必要とされている。
【課題を解決するための手段】
【００１９】
したがって、第１の態様によれば、本発明は、インテリジェント・ネットワーク向けのアプリケーション実行環境を提供する。この環境は、サービス論理層にあり、サービス論理層のサービス・コンポーネントとプロトコル層およびアプリケーション層のクライアント・コンポーネントの間でイベントをルーティングするためのイベント・ルーティング・バスを含むＳＬＥＥと、プロトコル層にあり、コネクタ／ラッパ・インターフェースを介してＳＬＥＥに通信可能にリンクされる少なくとも１つのクライアント・コンポーネントと、少なくとも１つがＳＬＥＥ内で実行され、プロトコル層のクライアント・コンポーネントおよびサービス論理層の他のサービス・コンポーネントと、前記ＳＬＥＥ内のイベント・ルーティング・バスを介して通信するように構成された電話サービス・コンポーネントとを含む。
【００２０】
アプリケーション実行環境はさらに、ＳＬＥＥ内で実行される少なくとも１つの総称サービス・コンポーネントを含むことが好ましい。総称サービス・コンポーネントは、ＳＬＥＥ内の他のサービス・コンポーネントと通信するように構成することができる。総称サービス・コンポーネントは、アプリケーション層の特定の外部サービスと通信するように構成することもできる。
【００２１】
好ましくは、アプリケーション実行環境はさらに、少なくとも１つが前記ＳＬＥＥ内で実行され、前記イベント・ハンドラを介して、前記ＳＬＥＥ内の他のサービス・コンポーネントとの間でメッセージの送受信を行うように構成され、前記ＳＬＥＥの外部のサーバ側プログラムと通信可能なリンクを備えるインターネット対応のサービス・コンポーネント（ＩＥＳＣ）を含む。
【００２２】
好ましくは、コネクタ／ラッパ・インターフェースは、プロトコル層のクライアント・コンポーネントに抽象インターフェースを提供するクライアント・コンポーネント・ラッパと、ＳＬＥＥに関連付けられ、クライアント・コンポーネント・ラッパに対応し、クライアント・コンポーネント・ラッパによって提供される抽象インターフェースを介してクライアント・コンポーネントと通信するように構成されるコネクタとを含む。
【００２３】
好ましくは、アプリケーション実行環境はさらに、ＳＬＥＥがコネクタ／ラッパ・インターフェースを介して通信するように構成することができる、少なくとも１つのクライアント・コンポーネントを指定するＳＬＥＥディスクリプタを含む。
【００２４】
好ましくは、アプリケーション実行環境はさらに、それぞれがプロトコル層の特定のクライアント・コンポーネントに対応し、特定のイベントを指定し、そのイベントについて、ＳＬＥＥ内のイベント・ルーティング・バスによって特定のクライアント・コンポーネントに通知することができる、少なくとも１つのクライアント・コンポーネント・ディスクリプタを含む。
【００２５】
クライアント・コンポーネントは、プロトコル・スタックであることが好ましい。あるいは、クライアント・コンポーネントは、コール制御コンポーネントでも、シグナリング・プロトコル・コンポーネントでも、接続管理プロトコル・コンポーネントでも、またはセキュア・ネットワーク・アクセス・プロトコル・コンポーネントでもよい。
【００２６】
ＳＬＥＥは、ＪＡＩＮ準拠のＳＬＥＥであることが好ましい。
【００２７】
好ましくは、ＳＬＥＥはさらに、サービス・コンポーネントをＳＬＥＥ内にロードするためのクラス・ローダを含み、ＳＬＥＥが、ロードされた各サービス・コンポーネントを、特定の登録済みサービス・コンポーネント向けのイベントを受信するために登録し、前記イベント・ルーティング・バスが、前記受信済みイベントをＳＬＥＥ内で実行される前記特定の登録済みサービス・コンポーネントにルーティングする。
【００２８】
ＳＬＥＥはさらに、スレッド・プールと、スレッドを前記ロードされたサービス・コンポーネントが使用できるように割り振るためのスレッド・プール・マネージャとを含むことが好ましい。
【００２９】
第２の態様によれば、本発明は、電話サービス提供方法を提供する。この方法では、第１に、サービス論理実行環境（ＳＬＥＥ）内のイベント・ルーティング・バスにおいて、クライアント・コンポーネントからコネクタ／ラッパ・インターフェースを介してプロトコル層イベントを受信し、ＳＬＥＥ内で実行されるサービス・コンポーネントからサービス論理層イベントを受信し、特定のプロトコル層イベントおよびサービス論理層イベントを、特定のプロトコル層イベントおよびサービス論理層イベントを受信するために登録されたサービス・コンポーネントおよびクライアント・コンポーネントに転送し、第２に、ＳＬＥＥで実行されるサービス・コンポーネントのうちの少なくとも１つにおいて、少なくとも１つのサービス論理層イベントをイベント・ルーティング・バスに送信し、イベント・ルーティング・バスは、送信されたサービス論理層イベントを、送信されたサービス論理層イベントを受信するために登録された別のサービス・コンポーネントに転送することができる。
【００３０】
好ましくは、電話サービスを提供する方法の一環として、サービス・コンポーネントの少なくとも１つにおいて、特定の外部サービスと通信リンクが確立され、別のサービス・コンポーネントから外部サービスを要求するサービス論理層イベントを受信し、別のサービス・コンポーネントからサービス論理層イベントを受信したことに応答して、リンクされた特定の外部サービスによって提供される機能への少なくとも１つの特定の呼び出しを介して、前記要求された外部サービスを提供する。
【００３１】
第３の態様によれば、本発明は、電話サービスを提供するためのコンピュータ・プログラムを格納する機械可読記憶装置であって、前記コンピュータ・プログラムが、機械に第２態様による方法を実施させるために、機械で実行可能なプログラム・コードを含む、機械可読記憶装置を提供する。
【００３２】
第４の態様によれば、本発明は、高度インテリジェント・ネットワークを提供する。このネットワークは、クライアント・コンポーネントとサービス・コンポーネントの間でメッセージをルーティングするイベント・ハンドラを含むサービス論理実行環境（ＳＬＥＥ）と、前記イベント・ハンドラを介して前記ＳＬＥＥ内の他のサービス・コンポーネントとの間でメッセージを送受信するように構成された少なくとも１つのサービス・コンポーネントと、前記ＳＬＥＥ内で実行される少なくとも１つのインターネット対応サービス・コンポーネント（ＩＥＳＣ）とを含み、前記ＩＥＳＣは、前記イベント・ハンドラを介して前記ＳＬＥＥ内の他のサービス・コンポーネントとの間でメッセージを送受信するように構成され、前記ＳＬＥＥの外部にあるサーバ側プログラムに通信可能にリンクする。
【００３３】
第５の態様によれば、本発明はインテリジェント・ネットワーク・モデルにおけるサービス論理実行環境（ＳＬＥＥ）を提供する。前記ＳＬＥＥは、その中にサービス・コンポーネントをロードするためのクラス・ローダであって、ＳＬＥＥが特定の登録済みサービス・コンポーネント向けのイベントを受信するために各ロードされたサービス・コンポーネントを登録するクラス・ローダと、プロトコル層および他のサービス・コンポーネントからイベントを受信するためのイベント・ルーティング・バスであって、ＳＬＥＥ内で実行される前記特定の登録済みサービス・コンポーネントに前記受信済みイベントをルーティングするイベント・ルーティング・バスとを含む。
【００３４】
本発明の第６の態様によれば、本発明は、インテリジェント・ネットワーク向けのアプリケーション実行環境を提供する。このアプリケーション実行環境は、サービス論理実行環境（ＳＬＥＥ）と、特定のクライアント・コンポーネントとの抽象インターフェースを提供する少なくとも１つのクライアント・コンポーネント・ラッパと、前記ＳＬＥＥに関連付けられ、少なくとも１つのクライアント・コンポーネント・ラッパに対応し、前記対応する少なくとも１つのクライアント・コンポーネント・ラッパによって提供される抽象インターフェースを介してクライアント・コンポーネントと通信するように構成された少なくとも１つのコネクタとを含む。
【００３５】
本発明の第７の態様によれば、本発明は、無線サービスで使用する高度インテリジェント・ネットワークを提供する。このネットワークは、サービス論理実行環境（ＳＬＥＥ）と、前記ＳＬＥＥ内で実行される少なくとも１つのサービス・アプリケーションと、前記サービス・アプリケーションに通信可能にリンクされた無線サービス・アプリケーションで使用され、前記ＳＬＥＥの外部にある前記無線サービス・アプリケーションとのインターフェースを含む少なくとも１つの総称サービス・コンポーネントとを含む。
【００３６】
本発明の第８の態様によれば、本発明は、コール・モデルで使用される高度インテリジェント・ネットワークを提供する。このネットワークは、サービス論理実行環境（ＳＬＥＥ）と、前記ＳＬＥＥ内で実行される少なくとも１つのサービス・アプリケーションと、前記サービス・アプリケーションに通信可能にリンクされ、前記ＳＬＥＥの外部にある第２のサービス・アプリケーションとのインターフェースを含む少なくとも１つの総称サービス・コンポーネントとを含む。
【００３７】
本発明の第９の態様によれば、本発明は、インテリジェント・ネットワーク向けのデータ処理システムを提供する。このデータ処理システムは、サービス論理実行環境（ＳＬＥＥ）を含むサービス論理層と、少なくとも１つのクライアント・コンポーネントを含むプロトコル層であって、前記少なくとも１つのクライアント・コンポーネントが、コネクタ／ラッパ・インターフェースを介して前記ＳＬＥＥに通信可能にリンクされ、前記ＳＬＥＥが、サービス論理層のサービス・コンポーネントと、プロトコル層およびアプリケーション層のクライアント・コンポーネントの間でイベントをルーティングするイベント・ルーティング・バスを含むプロトコル層と、前記ＳＬＥＥ内で実行され、前記ＳＬＥＥ内のイベント・ルーティング・バスを介してプロトコル層のクライアント・コンポーネントおよびサービス論理層の他のサービス・コンポーネントと通信するように構成された少なくとも１つの電話サービス・コンポーネントとを含む。
【００３８】
したがって、本発明は、統合ネットワーク・サービス・プロバイダ向けの柔軟なサービス・アプリケーション・アーキテクチャを提供する。本発明は、サービス・コンポーネントによるより直接的なイベント処理を提供し、サービス論理実行環境（ＳＬＥＥ）内に含まれるプロトコル・スタック特有のコードを減らすことにより、従来技術の欠点に対処するものである。さらに、本発明は、ＳＬＥＥから特定のクライアント・コンポーネントに関する情報を取り除き、その代わりにコネクタ／ラッパ通信インターフェースを用いることにより、従来技術の欠点に対処する。その結果、ＳＬＥＥは、基本となるクライアント・コンポーネントの実装の詳細に関係なく、コネクタ／ラッパ・インターフェースを介した通信を総称的に送受信することができる。したがって、本発明によれば、ＳＬＥＥの複雑さを緩和することができる。さらに、本発明に従って構成されたＳＬＥＥは、特定のクライアント・コンポーネントと直接バインドする必要がない。
【００３９】
本発明のアーキテクチャは、ＳＬＥＥ内で実行される他のサービス・コンポーネントとの総称インターフェースを提供しながら、特定の外部サービスと通信するように構成することができる総称サービス・コンポーネントを含むことが好ましい。このようにして、たとえば電話サービス・コンポーネントなどＳＬＥＥ内で実行されるサービス・コンポーネントはデータベース操作などの外部サービスを、総称サービス・コンポーネントに総称的に要求することができる。外部サービスを求める総称要求を受信したことに応答して、総称サービス・コンポーネントは、要求された外部サービスを要求元の電話サービス・コンポーネントに提供するために、対応する特定の外部サービスに特有の１つまたは複数の機能を呼び出すことができる。その結果、電話サービス・コンポーネントは特定の外部サービス向けの特有のコードを組み込む必要がなくなる。総称サービス・コンポーネントが特定の外部サービス向けの特有のコードを組み込むだけでよい。したがって、電話サービス・コンポーネントの複雑さを緩和することができる。
【００４０】
次に本発明を、添付の図面に示すその好ましい一実施形態に則して、例としてのみ説明する。
【発明を実施するための最良の形態】
【００４１】
本発明は、統合ネットワーク・サービス・プロバイダ向けの柔軟なサービス・アプリケーション・アーキテクチャである。このアーキテクチャは、プロトコル層、サービス論理層およびアプリケーション層を含むことができるので、高度インテリジェント・ネットワーク・アーキテクチャ（ＡＩＮ）に類似したものとすることができる。本発明の構成によれば、本発明のアーキテクチャは、サービス論理層にサービス論理実行環境（ＳＬＥＥ）を含むことができる。特に、ＳＬＥＥは、ＪＡＩＮ準拠のＳＬＥＥとすることができる。ＳＬＥＥは、サービス論理層のサービス・コンポーネントと、プロトコル層およびアプリケーション層のクライアント・コンポーネントの間でイベントをルーティングするイベント・ルーティング・バスを含むことができる。特に、ＳＬＥＥ内で実行される電話サービス・コンポーネントは、ＳＬＥＥのイベント・ルーティング・バスを介して、プロトコル層のクライアント・コンポーネントおよびサービス論理層の他のサービス・コンポーネントと通信するように構成することができる。最後に、クライアント・コンポーネントはコネクタ／ラッパ・インターフェースを介して、ＳＬＥＥに通信可能にリンクすることができる。
【００４２】
本発明の好ましい一実施形態に従って構成されたＳＬＥＥを取り込むと、サービス・コンポーネント間でのイベント通信を円滑にすることができるイベント・ルーティング・バスが提供されるので、従来技術の欠点を解決する助けとなる。より直接的なイベント通信を提供することにより、ＪＡＩＮ仕様のＥＪＢ手法に付随する固有の待ち時間を少なくすることができる。同様に、サービス・コンポーネントがＳＬＥＥを介してプロトコル・スタックなどのクライアント・コンポーネントからだけイベントを受信し、受信したイベントを処理することができるＳＬＥＥの従来の実装とは異なり、本発明の好ましい一実施形態では、サービス・コンポーネントは他のサービス・コンポーネントからもイベントを受信し処理することもできる。したがって、マクロ・サービス・コンポーネントを形成するために、拡張されたサービス・コンポーネントの組合せを生み出すことができる。
【００４３】
サービス・コンポーネントは、特定のプロトコル・スタックに関する特有の知識を有するように構築することもできる。その結果、特定のプロトコル・スタックに関する特有の知識をＳＬＥＥから取り除き、それによってＳＬＥＥの複雑さを緩和することができる。その結果、本発明の好ましい一実施形態のＳＬＥＥでは、ＳＬＥＥの再コーディングを必要とせずに、新しいプロトコル・スタックをインテリジェント・ネットワークに追加することができる。この追加のプロトコル・スタックに関する特有の知識を有するサービス・コンポーネントを生成することができるからである。他のサービス・コンポーネントは、ＳＬＥＥに動的に挿入されると、挿入されたサービス・コンポーネントを介しイベント・ルーティング・バスを経由して新しいプロトコル・スタックにアクセスすることができる。サービス・コンポーネント間の通信が不可能であった従来のインテリジェント・ネットワークとは異なり、本発明の好ましい一実施形態では、サービス・コンポーネント間の通信によって、新しいプロトコル・スタックを容易に追加することが可能になる。
【００４４】
本発明のアーキテクチャは、プロトコル層のクライアント・コンポーネントにＳＬＥＥを通信可能にリンクするためのコネクタ／ラッパ・インターフェースを含むこともできる。ＳＬＥＥとプロトコル層のクライアント・コンポーネントの間のコネクタ／ラッパ・インターフェースは、クライアント・コンポーネントをＳＬＥＥに固定的にバインドせずに、特定のクライアント・コンポーネントに総称インターフェースを介した構成可能な接続を提供することによって、従来技術の欠点の解決に役立つことができる。
【００４５】
ＳＬＥＥが、その通信相手であるクライアント・コンポーネントと直接バインドされるＳＬＥＥの従来の実装とは異なり、本発明の好ましい一実施形態では、ＳＬＥＥとクライアント・コンポーネントを互いに近接して配置する必要はない。むしろ、必要であれば、ＳＬＥＥとクライアント・コンポーネントは、ネットワークをはさんで配置することができる。このようにして、クライアント・コンポーネントとＳＬＥＥの間のより柔軟な関係が可能になり、それによって、ライフサイクル・メンテナンス中のＳＬＥＥのメンテナンスおよび拡張を容易にすることができる。さらに、特定のクライアント・コンポーネントに関する特有の知識をＳＬＥＥから取り除き、代わりにクライアント・コンポーネントとのインターフェースに含めることができる。その結果、ＳＬＥＥの複雑さを緩和することができる。
【００４６】
最後に、本発明の好ましい一実施形態は、特定の外部サービスとの抽象インターフェースを提供する総称サービス・コンポーネントを含む。より詳細には、各総称サービス・コンポーネントは特定の外部サービスの個々の実装に対する認識を維持することができ、ＳＬＥＥ内で実行される他のサービス・コンポーネント、特に電話サービス・コンポーネントは、対応する特定の外部サービスの個々の実装について知らなくても、総称サービス・コンポーネントの外部サービスを総称的に要求することができる。このようにして、サービス・コンポーネントの複雑さを緩和することができ、サービス・コンポーネントを外部サービスの特定の実装から切り離すことができる。
【００４７】
図２は、本発明の好ましい一実施形態に従って構成されたＪＡＩＮ準拠のインテリジェント・ネットワークの概略図である。ＪＡＩＮ準拠のネットワークは、プロトコル層２０２、アプリケーション層２０５、およびサービス論理層２０７を含むように構成される。アプリケーション層２０５は、外部の第三者アプリケーション２０８をホスティングすることができる。通常の第三者アプリケーション２０８は、仮想プライベート・ネットワーク（ＶＰＮ）、受信サービス、統合メッセージングなどのサービスに対する一般大衆市場の要求に適したものとすることができる。外部の第三者アプリケーション２０８は、短命およびニッチなアプリケーションを含むこともでき、このアプリケーションは、当技術分野で周知のデータベース検索インターフェース、ダウンロード可能な機構、およびＰａｒｌａｙ  ＡＰＩなどの信頼できないアプリケーション空間デプロイメント技術を用いて展開することができる。最後に、データベース・サービス、ディレクトリ・サービス、および無線サービスなど特定の外部サービス２２０は、アプリケーション層２０５に含めることができる。
【００４８】
サービス論理層２０７は、ＪＡＩＮ仕様と互換がとれるように構成することができるＪＳＬＥＥサーバ２００などのＳＬＥＥサーバを含むことができる。重要なことに、ＪＳＬＥＥサーバ２００は、イベント・ルーティング・バス２１８を含むことができる。イベント・ルーティング・バス２１８は、サービス・コンポーネント２０３、２０４、２０５との間でメッセージを送受信することができる。特に、サービス・コンポーネント２０３、２０４、２０５は、イベント・ルーティング・バス２１８にメッセージを送信するように構成することができ、サービス・コンポーネント２０３、２０４、２０５はＪＳＬＥＥサーバ２００に登録し、こうした送信されたイベントを他のサービス・コンポーネント２０３、２０４、２０５から受信することができる。このようにして、サービス・コンポーネント間の通信が可能になる。さらに、サービス・コンポーネント２０３、２０４、２０５は、イベント・ルーティング・バス２１８を介して、外部アプリケーション２０８からイベントを受信するように構成することができる。また、外部アプリケーション２０８から受信され、イベント・バス２０８に送信されたイベントは、こうしたイベントを受信するために登録を行った他のサービス・コンポーネント２０３、２０４、２０５にルーティングすることができる。
【００４９】
サービス・コンポーネント２０３、２０４、２０５は、電話サービス・コンポーネント２０４、総称サービス・コンポーネント２０３、およびインターネット・サービス・コンポーネント２０５を含むことができる。図３は、図２のＪＳＬＥＥサーバ２００で使用するように構成された電話サービス・コンポーネント２０４の概略図である。図３に示すように、電話サービス・コンポーネント２０４は、１つまたは複数のサービス・インスタンス３０２を含むことができる。サービス・インスタンス３０２は、ＪＳＬＥＥ２００内で実行することができる、個別にインスタンス化されたサービスである。さらに重要なことに、各サービス・インスタンス３０２は、イベント・ルーティング・バス２１８に登録し、プロトコル層２０２、ならびに他の電話および総称サービス・コンポーネント２０３、２０４、２０５との間でイベントを送受信する。
【００５０】
各サービス・インスタンス３０２はサービス・ラッパ３０６を介してアクセスすることができ、このサービス・ラッパは、サービス・インスタンスの実装の詳細を隔離する。より詳細には、サービス・クラスのデータおよびメソッドのメンバは、サービス・ラッパ３０６に含まれる共通インターフェースを介してアクセスすることができる。デプロイメント・ディスクリプタ３１０も同様に提供される。デプロイメント・ディスクリプタ３１０は文書、たとえばＸＭＬ文書とすることができ、ＪＳＥＬＬサーバ２００にサービス・コンポーネント３０２のインスタンスを最初にロードするための適当なパラメータを記述することができる。特に、サービス・ラッパ３０６とのインターフェースは、たとえばＸＭＬ文書の一部として含めることができるサービス・インターフェース３０８を介して外部オブジェクトにパブリッシュすることができる。同様に、各サービス・インスタンス３０２とのインターフェースは、コンテキスト・インターフェース３０４の一部として含めることができ、このコンテキスト・インターフェースも、たとえばＸＭＬ文書の一部としてパブリッシュすることができる。サービス・インスタンス３０２は、ロードされると、ＪＳＥＬＬサーバ２００のイベント・ルーティング・バス２１８を介して通信することができる。
【００５１】
電話サービス・コンポーネント２０４に、プロプラエタリおよびリレーショナル・データベース・サービスやディレクトリ・サービスなどの特定の外部サービス２２０にアクセスするためのコードを含まないようにするために、総称サービス・コンポーネント２０３を本発明のアーキテクチャに組み込むことができる。総称サービス・コンポーネント２０３は、特定の外部サービス２２０との抽象インターフェースを提供し、特定の外部サービス２２０との対話を求める、他のサービス・コンポーネント２０３、２０４、２０５からの総称要求に固有に応答することができる。特に、総称サービス・コンポーネント２０３は、無線サービス、ディレクトリ・サービス、データベース・サービス、またはメッセージング・サービスなどのサービス・アプリケーションにアクセスするための共通ＡＰＩを提供することができる。
【００５２】
実際、総称サービス・コンポーネント２０３は、異なるサービス・アプリケーションごとに構築することができる。さらに、総称サービス・コンポーネント２０３は、サービス・アプリケーションが用いる異なるプロトコルごとに構築することができる。したがって、図２に示すように、それぞれがサービス・アプリケーションまたはプロトコルに対応している複数の総称サービス・コンポーネント２０３を含むことができる。たとえば、異なる総称サービス・コンポーネント２０３を、ＬＤＡＰ、ＤＢ２、およびＭＱＳｅｒｉｅｓ対応のサービスまたは機能向けに構築することができる。同様に、異なる総称サービス・コンポーネント２０３は、移動通信向けグローバル・システム（ＧＳＭ）、総称パケット無線サービス（ＧＰＲＳ）、拡張データＧＳＭ環境（ＥＤＧＥ）、ユニバーサル移動電話システム（ＵＴＭＳ）、ＷＡＰ、モバイル・アクセス・プロトコル（ＭＡＰ）、およびｉ−Ｍｏｄｅを使用するグローバル・システムなど、無線サービス・アプリケーションへのアクセス向けに構築することができる。したがって、総称サービス・コンポーネント２０３を含めることで、他のサービス・コンポーネント、特に電話サービス・コンポーネント２０４は、特定の外部サービス２２０と通信するための特有の構成を含まなくてもよくなる。
【００５３】
図４は、図２のＪＳＬＥＥサーバ２００で使用するように構成された総称サービス・コンポーネント２０３の概略図である。図４に示すように、総称サービス・コンポーネント２０３は、１つまたは複数の総称サービス・インスタンス４０２を含むことができる。図３の電話サービス・インスタンス３０２と同様に、図４の総称サービス・インスタンス４０２は、ＪＳＬＥＥ２００内で実行することができる個別にインスタンス化された総称サービスである。より重要なことに、各総称サービス・インスタンス４０２はイベント・ルーティング・バス２１８に登録し、サービス論理層２０７の他のサービス・コンポーネント２０３、２０４、２０５との間でイベントを送受信することができる。電話サービス・コンポーネント２０４の場合と同様に、各総称サービス・インスタンス４０２はサービス・インスタンスの実装の詳細を隔離する総称サービス・ラッパ４０６を介してアクセスすることができる。より詳細には、サービス・クラスのデータおよびメソッドのメンバは、総称サービス・ラッパ４０６に含まれる共通インターフェースを介してアクセスすることができる。
【００５４】
デプロイメント・ディスクリプタ４１０もまた提供される。デプロイメント・ディスクリプタ４１０は、文書、たとえばＸＭＬ文書とすることができ、ＪＳＬＥＥサーバ２００に総称サービス・コンポーネント４０２のインスタンスを最初にロードするために適当なパラメータを記述することができる。特に、総称サービス・ラッパ４０６とのインターフェースは、たとえばＸＭＬ文書の一部として含めることができる総称サービス・インターフェース４０８を介して外部オブジェクトにパブリッシュすることができる。同様に、各サービス・インスタンス４０２とのインターフェースは、コンテキスト・インターフェース４０４の一部として含めることができ、このコンテキスト・インターフェースもたとえばＸＭＬ文書の一部としてパブリッシュすることができる。ロードされると、総称サービス・インスタンス４０２は、ＪＳＬＥＥサーバ２００内のイベント・ルーティング・バス２１８を介して通信することができる。
【００５５】
図５は、本発明の好ましい一実施形態のＪＡＩＮ準拠のインテリジェント・ネットワークにおける総称サービス・コンポーネント５０２Ａ、５０２Ｂ、５０２Ｃ、５０２Ｄ、５０２Ｅ、５０２Ｆの構成の例を示す簡略化した図である。図５に示すように、各総称サービス・コンポーネント５０２Ａ、５０２Ｂ、５０２Ｃ、５０２Ｄ、５０２Ｅ、５０２Ｆは、サービス・ラッパ５０６および１つまたは複数のクライアント・サービス・インスタンス５０２を含むことができる。サービス・ラッパ５０６は、ＪＳＬＥＥサーバ２００に登録し、サービス・アプリケーション５３０に対応する特定の種類のイベントを受信することができる。したがって、サービス・ラッパ５０６は、特定のプロトコルに従って受信済みイベントを変換し、そのイベントを再フォーマットするために必要な機能を含むことができる。再フォーマットされたイベントは、特定の無線サービス・アプリケーションにルーティングすることができる。サービス・ラッパ５０６は特定のトランザクション、すなわち１つまたは複数のイベントを処理するためにクライアント・サービス・インスタンス５０２をインスタンス化することができる。クライアント・サービス・インスタンス５０２は、サービス・アプリケーション５３０Ａ、５３０Ｂ、５３０Ｃ、５３０Ｄ、５３０Ｅ、５３０Ｆのうちの１つと通信するためにインスタンス化することもできる。
【００５６】
図５に示すように、例示的な総称サービス・コンポーネント５０２Ａ、５０２Ｂ、５０２Ｃ、５０２Ｄ、５０２Ｅ、５０２Ｆは、それだけには限らないが、ＷＡＰ総称サービス・コンポーネント５０２Ａ、ＥＤＧＥ総称サービス・コンポーネント５０２Ｂ、ＧＰＲＳ総称サービス・コンポーネント５０２Ｃ、ＬＤＡＰ総称サービス・コンポーネント５０２Ｄ、ＤＢ２総称サービス・コンポーネント５０２Ｅ、およびＭＱＳｅｒｉｅｓ総称サービス・コンポーネント５０２Ｆを含むことができる。たとえば、サービス・ラッパ５０６は、ＷＡＰ総称サービス・コンポーネント５０２Ａの一部として、ＪＳＬＥＥサーバ２００に登録し、無線のハンドヘルド装置などの無線装置に関連する無線イベントを受信することができる。図５に示すように、サービス・ラッパ５０６は、各受信済みイベント、すなわちＷＡＰ対応の無線サービス・アプリケーションに関連するトランザクションを含む一連のイベントごとに１つずつ、計３つのクライアント・サービス・インスタンス５０２をインスタンス化している。あるいは、単独のクライアント・サービス・インスタンス５０２は複数のトランザクションを処理することもできる。したがって、各クライアント・サービス・インスタンス５０２は、ＷＡＰ対応のサービス・アプリケーション５３０Ａと対話することができる。
【００５７】
同様に、ＥＤＧＥ総称サービス・コンポーネント５０２ＢおよびＭＱＳｅｒｉｅｓ総称サービス・コンポーネント５０２Ｆはそれぞれサービス・ラッパ、および１つまたは複数のクライアント・サービス・インスタンスを含み、ＥＤＧＥ対応の無線サービス・アプリケーション５３０ＢおよびＭＱＳｅｒｉｅｓメッセージ・キュー・サービス・アプリケーション５３０Ｆとそれぞれに対話することができる。総称サービス・コンポーネントは、必要に応じて、プロプラエタリ・データベースおよびプロプラエタリ・インターフェースおよびプロトコルを用いる無線サービスを含めていずれのサービス・アプリケーション向けにも構築することができることを理解されたい。
【００５８】
次に図２を参照すると、電話および総称サービス・コンポーネント２０３、２０４とは異なり、インターネット対応のサービス・コンポーネント２０５は、サーブレットやスクリプトなどの外部サーバ側プログラムと通信するように事前に構成することができる。サーバ側プログラムの例には、これだけには限らないが、共通ゲートウェイ・インターフェース（ＣＧＩ）、Perlスクリプト、Java（商標）ServerPage、ＶＢスクリプト、Active Server Page（商標）、または他のスクリプト技術が含まれる。外部アプリケーション２３２がインターネット対応サービス・コンポーネント２０５にアクセスすると、インターネット対応サービス・コンポーネント２０５は、外部アプリケーション２３２にＪＳＬＥＥサーバ２００内のイベント・ルーティング・バス２１８へのアクセスを提供することができ、このバスを介して、サービス・コンポーネント２０３、２０４、２０５は互いに通信することができる。
【００５９】
この機構を介して、ＪＳＬＥＥサーバ２００上で実行されるサービス・コンポーネント２０３、２０４、２０５は、インターネット対応サービス・コンポーネント２０５とも通信することができる。したがって、インターネット対応サービス・コンポーネント２０５は、インターネットなどのコンピュータ通信ネットワーク内のウェブ・サーバ２３０と連携して動作するサーバ側プログラム２３２に通信可能にリンクすることができるので、ＪＳＬＥＥサーバ２００上の他のサービス・コンポーネント２０３、２０４は、インターネット対応サービス・コンポーネント２０５を使用して、インターネット上で情報を送受信することができる。さらに、ＪＳＬＥＥサーバ２００上の他のサービス・コンポーネント２０３、２０４は、ユーザおよび管理者によってインターネットからアクセスすることができる。
【００６０】
インターネット対応サービス・コンポーネント２０５は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に従って要求および応答を送受することにより、ウェブ・サーバ２３０と直接通信するように構成することができる。同様に、ウェブ・サーバ２３０は、やはりＨＴＴＰに従ってインターネット対応サービス・コンポーネント２０５と通信するように構成されたサーバ側プログラム２３２を含むことができる。とはいえ、本発明は、インターネット対応サービス・コンポーネント２０５と、対応するサーバ側プログラム２３２がどのように通信するかについて制限されていない。むしろ、明示的なＴＣＰ／ＩＰ通信などの一般的な接続指向技術を含めてどんな周知の通信技術でも十分であり得る。
【００６１】
サーバ側プログラム２３２とインターネット対応サービス・コンポーネント２０５を組み合わせることで、サービスおよびサービス・コンポーネントの様々な側面に、インターネットを介して、インターネット対応サービス・コンポーネント２０５によって提供される共通のアプリケーション・プログラミング・インターフェース（ＡＰＩ）からアクセスすることが可能になる。たとえば、加入者はサービス属性にアクセスしそれを修正することができる。サービス属性は加入者によってアクセス可能などんなサービスの側面も含むことができる。同様に、サービス管理者またはスーパ・ユーザは、インターネット上で管理機能へのアクセス、監視、および実施を行うことができる。管理機能は、それだけには限らないが、システム管理者またはスーパ・ユーザのために確保され、加入者には提供されないどんな機能も含むことができる。特に、インターネット対応サービス・コンポーネント２０５は、外部サービスまたはシステムの補助なしに、加入者および管理者にこうしたアクセスをインターネット上で提供することができる。
【００６２】
ＪＳＬＥＥサーバ２００上の他のサービス・コンポーネント２０３、２０４と同様に、各インターネット対応サービス・コンポーネント２０５は、ＪＳＬＥＥサーバ２００との間でイベントの送受信が行えるように構成することもできる。このようにして、他のサービス・コンポーネント２０３、２０４は、ＪＳＬＥＥサーバ２００に登録し、こうしたイベントを受信することができる。サービス・コンポーネント２０３、２０４は、それに対応して、ＪＳＬＥＥサーバにイベントを送信することができ、インターネット対応サービス・コンポーネント２０５を登録してそのイベントを受信することができる。インターネット対応サービス・コンポーネント２０５は、ＪＳＬＥＥサーバ２００から受信するイベント、ならびにウェブ・サーバ２３０から受信する通信を処理することができることを理解されたい。このようにして、インターネット対応サービス・コンポーネント２０５は、インターネットとＪＳＬＥＥサーバ２００の間のインターフェースとして機能することができる。
【００６３】
特に、ＪＳＬＥＥサーバ２００は、スレッド・プール２２２、クラス・ローダ２２４、タイマ２２６、使用カウンタ２２８を含む複数のライフサイクル管理コンポーネントも含むことができる。しかし、ライフサイクル管理コンポーネントは、図２に示すものだけには限られない。むしろ、ライフサイクル管理コンポーネントは、たとえばロード・バランシングなどの他のライフサイクル管理責任を実施することができるコンポーネントを含むことができる。いずれにせよ、本発明の構成によれば、個々のサービス・コンポーネントは、ライフサイクル管理を実施するオーバヘッドから解放され、電話アプリケーションにおいてより適切に使用することができる。
【００６４】
特に、図２に示すように、スレッド・プール２２２は、複数の事前構成およびロードされた実行スレッドを含むことができ、この実行スレッドは、要求に応じて、スレッド・プール管理コンポーネントによって、ＪＳＬＥＥサーバ２００上で実行される要求元のサービス・コンポーネント２０３、２０４、２０５に割り当てることができる。要求元のサービス・コンポーネント２０３、２０４、２０５が割り当てられたスレッドの使用を完了したとき、スレッド・プール管理コンポーネントは、その割り当て済みのスレッドを割り当て解除することができ、その割り当て解除されたスレッドを、ＪＳＬＥＥサーバ２００上で実行される他の要求元のサービス・コンポーネント２０３、２０４、２０５が使用できるように、スレッド・プール２２２に戻すことができる。
【００６５】
クラス・ローダ２２４をＪＳＬＥＥサーバ２００は使用して、ＪＳＬＥＥサーバ２００上で実行すべくサービス・コンポーネント２０３、２０４、２０５を適切にロードすることができる。特に、クラス・ローダ２２４は、ロードされる各サービス・コンポーネント２０３、２０４、２０５に関連する構成およびロード・パラメータを識別することができる。次いで、クラス・ローダ２２４は、識別された構成およびロード・パラメータを用いて、サービス・コンポーネント２０３、２０４、２０５を実行することができる。最後に、クラス・ローダ２２４は、サービス・コンポーネント２０３、２０４、２０５を、イベント・ルーティング・バス２１８に登録することができ、ＪＳＬＥＥサーバ２００上で実行されるサービス・コンポーネント２０３、２０４、２０５との間でイベントを送受信することができる。
【００６６】
最後に、プロトコル層２０２は、１つまたは複数のプロトコル・スタックを含むことができ、このプロトコル・スタック２０６は、ＪＳＬＥＥサーバ２００上で実行されるサービス・コンポーネント２０４と通信するように構成することができる。特に、図２には、３つのプロトコル・スタック２０６だけしか示されていないが、本発明は、プロトコル・スタック２０６の数または種類について制限していない。むしろ、ＪＳＬＥＥサーバ２００は、いずれのプロトコル・スタック、たとえばＪＡＩＮ仕様に従って構成されたプロトコル・スタックとも通信することができる。
【００６７】
動作中、ＪＳＬＥＥサーバ２００はプロトコル層２０２のプロトコル・スタック２０６との間でイベントを送受信することができる。より詳細には、イベントは、ＪＳＬＥＥサーバ２００に含まれる、イベント・ルーティング・バス２１８で送受信される。電話サービス・コンポーネント２０４および総称サービス・コンポーネント２０３は、イベント・ルーティング・バス２１８で受信される特定のイベントのリスナーとして登録することができる。ＪＳＬＥＥサーバ２００に登録されたサービス・コンポーネント２０３、２０４、２０５は、サービス・コンポーネント２０３、２０４、２０５のうちの特定のコンポーネントに向けたプロトコル・スタック・イベントを受信することができる。サービス・コンポーネント２０３、２０４、２０５はまた、サービス・コンポーネント２０３、２０４、２０５のうちの特定のコンポーネントに向けたサービス・コンポーネント・イベントを受信することができる。より詳細には、ＪＳＬＥＥサーバ２００のイベント・ルーティング・バス２１８は、受信したイベントを、こうしたイベントを受信するためにＪＳＬＥＥサーバ２００に登録を行ったサービス・コンポーネント２０３、２０４、２０５にルーティングすることができる。
【００６８】
本発明の好ましい一実施形態によれば、ＪＳＬＥＥサーバ２００は、ＪＡＩＮ準拠のインテリジェント・ネットワーク上のクライアント・コンポーネントと通信するように構成することができる。クライアント・コンポーネントは、プロトコル・スタック２０６だけでなく、他のサービス・コンポーネント２０３、２０４、２０５、特定の外部サービス２２０、および外部アプリケーション２０８も含むことができる。重要なことに、ＪＳＬＥＥサーバ２００は、各クライアント・コンポーネントの実装に関する特定の知識がなくても、このように構成することができる。この難しい仕事を成し遂げるために、ＪＳＬＥＥサーバ２００は、コネクタ２１０を含むことができ、このコネクタはラッパ２１６と通信し、それによってコネクタ／ラッパ・インターフェースを形成することができる。ラッパ２１６は、コネクタ２１０に、プロトコル・スタック２０６などの特定のクライアント・コンポーネントとの抽象インターフェースを提供することができる。各コネクタ２１０は、対応するラッパ２１６によって提供される抽象インターフェースを介して、プロトコル・スタック２０６などの対応するクライアント・コンポーネントと通信するように構成することができる。
【００６９】
したがって、一般に、ＪＳＬＥＥサーバ２００は、プロトコル・スタック２０６などの基本となるクライアント・コンポーネントの実装の詳細に関係なく、コネクタ／ラッパ・インターフェースを介してイベントを総称的に送受信することができるが、ラッパ２１６だけは基本となるプロトコル・スタック２０６の実装の詳細に関する特定の知識を必要とする。本発明の一態様では、個々のラッパ２１６を指定することができるＪＳＬＥＥディスクリプタ２１４を含めることができ、対応するコネクタ２１０をこのラッパと通信するように構成することができる。
【００７０】
特に、ＪＳＬＥＥサーバ２００は、始動時、ＪＳＬＥＥディスクリプタ２１４を読み取り、指定された各ラッパ２１６の識別について知ることができる。次いで、ＪＳＬＥＥサーバ２００は、コネクタ２１０を、指定されたラッパ２１６と通信するように構成することができる。同様に、クライアント・コンポーネント・ディスクリプタ２１２を、各コネクタ２１０ごとに提供することができる。クライアント・コンポーネント・ディスクリプタ２１２は特定のイベントを指定することができ、そのイベントについては、プロトコル・スタック２０６などの関連するクライアント・コンポーネントにＪＳＬＥＥサーバ２００のイベント・ルーティング・バス２１８を介して通知することができる。
【００７１】
図６は、統合ネットワークのアプリケーション実行環境内のクライアント・コンポーネントにＳＬＥＥを通信可能にリンクする方法を示すフローチャートである。この方法は、ブロック６０２で、ＳＬＥＥをロードして開始することができる。ブロック６０４で、ＳＬＥＥディスクリプタをロードすることができる。判断ブロック６０６で、クライアント・コンポーネントが指定されている場合、ブロック６０８で、コネクタ・インスタンスを生成し、それを指定されたクライアント・コンポーネントに関連するラッパと通信するように構成することができる。ブロック６１０で、構成されたコネクタに関連するサブスクリプション・ディスクリプタをロードすることができ、ブロック６１２で、サブスクリプション・ディスクリプタにリストされているイベントを受信するために、指定されたクライアント・コンポーネントをＳＬＥＥ内のイベント・ハンドラに登録することができる。
【００７２】
次いで、判断ブロック６１４で、追加のクライアント・コンポーネントがＳＬＥＥディスクリプタにリストされている場合、追加のコネクタ・インスタンスを、ブロック６０８から６１２に従って生成し構成することができる。最後に、すべてのコネクタ・インスタンスが生成および構成されると、ブロック６１６で、ＳＬＥＥを開始し、個々のクライアント・コンポーネントごとの基本となる実装に関係なく、コネクタ／ラッパ・インターフェースを介して登録済みクライアント・コンポーネントにイベントをルーティングすることができる。その結果、ＳＬＥＥは、各クライアント・コンポーネントに関する特定の知識を必要とせずに、クライアント・コンポーネント・ラッパを介して、クライアント・コンポーネントに通信可能にリンクすることができる。
【００７３】
本発明は、ハードウェアでも、ソフトウエアでも、またはハードウェアとソフトウエアの組合せにおいても実現することができる。本発明による電話サービス提供方法は、１つのコンピュータによる集中方式でも、異なる要素が相互接続された複数のコンピュータに広がる分散方式でも実現することができる。どんな種類のコンピュータ・システム、すらわち本明細書に記載した方法を実施するように適合された他の装置にも適している。ハードウェアとソフトウェアの通常の組合せは、ロードされ実行されたとき、本明細書に記載した方法を実施するようにコンピュータ・システムを制御するコンピュータ・プログラムを有する汎用コンピュータ・システムとすることができる。
【００７４】
本発明は、本明細書に記載した方法の実装を可能にするすべての機能を備え、コンピュータ・システムにロードされたとき、こうした方法を実施することができるコンピュータ・プロダクトに組み込むこともできる。コンピュータ・プログラム、すなわち本発明との関連におけるコンピュータ・プログラムは、情報処理能力を有するシステムに、直接に、またはａ）別の言語、コードまたは表記への変換、ｂ）異なる材料形式への複製のうちの一方または両方を行った後に、特定の機能を実行させるための１組の命令に関する、任意の言語、コード、または表記による任意の表現を意味する。
【図面の簡単な説明】
【００７５】
【図１】従来技術において周知の従来型のＪＡＩＮ実装に従って構成されたインテリジェント・ネットワーク・アーキテクチャの概略図である。
【図２】サービス論理実行環境（ＳＬＥＥ）を含めたインテリジェント・ネットワーク・アーキテクチャの概略図である。
【図３】図２のＳＬＥＥ内で実行するように構成された電話サービス・コンポーネントの細部を示す図である。
【図４】図２のＳＬＥＥ内で実行するように構成された総称サービス・コンポーネントの細部を示す図である。
【図５】図２のインテリジェント・ネットワーク・アーキテクチャのアプリケーション層のサービス・アプリケーションにアクセスするように構成された総称サービス・コンポーネントの集合体を示すブロック図である。
【図６】コネクタ／ラッパ・インターフェースを介して、クライアント・コンポーネントと図２のＳＬＥＥの間で通信リンクを確立する方法を示すフローチャートである。
【図１】
2004537886.tif 000003
【図２】
2004537886.tif 000004
【図３】
2004537886.tif 000005
【図４】
2004537886.tif 000006
【図５】
2004537886.tif 000007
【図６】
2004537886.tif 000008
【国際公開パンフレット】
2004537886.tif 000009
2004537886.tif 000010
2004537886.tif 000011
2004537886.tif 000012
2004537886.tif 000013
2004537886.tif 000014
2004537886.tif 000015
2004537886.tif 000016
2004537886.tif 000017
2004537886.tif 000018
2004537886.tif 000019
2004537886.tif 000020
2004537886.tif 000021
2004537886.tif 000022
2004537886.tif 000023
2004537886.tif 000024
2004537886.tif 000025
2004537886.tif 000026
2004537886.tif 000027
2004537886.tif 000028
2004537886.tif 000029
2004537886.tif 000030
2004537886.tif 000031
2004537886.tif 000032
2004537886.tif 000033
2004537886.tif 000034
2004537886.tif 000035
2004537886.tif 000036
2004537886.tif 000037
2004537886.tif 000038
2004537886.tif 000039
2004537886.tif 000040
2004537886.tif 000041
【国際公開パンフレット（コレクトバージョン）】
2004537886.tif 000042
2004537886.tif 000043
【手続補正書】
【提出日】平成15年9月5日(2003.9.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
インテリジェント・ネットワーク向けのアプリケーション実行環境であって、
サービス論理層にあり、サービス論理層のサービス・コンポーネントとプロトコル層およびアプリケーション層のクライアント・コンポーネントの間でイベントをルーティングするためのイベント・ルーティング・バスを含むサービス論理実行環境（ＳＬＥＥ）と、
前記プロトコル層にあり、コネクタ／ラッパ・インターフェースを介して前記ＳＬＥＥに通信可能にリンクされる少なくとも１つのクライアント・コンポーネントと、
少なくとも１つが前記ＳＬＥＥ内で実行され、前記イベント・ルーティング・バスを介して前記ＳＬＥＥ内の他のサービス・コンポーネントとの間でイベントの送受信を行うように構成され、前記ＳＬＥＥの外部のサーバ側プログラムと通信可能なリンクを備えるインターネット対応サービス・コンポーネント（ＩＥＳＣ）とを含む、アプリケーション実行環境。
【請求項２】
少なくとも１つが前記ＳＬＥＥ内で実行され、前記プロトコル層のクライアント・コンポーネントおよび前記サービス論理層の他のサービス・コンポーネントと、前記ＳＬＥＥ内の前記イベント・ルーティング・バスを介して通信するように構成された電話サービス・コンポーネントをさらに含む、請求項１に記載のアプリケーション実行環境。
【請求項３】
少なくとも１つが前記ＳＬＥＥ内で実行され、前記ＳＬＥＥ内の他のサービス・コンポーネントおよび前記アプリケーション層の特定の外部サービスと通信するように構成された総称サービス・コンポーネントをさらに含む、請求項１または２のいずれかに記載のアプリケーション実行環境。
【請求項４】
前記コネクタ／ラッパ・インターフェースが、
前記プロトコル層のクライアント・コンポーネントに抽象インターフェースを提供するクライアント・コンポーネント・ラッパと、
前記ＳＬＥＥに関連付けられ、前記クライアント・コンポーネント・ラッパに対応し、前記クライアント・コンポーネント・ラッパによって提供される前記抽象インターフェースを介して前記クライアント・コンポーネントと通信するように構成されたコネクタと
を含む、請求項１ないし３のいずれかに記載のアプリケーション実行環境。
【請求項５】
前記ＳＬＥＥがコネクタ／ラッパ・インターフェースを介して通信するように構成することができる、少なくとも１つのクライアント・コンポーネントを指定するＳＬＥＥディスクリプタをさらに含む、請求項１ないし４のいずれかに記載のアプリケーション実行環境。
【請求項６】
それぞれが前記プロトコル層の特定のクライアント・コンポーネントに対応し、特定のイベントを指定し、そのイベントについて、前記ＳＬＥＥ内の前記イベント・ルーティング・バスによって前記特定のクライアント・コンポーネントに通知することができる、少なくとも１つのクライアント・コンポーネント・ディスクリプタをさらに含む、請求項１ないし５のいずれかに記載のアプリケーション実行環境。
【請求項７】
前記クライアント・コンポーネントがプロトコル・スタックである、請求項１ないし６のいずれかに記載のアプリケーション実行環境。
【請求項８】
前記クライアント・コンポーネントが、コール制御コンポーネント、シグナリング・プロトコル・コンポーネント、接続管理プロトコル・コンポーネント、およびセキュア・ネットワーク・アクセス・プロトコル・コンポーネントからなる群から選択される、請求項１ないし６のいずれか一項に記載のアプリケーション実行環境。
【請求項９】
前記ＳＬＥＥが、統合ネットワーク向けＪａｖａ（Ｒ）  ＡＰＩ（ＪＡＩＮ）パラダイムに準拠している、請求項１ないし８のいずれかに記載のアプリケーション実行環境。
【請求項１０】
前記ＳＬＥＥが、
サービス・コンポーネントを前記ＳＬＥＥ内にロードするためのクラス・ローダをさらに含み、
前記ＳＬＥＥが、ロードされた各サービス・コンポーネントを、特定の登録済みサービス・コンポーネント向けのイベントを受信するために登録し、前記イベント・ルーティング・バスが、前記受信済みイベントを、前記ＳＬＥＥ内で実行される前記特定の登録済みサービス・コンポーネントにルーティングする、
請求項１ないし９のいずれかに記載のアプリケーション実行環境。
【請求項１１】
前記ＳＬＥＥが、
スレッド・プールと、
スレッドを前記ロードされたサービス・コンポーネントが使用できるように割り振るためのスレッド・プール・マネージャと
をさらに含む、請求項１ないし１０のいずれかに記載のアプリケーション実行環境。
【請求項１２】
サービス論理実行環境（ＳＬＥＥ）内のイベント・ルーティング・バスにおいて、コネクタ／ラッパ・インターフェースを介して、クライアント・コンポーネントからプロトコル層イベントを受信するステップと、
前記ＳＬＥＥ内で実行されるサービス・コンポーネントからサービス論理層イベントを受信するステップと、
前記特定のプロトコル層イベントおよび前記サービス論理層イベントを、前記特定のプロトコル層イベントおよび前記サービス論理層イベントを受信するために登録されたサービス・コンポーネントおよびクライアント・コンポーネントに転送するステップと、
前記ＳＬＥＥ内で実行される前記サービス・コンポーネントのうちの少なくとも１つにおいて、
少なくとも１つのサービス論理層イベントを、受信するために登録された別のサービス・コンポーネントに転送することができる前記イベント・ルーティング・バスに送信するステップと、
別のサービス・コンポーネントからサービス論理層イベントを受信するステップと、
前記別のサービス・コンポーネントから前記サービス論理層イベントを受信したことに応答して、サーバ側プログラムに通信可能なリンクを提供するステップと
を含む、電話サービス提供方法。
【請求項１３】
電話サービスを提供するためのコンピュータ・プログラムを格納する機械可読記憶装置であって、前記コンピュータ・プログラムが、機械に請求項１２に記載のステップを実施させるために、前記機械で実行可能なプログラム・コードを含む、機械可読記憶装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、高度インテリジェント・ネットワークの分野に関し、より詳細には、統合ネットワーク・サービス・プロバイダ向けのサービス・アプリケーション・アーキテクチャに関する。
【背景技術】
【０００２】
オープン・ネットワーク・アプリケーション・プログラミング・インターフェース（ＡＰＩ）は、公衆交換電話網（ＰＳＴＮ）アーキテクチャをオープンにするための従来方法からの重要な脱却を意味している。こうしたオープン・ネットワークＡＰＩの１つである、高度インテリジェント・ネットワーク（ＡＩＮ）ＡＰＩおよびアーキテクチャでは、スイッチ環境外での遠隔通信サービス・アプリケーションの生成を可能にするコール・モデルが定義される。遠隔通信サービス・アプリケーションは、二者以上の間で確立される遠隔通信セッション向けの高度サービスを実施することができる選択可能な遠隔通信アプリケーションである。こうしたサービス・アプリケーションの例には、キャッチホン、発信者番号通知、自動転送、音声ダイヤル、および参加型電話会議がある。
【０００３】
ＡＩＮが初めて導入されたとき、ＡＩＮアーキテクチャはサービス・アプリケーション生成プロセスの面での重要な進歩を意味していた。スイッチングから切り離されたＡＩＮのサービス開発では、サービス論理コンポーネントを、より迅速に開発し、データベースに接続された特定のネットワーク要素内に配置することができる。スイッチは、その結果、すべてのサービス論理から解放され、速度および効率についてその最適化を図ることができる。しかし、ＡＩＮ仕様で開発された通常のサービス・アプリケーションは、特別なサービス生成環境を用いて、特別に訓練されたプログラマによって、特別な言語で記述されている。
【０００４】
重要なことに、今後の遠隔通信ネットワークは新しい進化するネットワーク・アーキテクチャを特徴とし、このアーキテクチャでは、パケット交換、回線交換、および無線のネットワークが統合され、一連の革新的なマルチメディアのマルチパーティ・アプリケーションが加入者に提供されるようになる。同様に重要なことに、遠隔通信アプリケーション開発のプロセスが変化し、単に遠隔通信ネットワーク・プロバイダまたはサービス・アプリケーション・プロバイダの分野ではなくなると予想される。実際、新規で強力なアプリケーションの幅広いポートフォリオを迅速に提供するために、サービス・アプリケーション・プロバイダは、第三者のアプリケーション開発者およびソフトウエア・ベンダにますます依存するようになる。したがって、遠隔通信分野のアプリケーション開発は、一般にソフトウエアおよび情報技術のそれとますます類似するようになり、それが開発されるに伴って、顧客は競争の激化、製品化までの時間短縮および新技術の利用の恩恵を享受することになる。
【０００５】
こうしたビジョンを実現するために、新しいサービス・アプリケーション・コンポーネント開発パラダイムが優先され、ＡＩＮの原理は切り捨てられてきた。特に、今後の統合ネットワークは、あるベンダのシステムとの互換がとれるように作成されたアプリケーションが他のベンダのシステムで実行できるように、アプリケーション開発者に１組の標準、すなわちオープンＡＰＩを提供する必要があることが認識されてきた。その結果、アプリケーション開発コストが償却され、顧客への最終コストを削減することができる。統合ネットワーク向けＪＡＶＡ（Ｒ）ＡＰＩ（ＪＡＩＮ）はこの新しいサービス・アプリケーション・コンポーネント開発パラダイムの要件を満たすものである。現在、ＪＡＩＮは、統合インターネット・プロトコル（ＩＰ）または非同期転送モード（ＡＴＭ）ネットワーク、ＰＳＴＮ、および無線ネットワークからなる次世代システム向けの公開された標準のオープンなＪＡＶＡ（Ｒ）ＡＰＩを含んでいる。ＪＡＩＮ  ＡＰＩは、メディア・ゲートウェイ制御プロトコル（ＭＧＣＰ）、セッション初期化プロトコル(ＳＩＰ）、トランザクション機能アプリケーション部（ＴＣＡＰ）、ならびに遠隔通信プロトコル・スタックの上位層に常駐するプロトコルなど様々なプロトコル用に、プロトコル・レベルのインターフェースを含んでいる。
【０００６】
ＪＡＩＮは、ＪＡＩＮコンポーネントを構築し、ＰＳＴＮ、パケットおよび無線ネットワークにわたって機能するサービスまたはアプリケーションに統合するためのＪａｖａ（Ｒ）プラットフォーム向けの１組の統合ネットワークＡＰＩおよび環境を含んでいる。ＪＡＩＮ手法では、サービス・ベースの論理をネットワーク・ベースの論理から切り離すことによって有線、無線、およびパケット・ベースのネットワークを統合する。図１に従来型のＪＡＩＮ実装を示す。図１に示すように、従来型のＪＡＩＮ実装は、プロトコル層１０２を含むことができ、このプロトコル層はＩＰ、有線、無線のシグナリング・プロトコルとのインターフェースを含むことができる。ＴＣＡＰ、ＪＣＣ、およびＨ．３２３プロトコル１１０だけが示されているが、ＪＡＩＮ仕様によってサポートされるプロトコルは、特定のプロトコルに限定されず、たとえばＴＣＡＰ、ＩＳＵＰ、ＩＮＡＰ、ＭＡＰ、ＳＩＰ、ＭＧＣＰおよびＨ．３２３を含むことができる。さらに、ＪＡＩＮ実装は、ＪＣＣなどの接続管理およびコール制御プロトコルとのインターフェースを含むことができる。
【０００７】
従来型のＪＡＩＮ実装では、プロトコル層１０２に加えて、セキュア・ネットワーク・アクセスおよび他の外部サービス１２０を処理するためのアプリケーション層１０４を含むこともできる。従来型のＪＡＩＮ実装では、サービス論理層１０６も含むことができ、このサービス論理層はサービス生成およびキャリア・グレードのサービス論理実行環境（ＳＬＥＥ）１０８を含むことができる。サービス・コンポーネント１１２は核となるＪＡＩＮコンポーネントであり、ＳＬＥＥ１０８内で実行することができる。より具体的には、サービス・コンポーネント１１２は電話およびネットワーク・サービスを実装することができ、標準のコンポーネント・モデルに従って構築することができる。サービス・コンポーネント・アセンブリのインスタンスは、ＳＬＥＥ１０８と協調して実行される。
【０００８】
動作中、サービス・コンポーネント１１２は、ＳＬＥＥ１０８に組み込むことができるプロトコル層１０２に関する情報を使用して、プロトコル・スタック１１０に関する特定の知識がなくても基本となるプロトコル・スタック１１０と対話することができる。さらに重要なことに、ＳＬＥＥ１０８では、トランザクション、持続性、ロード・バランシング、セキュリティ、およびオブジェクトならび接続インスタンス・プーリングのための移植可能なサポートを提供することによって、サービス・コンポーネント１１２が負う従来のライフサイクルにわたる責任を軽減することができる。このようにして、サービス・コンポーネント１１２は、電話サービスまたはネットワーク・サービスあるいはその両方の提供に集中することができる。特に、ＳＬＥＥ１０８は、外部アプリケーション１１６、プロトコル・スタック１１０、サービス・コンポーネント１１２などのクライアント・コンポーネントに直接、通信可能にリンクすることができる。
【０００９】
たとえば、ＳＬＥＥ１０８のサービス論理層１０６で実行されるサービス・コンポーネント１１２は、ＳＬＥＥ１０８のプロトコル・アダプタを介して、プロトコル層のプロトコル・スタック１１０と通信することができる。プロトコル・アダプタは一般にクラス・メソッド、コールバック、カプセル化インターフェース、またはイベント・ハンドラを含むことができる。多くの場合、基本となるプロトコル・スタック１１０は、ＳＬＥＥ１０８のイベント・テーブル１１４を介して、ＳＬＥＥ１０８と直接に通信することができ、このイベント・テーブルは基本となるプロトコル・スタック１１０にとって特別なイベントを固有に処理するように構成することができる。その結果、ＳＬＥＥ１０８は、特別なイベントを認識することができ、基本となるプロトコル・スタック１１０からこうしたイベントを受信すると、ＳＬＥＥ１０８は登録しているサービス・コンポーネント１１２にそのイベントを渡すことができる。また、サービス・コンポーネント１１２は、リレーショナル・データベースやディレクトリ・サービスなどの特定の外部サービス１２０と対話するように個別にプログラムすることができる。
【００１０】
しかし、一見すると有利なＪＡＩＮ仕様であるが、従来型のＪＡＩＮ仕様の実装は、特にリアル・タイム電話の応用例においていくつかの欠点を含んでいる。まず、従来型のＪＡＩＮ実装のＳＬＥＥは、たとえばライフサイクルにわたる責任などの不要なシステム・ハウスキーピングの雑用を伴うEnterprise Java(R) bean（ＥＪＢ）手法を取り入れている。しかし、ライフサイクルにわたる責任は、リアル・タイム電話分野にとっては、他の通信分野ほどに重要ではない。したがって、ＥＪＢを使用すると、待ち時間が多すぎてリアル・タイム操作の要求を満たすことができない。さらに、ＳＬＥＥと基本となるプロトコル・スタックの間の通信を容易にするために使用することができる対応イベント・テーブルから明らかであるように、サービス・コンポーネント上のプロトコル・スタックの複雑さを緩和するには、ＳＬＥＥに、基本となるプロトコル・スタックの特定の知識が必要になる。しかし、ＳＬＥＥに特定のクライアント・コンポーネント情報を含めると、ＳＬＥＥに不必要な複雑さが加わることがある。ライフサイクル・メンテナンスの点からするとこれは問題になり得る。また、ＳＬＥＥにクライアント・コンポーネント情報を含めると、特定のクライアント・コンポーネントにＳＬＥＥを不必要に直接バインドすることにもなる。最後に、ＳＬＥＥを特定のクライアント・コンポーネントに直接バインドするには、アプリケーション層、プロトコル層およびサービス論理層をコンピューティング上で互いにきわめて近接して配置しなければならないことがある。
【００１１】
ＳＬＥＥ内のサービス・コンポーネントとの通信も外部アプリケーションにとって問題になることがある。特に、外部アプリケーションは、それが通信することができるＳＬＥＥ内のサービス・コンポーネントとプログラム上でバインドされなければならない。外部アプリケーションが、インターネットなどのコンピュータ通信ネットワーク全体にわたって分散されている場合は、この問題が複雑になることがある。したがって、ワールド・ワイド・ウェブを含めたインターネットを介して利用可能なサービスまたは他の機能を統合しようとするいずれの試みも、別個のプロプラエタリ・システムを使用して実装しなければならない。
【００１２】
特に、ＪＡＩＮ仕様によれば、無線サービス・アプリケーションの開発には、無線サービスにアクセスするための多数の異なる通信インターフェースおよびプロトコルに関する知識が必要である。たとえば、現在、無線ネットワークの使用をサポートする様々な異なる通信プロトコルが存在している。こうしたプロトコルには、移動通信向けグローバル・システム（ＧＳＭ）、総称パケット無線サービス（ＧＰＲＳ）、拡張データＧＳＭ環境（ＥＤＧＥ）、ユニバーサル移動電話システム（ＵＴＭＳ）、無線アプリケーション・プロトコル（ＷＡＰ）、移動アクセス・プロトコル（ＭＡＰ）、およびｉ−Ｍｏｄｅが含まれる。
【００１３】
無線サービス・アプリケーションを開発するために、開発者は、開発する無線サービス・アプリケーションに組み込まれる無線サービスまたは機能に対応する特定の無線プロトコル・インターフェースを熟知しなければならない。たとえば、ＷＡＰは、無線装置による通信を標準化する１組の通信プロトコル用の仕様である。したがって、ハンドヘルド装置の無線サービス向けのサービス・アプリケーションの開発者は、こうしたサービス・アプリケーションを首尾よく開発するためには、ＷＡＰについて少なくとも全般的に熟知している必要がある。
【００１４】
同様に、無線のハンドヘルド装置を介したウェブ・サイトのインタラクティブな使用を可能にするアプリケーション・サービスを提供しようとするサービス・アプリケーション開発者は、おそらく、ＷＡＰより高いデータ速度を提供することができるＧＰＲＳを熟知する必要があろう。ＧＰＲＳやＷＡＰなどのソリューションは様々な装置およびサービスの相互運用性を高め、またプロプライエタリ・ソリューションの使用を最小限に抑えることができる。しかし、様々な無線サービス・アプリケーションを開発するためには、開発者は多種の無線プロトコルおよびインターフェースを熟知しなければならない。したがって、様々な無線通信プロトコルおよびインターフェースを使用するのに必要な専門知識を有する人の数が限られることがある。
【００１５】
無線サービス・アプリケーションの開発に際して直面する問題と同様に、遠隔通信サービス・アプリケーションの開発もまたサービス・アプリケーションおよび機能にアクセスするための多くの異なる通信インターフェースおよびプロトコルに関する知識を必要とする。たとえば、コール・ブロッキングや自動転送などのサービス・アプリケーションでは、コール・モデルにアクセスするためのサービス・コンポーネントに加えて、コール・モデルを実装するための情報にアクセスするためにディレクトリ・サービスまたは他のプロプラエタリ・データベースへのアクセスが必要となることがある。しかし、ディレクトリ・サービスにアクセスするには、簡易ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）に関する特定の知識が必要となることがある。一方、どんな特定のデータベースにアクセスするにも、ＤＢ２、ＭＱＳｅｒｉｅｓ、または別のプロプライエタリ・データベース・アクセス・プロトコルに関する知識が必要となることがある。
【００１６】
通常、特定のプロトコルを用いて無線アプリケーションを実装するために必要な知識は、極めて専門的なため、必要な専門知識を有する人が所与の組織内で１人しかいないことがある。こうした人事上のジレンマは、しばしば、特定の無線フォーマットについてソリューションが開発されるたびに、そのソリューションを異なる無線フォーマットまたはプロトコルに容易には移植できないという形で現れる。さらに、プログラミングの専門知識は極めて専門的なことがあるので、サービス・アプリケーションを別のフォーマットまたはプロトコルに移植するには、一般に、対象のフォーマットまたはプロトコルの専門知識を有する追加の要員が必要になる。
【００１７】
したがって、電話サービス・アプリケーションの開発が極めて専門的な性質のものであるため、開発費用が増大し、設計サイクルが長くなることがある。さらに、それに伴う複雑さにより、システム、機能およびアプリケーションのリサイクリングおよびメンテナンスが極めて難しくなる。たとえば、特定のサービス機能にアクセスするために必要なプロトコルおよび論理が開発中のサービス・アプリケーションに含まれているので、基本となるプロトコルに対してどんな変更を行うにも、サービス・アプリケーション全体の再プログラミングが必要になることがある。要するに、無線サービス・アプリケーションの開発が極めて専門的な性質のものであるため、開発費用が増大し、設計サイクルが長くなることがある。さらに、それに伴う複雑さにより、システム、機能およびアプリケーションのリサイクリングが極めて難しくなる。
【００１８】
Broadsoft Inc.のＷＯ  ０１／２８１８６号は、サービス・エンティティ、インターフェース・エンティティ、およびサービス・バスを含む、サービスを提供するためのシステムを開示している。サービス・バスは、インターフェース・エンティティとサービス・エンティティを結合し、インターフェース・エンティティとサービス・エンティティの間でイベントを受け渡しする。
【特許文献１】
ＷＯ  ０１／２８１８６号、Broadsoft Inc.
【発明の開示】
【発明が解決しようとする課題】
【００１９】
したがって、統合ネットワーク・サービス・プロバイダ向けのより柔軟なサービス・アプリケーション・アーキテクチャが必要とされている。
【課題を解決するための手段】
【００２０】
第１の態様によれば、本発明は、アプリケーション実行環境を提供する。この環境は、クライアント・コンポーネントとサービス・コンポーネントの間でイベントをルーティングするイベント・ハンドラを含むサービス論理実行環境（ＳＬＥＥ）と、前記イベント・ハンドラを介して、前記ＳＬＥＥ内の他のサービス・コンポーネントとの間でイベントを送受信するように構成された少なくとも１つのサービス・コンポーネントと、前記ＳＬＥＥ内で実行される少なくとも１つのインターネット対応サービス・コンポーネント（ＩＥＳＣ）とを含み、前記ＩＥＳＣは、前記イベント・ハンドラを介して、前記ＳＬＥＥ内の他のサービス・コンポーネントとの間でイベントを送受信するように構成され、前記ＳＬＥＥの外部にあるサーバ側プログラムに通信可能にリンクする。
【００２１】
アプリケーション実行環境はさらに、ＳＬＥＥ内で実行される少なくとも１つの総称サービス・コンポーネントを含むことが好ましい。総称サービス・コンポーネントは、ＳＬＥＥ内の他のサービス・コンポーネントと通信するように構成することができる。総称サービス・コンポーネントは、アプリケーション層の特定の外部サービスと通信するように構成することもできる。
【００２２】
好ましくは、アプリケーション実行環境が、少なくとも１つが前記ＳＬＥＥ内で実行され、前記ＳＬＥＥ内の前記イベント・ルーティング・バスを介して、プロトコル層のクライアント・コンポーネントおよびサービス論理層の他のサービス・コンポーネントと通信するように構成された電話コンポーネントをさらに含む。
【００２３】
好ましくは、コネクタ／ラッパ・インターフェースは、プロトコル層のクライアント・コンポーネントに抽象インターフェースを提供するクライアント・コンポーネント・ラッパと、ＳＬＥＥに関連付けられ、クライアント・コンポーネント・ラッパに対応し、クライアント・コンポーネント・ラッパによって提供される抽象インターフェースを介してクライアント・コンポーネントと通信するように構成されるコネクタとを含む。
【００２４】
好ましくは、アプリケーション実行環境はさらに、ＳＬＥＥがコネクタ／ラッパ・インターフェースを介して通信するように構成することができる、少なくとも１つのクライアント・コンポーネントを指定するＳＬＥＥディスクリプタを含む。
【００２５】
好ましくは、アプリケーション実行環境はさらに、それぞれがプロトコル層の特定のクライアント・コンポーネントに対応し、特定のイベントを指定し、そのイベントについて、ＳＬＥＥ内のイベント・ルーティング・バスによって特定のクライアント・コンポーネントに通知することができる、少なくとも１つのクライアント・コンポーネント・ディスクリプタを含む。
【００２６】
クライアント・コンポーネントは、プロトコル・スタックであることが好ましい。あるいは、クライアント・コンポーネントは、コール制御コンポーネントでも、シグナリング・プロトコル・コンポーネントでも、接続管理プロトコル・コンポーネントでも、またはセキュア・ネットワーク・アクセス・プロトコル・コンポーネントでもよい。
【００２７】
ＳＬＥＥは、ＪＡＩＮ準拠のＳＬＥＥであることが好ましい。
【００２８】
好ましくは、ＳＬＥＥはさらに、サービス・コンポーネントをＳＬＥＥ内にロードするためのクラス・ローダを含み、ＳＬＥＥが、ロードされた各サービス・コンポーネントを、特定の登録済みサービス・コンポーネント向けのイベントを受信するために登録し、前記イベント・ルーティング・バスが、前記受信済みイベントをＳＬＥＥ内で実行される前記特定の登録済みサービス・コンポーネントにルーティングする。
【００２９】
ＳＬＥＥはさらに、スレッド・プールと、スレッドを前記ロードされたサービス・コンポーネントが使用できるように割り振るためのスレッド・プール・マネージャとを含むことが好ましい。
【００３０】
第２の態様によれば、本発明は、電話サービス提供方法を提供する。この方法では、サービス論理実行環境（ＳＬＥＥ）内のイベント・ルーティング・バスにおいて、クライアント・コンポーネントからコネクタ／ラッパ・インターフェースを介してプロトコル層イベントを受信するステップと、ＳＬＥＥ内で実行されるサービス・コンポーネントからサービス論理層イベントを受信するステップと、前記特定のプロトコル層イベントおよび前記サービス論理層イベントを、前記特定のプロトコル層イベントおよび前記サービス論理層イベントを受信するために登録されたサービス・コンポーネントおよびクライアント・コンポーネントに転送するステップと、前記ＳＬＥＥで実行される前記サービス・コンポーネントのうちの少なくとも１つにおいて、少なくとも１つのサービス論理層イベントを前記イベント・ルーティング・バスに送信するステップであって、前記イベント・ルーティング・バスは、前記送信されたサービス論理層イベントを、前記送信されたサービス論理層イベントを受信するために登録された別のサービス・コンポーネントに転送するステップと、別のサービス・コンポーネントからサービス論理層イベントを受信するステップと、前記別のサービス・コンポーネントから前記サービス論理層イベントを受信したことに応答して、通信可能なリンクをサーバ側プログラムに提供するステップとを含む。
【００３１】
第３の態様によれば、本発明は、電話サービスを提供するためのコンピュータ・プログラムを格納する機械可読記憶装置であって、前記コンピュータ・プログラムが、機械に第２態様による方法を実施させるために、機械で実行可能なプログラム・コードを含む、機械可読記憶装置を提供する。
【００３２】
したがって、本発明は、統合ネットワーク・サービス・プロバイダ向けの柔軟なサービス・アプリケーション・アーキテクチャを提供する。本発明は、サービス・コンポーネントによるより直接的なイベント処理を提供し、サービス論理実行環境（ＳＬＥＥ）内に含まれるプロトコル・スタック特有のコードを減らすことにより、従来技術の欠点に対処するものである。さらに、本発明は、ＳＬＥＥから特定のクライアント・コンポーネントに関する情報を取り除き、その代わりにコネクタ／ラッパ通信インターフェースを用いることにより、従来技術の欠点に対処する。その結果、ＳＬＥＥは、基本となるクライアント・コンポーネントの実装の詳細に関係なく、コネクタ／ラッパ・インターフェースを介した通信を総称的に送受信することができる。したがって、本発明によれば、ＳＬＥＥの複雑さを緩和することができる。さらに、本発明に従って構成されたＳＬＥＥは、特定のクライアント・コンポーネントと直接バインドする必要がない。
【００３３】
本発明のアーキテクチャは、ＳＬＥＥ内で実行される他のサービス・コンポーネントとの総称インターフェースを提供しながら、特定の外部サービスと通信するように構成することができる総称サービス・コンポーネントを含むことが好ましい。このようにして、たとえば電話サービス・コンポーネントなどＳＬＥＥ内で実行されるサービス・コンポーネントはデータベース操作などの外部サービスを、総称サービス・コンポーネントに総称的に要求することができる。外部サービスを求める総称要求を受信したことに応答して、総称サービス・コンポーネントは、要求された外部サービスを要求元の電話サービス・コンポーネントに提供するために、対応する特定の外部サービスに特有の１つまたは複数の機能を呼び出すことができる。その結果、電話サービス・コンポーネントは特定の外部サービス向けの特有のコードを組み込む必要がなくなる。総称サービス・コンポーネントが特定の外部サービス向けの特有のコードを組み込むだけでよい。したがって、電話サービス・コンポーネントの複雑さを緩和することができる。
【００３４】
次に本発明を、添付の図面に示すその好ましい一実施形態に則して、例としてのみ説明する。
【発明を実施するための最良の形態】
【００３５】
本発明は、統合ネットワーク・サービス・プロバイダ向けの柔軟なサービス・アプリケーション・アーキテクチャである。このアーキテクチャは、プロトコル層、サービス論理層およびアプリケーション層を含むことができるので、高度インテリジェント・ネットワーク・アーキテクチャ（ＡＩＮ）に類似したものとすることができる。本発明の構成によれば、本発明のアーキテクチャは、サービス論理層にサービス論理実行環境（ＳＬＥＥ）を含むことができる。特に、ＳＬＥＥは、ＪＡＩＮ準拠のＳＬＥＥとすることができる。ＳＬＥＥは、サービス論理層のサービス・コンポーネントと、プロトコル層およびアプリケーション層のクライアント・コンポーネントの間でイベントをルーティングするイベント・ルーティング・バスを含むことができる。特に、ＳＬＥＥ内で実行される電話サービス・コンポーネントは、ＳＬＥＥのイベント・ルーティング・バスを介して、プロトコル層のクライアント・コンポーネントおよびサービス論理層の他のサービス・コンポーネントと通信するように構成することができる。最後に、クライアント・コンポーネントはコネクタ／ラッパ・インターフェースを介して、ＳＬＥＥに通信可能にリンクすることができる。
【００３６】
本発明の好ましい一実施形態に従って構成されたＳＬＥＥを取り込むと、サービス・コンポーネント間でのイベント通信を円滑にすることができるイベント・ルーティング・バスが提供されるので、従来技術の欠点を解決する助けとなる。より直接的なイベント通信を提供することにより、ＪＡＩＮ仕様のＥＪＢ手法に付随する固有の待ち時間を少なくすることができる。同様に、サービス・コンポーネントがＳＬＥＥを介してプロトコル・スタックなどのクライアント・コンポーネントからだけイベントを受信し、受信したイベントを処理することができるＳＬＥＥの従来の実装とは異なり、本発明の好ましい一実施形態では、サービス・コンポーネントは他のサービス・コンポーネントからもイベントを受信し処理することもできる。したがって、マクロ・サービス・コンポーネントを形成するために、拡張されたサービス・コンポーネントの組合せを生み出すことができる。
【００３７】
サービス・コンポーネントは、特定のプロトコル・スタックに関する特有の知識を有するように構築することもできる。その結果、特定のプロトコル・スタックに関する特有の知識をＳＬＥＥから取り除き、それによってＳＬＥＥの複雑さを緩和することができる。その結果、本発明の好ましい一実施形態のＳＬＥＥでは、ＳＬＥＥの再コーディングを必要とせずに、新しいプロトコル・スタックをインテリジェント・ネットワークに追加することができる。この追加のプロトコル・スタックに関する特有の知識を有するサービス・コンポーネントを生成することができるからである。他のサービス・コンポーネントは、ＳＬＥＥに動的に挿入されると、挿入されたサービス・コンポーネントを介しイベント・ルーティング・バスを経由して新しいプロトコル・スタックにアクセスすることができる。サービス・コンポーネント間の通信が不可能であった従来のインテリジェント・ネットワークとは異なり、本発明の好ましい一実施形態では、サービス・コンポーネント間の通信によって、新しいプロトコル・スタックを容易に追加することが可能になる。
【００３８】
本発明のアーキテクチャは、プロトコル層のクライアント・コンポーネントにＳＬＥＥを通信可能にリンクするためのコネクタ／ラッパ・インターフェースを含むこともできる。ＳＬＥＥとプロトコル層のクライアント・コンポーネントの間のコネクタ／ラッパ・インターフェースは、クライアント・コンポーネントをＳＬＥＥに固定的にバインドせずに、特定のクライアント・コンポーネントに総称インターフェースを介した構成可能な接続を提供することによって、従来技術の欠点の解決に役立つことができる。
【００３９】
ＳＬＥＥが、その通信相手であるクライアント・コンポーネントと直接バインドされるＳＬＥＥの従来の実装とは異なり、本発明の好ましい一実施形態では、ＳＬＥＥとクライアント・コンポーネントを互いに近接して配置する必要はない。むしろ、必要であれば、ＳＬＥＥとクライアント・コンポーネントは、ネットワークをはさんで配置することができる。このようにして、クライアント・コンポーネントとＳＬＥＥの間のより柔軟な関係が可能になり、それによって、ライフサイクル・メンテナンス中のＳＬＥＥのメンテナンスおよび拡張を容易にすることができる。さらに、特定のクライアント・コンポーネントに関する特有の知識をＳＬＥＥから取り除き、代わりにクライアント・コンポーネントとのインターフェースに含めることができる。その結果、ＳＬＥＥの複雑さを緩和することができる。
【００４０】
最後に、本発明の好ましい一実施形態は、特定の外部サービスとの抽象インターフェースを提供する総称サービス・コンポーネントを含む。より詳細には、各総称サービス・コンポーネントは特定の外部サービスの個々の実装に対する認識を維持することができ、ＳＬＥＥ内で実行される他のサービス・コンポーネント、特に電話サービス・コンポーネントは、対応する特定の外部サービスの個々の実装について知らなくても、総称サービス・コンポーネントの外部サービスを総称的に要求することができる。このようにして、サービス・コンポーネントの複雑さを緩和することができ、サービス・コンポーネントを外部サービスの特定の実装から切り離すことができる。
【００４１】
図２は、本発明の好ましい一実施形態に従って構成されたＪＡＩＮ準拠のインテリジェント・ネットワークの概略図である。ＪＡＩＮ準拠のネットワークは、プロトコル層２０２、アプリケーション層２０５、およびサービス論理層２０７を含むように構成される。アプリケーション層２０５は、外部の第三者アプリケーション２０８をホスティングすることができる。通常の第三者アプリケーション２０８は、仮想プライベート・ネットワーク（ＶＰＮ）、受信サービス、統合メッセージングなどのサービスに対する一般大衆市場の要求に適したものとすることができる。外部の第三者アプリケーション２０８は、短命およびニッチなアプリケーションを含むこともでき、このアプリケーションは、当技術分野で周知のデータベース検索インターフェース、ダウンロード可能な機構、およびＰａｒｌａｙ  ＡＰＩなどの信頼できないアプリケーション空間デプロイメント技術を用いて展開することができる。最後に、データベース・サービス、ディレクトリ・サービス、および無線サービスなど特定の外部サービス２２０は、アプリケーション層２０５に含めることができる。
【００４２】
サービス論理層２０７は、ＪＡＩＮ仕様と互換がとれるように構成することができるＪＳＬＥＥサーバ２００などのＳＬＥＥサーバを含むことができる。重要なことに、ＪＳＬＥＥサーバ２００は、イベント・ルーティング・バス２１８を含むことができる。イベント・ルーティング・バス２１８は、サービス・コンポーネント２０３、２０４、２０５との間でメッセージを送受信することができる。特に、サービス・コンポーネント２０３、２０４、２０５は、イベント・ルーティング・バス２１８にメッセージを送信するように構成することができ、サービス・コンポーネント２０３、２０４、２０５はＪＳＬＥＥサーバ２００に登録し、こうした送信されたイベントを他のサービス・コンポーネント２０３、２０４、２０５から受信することができる。このようにして、サービス・コンポーネント間の通信が可能になる。さらに、サービス・コンポーネント２０３、２０４、２０５は、イベント・ルーティング・バス２１８を介して、外部アプリケーション２０８からイベントを受信するように構成することができる。また、外部アプリケーション２０８から受信され、イベント・バス２０８に送信されたイベントは、こうしたイベントを受信するために登録を行った他のサービス・コンポーネント２０３、２０４、２０５にルーティングすることができる。
【００４３】
サービス・コンポーネント２０３、２０４、２０５は、電話サービス・コンポーネント２０４、総称サービス・コンポーネント２０３、およびインターネット・サービス・コンポーネント２０５を含むことができる。図３は、図２のＪＳＬＥＥサーバ２００で使用するように構成された電話サービス・コンポーネント２０４の概略図である。図３に示すように、電話サービス・コンポーネント２０４は、１つまたは複数のサービス・インスタンス３０２を含むことができる。サービス・インスタンス３０２は、ＪＳＬＥＥ２００内で実行することができる、個別にインスタンス化されたサービスである。さらに重要なことに、各サービス・インスタンス３０２は、イベント・ルーティング・バス２１８に登録し、プロトコル層２０２、ならびに他の電話および総称サービス・コンポーネント２０３、２０４、２０５との間でイベントを送受信する。
【００４４】
各サービス・インスタンス３０２はサービス・ラッパ３０６を介してアクセスすることができ、このサービス・ラッパは、サービス・インスタンスの実装の詳細を隔離する。より詳細には、サービス・クラスのデータおよびメソッドのメンバは、サービス・ラッパ３０６に含まれる共通インターフェースを介してアクセスすることができる。デプロイメント・ディスクリプタ３１０も同様に提供される。デプロイメント・ディスクリプタ３１０は文書、たとえばＸＭＬ文書とすることができ、ＪＳＥＬＬサーバ２００にサービス・コンポーネント３０２のインスタンスを最初にロードするための適当なパラメータを記述することができる。特に、サービス・ラッパ３０６とのインターフェースは、たとえばＸＭＬ文書の一部として含めることができるサービス・インターフェース３０８を介して外部オブジェクトにパブリッシュすることができる。同様に、各サービス・インスタンス３０２とのインターフェースは、コンテキスト・インターフェース３０４の一部として含めることができ、このコンテキスト・インターフェースも、たとえばＸＭＬ文書の一部としてパブリッシュすることができる。サービス・インスタンス３０２は、ロードされると、ＪＳＥＬＬサーバ２００のイベント・ルーティング・バス２１８を介して通信することができる。
【００４５】
電話サービス・コンポーネント２０４に、プロプラエタリおよびリレーショナル・データベース・サービスやディレクトリ・サービスなどの特定の外部サービス２２０にアクセスするためのコードを含まないようにするために、総称サービス・コンポーネント２０３を本発明のアーキテクチャに組み込むことができる。総称サービス・コンポーネント２０３は、特定の外部サービス２２０との抽象インターフェースを提供し、特定の外部サービス２２０との対話を求める、他のサービス・コンポーネント２０３、２０４、２０５からの総称要求に固有に応答することができる。特に、総称サービス・コンポーネント２０３は、無線サービス、ディレクトリ・サービス、データベース・サービス、またはメッセージング・サービスなどのサービス・アプリケーションにアクセスするための共通ＡＰＩを提供することができる。
【００４６】
実際、総称サービス・コンポーネント２０３は、異なるサービス・アプリケーションごとに構築することができる。さらに、総称サービス・コンポーネント２０３は、サービス・アプリケーションが用いる異なるプロトコルごとに構築することができる。したがって、図２に示すように、それぞれがサービス・アプリケーションまたはプロトコルに対応している複数の総称サービス・コンポーネント２０３を含むことができる。たとえば、異なる総称サービス・コンポーネント２０３を、ＬＤＡＰ、ＤＢ２、およびＭＱＳｅｒｉｅｓ対応のサービスまたは機能向けに構築することができる。同様に、異なる総称サービス・コンポーネント２０３は、移動通信向けグローバル・システム（ＧＳＭ）、総称パケット無線サービス（ＧＰＲＳ）、拡張データＧＳＭ環境（ＥＤＧＥ）、ユニバーサル移動電話システム（ＵＴＭＳ）、ＷＡＰ、モバイル・アクセス・プロトコル（ＭＡＰ）、およびｉ−Ｍｏｄｅを使用するグローバル・システムなど、無線サービス・アプリケーションへのアクセス向けに構築することができる。したがって、総称サービス・コンポーネント２０３を含めることで、他のサービス・コンポーネント、特に電話サービス・コンポーネント２０４は、特定の外部サービス２２０と通信するための特有の構成を含まなくてもよくなる。
【００４７】
図４は、図２のＪＳＬＥＥサーバ２００で使用するように構成された総称サービス・コンポーネント２０３の概略図である。図４に示すように、総称サービス・コンポーネント２０３は、１つまたは複数の総称サービス・インスタンス４０２を含むことができる。図３の電話サービス・インスタンス３０２と同様に、図４の総称サービス・インスタンス４０２は、ＪＳＬＥＥ２００内で実行することができる個別にインスタンス化された総称サービスである。より重要なことに、各総称サービス・インスタンス４０２はイベント・ルーティング・バス２１８に登録し、サービス論理層２０７の他のサービス・コンポーネント２０３、２０４、２０５との間でイベントを送受信することができる。電話サービス・コンポーネント２０４の場合と同様に、各総称サービス・インスタンス４０２はサービス・インスタンスの実装の詳細を隔離する総称サービス・ラッパ４０６を介してアクセスすることができる。より詳細には、サービス・クラスのデータおよびメソッドのメンバは、総称サービス・ラッパ４０６に含まれる共通インターフェースを介してアクセスすることができる。
【００４８】
デプロイメント・ディスクリプタ４１０もまた提供される。デプロイメント・ディスクリプタ４１０は、文書、たとえばＸＭＬ文書とすることができ、ＪＳＬＥＥサーバ２００に総称サービス・コンポーネント４０２のインスタンスを最初にロードするために適当なパラメータを記述することができる。特に、総称サービス・ラッパ４０６とのインターフェースは、たとえばＸＭＬ文書の一部として含めることができる総称サービス・インターフェース４０８を介して外部オブジェクトにパブリッシュすることができる。同様に、各サービス・インスタンス４０２とのインターフェースは、コンテキスト・インターフェース４０４の一部として含めることができ、このコンテキスト・インターフェースもたとえばＸＭＬ文書の一部としてパブリッシュすることができる。ロードされると、総称サービス・インスタンス４０２は、ＪＳＬＥＥサーバ２００内のイベント・ルーティング・バス２１８を介して通信することができる。
【００４９】
図５は、本発明の好ましい一実施形態のＪＡＩＮ準拠のインテリジェント・ネットワークにおける総称サービス・コンポーネント５０２Ａ、５０２Ｂ、５０２Ｃ、５０２Ｄ、５０２Ｅ、５０２Ｆの構成の例を示す簡略化した図である。図５に示すように、各総称サービス・コンポーネント５０２Ａ、５０２Ｂ、５０２Ｃ、５０２Ｄ、５０２Ｅ、５０２Ｆは、サービス・ラッパ５０６および１つまたは複数のクライアント・サービス・インスタンス５０２を含むことができる。サービス・ラッパ５０６は、ＪＳＬＥＥサーバ２００に登録し、サービス・アプリケーション５３０に対応する特定の種類のイベントを受信することができる。したがって、サービス・ラッパ５０６は、特定のプロトコルに従って受信済みイベントを変換し、そのイベントを再フォーマットするために必要な機能を含むことができる。再フォーマットされたイベントは、特定の無線サービス・アプリケーションにルーティングすることができる。サービス・ラッパ５０６は特定のトランザクション、すなわち１つまたは複数のイベントを処理するためにクライアント・サービス・インスタンス５０２をインスタンス化することができる。クライアント・サービス・インスタンス５０２は、サービス・アプリケーション５３０Ａ、５３０Ｂ、５３０Ｃ、５３０Ｄ、５３０Ｅ、５３０Ｆのうちの１つと通信するためにインスタンス化することもできる。
【００５０】
図５に示すように、例示的な総称サービス・コンポーネント５０２Ａ、５０２Ｂ、５０２Ｃ、５０２Ｄ、５０２Ｅ、５０２Ｆは、それだけには限らないが、ＷＡＰ総称サービス・コンポーネント５０２Ａ、ＥＤＧＥ総称サービス・コンポーネント５０２Ｂ、ＧＰＲＳ総称サービス・コンポーネント５０２Ｃ、ＬＤＡＰ総称サービス・コンポーネント５０２Ｄ、ＤＢ２総称サービス・コンポーネント５０２Ｅ、およびＭＱＳｅｒｉｅｓ総称サービス・コンポーネント５０２Ｆを含むことができる。たとえば、サービス・ラッパ５０６は、ＷＡＰ総称サービス・コンポーネント５０２Ａの一部として、ＪＳＬＥＥサーバ２００に登録し、無線のハンドヘルド装置などの無線装置に関連する無線イベントを受信することができる。図５に示すように、サービス・ラッパ５０６は、各受信済みイベント、すなわちＷＡＰ対応の無線サービス・アプリケーションに関連するトランザクションを含む一連のイベントごとに１つずつ、計３つのクライアント・サービス・インスタンス５０２をインスタンス化している。あるいは、単独のクライアント・サービス・インスタンス５０２は複数のトランザクションを処理することもできる。したがって、各クライアント・サービス・インスタンス５０２は、ＷＡＰ対応のサービス・アプリケーション５３０Ａと対話することができる。
【００５１】
同様に、ＥＤＧＥ総称サービス・コンポーネント５０２ＢおよびＭＱＳｅｒｉｅｓ総称サービス・コンポーネント５０２Ｆはそれぞれサービス・ラッパ、および１つまたは複数のクライアント・サービス・インスタンスを含み、ＥＤＧＥ対応の無線サービス・アプリケーション５３０ＢおよびＭＱＳｅｒｉｅｓメッセージ・キュー・サービス・アプリケーション５３０Ｆとそれぞれに対話することができる。総称サービス・コンポーネントは、必要に応じて、プロプラエタリ・データベースおよびプロプラエタリ・インターフェースおよびプロトコルを用いる無線サービスを含めていずれのサービス・アプリケーション向けにも構築することができることを理解されたい。
【００５２】
次に図２を参照すると、電話および総称サービス・コンポーネント２０３、２０４とは異なり、インターネット対応のサービス・コンポーネント２０５は、サーブレットやスクリプトなどの外部サーバ側プログラムと通信するように事前に構成することができる。サーバ側プログラムの例には、これだけには限らないが、共通ゲートウェイ・インターフェース（ＣＧＩ）、Perlスクリプト、Java（R）ServerPage、ＶＢスクリプト、Active Server Page（商標）、または他のスクリプト技術が含まれる。外部アプリケーション２３２がインターネット対応サービス・コンポーネント２０５にアクセスすると、インターネット対応サービス・コンポーネント２０５は、外部アプリケーション２３２にＪＳＬＥＥサーバ２００内のイベント・ルーティング・バス２１８へのアクセスを提供することができ、このバスを介して、サービス・コンポーネント２０３、２０４、２０５は互いに通信することができる。
【００５３】
この機構を介して、ＪＳＬＥＥサーバ２００上で実行されるサービス・コンポーネント２０３、２０４、２０５は、インターネット対応サービス・コンポーネント２０５とも通信することができる。したがって、インターネット対応サービス・コンポーネント２０５は、インターネットなどのコンピュータ通信ネットワーク内のウェブ・サーバ２３０と連携して動作するサーバ側プログラム２３２に通信可能にリンクすることができるので、ＪＳＬＥＥサーバ２００上の他のサービス・コンポーネント２０３、２０４は、インターネット対応サービス・コンポーネント２０５を使用して、インターネット上で情報を送受信することができる。さらに、ＪＳＬＥＥサーバ２００上の他のサービス・コンポーネント２０３、２０４は、ユーザおよび管理者によってインターネットからアクセスすることができる。
【００５４】
インターネット対応サービス・コンポーネント２０５は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に従って要求および応答を送受することにより、ウェブ・サーバ２３０と直接通信するように構成することができる。同様に、ウェブ・サーバ２３０は、やはりＨＴＴＰに従ってインターネット対応サービス・コンポーネント２０５と通信するように構成されたサーバ側プログラム２３２を含むことができる。とはいえ、本発明は、インターネット対応サービス・コンポーネント２０５と、対応するサーバ側プログラム２３２がどのように通信するかについて制限されていない。むしろ、明示的なＴＣＰ／ＩＰ通信などの一般的な接続指向技術を含めてどんな周知の通信技術でも十分であり得る。
【００５５】
サーバ側プログラム２３２とインターネット対応サービス・コンポーネント２０５を組み合わせることで、サービスおよびサービス・コンポーネントの様々な側面に、インターネットを介して、インターネット対応サービス・コンポーネント２０５によって提供される共通のアプリケーション・プログラミング・インターフェース（ＡＰＩ）からアクセスすることが可能になる。たとえば、加入者はサービス属性にアクセスしそれを修正することができる。サービス属性は加入者によってアクセス可能などんなサービスの側面も含むことができる。同様に、サービス管理者またはスーパ・ユーザは、インターネット上で管理機能へのアクセス、監視、および実施を行うことができる。管理機能は、それだけには限らないが、システム管理者またはスーパ・ユーザのために確保され、加入者には提供されないどんな機能も含むことができる。特に、インターネット対応サービス・コンポーネント２０５は、外部サービスまたはシステムの補助なしに、加入者および管理者にこうしたアクセスをインターネット上で提供することができる。
【００５６】
ＪＳＬＥＥサーバ２００上の他のサービス・コンポーネント２０３、２０４と同様に、各インターネット対応サービス・コンポーネント２０５は、ＪＳＬＥＥサーバ２００との間でイベントの送受信が行えるように構成することもできる。このようにして、他のサービス・コンポーネント２０３、２０４は、ＪＳＬＥＥサーバ２００に登録し、こうしたイベントを受信することができる。サービス・コンポーネント２０３、２０４は、それに対応して、ＪＳＬＥＥサーバにイベントを送信することができ、インターネット対応サービス・コンポーネント２０５を登録してそのイベントを受信することができる。インターネット対応サービス・コンポーネント２０５は、ＪＳＬＥＥサーバ２００から受信するイベント、ならびにウェブ・サーバ２３０から受信する通信を処理することができることを理解されたい。このようにして、インターネット対応サービス・コンポーネント２０５は、インターネットとＪＳＬＥＥサーバ２００の間のインターフェースとして機能することができる。
【００５７】
特に、ＪＳＬＥＥサーバ２００は、スレッド・プール２２２、クラス・ローダ２２４、タイマ２２６、使用カウンタ２２８を含む複数のライフサイクル管理コンポーネントも含むことができる。しかし、ライフサイクル管理コンポーネントは、図２に示すものだけには限られない。むしろ、ライフサイクル管理コンポーネントは、たとえばロード・バランシングなどの他のライフサイクル管理責任を実施することができるコンポーネントを含むことができる。いずれにせよ、本発明の構成によれば、個々のサービス・コンポーネントは、ライフサイクル管理を実施するオーバヘッドから解放され、電話アプリケーションにおいてより適切に使用することができる。
【００５８】
特に、図２に示すように、スレッド・プール２２２は、複数の事前構成およびロードされた実行スレッドを含むことができ、この実行スレッドは、要求に応じて、スレッド・プール管理コンポーネントによって、ＪＳＬＥＥサーバ２００上で実行される要求元のサービス・コンポーネント２０３、２０４、２０５に割り当てることができる。要求元のサービス・コンポーネント２０３、２０４、２０５が割り当てられたスレッドの使用を完了したとき、スレッド・プール管理コンポーネントは、その割り当て済みのスレッドを割り当て解除することができ、その割り当て解除されたスレッドを、ＪＳＬＥＥサーバ２００上で実行される他の要求元のサービス・コンポーネント２０３、２０４、２０５が使用できるように、スレッド・プール２２２に戻すことができる。
【００５９】
クラス・ローダ２２４をＪＳＬＥＥサーバ２００は使用して、ＪＳＬＥＥサーバ２００上で実行すべくサービス・コンポーネント２０３、２０４、２０５を適切にロードすることができる。特に、クラス・ローダ２２４は、ロードされる各サービス・コンポーネント２０３、２０４、２０５に関連する構成およびロード・パラメータを識別することができる。次いで、クラス・ローダ２２４は、識別された構成およびロード・パラメータを用いて、サービス・コンポーネント２０３、２０４、２０５を実行することができる。最後に、クラス・ローダ２２４は、サービス・コンポーネント２０３、２０４、２０５を、イベント・ルーティング・バス２１８に登録することができ、ＪＳＬＥＥサーバ２００上で実行されるサービス・コンポーネント２０３、２０４、２０５との間でイベントを送受信することができる。
【００６０】
最後に、プロトコル層２０２は、１つまたは複数のプロトコル・スタックを含むことができ、このプロトコル・スタック２０６は、ＪＳＬＥＥサーバ２００上で実行されるサービス・コンポーネント２０４と通信するように構成することができる。特に、図２には、３つのプロトコル・スタック２０６だけしか示されていないが、本発明は、プロトコル・スタック２０６の数または種類について制限していない。むしろ、ＪＳＬＥＥサーバ２００は、いずれのプロトコル・スタック、たとえばＪＡＩＮ仕様に従って構成されたプロトコル・スタックとも通信することができる。
【００６１】
動作中、ＪＳＬＥＥサーバ２００はプロトコル層２０２のプロトコル・スタック２０６との間でイベントを送受信することができる。より詳細には、イベントは、ＪＳＬＥＥサーバ２００に含まれる、イベント・ルーティング・バス２１８で送受信される。電話サービス・コンポーネント２０４および総称サービス・コンポーネント２０３は、イベント・ルーティング・バス２１８で受信される特定のイベントのリスナーとして登録することができる。ＪＳＬＥＥサーバ２００に登録されたサービス・コンポーネント２０３、２０４、２０５は、サービス・コンポーネント２０３、２０４、２０５のうちの特定のコンポーネントに向けたプロトコル・スタック・イベントを受信することができる。サービス・コンポーネント２０３、２０４、２０５はまた、サービス・コンポーネント２０３、２０４、２０５のうちの特定のコンポーネントに向けたサービス・コンポーネント・イベントを受信することができる。より詳細には、ＪＳＬＥＥサーバ２００のイベント・ルーティング・バス２１８は、受信したイベントを、こうしたイベントを受信するためにＪＳＬＥＥサーバ２００に登録を行ったサービス・コンポーネント２０３、２０４、２０５にルーティングすることができる。
【００６２】
本発明の好ましい一実施形態によれば、ＪＳＬＥＥサーバ２００は、ＪＡＩＮ準拠のインテリジェント・ネットワーク上のクライアント・コンポーネントと通信するように構成することができる。クライアント・コンポーネントは、プロトコル・スタック２０６だけでなく、他のサービス・コンポーネント２０３、２０４、２０５、特定の外部サービス２２０、および外部アプリケーション２０８も含むことができる。重要なことに、ＪＳＬＥＥサーバ２００は、各クライアント・コンポーネントの実装に関する特定の知識がなくても、このように構成することができる。この難しい仕事を成し遂げるために、ＪＳＬＥＥサーバ２００は、コネクタ２１０を含むことができ、このコネクタはラッパ２１６と通信し、それによってコネクタ／ラッパ・インターフェースを形成することができる。ラッパ２１６は、コネクタ２１０に、プロトコル・スタック２０６などの特定のクライアント・コンポーネントとの抽象インターフェースを提供することができる。各コネクタ２１０は、対応するラッパ２１６によって提供される抽象インターフェースを介して、プロトコル・スタック２０６などの対応するクライアント・コンポーネントと通信するように構成することができる。
【００６３】
したがって、一般に、ＪＳＬＥＥサーバ２００は、プロトコル・スタック２０６などの基本となるクライアント・コンポーネントの実装の詳細に関係なく、コネクタ／ラッパ・インターフェースを介してイベントを総称的に送受信することができるが、ラッパ２１６だけは基本となるプロトコル・スタック２０６の実装の詳細に関する特定の知識を必要とする。本発明の一態様では、個々のラッパ２１６を指定することができるＪＳＬＥＥディスクリプタ２１４を含めることができ、対応するコネクタ２１０をこのラッパと通信するように構成することができる。
【００６４】
特に、ＪＳＬＥＥサーバ２００は、始動時、ＪＳＬＥＥディスクリプタ２１４を読み取り、指定された各ラッパ２１６の識別について知ることができる。次いで、ＪＳＬＥＥサーバ２００は、コネクタ２１０を、指定されたラッパ２１６と通信するように構成することができる。同様に、クライアント・コンポーネント・ディスクリプタ２１２を、各コネクタ２１０ごとに提供することができる。クライアント・コンポーネント・ディスクリプタ２１２は特定のイベントを指定することができ、そのイベントについては、プロトコル・スタック２０６などの関連するクライアント・コンポーネントにＪＳＬＥＥサーバ２００のイベント・ルーティング・バス２１８を介して通知することができる。
【００６５】
図６は、統合ネットワークのアプリケーション実行環境内のクライアント・コンポーネントにＳＬＥＥを通信可能にリンクする方法を示すフローチャートである。この方法は、ブロック６０２で、ＳＬＥＥをロードして開始することができる。ブロック６０４で、ＳＬＥＥディスクリプタをロードすることができる。判断ブロック６０６で、クライアント・コンポーネントが指定されている場合、ブロック６０８で、コネクタ・インスタンスを生成し、それを指定されたクライアント・コンポーネントに関連するラッパと通信するように構成することができる。ブロック６１０で、構成されたコネクタに関連するサブスクリプション・ディスクリプタをロードすることができ、ブロック６１２で、サブスクリプション・ディスクリプタにリストされているイベントを受信するために、指定されたクライアント・コンポーネントをＳＬＥＥ内のイベント・ハンドラに登録することができる。
【００６６】
次いで、判断ブロック６１４で、追加のクライアント・コンポーネントがＳＬＥＥディスクリプタにリストされている場合、追加のコネクタ・インスタンスを、ブロック６０８から６１２に従って生成し構成することができる。最後に、すべてのコネクタ・インスタンスが生成および構成されると、ブロック６１６で、ＳＬＥＥを開始し、個々のクライアント・コンポーネントごとの基本となる実装に関係なく、コネクタ／ラッパ・インターフェースを介して登録済みクライアント・コンポーネントにイベントをルーティングすることができる。その結果、ＳＬＥＥは、各クライアント・コンポーネントに関する特定の知識を必要とせずに、クライアント・コンポーネント・ラッパを介して、クライアント・コンポーネントに通信可能にリンクすることができる。
【００６７】
本発明は、ハードウェアでも、ソフトウエアでも、またはハードウェアとソフトウエアの組合せにおいても実現することができる。本発明による電話サービス提供方法は、１つのコンピュータによる集中方式でも、異なる要素が相互接続された複数のコンピュータに広がる分散方式でも実現することができる。どんな種類のコンピュータ・システム、すらわち本明細書に記載した方法を実施するように適合された他の装置にも適している。ハードウェアとソフトウェアの通常の組合せは、ロードされ実行されたとき、本明細書に記載した方法を実施するようにコンピュータ・システムを制御するコンピュータ・プログラムを有する汎用コンピュータ・システムとすることができる。
【００６８】
本発明は、本明細書に記載した方法の実装を可能にするすべての機能を備え、コンピュータ・システムにロードされたとき、こうした方法を実施することができるコンピュータ・プロダクトに組み込むこともできる。コンピュータ・プログラム、すなわち本発明との関連におけるコンピュータ・プログラムは、情報処理能力を有するシステムに、直接に、またはａ）別の言語、コードまたは表記への変換、ｂ）異なる材料形式への複製のうちの一方または両方を行った後に、特定の機能を実行させるための１組の命令に関する、任意の言語、コード、または表記による任意の表現を意味する。
【図面の簡単な説明】
【００６９】
【図１】従来技術において周知の従来型のＪＡＩＮ実装に従って構成されたインテリジェント・ネットワーク・アーキテクチャの概略図である。
【図２】サービス論理実行環境（ＳＬＥＥ）を含めたインテリジェント・ネットワーク・アーキテクチャの概略図である。
【図３】図２のＳＬＥＥ内で実行するように構成された電話サービス・コンポーネントの細部を示す図である。
【図４】図２のＳＬＥＥ内で実行するように構成された総称サービス・コンポーネントの細部を示す図である。
【図５】図２のインテリジェント・ネットワーク・アーキテクチャのアプリケーション層のサービス・アプリケーションにアクセスするように構成された総称サービス・コンポーネントの集合体を示すブロック図である。
【図６】コネクタ／ラッパ・インターフェースを介して、クライアント・コンポーネントと図２のＳＬＥＥの間で通信リンクを確立する方法を示すフローチャートである。




【国際調査報告】
2004537886.tif 000044
2004537886.tif 000045
2004537886.tif 000046