JP2006502493A - サービス統合システムのための方法およびシステム - Google Patents

Abstract

新しいサービスを開発して既存のネットワークにそれらを統合するためのオープンな環境を提供する、ソフトウェアによって実施される分散型のサービス統合システムであって、統合は、サービスの開発の責務も負うサービス統合システムの管理者によって実行される。従って、新しいサービスの開発及び統合の手順が、電話サービス統合システムにおける一般的な手順よりも短くかつ安価である。既存のネットワークインフラストラクチャに統合される新しいサービスの例として、通信業者の課金インフラストラクチャを使用する高度な課金サービスをサービス開発者が開発することが挙げられる。また、本発明のシステムでは、システム管理者によって定義される修正可能なポリシーを通じて、サービス統合システムの中と、サービス統合システム及び通信ネットワークの間と、の両方においてパケットの流れがサービスレベルで制御される。本発明のシステムでは、システム上に配置されるサービスへのシグナリングプロセスの可視性も提供され、ネットワーク適合化コンポーネントによってＩＰやＳＳ７などのさまざまなプロトコルと直接通信することができる。

Description

本発明は、一般的には、通信ネットワークサービスに関する。より詳細には、本発明は、アプリケーションサーバーとして実施され、ネットワークサービスの配置（deployment）、実行、および管理を可能にする、通信ネットワーク用の分散型サービス統合システムに関する。

最近のサービス統合／実行システムは、ネットワークセッション中にユーザーに何らかの特殊な機能を提供する高度なネットワークサービスをユーザーに提供することができる。ネットワークセッションは、開始イベントによって始まり終了イベントによって終わる一連のイベント群であり、例えば、電話の呼やＷｅｂサイトへのアクセスなどである。

サービスの実行を伴うセッションが開始されるとき、送られるデータの基本タイプは最大３種類ある、すなわち、セッション処理データと、伝送される実際のメディア（例：音声、映像、ストリームなど）と、サービスに関するデータである。

サービスに関するデータには、サービスの起動を求めるトリガーまたは要求が含まれる。サービスの使用をサポートするネットワークには、これらのトリガーおよび要求を認識する責務を負うコンポーネントが存在する。サービスを実行する必要があることをこれらのコンポーネントが認識すると、必要なサービスの実行および提供に必要な情報がサービス統合システムに伝えられる。

サービス統合システムは、一般には２つの主機能を有するものとして記述することができ、２つの主機能とは、（ａ）さまざまなサービスのサービスロジックがインストールされているアプリケーション機能と、（ｂ）さまざまなベンダー（通常はＡｌｃａｔｅｌ、Ｎｏｒｔｅｌ、Ｅｒｉｃｓｓｏｎなどの主要な機器ベンダーによって開発される、さまざまなサービスによって使用される一連の汎用プラットフォーム機能、である。

サービス統合システムは、通信ネットワークによってサポートされるサービスの実行および管理の責任を負い、特定のネットワークがどのサービスを提供するかを定義する。現時点では、これらのコンポーネントは特定のプロバイダ（上述したように通常は主要な通信機器ベンダー）によって提供されている。

現在のサービス統合技術には、実用上の問題点がいくつかの存在する。第一に、現在の技術では、通常、閉じた独自の（closed, proprietary）システムが提供される（すなわち、新しいサービスの追加および配置は、これら独自のシステムのプロバイダのみが行うことができる）。この結果として、新しいサービスの追加とその配置は、時間および費用が非常にかかるタスクとなる。例えば、ユーザーが自身のネットワークに新しいサービスを追加しようとする場合、先行技術によれば、そのユーザーはシステム統合システムのプロバイダに連絡して、新しいサービスの開発および配置を要求する必要がある。このことは、最も基本的なサービスを除いて、要求するサービスすべてに当てはまる。例えば、電話網に関する限りは、あるサービスが要求された時点からそのサービスが運用されるまでには２年以上もの月日が経過することがあり、このように期間が長く手続きが複雑である結果として、サービスが非常に高価にもなる。先行技術によるサービス統合システムが閉じていることに起因する別の２つの結果として、（ｉ）標準的なソフトウェアベースの開発ツールを使用することができないこと、（ｉｉ）ネットワーク内の他のコンポーネントとの統合が複雑であること、があげられる。

従って、アプリケーションサーバーとして実施される、ソフトウェアベースのオープンなサービス統合システムであって、先行技術のサービス統合システムの前述した欠点に対処するようにされており、電話網、ＩＮネットワーク、ＩＰネットワーク、ハイブリッドネットワーク（すなわち各種の通信システムを組み合わせたネットワーク）などの各種の通信ネットワークと連携して動作することのできるサービス統合システム、を提供することが望まれている。

従って、本発明の主な目的は、オープンな環境を提供するサービス統合システムを提供することである（すなわち新しいサービスを開発すること、それらを既存のネットワークへ追加すること、およびそれらを既存のネットワークと統合することとが、サービス統合システムの管理者によって行われ、管理者がサービスの開発の責務も負う（「サービス開発者」または「システム管理者」））。この結果として、新しいサービスの開発および統合の手順が比較的短くなりかつ安価になる。

本発明のさらに別の目的は、既存のネットワークインフラストラクチャに統合される新しいサービスを開発できるようにする（例：通信業者の課金インフラストラクチャを使用する高度な課金サービスをサービス開発者が開発する）ことである。

本発明のさらに別の目的は、サービス統合システムの中と、サービス統合システムと通信ネットワークとの間、の両方のパケットの流れを制御および管理するコンポーネントであって、管理が、システム管理者によって定義される修正可能なポリシーに従って実行される、コンポーネント、をサービス統合システム内に実装するとである。

本発明のさらに別の目的は、システム管理者がコンポーネントを構成することのできるサービス統合システムを実施することである。

本発明のさらに別の目的は、通信ネットワークに固有なサービス統合システムであって、シグナリングプロセスの良好な可視性および制御性を可能にするサービス統合システム、を実施することである。

本発明のさらに別の目的は、サービス統合システムがネットワーク適合化コンポーネントによってＩＰ、ＳＳ７などのさまざまなプロトコルと直接通信できるようにすることである。

本発明の好ましい実施形態によると、ソフトウェアによって実施される（すなわちソフトウェアが専用マシン上ではなくコモディティ（commodity）コンピュータ上で実行される）、通信ネットワーク用の分散型サービス統合システムであって、サービス統合システムを含みその管理及び制御を実行するさまざまなモジュールを管理および制御する少なくとも１つのモジュールと、ネットワークからのメッセージの受信とネットワークへのメッセージの送信を行う少なくとも１つのモジュールと、少なくとも１つのサービスロジック実行環境モジュールと、サービス統合システムのコンポーネントの間並びにサービス統合システム及びネットワークの間の両方のデータの流れを最適化する少なくとも１つのリソース制御モジュールであって、サービスの追加と、サービスの配置と、サービスの実行と、のうちの少なくとも１つを行うことができるように、ネットワークからのメッセージの受信とネットワークへのメッセージの送信を行う少なくとも１つのモジュールと、サービスロジック実行環境モジュールとに少なくとも接続されている、リソース制御モジュールと、を備えている、サービス統合システム、が提供される。

本発明のさらなる特徴および利点は、以下の詳細な説明と添付の図面とから明らかになるであろう。

本発明をより完全に理解することができるように、模範的な実施形態について添付の図面を参照しながら以下に詳しく説明する。これらの実施形態は一例であり、本発明を制限するものではない。

図１を参照する。この図は、本発明のサービス統合システムの模範的な実施形態を開示しており、このシステムは、「ＴａｐｐＳ」１０として知られており、通信ネットワーク用の分散型サービス統合システムである。ＴａｐｐＳ１０は、ソフトウェアによって実施される（すなわち本発明のサービス統合システムは、専用マシン上ではなくコモディティコンピュータ上で実行されるソフトウェアである）。この方式において、ＴａｐｐＳ１０では、既存のネットワークサービスを配置し、実行し、管理することと、新しいネットワークサービスを作成することとが可能であり、これらのことは先行技術においては現時点では可能ではない。

本明細書に説明する模範的な実施形態によると、ＴａｐｐＳ１０は、分散型アーキテクチャを使用し、少なくとも１つのマネージャモジュール１２と、少なくとも１つのコントローラモジュール１４と、少なくとも１つのサービスロジック実行環境モジュール（「ＳＬＥＥ」）１６と、少なくとも１つのリソース制御層モジュール（「ＲＣＬＣ」）１８と、少なくとも１つの機能モジュール要素４２と、少なくとも１つのゲートウェイモジュール４０と、少なくとも１つのネーミングサービスモジュール２２と、を有する。機能モジュール要素４２とゲートウェイモジュール４０は、両方をまとめてネットワークアダプタ２０と称する。

本発明の模範的な実施形態によると、上述したモジュールのそれぞれは、異なる計算ステーション（「コンピュータ」）として実施される。本発明の代替実施形態によると、上述したモジュールの１つまたは複数は同じコンピュータを共有する。使用する実施形態の選択は、モジュールのそれぞれのリソースの使用状況と、本発明を使用するネットワークの規模と、ネットワークのトラフィックレートとに依存する。

ＴａｐｐＳ１０のさまざまなコンポーネント間の通信は、一般には「ＣＯＲＢＡ」と称される共通オブジェクトリクエストブローカーアーキテクチャ（ＣＯＲＢＡ：Common Object Request Broker Architecture）によって実行される。機能モジュール要素４２とＲＣＬＣ１８との間など、高い伝送率が要求される接続は、ＴａｐｐＳ１０に独自のプロトコルによって実行される。これら独自のプロトコルは、ＴＣＰやＵＤＰなどの標準的なネットワークプロトコルによって伝送される。より具体的には、ＳＬＥＥ１６とＲＣＬＣ１８との間、ＲＣＬＣ１８とネットワークアダプタ２０との間、およびＲＣＬＣ１８とネーミングサービス２２との間の通信では、その方向のみにおいて、ＴａｐｐＳ１０の独自のプロトコルが使用される。それ以外のすべての通信では、ＣＯＲＢＡ ＩＩＯＰ（Internet Inter ORB protocol）が使用される。

ＴａｐｐＳ１０の上述したモジュールとその機能について、以下に要約しておく。

マネージャ１２は、インタフェースであり、システム管理者は、ＴａｐｐＳ１０を含んでいる複数のモジュールのそれぞれをこのインタフェースを使用して構成することができ、これについては後から説明する。マネージャ１２は、コントローラ１４にアクセスし、ＴａｐｐＳ１０のモジュールを構成するようにコントローラ１４に命令することによって、さまざまなＴａｐｐＳ１０のモジュールを構成する。マネージャ１２は、システム管理者がグラフィカルユーザーインタフェースを使用して動作させる。

コントローラ１４は、ＴａｐｐＳ１０のさまざまなモジュールを監視および維持管理する。コントローラ１４は、機能不良を特定し、冗長性の処理を行い、耐障害性を提供し、ＴａｐｐＳ１０を含んでいる複数のモジュールのうちダウンしているかまたは機能不良のモジュールがあれば置き換えるかリスタートさせる。また、コントローラ１４は、新しいバージョンのリリースの場合にＴａｐｐＳ１０のさまざまなシステムモジュールのアップグレードを行い、この場合、コントローラ１４は、自身を除くＴａｐｐＳ １０のすべてのモジュールを置き換えることができる。コントローラ１４を置き換える必要がある場合、その置き換えはマネージャ１２によって行われる。

コントローラ１４によるモジュールのリスタートは、システム管理者が行うか、またはモジュールをリスタートさせる必要があること（例えばモジュールがクラッシュしたとき）をコントローラ１４が検出したときにコントローラ１４によって自動的に行わせることができる。

図２を参照する。ＳＬＥＥ１６は、ＴａｐｐＳ１０によって提供されるサービスが実行される環境を提供するモジュールである。サービスは、ステートマシンをモデル化するプログラムコードから成る、サービス開発者によって開発されたアプリケーションを含んでいる。ＳＬＥＥ１６は、少なくとも１つのステートマシンコントローラ３０と、少なくとも１つのメモリモジュール２４と、少なくとも１つの実行可能ステートマシン２８とを備えており、実行可能ステートマシン２８は、少なくとも１つのステートマシン２９をさらに備えている。

ＳＬＥＥ１６では、さまざまなネットワークサービス２６のサービスロジックがメモリ２４に格納される。さまざまなサービス２６は、ステートマシンとして表されている。ＳＬＥＥ１６は、ＴａｐｐＳ１０によって提供されるさまざまなサービスを実行する責務を負う。各サービス２６は、ステートグラフによって表されており、ステートグラフ上の各ノードがサービス２６のステートを表す。ステートは、サービスを実行するときの方法に関する一組の値および命令と、実行中のサービスの後継のステートを解決する方法の一組の値および命令とをカプセル化した静的エンティティである。ステートグラフは、サービス２６の可能なノードすべてを定義し、従って、特定のサービス２６がその実行時にとることのできる経路すべてを記述する。２つのステート（またはノード）の間を結合している線分を、ステート遷移と称する。サービス２６の実行は、サービス２６を表すステートグラフのステートノードに沿って進むことによって行われる。サービス２６の実行の開始時には、サービス２６のステートノードをすべて集める必要はなく、なぜなら、第１のステートノードに続くステートノードのそれぞれは、実行されるときにサービス２６によって動的に解決されるためである。注意すべき点として、サービスの実行が開始されるときには、すべてのステートノードがメモリ内に存在している必要はないが、サービス２６を記述するステートグラフは、サービスの可能な分岐すべてを含んでおり、実行のステートには関係なく全体が存在する。

サービス２６（すなわちステートグラフ）は、実行可能ステートマシン２８によって実行される。実行可能ステートマシン２８は、ＴａｐｐＳ１０によって提供されるサービス２６を実行する汎用エンジンである。ＳＬＥＥ１６は、少なくとも１つの実行可能ステートマシン２８を備えている。

ＳＬＥＥ１６の２つの主要コンポーネントは、実行可能ステートマシン２８とステートマシンコントローラ３０である。ステートマシンコントローラ３０は、新しいサービス要求を待機している空いている実行可能ステートマシン２８を管理する。

ステートマシンコントローラ３０の主な責務は、入力される要求を受信し、要求されたサービス２６を表すステートグラフを取り出し、ステートグラフを実行を目的として空いている実行可能ステートマシン２８に割り当てる。ステートマシンコントローラ３０は、ＴａｐｐＳ１０によってサポートされる有効なサービス２６（すなわちステートグラフ）のすべてが格納されているメモリ２４の内容を管理する。ステートマシンコントローラ３０は、新しいサービスの要求を受信すると、合致するサービス２６をメモリ２４から取り出し、それを実行を目的として実行可能ステートマシン２８に割り当てる。割り当てが行われると、ステートマシンコントローラ３０は実行中のサービス３２とそれ以上は通信しない。ステートマシンコントローラ３０の二次的な責務は、実行中の実行可能ステートマシンオブジェクト２８の正しさの監視などのサービス要求の割り当ておよび実行に必要なリソースを維持することや、メモリの使用状況を監視することなどである。

実行可能ステートマシン２８は、１つのサービス２６の実行の責務を負う。実行可能ステートマシン２８と実行中のサービス３２との間には、ステートマシン２９である中間層が存在する。ステートマシン２９は、その中で実行可能ステートマシン２８がサービスを実行するコンポーネントである。

実行可能ステートマシン２８は、実行中のサービス３２と機能モジュール要素４２との間の接続も維持する。多くの場合、サービスによっていくつかの機能モジュール要素４２が必要となることがある。接続は、後から説明するようにＲＣＬＣ１８によって維持される。実行プロセスに沿って、実行中のサービス３２は、機能モジュール要素４２のタスクをポストする。これらのタスクには、現在のステートノードの実行に必要なデータが含まれている。実行中のサービス３２によってポストされたタスクを実行する機能モジュール要素４２の動作と、実行中のサービスの動作は、非同期である。この場合の非同期とは、実行中のサービス３２が、機能モジュール要素４２が実行すべきタスクを送信した後は、機能モジュール要素４２によって生成される結果を待たずに、サービス実行プロセスに関連する動作の実行を機能モジュール要素４２の動作と同時に続けるという意味である。

実行可能ステートマシン２８と機能モジュール要素４２との間の相互作用は、以下のとおりである。実行可能ステートマシン２８から機能モジュール要素４２にＲＣＬＣ１８によってタスクが送られる。機能モジュール要素４２によってタスクが完了すると、その結果が実行可能ステートマシン２８に送り返される。実行可能ステートマシン２８は、結果を受信し、現在のステートを維持しているステートマシン２９にその結果を割り当てる。ステートマシン２９は、結果を受信すると、サービス２６のステートグラフ上の次のステートノードを解決する目的で、実行中のサービス３２の現在のステートノードを伝える。

ＳＬＥＥ１６は、少なくとも１つの実行可能ステートマシン２８を持ち、本発明の模範的な実施形態によると、複数の実行可能ステートマシン２８を持ち、これらをプールと称する。ステートマシンコントローラ３０が新しいサービス要求を受信すると、実行可能ステートマシン２８のインスタンスが実行を目的として割り当てられる。割り当てられた実行可能ステートマシン２８は、サービス２６のステートグラフを取得し、完了するまでそのサービスを実行する。割り当てられた実行可能ステートマシン２８は、サービスの実行を終了すると、空いている実行可能ステートマシン２８のプールに解放され、プールの中で次の割り当てを待つ。サービスを実行中の実行可能ステートマシン２８のそれぞれは、自身の一意のリファレンス（reference）を有し、実行可能ステートマシン２８を宛先とするメッセージは、このリファレンスに従ってルーティングされる。実行可能ステートマシン２８へのこれらのメッセージのルーティングは、以下のように行われる。ＳＬＥＥ１６の外側のモジュールが、実行可能ステートマシン２８を宛先とするメッセージすべてをステートマシンコントローラ３０にルーティングする。これらの外部コンポーネントは、一般には「ＩＯＲ」（Interoperable Object Reference）と称されるＣＯＲＢＡアドレスに従ってステートマシンコントローラ３０の位置を認識し、ＣＯＲＢＡアドレスは、ステートマシンコントローラ３０がその開始時にこれらの外部コンポーネントに伝える。実行可能ステートマシン２８の１つを宛先とするメッセージがステートマシンコントローラ３０に達すると、ステートマシンコントローラ３０は、そのメッセージに関連する実行可能ステートマシン２８にメッセージをさらにルーティングする。メッセージが新しいサービスの要求である場合、ステートマシンコントローラ３０は、合致するサービス２６をメモリ２４から解決し、空いている実行可能ステートマシン２８によって実行されるようにそれを割り当て（すなわちＳＬＥＥ１６の外側のモジュールはステートマシンコントローラ３０を「認識」しているのみであり、ステートマシンコントローラ３０が実行可能ステートマシン２８を「認識」している。）、これについては後からさらに説明する。

実行中のサービス３２のそれぞれは、その現在のステートと、その実行の次のステートを解決する方法とを認識している。現在のステートは、実行可能ステートマシン２８によって実行される。現在のステートの実行は、ＲＣＬＣ１８によって機能モジュール要素４２に送られるタスクによって終了する。機能モジュール要素４２は、タスクを実行し、この場合にもＲＣＬＣ１８を介して結果を実行可能ステートマシン２８に戻す。戻された結果は、これに従って実行中のサービス３２の次のステートが解決される入力である。

ＴａｐｐＳ１０では、サービス２６の決定論的な実行（deterministic execution）がサポートされる。各サービス２６は、最初のステートノードに定義されているクリティカルパスとデッドライン（deadline）とを持つ。サービスが実行可能ステートマシン２８に割り当てられると、その実行可能ステートマシン２８は、サービスの実行を開始する前にクリティカルパスおよびデッドラインを認識する。サービス２６の実行の間、これらの限界条件のすべてが満たされている必要があり、満たされないとサービス２６の実行が終了し、例外が破棄（thrown）される。この例外は、ステートマシンコントローラ３０が捕らえて処理する。

各サービス２６は、優先度を持つ。サービスの優先度は、実行を目的として実行可能ステートマシン２８に割り当てられる前にステートマシンコントローラ３０によって計算される。優先度は、サービスの推定実行時間と存続時間に基づいて計算される。

ＳＬＥＥ１６によるサービスの実行プロセスについて深く理解できるように、本発明の模範的な実施形態による代表的な実行のシナリオについて以下に説明する。サービスの実行は、入力されるサービス要求がＲＣＬＣ１８によってＳＬＥＥ１６に達したときに始まる。ステートマシンコントローラ３０は、このような入力されるサービス要求を調べ、サービスの実行プロセスを開始する。ステートマシンコントローラ３０は、要求されたサービスをメモリ２４の中で特定し、空いている実行可能ステートマシンのプールから選択される実行可能ステートマシン２８の空いているインスタンスに、実行を目的としてそのサービスを割り当てる。次のステップにおいて、実行可能ステートマシン２８がステートマシンコントローラ３０によって起動される。ステートマシンコントローラ３０は、実行可能ステートマシン２８に実行を目的としてサービス２６を割り当てることによって、実行可能ステートマシン２８を起動する。実行可能ステートマシン２８は、起動されると、新しいステートマシン２９のインスタンスを開始し、このインスタンスは、サービス２６のステートグラフの最初のステートノード３６を要求し、これによって実行プロセスが開始される。実行中のサービス３２のノード３６は、機能モジュール要素４２のタスクをポストし、機能モジュール要素４２から受信される結果を処理する。ステートノード３６と機能モジュール要素４２との間のこのトラフィックは、ＲＣＬＣ１８を介して実行される。実行可能ステートマシン２８は、機能モジュール要素４２からタスクの処理の結果を受信し、そのタスクを開始したステートノード３６にこれらの結果を渡す。次いで、ステートノード３６は、機能モジュール要素４２から受信した結果と、現在のステートにおいて利用可能な情報とを評価することによって、ステートグラフ上の次のステートノードを解決する。サービス２６のステートグラフの最後のステートノード３６に達し、これによってサービスの実行プロセスが終了するまで、実行は続く。実行が終了すると、ステートマシン２９が解放され、実行可能ステートマシン２８は空いている実行可能ステートマシンのプールに戻る。

ＳＬＥＥ１６のアーキテクチャに関しては、ＳＬＥＥ１６の外側からのリモート呼び出しを受信する２つのコンポーネントは、ステートマシンコントローラ３０と実行可能ステートマシン２８である。従って、本発明の模範的な実施形態によると、両方のコンポーネントのアーキテクチャは分散されている。これは、ＣＯＲＢＡによって実施される。従って、ＳＬＥＥ１６の中には、ＣＯＲＢＡに属する２つのオブジェクト、すなわちステートマシンコントローラ３０と実行可能ステートマシン２８とが存在する。ＳＬＥＥ１６を実行しているプラットフォーム（上述したように１つまたは複数のプラットフォームが存在することができる）ごとに、オブジェクトリクエストブローカー（ＯＲＢ）が実装されて実行されている。このＯＲＢのそれぞれは、ＳＬＥＥ１６に属する２つのコンポーネント、すなわちステートマシンコントローラ３０と実行可能ステートマシン２８とをＳＬＥＥ１６の中に持つ。ＯＲＢ環境では、ＳＬＥＥ１６に入力される通信はステートマシンコントローラ３０および実行可能ステートマシン２８に送られ、これらのコンポーネントにはＯＲＢ環境によって提供されるプールスレッディング（pool threading）や永続性（persistency）などのさまざまな機能が提供される。本発明の代替実施形態によると、Ｊａｖａプログラミング言語ライブラリの一部であるリモートメソッド呼び出し（「ＲＭＩ」）など、ＣＯＲＢＡ以外の分散型実施形態を使用することができる。

上述したように、ＳＬＥＥ１６からＲＣＬＣ１８へ発信される通信は、ＴａｐｐＳ１０の独自のプロトコルによって実行される。

図６を参照する。この図は、サービス実行プロセスの代表的なレイアウトを示している。図示したように、第１および第２の実行可能ステートマシン２８のそれぞれがサービスを実行している。実行中のサービスのそれぞれに対して、サービス２６の対応する実行コンテキストを表すステートマシンオブジェクト２９が存在している。サービスの実行の間、この場合にもＲＣＬＣ１８を通じてタスクが機能モジュール要素４２にポストされる。機能モジュール要素４２は、タスクを受信し、それを実行し、タスクの発行元である実行可能ステートマシン２８にＣＯＲＢＡ呼び出しを使用してその結果を送る。機能モジュール要素４２は、発行元である実行可能ステートマシン２８に応答を送る方法を、タスクと一緒に受信したＩＯＲに従って認識する。タスクには、ＩＯＲ以外に、現在のステート３６の定義に関するデータと、サービス２６を実行している実行可能ステートマシン２８のＩＤも含まれる。

本発明の模範的な実施形態によると、複数のステートマシンコントローラ３０と複数の実行可能ステートマシン２８とが使用される。本発明の代替実施形態によると、１つのステートマシンコントローラ３０のみが使用される。この理由は、ステートマシンコントローラ３０は再入可能オブジェクトであり、従って１つのインスタンスに複数の要求によってアクセスできるためである。

本発明の模範的な実施形態によると、ステートマシンコントローラ３０と実行可能ステートマシン２８の両方は、同じコンピュータ上で実行され、１つのＯＲＢと相互関係を持つ。機能モジュール要素４２は、上述したように別のコンピュータ上で実行することができる。これら３つのコンポーネントは、ＳＬＥＥ１６がその機能を果たすように動作させる責務を負う。ＲＣＬＣ１８は、フロー制御など機能以外の要件に責務を負うコンポーネントである。

図４を参照する。ネットワークアダプタ２０は、２つの主モジュールを有する。１つはゲートウェイモジュール４０であり、もう１つは機能モジュール要素４２である。ゲートウェイモジュール４０は、サーバーとして実施されており、ＳＳ７やＩＰなどネットワークインタフェース上の入力メッセージをリスンする。

ゲートウェイモジュール４０によって受信されるメッセージは、サービス要求と外部タスクとに分類される。サービス要求は、ネットワークから受信される、新しいサービスの実行の外部要求であり、従って、新しいサービスの実行につながる。これに対して、外部タスクは、すでに実行中のサービスに関連する外部メッセージであり、従って新しいサービスの実行にはつながらず、すでに実行中のサービス３２に送られる。これらの外部タスクは、例えばＳＬＥＥ１６が発行元であるタスクなど、ＴａｐｐＳ１０自体の中から発行されて上述のタスクとは異なり、機能モジュール要素４２を宛先として送られる。

機能モジュール要素４２は、ＳＬＥＥ１６から受信したタスクを処理することと、処理の結果と一緒に各種のネットワークプロトコルをさらに伝えることの責務を負う。

機能モジュール要素４２は、基本的な構成ブロックであり、少なくとも１つの機能モジュールマネージャ４４と、サービスを実施する目的に使用される少なくとも１つの機能モジュール４６とを備えている。サービスは、一連の機能モジュール要素４２を呼び出すことによって実施される。機能モジュール要素４２によって実行される動作の１つの例は、データベースへの問い合わせをポストすることである。例えば、実行中のサービス３２によってあるデータが必要になると、実行中のサービス３２はそのデータの要求を機能モジュール要素４２に伝える。機能モジュール要素４２にアドレッシングされている他の要求は、他の要素とともに、タスクと総称される。タスクには、問い合わせを実行するのに必要なパラメータが含まれている。機能モジュール要素４２は、タスクを受信すると、適切なネットワークにアクセスして問い合わせを行う。問い合わせの結果は、ゲートウェイコンポーネント４０によって受信され、ＳＬＥＥ１６内の実行中のサービス３２のアドレスに関してネーミングサービス２２に尋ねた後、（実行中のサービス３２によって使用されるように）ＳＬＥＥ１６に送られる。

本発明の模範的な実施形態によると、いくつかのタイプの機能モジュール４６が存在し、それぞれが、ＴａｐｐＳ１０によってサポートされる各プロトコルを伝える。

上述したさまざまなタイプのメッセージは、ＲＣＬＣ１８を介して機能モジュール要素４２に伝送される。

機能モジュール要素４２の中のコンポーネントのうち、ＲＣＬＣ１８から要求を受信するコンポーネントは、機能モジュールマネージャ４４である。機能モジュールマネージャ４４は、タスクを処理する責務を負う機能モジュール４６とＲＣＬＣ１８との間のインタフェースの役割りを果たす。特定のタイプの機能モジュール４６のすべてのインスタンスは、１つの機能モジュールマネージャ４４によって制御され、従って、特定のプラットフォーム上の各タイプの機能モジュールに対して１つの機能モジュールマネージャ４４が存在する。本明細書に説明した模範的な実施形態によると、機能モジュール４６のインスタンスと、これらを制御する機能モジュールマネージャ４４は、いずれも同じコンピュータ上に位置している。機能モジュール４６のインスタンスは、プールの形式において機能モジュールマネージャ４４によって管理される。機能モジュールマネージャ４４は、同じタイプの機能モジュール４６のインスタンスすべてのリファレンスのリストを保持し、これらのインスタンスと絶え間なく連絡する。従って、機能モジュールマネージャ４４は、機能モジュール４６のインスタンスのうちどのインスタンスが空いているかを常に認識している。

機能モジュールマネージャ４４は、特定のマシン上に存在する機能モジュール４６のインスタンスの数も制御する。既存の機能モジュール４６の数は、機能モジュールマネージャ４４が受信するタスクの負荷に従って決定される。機能モジュールマネージャ４４は、必要な場合に、機能モジュール４６のインスタンスの作成、削除、起動、およびシャットダウンを行う。機能モジュールマネージャ４４は、発行待ちである未発行の要求の短いキューも管理する。

機能モジュールマネージャ４４がタスクを受信すると、最初に行うことは、空いている機能モジュール４６のインスタンスにそのタスクをルーティングすることである。そのような空いているインスタンスが存在しない場合、タスクは未発行要求のキューに転送され、機能モジュール４６のインスタンスの数のバランスをとるために使用される方法が呼び出される。

それらのタスクは、機能モジュール４６のインスタンスによる実行を目的として機能モジュール４６のインスタンスに割り当てられる。実行が終了すると、機能モジュール４６のインスタンスのステートはアイドルに変化し、アイドルとは、さらなるタスクの実行用に空いていることを意味する。

タスクの各実行の最後に、機能モジュールマネージャ４４は、機能モジュール４６のインスタンスのバランスをとるために使用される上述した方法を呼び出す。この方法は、現在の負荷とタスクのポスト率とを調べ、それに応じて機能モジュール４６のインスタンスの数を低減または増加させる。

上記の呼び出しに加えて、機能モジュールマネージャ４４は、既存の機能モジュール４６のインスタンスの数に関連する機能モジュール４６のインスタンスに対する負荷と、それらを実行しているプラットフォームの一般リソース（例：Ｉ／Ｏ、ＣＰＵ、メモリなど）に対する負荷とに関して、ＲＣＬＣ１８に通知する。

空いている機能モジュール４６にタスクが割り当てられると、その機能モジュール４６はタスクを実行する。機能モジュール４６は、タスクを実行する目的で、必要であればＴａｐｐＳ１０の外側のデバイス（ネットワークインタフェースカードなど）に接続する。

一般的な原則として、機能モジュール４６は、以下の３層から構築されている。（ｉ）インタフェース層：機能モジュール４６が別のコンポーネントと情報をやりとりするときに使用する。（ｉｉ）ロジック層：機能モジュール４６の実際のサービスロジックを提供する。サービスロジックは、機能モジュール４６の各タイプごとに個別に実装されている。（ｉｉｉ）ハードウェア適合化層：ネットワークインタフェースカードなどのハードウェアを使用するタイプの機能モジュール４６にのみ存在する。この第三層は、ロジック層がその機能モジュールに関連するハードウェアと通信するときに使用する。ベンダーの独立性を維持する目的で、異なるタイプのハードウェアデバイスと接続する機能モジュールは、それぞれ独立して実装されているハードウェア適合化層を有する。

機能モジュールマネージャ４４とＲＣＬＣ１８は、独自のネットワークプロトコルを介して接続されている。２つのコンポーネントの間の接続は、ネーミングサービス２２に尋ねることよって作成される。各機能モジュール４６は、作成されると、対応するＲＣＬＣ１８の位置とその指定ポートとをネーミングサービス２２に尋ねる。新しく作成された機能モジュール４６は、これらのデータを取得すると、自身の存在をＲＣＬＣ１８に通知する目的でＲＣＬＣ１８に連絡する。

同様に、新しく作成されたＲＣＬＣ１８は、作成されると、既存の機能モジュール４６すべての位置をネーミングサービス２２に尋ね、それらに接続する。連絡が行われると、ＲＣＬＣ１８と機能モジュール４６との間の後続するすべてのトラフィックは、所定のプロトコルを使用して特定のポートを通じて行われる。接続が確立されると、機能モジュール４６は、そのポートを絶え間なくリスンするスレッドを開き、このスレッドは、ＲＣＬＣ１８から送られる要求を識別する。

上述したタスクの形式以外のさまざまなタイプのイベントは、時間によってトリガーされるイベントであり、例えば、ＲＣＬＣ１８に機能モジュール要素４２の中の負荷を調べさせるイベントや、機能モジュール要素４２にその負荷ステータスをＲＣＬＣ１８に通知させるイベントである。時間によってトリガーされるこれらのイベントは、時間によってトリガーされるイベントを識別して必要な方法を呼び出す別のスレッドによって処理される。

ＲＣＬＣ１８の主な機能は、ＴａｐｐＳ１０の中のトラフィック負荷と、ＴａｐｐＳ１０及びネットワークの間のトラフィック負荷とを監視することである。ＲＣＬＣ１８は、これらの負荷のステータスを常に認識しており、ＴａｐｐＳ１０によって提供されるさまざまなサービスのリソース消費挙動を学習し、入力および出力されるメッセージのトラフィックをそれに応じて送る。また、ＲＣＬＣ１８は、システム管理者によって事前に設定される所定のポリシーに従って動作する。例えば、システム管理者は、ＴａｐｐＳ１０によって提供されるさまざまなサービス２６の重要度に関する特定の優先度を定義することができ、これによって、重要度の高いサービス２６の実行は、重要度の低いサービス２６の実行よりも優先される。

ネーミングサービス２２は、ＳＬＥＥ１６のコンピュータおよびそれらのＩＯＲのリストと、その中で現在実行中のサービスのリストを維持する。ネットワークからメッセージが到着すると、ゲートウェイ４０は、入力されたメッセージをルーティングすべき宛先についてネーミングサービス２２に尋ねる。ネーミングサービス２２は、メッセージをルーティングすべき先の正しいＳＬＥＥ１６のＩＯＲをゲートウェイ４０に戻す。ＴａｐｐＳ１０の他のコンポーネントも、上記方法と同じようにルーティング情報についてネーミングサービス２２に問い合わせを行う。

上述したように、ＴａｐｐＳ１０は、新しいサービスを通信ネットワークに追加し、サービスを配置し、通信ネットワークから受信したサービス要求を処理する機能を持つ。以下に、ＴａｐｐＳ１０がサービス要求を処理するときの方法について概説する。

特定のセッションにおいてサービスの実行が必要であることがネットワークによって認識されると、その必要なサービスの提供を要求するメッセージがＴａｐｐＳ１０に送られる。

ＴａｐｐＳ１０の中のコンポーネントのうち、入力されるメッセージを検出する責務を負うコンポーネントは、ゲートウェイ４０である。メッセージは、新しいサービス要求か、すでに実行中のサービスに関連する外部イベントのいずれかとすることができる。メッセージがＴａｐｐＳ１０によって受信されると、ゲートウェイ４０はネーミングサービス２２に尋ねて、メッセージが実行中のサービスに関連するのか新しいサービス要求であるのかを認識する。メッセージがすでに実行中のサービスに関連する外部イベントである場合、その実行中のサービス３２の位置が取得され、外部イベントが、ＳＬＥＥ１６の中で実行されている実行中のサービス３２によって使用されるパラメータとしてＲＣＬＣ１８を介して送られる。メッセージが新しいサービス要求である場合、ＲＣＬＣ１８を介してＳＬＥＥ１６に送られ、ＳＬＥＥ１６において、要求されたサービス２６が解決され、サービスの実行が開始される。ＳＬＥＥ１６の中で実行されている実行中のサービス３２は、ネットワークから到着する、外部イベントであるメッセージを受信すると、これらの外部イベントを処理し、この場合にもＲＣＬＣ１８を介して機能モジュール要素４２にタスクを送り返す。機能モジュール要素４２は、これらのタスクを処理し、その結果は２つの結果の一方、すなわち、機能モジュール要素４２のステートが変化するか、１つ以上のネットワークメッセージが実行中のサービス３２に送り返される、のいずれかとなる。一般的なシナリオでは、タスクが実行されることに起因して、１つの以上のメッセージがネットワーク若しくは実行中のサービス、またはその両方に送られる。機能モジュール要素４２は、メッセージをネットワーク若しくは実行中のサービス、またはその両方に送った後、ネットワークからの応答、若しくは実行中のサービス３２からの新しいタスク、またはその両方を受信する。このプロセスは、サービスの実行が終了するまで発生する。

ＴａｐｐＳ１０によってサービス２６を実行するための必要条件は、必要なサービス２６がＴａｐｐＳ１０と一緒に配置されていることである。ＴａｐｐＳ１０では、サービス開発者は、ネットワークのユーザーによって要求されてＴａｐｐＳ１０によって実行される新しいサービス２６を開発および配置することができる。本発明によると、新しいサービスの開発は、高水準コンピュータ言語（例：Ｊａｖａなど）によって達成される。ＴａｐｐＳ１０では、システム管理者にアプリケーションプログラミングインタフェース（「ＡＰＩ」）が提供され、新しいサービスのソースコードはこのＡＰＩに基づいて開発される。新しいサービスの開発が終了すると、ソースコードがコンパイルされ、コンパイル後、コントローラ１４によってバイナリコードがＳＬＥＥ１６に伝送される（システム管理者がマネージャ１２を使用してコントローラ１４を動作させて新しいサービスを配置する。マネージャ１２は、上述したようにシステム管理者にＴａｐｐＳ１０へのＧＵＩを提供する）。続くステップでは、バイナリコードが、Ｊａｖａのクラスローディング機能（動的にロードされるライブラリと同様である）を使用してＳＬＥＥ１６にリンクされる。これらのステップの後、新しいサービスは、システム管理者によって起動することができ、ＴａｐｐＳ１０のすべての機能にアクセスできる。

サービスは、配置されるとＳＬＥＥ１６内のメモリ２４に追加され、この時点で、ＴａｐｐＳ１０によって提供される有効なサービスとなり、従って実行できる状態となる。

上記に開示した内容は、すべて、ＴａｐｐＳ１０に独自の機能を与えるものである。これらの機能の１つは、少なくとも１つの呼び出し制御セッションおよび他のセッション（例：Ｗｅｂセッション、データベース接続）から１つのセッションを作成することである。さらに、ＴａｐｐＳ１０の分散型アーキテクチャでは、高い耐障害性、高いパフォーマンスレベル、大容量を処理できる能力などの特性を達成するうえでの必要に応じて、その要素のすべてを複製することが可能である。ＴａｐｐＳ１０はネットワークでもあり、電話網に関してはプロトコルに依存しない（すなわち、ＩＮＡＰを介したＰＳＴＮ、ＩＳＵＰを介したＰＳＴＮ、またはＳＩＰを介した次世代ネットワークにおいて、コードを変更することなく同じサービスを実行することができる）。さらに、特に述べておくべき点として、先行技術のいくつかのサービス統合システムのように、ＴａｐｐＳ１０は電話網に限定されず、従って、例えば、ＨＴＴＰ要求やＲＡＤＩＵＳ認証要求、または他のプロトコルによるものなど、電話以外のイベントに応答してサービスセッションを開始することができる。ＴａｐｐＳ１０の注目すべき別の特徴は、ＴａｐｐＳ１０では、すべてのアクティブセッションによって消費されているリソースの完全なビューが保持されることであり、従って、（ＴａｐｐＳ１０のシステム内の）内部リソースと外部リソース（ネットワーク帯域幅など）の両方についてリソース消費量を優先的に割り当てたり抑圧したりすることができる。ＴａｐｐＳ１０のシステムの中と、ＴａｐｐＳ１０のシステム及びネットワークの間と、の両方について決定論的なトラフィック制御も可能にするのは、さらなる特徴である。

最後になるが、当然ながら、本発明の模範的な実施形態の上述の説明は、単なる一例であることを理解されたい。当業者は、模範的な実施形態の多数の変形および修正を行うことができ、それらについても、添付される請求項の参照によって定義される本発明の精神および範囲に依然として含まれる。

本発明の構造と、そのコンポーネントの間並びにコンポーネント及びネットワークの間の論理的な関係とを示す概略ブロック図である。 本発明の模範的な実施形態によるサービスロジック実行環境を示す概略ブロック図である。 本発明の模範的な実施形態によるサービス実行プロセスのレイアウトを示すフロー図である。 本発明のシステムのネットワークアダプタと、そのコンポーネント及び本発明の他のコンポーネント（いずれも本発明の模範的な実施形態による）の間の論理的な関係と、を示す概略ブロック図である。

Claims (26)

1. アプリケーションサーバーとして実施される、通信ネットワーク用の分散型サービス統合システムであって、
   （ａ）前記サービス統合システムを管理および制御する少なくとも１つのモジュールであって、前記サービス統合システムを含んでいる前記モジュールのそれぞれと、これらの管理および制御を実行する目的で相互作用する、モジュールと、
   （ｂ）ネットワークからのメッセージの受信とネットワークへのメッセージの送信を行う少なくとも１つのモジュールと、
   （ｃ）少なくとも１つのサービスロジック実行環境モジュールと、
   （ｄ）前記サービス統合システムの前記コンポーネントの間と、前記サービス統合システム及び前記ネットワークの間と、の両方のデータの流れを最適化する少なくとも１つのリソース制御モジュールであって、ネットワークからのメッセージの受信とネットワークへのメッセージの送信を行う前記モジュールと、前記サービスロジック実行環境モジュールとに少なくとも接続されている、リソース制御モジュールと、
   を備えており、
   上記の前記モジュールのすべてが、それらの各機能を実行する目的で、必要な対応するハードウェア機器と相互作用する、
   サービス統合システム。
2. 前記サービス統合システムを管理および制御する前記少なくとも１つのモジュールが、前記サービス統合システムを管理する少なくとも１つのモジュールと、前記サービス統合システムを制御する少なくとも１つのモジュールとに分離されている、請求項１に記載のサービス統合システム。
3. ネットワークからのメッセージの受信とネットワークへのメッセージの送信を行う前記少なくとも１つのモジュールが、少なくとも１つのゲートウェイモジュールと、少なくとも１つの機能モジュール要素とに分離されている、請求項１に記載のサービス統合システム。
4. 前記サービス統合システムが、ネットワークサービスの非同期実行をサポートする、請求項１に記載のサービス統合システム。
5. 前記分散型アーキテクチャは、前記サービス統合システムを含んでいる前記要素を複製して、
   （ａ）耐障害性と、
   （ｂ）パフォーマンスと、
   （ｃ）容量と、
   から成る群から選択される少なくとも１つを提供することが可能である、請求項１に記載のサービス統合システム。
6. 前記サービス統合システムが、処理されているセッションすべてによって消費されているリソースを絶え間なく認識している、請求項１に記載のサービス統合システム。
7. 前記サービス統合システムが、前記サービス統合システムによって処理されているさまざまなセッションに割り当てられているリソースの量を制御する、請求項１に記載のサービス統合システム。
8. 前記ＴａｐｐＳ１０のシステムの中と、前記ＴａｐｐＳ１０のシステム及び前記ネットワークの間と、の両方において決定論的なトラフィック制御が可能である、請求項１に記載のサービス統合システム。
9. 前記ネットワークが、時間依存トラフィックを伝送するリアルタイム通信ネットワークである、請求項１に記載のサービス統合システム。
10. 前記ネットワークがデータ通信ネットワークである、請求項１に記載のサービス統合システム。
11. 前記ネットワークが、少なくとも音声通信とデータ通信とを組み合わせたハイブリッド通信ネットワークである、請求項１に記載のサービス統合システム。
12. 前記少なくとも１つの機能モジュール要素が、
    （ａ）少なくとも１つの機能モジュールマネージャと、
    （ｂ）少なくとも１つの機能モジュールと、
    をさらに備えている、請求項３に記載のサービス統合システム。
13. 前記少なくとも１つのサービスロジック実行環境モジュールが、
    （ａ）少なくとも１つのステートマシンコントローラと、
    （ｂ）少なくとも１つのメモリと、
    （ｃ）少なくとも１つの実行可能ステートマシンと、
    をさらに備えている、請求項３に記載のサービス統合システム。
14. 前記少なくとも１つのリソース制御要素が、前記システム管理者によって定義される所定のポリシーに従ってトラフィックの流れをさらに最適化する、請求項１に記載のサービス統合システム。
15. 前記少なくとも１つのリソース制御要素が、前記サービス統合システムによって提供される前記さまざまなサービスの履歴的なシステムリソース消費率をさらに分析および格納し、前記格納されているデータを使用して前記フローを最適化する、請求項１に記載のサービス統合システム。
16. （ａ）サービスの配置と、
    （ｂ）サービスの実行と、
    （ｃ）サービスの管理と、
    から成る群から選択される少なくとも１つを行うことができる、請求項１に記載のサービス統合システム。
17. 前記少なくとも１つの実行可能ステートマシンが、少なくとも１つのステートマシンをさらに備えている、請求項１３に記載のサービス統合システム。
18. アプリケーションサーバーとして実施される、通信ネットワーク用の分散型アーキテクチャのサービス統合システムであって、
    （ａ）前記サービス統合システムを管理および制御する少なくとも１つの手段であって、前記サービス統合システムを含んでいる複数の前記手段と、これらの管理および制御を実行する目的で相互作用する、手段と、
    （ｂ）ネットワークからのメッセージの受信とネットワークへのメッセージの送信を行う少なくとも１つの手段と、
    （ｃ）サービスを実行することを目的とするサービスロジック実行環境を提供する少なくとも１つの手段と、
    （ｄ）前記サービス統合システムの前記コンポーネントの間と、前記サービス統合システム及び前記ネットワークの間と、の両方のデータの流れを最適化する少なくとも１つの手段であって、ネットワークからのメッセージの受信とネットワークへのメッセージの送信を行う前記手段と、サービスロジック実行環境を提供する前記手段とに少なくとも接続されている、手段と、
    を備えている、分散型アーキテクチャのサービス統合システム。
19. （ａ）サービスの配置と、
    （ｂ）サービスの実行と、
    （ｃ）サービスの管理と、
    から成る群から選択される少なくとも１つを行うことができる、請求項１８に記載のサービス統合システム。
20. 通信ネットワークにおいてサービスを提供する方法であって、
    （ａ）前記通信ネットワークから新しいメッセージを受信するステップと、
    （ｂ）前記新しいメッセージが新しいサービス要求であるかすでに実行中のサービスに関連するメッセージであるかを、独立した中央集中型ネットワークリソースに確認するステップと、
    （ｃ）前記新しいメッセージがすでに実行中のサービスに関連する場合、前記新しいメッセージを、前記メッセージに関連する前記実行中のサービスに送るステップと、
    （ｄ）前記新しいメッセージが新しいサービス要求である場合、前記要求されたサービスの実行を目的として前記新しいメッセージをサービスロジック実行環境に送り、ステップ（ｅ）および（ｆ）を実行するステップと、
    （ｅ）前記サービス統合システムによってサポートされている前記サービスから前記要求されたサービスを解決するステップと、
    （ｆ）前記解決されたサービスを実行するステップと、
    を含んでいる、方法。
21. 前記ステップ（ｆ）が、
    （ａ）前記サービス統合システムによる実行を目的として、前記実行中のサービスによってタスクをポストするステップと、
    （ｂ）前記タスクを前記サービス統合システムによって処理するステップと、
    （ｃ）前記通信ネットワークと前記サービス統合システムとの両方から新しいメッセージを前記実行中のサービスによって受信するステップと、
    をさらに含んでいる、請求項２０に記載の方法。
22. 前記ステップ（ｂ）が、
    （ａ）前記通信ネットワークにメッセージを送るステップと、
    （ｂ）前記実行中のサービスにメッセージを送るステップと、
    をさらに含んでいる、請求項２１に記載の方法。
23. 通信ネットワーク用の新しいサービスを配置する方法であって、
    （ａ）高水準コンピュータ言語のソースコードによって前記新しいサービスを実施するステップと、
    （ｂ）前記ソースコードをコンパイルするステップと、
    （ｃ）前記コンパイルされたソースコードをメモリにインストールし、前記新しいサービスが実行できる状態にすることによって、前記コンパイルされたソースコードを前記通信ネットワークに統合するステップと、
    を含んでいる、方法。
24. サービス統合システムの中と、前記サービス統合システムの間と、前記サービス統合システム及び通信ネットワークの間と、の両方のトラフィックの流れを制御する方法であって、
    （ａ）受信されるタスクに必要であると予測されるリソース消費量を求めるステップと、
    （ｂ）外部ネットワークチャネルのリソース負荷レベルを求めるステップと、
    （ｃ）内部ネットワークチャネルのリソース負荷レベルを求めるステップと、
    （ｄ）ステップ（ａ）、（ｂ）、および（ｃ）の実行から受信される結果に従って、選択されるネットワークチャネルにメッセージを転送するステップと、
    を含んでいる、方法。
25. 前記時間依存トラフィックが音声である、請求項９に記載のサービス統合システム。
26. 前記時間依存トラフィックが映像である、請求項９に記載のサービス統合システム。

Images