JPH1145231A

JPH1145231A - 遠距離通信ネットワークの利用者に少なくとも一つのサービスを提供する方法、サービス管理ファシリティ及びサーバノード

Info

Publication number: JPH1145231A
Application number: JP10103192A
Authority: JP
Inventors: Nicolas Mercouroff; ニコラ・メルクロ; Alban Couturier; アルバン・クチユリエ
Original assignee: Alcatel Alsthom Compagnie Generale dElectricite
Current assignee: Alcatel Lucent SAS
Priority date: 1997-04-14
Filing date: 1998-04-14
Publication date: 1999-02-16
Also published as: AU6061798A; US6201862B1; DE69733543T2; EP0873025A1; DE69733543D1; AU739844B2; EP0873025B1; CA2231293A1; ATE298173T1

Abstract

(57)【要約】【課題】サービス制御ファシリティのデータ処理特性
を改善する。【解決手段】遠距離通信ネットワークの利用者にサー
ビスを提供する方法。利用者の一人一人のためにサービ
スの実行を要求するサービス呼出しは、遠距離通信ネッ
トワークのサービス切換交換局に送られるか、遠距離通
信ネットワークの数個のサービス切換交換局の一つに個
々に送られる。対応するサービス要求は、個々のサービ
ス呼出しを受信した個々のサービス切換交換局によっ
て、サービス制御ファシリティまたは数個の可能性のあ
るサービス制御ファシリティの一つに送られる。サービ
ス要求は、オブジェクト指向の計算環境内のオブジェク
トインフラストラクチャの最上部に形成された、サービ
ス制御ファシリティの複数のサーバの特定の一つに送ら
れる。特定のサーバはサービスレポジトリサーバとして
働き、利用可能で個々のサービス呼出しについてサービ
スの制御を実行することができる複数のサーバのもう一
つを決定する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は請求項１に記載の遠
距離通信ネットワークの利用者に少なくとも一つのサー
ビスを提供する方法、請求項１９に記載の遠距離通信シ
ステムのサービス制御ファシリティ内でサービスロジッ
クファンクションの実行を規定する方法、請求項２０に
記載の遠距離通信ネットワークの一つまたは数個のサー
ビス切換交換局に接続するためのサービス制御ファシリ
ティ、ならびに請求項２２に記載の遠距離通信ネットワ
ークの一つまたは数個のサービス切換交換局に接続され
たサービス制御ファシリティ用のサーバノードに関す
る。

【０００２】

【従来の技術】遠距離通信サービスはインテリジェント
ネットワークアーキテクチャに従って提供することがで
きる。

【０００３】遠距離通信ネットワークの利用者は、サー
ビス専用の番号をダイアルすることによりサービスを要
求する。この番号を用いた呼出しは遠距離通信ネットワ
ークを介して、この呼出しをサービスを要求する呼出し
として認識するサービス切換交換局に送られる。次に、
このサービス切換交換局はデータネットワークを介して
サービス制御ファシリティ、いわゆるサービス制御ポイ
ントと通信する。このサービス制御ポイントは、呼出し
者にサービスを提供するために実行されなければならな
い方法の記述を含む、サービスロジックを含んでいる。
サービス切換交換局の要求により、サービスロジックに
よるこの方法の実行が開始され、要求されたサービスが
要求者に提供される。

【０００４】サービス切換交換局はサービス制御ファシ
リティと密接にリンクしている。このリンクの編成は、
サービス切換交換局／サービス制御ファシリティの一対
のベンダーによって提供される基本的所有ツールによっ
て作られており、容易で動的な編成は許容しない。

【０００５】このサービスロジックは、全ての呼出しを
順次取り扱う単一の過程として認識される。個々の呼出
しは単一の待ち行列を通って進む。各呼出しは、利用者
のやり取りの間で呼出しの状態が失われないようにでき
るコンテキストと関連している。サービスは、呼出しの
コンテキストに関するＴＣＡＰメッセージを入力として
捉えて、有限状態マシンを介して実行される。

【０００６】

【発明が解決しようとする課題】このアプローチの短所
は、サービスを規定するこのアーキテクチャが柔軟性を
欠いており、その基礎となっているデータ処理システム
を十分に利用していないことである。

【０００７】従って、サービス制御ファシリティのデー
タ処理特性を改善することが、本発明の主たる目的であ
る。

【０００８】

【課題を解決するための手段】この目的は、請求項１の
教示に従って遠距離通信ネットワークの利用者に少なく
とも一つのサービスを提供する方法、請求項１９の教示
に従って遠距離通信システムのサービス制御ファシリテ
ィ内でサービスロジック機能の実行を規定する方法、請
求項２０の教示に従って遠距離通信ネットワークの一つ
または数個のサービス切換交換局に接続するためのサー
ビス制御ファシリティ、ならびに請求項２２の教示に従
って遠距離通信ネットワークの一つまたは数個のサービ
ス切換交換局に接続されたサービス制御ファシリティ用
のサーバノードによって解決される。

【０００９】本発明の基礎となる考えは、オブジェクト
指向の計算環境内のオブジェクトインフラストラクチャ
の最上部に形成される、一つまたは多数のサーバによる
サービス制御ファシリティによって提供される各サービ
スを実施し、特定のサーバ、すなわち受け取るサービス
要求に対してサービスを実行しなければならない１つの
サーバを決定するサービスレポジトリサーバを提供する
ことである。

【００１０】従って、サービスアーキテクチャは、マル
チスレッドまたはマルチ処理が適用されうるような機能
的な設計や技術にはもはや基づいてはいない。更に、一
つまたは数個のサービス切換交換局の周囲でサービス実
行ユニットを配布するオープンな方法が提供される。

【００１１】サービスレポジトリサーバを用いると、配
布はトランスペアレントでありシステム編成はプラグア
ンドプレーを通して非常に容易に達成される。オープン
インターフェイスを介して、システムのスケーラビリテ
ィが確実になり、容易に実現される。

【００１２】本発明のその他の有利な実施形態はサブク
レームに記載されている。

【００１３】ＣＯＲＢＡベースの配布の導入は高いスケ
ーラビリティとＩＴプラットフォームの独立性を提供す
る。これはソフトウエアのサービスの相互作用の個人
化、配布及び保全の容易さを考慮している。

【００１４】サービス制御ファシリティとサービス切換
交換局の間のリンクがＯＭＧＣＯＲＢＡ２．０仕様に従
っているアプローチでは、処理ノードとサーバノードの
編成は、その基礎にあるＣＯＲＢＡプラットフォームを
利用しなければならない。

【００１５】オブジェクト指向の計算環境及び上記の特
別オブジェクト設計の導入によって、サービス要求の処
理は分散することができ、これは高い販売可能性とＩＴ
プラットフォームの独立性を証明している。このアプロ
ーチに従ったサービスロジックの再設計は、ソフトウェ
アのサービスの相互作用の個人化、配布及び保全性の容
易さを考慮している。設計パターンは、オブジェクト指
向のプログラミングから全ての利益を得ることを考慮し
ている。

【００１６】更に、マルチスレッドを導入することを可
能にしている。直接的な利益は、サービスセッション、
つまりサービス要求の処理が、もう一つのサービスセッ
ションの実行によって妨げられないことである。

【００１７】ファクトリの使用は、サービスセッション
オブジェクトに関するいくつかのライフサイクルの方針
を実施することを可能にする。

【００１８】更に、下記事項を行うことが有利である。

【００１９】・サービス専用ファクトリによるサービス
セッションオブジェクトの生成を管理すること。

【００２０】・ＩＤＬ上にマップされたＴＣＡＰとし
て、サービスセッションオブジェクトのインターフェイ
ス定義を設定すること。

【００２１】ＣＯＲＢＡサーバの利用によって、サービ
ス制御ファシリティの実施は単純化され、販売可能性が
確実になる。

【００２２】ここで付属の図面を参照して、本発明を説
明する。

【００２３】

【発明の実施の形態】図１は、遠距離通信ネットワーク
ＫＮ１と、加入者Ａに割り当てられた加入者ターミナル
Ｔと、通信ネットワークＫＮ２と、二基のサービス制御
ファシリティＳＣＰ１及びＳＣＰ２とを備えた遠距離通
信システムＴＳを示す。

【００２４】遠距離通信ネットワークＫＮ１は、例えば
電話ネットワークである。このネットワークはデータネ
ットワークまたは混合データ音声及びビデオ送信用の通
信ネットワークであることも可能である。

【００２５】ネットワークＫＮ１の交換局から、二基の
特別に設計された交換局ＳＳＰ１とＳＳＰ２が示され
る。この交換局は、サービス切換機能ＳＳＰを含むサー
ビス切換交換局である。この交換局には、ネットワーク
の加入者からのサービス要求呼出しが送られる。かかる
サービス切換交換局がかかるサービス要求を受信する
と、二基のサービス制御ファシリティＳＣＰ１とＳＣＰ
２の一つに、ネットワークＫＮ２を介して対応する要求
を送信する。そうすると、サービスはサービス制御ファ
シリティＳＣＰ１及びＳＣＰ２それぞれの制御下で提供
される。

【００２６】サービス制御ファシリティＳＣＰ１及びＳ
ＣＰ２のそれぞれは、一つまたは数個のサービスＳを提
供し、サービス制御機能を実現する。

【００２７】通信ネットワークＫＮ２は、データネット
ワーク、特にＳＳ７信号送信プロトコルに従ったデータ
ネットワークであることが望ましい。このネットワーク
は、ＬＡＮ（ローカルエリアネットワーク）、ＭＡＮ
（メトロポリタンエリアネットワーク）またはＡＴＭ
（非同期転送モード）ネットワークであることも可能で
ある。

【００２８】サービス切換交換局ＳＳＰ１、ＳＳＰ２、
これらの間の通信及びサービス制御ファシリティＳＣＰ
１、ＳＣＰ２は、例えばＩＴＵ−ＴＱ．１２１４勧告で
説明された、インテリジェントネットワークアーキテク
チャに従って（サービス切換ポイントに従い、サービス
切換ポイントとサービス制御ポイントとの間の通信に従
って）設計されていることが好ましい。

【００２９】ユーザがサービスＳを開始したい場合に
は、そのサービスに特定の番号をダイアルする。ローカ
ル交換局がこの呼出しを最も近いサービス切換交換局に
送り、これによりサービス切換機能ＳＳＰが発動されサ
ービスが開始する。これはＳＣＰに要求を送ってサービ
スロジックプログラム（ＳＬＰ）の実行を開始すること
により行われる。ＳＬＰは各サービスに特有であり、サ
ービスをどのように扱うかについてネットワークを指示
する。これはサービスロジック、統計ロジック、データ
ベースロジック、請求ロジックなどを実行する。また、
スイッチに指示を出し（例えば、呼出しの第二レグを創
出する）、インテリジェントペリフェラル（ＩＰ）に指
示を出す（例えば、アナウンスマシン）。ＩＮＡＰプロ
トコルはこれに使用され、ＩＮＡＰメッセージはＳＣＰ
とＳＳＰとの間でＩＣＡＰメッセージで運ばれる。

【００３０】分散アプリケーションを設計する場合に
は、まず分散される可能性のあるシステム構成部品が識
別される（つまり、システムのオブジェクトは何か、そ
れらは分散されるより大きなオブジェクトにどのように
分類されるか）。

【００３１】ＳＣＰのオブジェクトへの分類は、ある種
の可能性を提示する。図２および図３は、異なったアー
キテクチャに編成されたオブジェクトを表す。一つの呼
出しを取り扱うための全ての状態情報は共に保持され、
全ての必要とされるデータはオブジェクトに編成され
た。従って、ＳＣＰオブジェクトに関する一つの可能性
は、一つの呼出しに関するサービスロジックを実行する
スクリプトオブジェクトとデータオブジェクト毎のオブ
ジェクトである。

【００３２】データオブジェクトの値はデータベースに
保持されるので、データベースの使用を隠すデータオブ
ジェクトを有することが望ましい（つまり、データベー
スに関するある種の独立性）。これらのオブジェクトを
ＣＯＲＢＡオブジェクトとすることは、方法（例えば、
属性の値を読むか書く方法）がそれらを求められている
場合には、大幅なオーバヘッドを発生させるという弱点
がある。従って、システムの性能は受け入れ難いものに
なる。

【００３３】スクリプトオブジェクトは、サービス実行
エンジンとＳＩＢグラフに分割することができる。従っ
て、ＳＩＢは分散オブジェクトにもなりうる。データベ
ースオブジェクトが分散されると、これは特定のデータ
オブジェクトが存在するマシン上でＳＩＢを実行する可
能性を提示する。我々は、ＳＩＢを離れたところから実
行する（オーバヘッドが増える可能性）制御実体（スク
リプト）があるスキームは、制御がＳＩＢからＳＩＢに
渡されるスキームであると考察することができる。一つ
のマシン上でデータを獲得してスクリプトを実行するこ
とと、データが存在するスクリプト（ＳＩＢ）の一部を
実行することとの間のこのトレードオフは、間違いなく
検討する価値がある。

【００３４】ＳＳＰの主たる機能性は、呼出し処理とＩ
Ｎシステムとの間にフックを提供することである。ＳＳ
Ｐサーバは、通常のコールコントロールファンクション
（ＣＣＦ）の間をブリッジするオブジェクトと、スイッ
チングファンクション（ＳＦ）の間をブリッジするオブ
ジェクトとを少なくとも有していなければならない。ス
ペシャライズドリソース（ＳＲＦ）（例えば、アナウン
ス機器）の間をブリッジするオブジェクトも自明である
と思われる。図５では、これらのオブジェクトはスイッ
チングコントロール、コールコントロール及びスペシャ
ルリソースオブジェクトとして示されている。我々は、
オブジェクトと、ＳＣＰと組み合わされるコールハンド
ラ（ＣＨ）とＳＳＰにおける他のオブジェクトをも必要
とする。二つの可能性がある。全ての呼出しを扱う一つ
だけが存在するか、それぞれが一つの呼出しを扱う複数
が存在する。呼出しの間のみ存在するいくつかがある場
合には、これらのオブジェクトのライフサイクルを制御
するために、対応するファクトリオブジェクトも必要で
ある。

【００３５】以下では、ＣＯＲＢＡ上のＳＳＰサーバの
アーキテクチャを説明する。スイッチングコントロー
ル、コールコントロール及びスペシャルリソースのオブ
ジェクトに関しては、二つのアプローチを採ることがで
きる。第一のアプローチにおいては、これらは既存のソ
フトウェアの所有アプリケーションインターフェイス
（ＡＰＩ）の間のインターフェイスオブジェクトにすぎ
ない。第二のアプローチにおいては、これらはハードウ
ェアを直接に制御する。これはスイッチングコントロー
ル、コールコントロール及びスペシャルリソースにＣＯ
ＲＢＡインターフェイスを提供することを意味する。理
論的には、これが最良のソリューションであり、このア
プローチは全体的に一貫したソフトウェアアーキテクチ
ャを与えるので、この場合には特別なＩＤＬアダプタイ
ンターフェイスを設計しなければならない。

【００３６】ＳＭＰはサービス制御とモニタリングに責
任がある。サービスを制御するために、ＳＭＰはＤＰＥ
オブジェクトである必要はない。必要なのは、制御され
るオブジェクト（例えばスクリプト）がそうするための
インターフェイスを提供することである。モニタリング
に関しては、監視されているオブジェクトから「イベン
ト」を受け取ることができるＳＭＰオブジェクトが必要
である。我々の研究のプロトタイプにおいては、ＳＣＰ
での管理機能性として可能であるものに関する例として
トレース制御を定義し実施した。

【００３７】前項では、ＩＮアーキテクチャにおけるＣ
ＯＲＢＡオブジェクトに関する多くの可能性を説明し
た。この項では、これらのＣＯＲＢＡオブジェクトのあ
るものを特定のアーキテクチャに区分する。アーキテク
チャのシーケンスは、現在のサービス規定（特にＩＮ）
製品から始まる、可能な発展のシナリオとして理解する
ことができる。

【００３８】第一のアーキテクチャの基礎は、データの
分散については分散データベースの、分散ＳＣＰについ
てはＣＯＲＢＡ分散の使用である。このアーキテクチャ
は既存のＳＳＰとインターフェイスするように設計され
ているため、ＳＳＰはＣＯＲＢＡオブジェクトではな
い。このアーキテクチャは研究のプロトタイプを実施す
るのに使用されたので、他のもの以上に詳細にそれに関
して説明する。図３はこのアーキテクチャを図示してい
る。

【００３９】このアーキテクチャの基本的構成部品は次
のものである。

【００４０】・スクリプト：正確に一つの呼出しを扱う
ＣＯＲＢＡオブジェクト・ＳＬＩ（サービスロジックインターフェイス）、ＳＳ
Ｐに代わってＴＣＡＰダイアログを扱い、ＳＳＰとイン
ターフェイスするＣＯＲＢＡオブジェクト・分散ＤＢ既存のＩＮサービススクリプトは、スクリプトオブジェ
クト内に閉じ込めることができる。

【００４１】スクリプトオブジェクトは、特定の呼出し
に関連したサービスデータとコールコンテクストも含
み、一つのスクリプトオブジェクトが呼出し毎に例示さ
れる。スクリプトオブジェクトのインターフェイスは、
その実行の間にスクリプトが受け取るＴＣＡＰメッセー
ジを表す操作を含む。

【００４２】特別のサービスロジックインターフェイス
（ＳＬＩ）オブジェクトはＳＳＰから＃７のメッセージ
を受け取り、ＯＲＢサービスを使って、対応するスクリ
プトオブジェクトインスタンシィエーションにそのメッ
セージを送る。ＳＬＩオブジェクトのインターフェイス
は、それに送られうるＴＣＡＰメッセージを含む。一つ
のＳＬＩオブジェクトは、呼出し毎にインスタンス化さ
れる。

【００４３】スクリプトとＳＬＩオブジェクトは呼出し
が続いている間だけ存在するので、それに対応するファ
クトリオブジェクトはそのオブジェクトを生成したり破
壊するのに使われる。データオブジェクトはＣＯＲＢＡ
オブジェクトではなく、Ｃ＋＋オブジェクトとして実行
される。このアプローチは、サービスロジックから特定
のデータベースの使用を隠す。

【００４４】例えばオラクル（Oracle）、ＳＱＬＮＥＴ
またはオブジェクトストア（ObjectStore）をデータベ
ースとして使うことは可能である。ＳＭＰは考慮されて
おらず、それに状況情報を送るのに所有機構を使用する
か、適切なＩＤＬインターフェイスを用いてそれをＣＯ
ＲＢＡオブジェクトとして定義できたはずである。

【００４５】しかし、何が可能かに関する例として、小
型のトレース制御システムを設計し実行することは容易
に可能であり、各サーバはトレーサオブジェクトを有
し、ＳＭＰのトレース制御部分は方法を呼び出して、特
定の実行オブジェクトに関するトレースを入れたり切っ
たりすることができる。ＳＭＰは（ＳＱＬＮＥＴを使用
して）データベースの管理も行う。

【００４６】スクリプトとＳＬＩはＣＯＲＢＡオブジェ
クトであり、サーバ上でそれらがどのように分散される
かは配置の問題である。ＣＯＲＢＡサーバは、システム
の特定のノードで行われるプロセスである。ＳＳＰとイ
ンターフェイスするシステムには、一つのＳＬＩサーバ
がある。ＣＯＲＢＡサーバは、サーバが動いているとき
に常に存在する一つのＣＯＲＢＡオブジェクト（ＳＬＩ
ファクトリ）を有する。

【００４７】このオブジェクトの主たる目的は、新たな
呼出しが開始されたときに（ＴＣＡＰダイアログが開か
れたときに）、新たなＳＬＩオブジェクトを生成するこ
とである。ＳＬＩサーバは、＃７ハードウェア及びソフ
トウエアがインストールされているノードに配置され
る。システムは利用できるノードについて一つずつ、多
くのスクリプトサーバを有することができる。

【００４８】このサーバは、サーバ自体が存続する間に
存在するファクトリオブジェクトも有する。このファク
トリオブジェクトはＣＯＲＢＡネーミングサービスに登
録されており、そのためＳＬＩがそれを発見することが
できる。このようにして、サービスロジックの分散が促
進される。システムに更に処理力を加えることは、スク
リプトサーバが動く新たなマシンを設置することを単に
意味し、次にＳＬＩがスクリプトファクトリを探すとき
には、新たな可能性が利用できる。同じメカニズムがあ
る種の信頼性も提供し、マシンが何らかの理由でダウン
すると、ＳＬＩはそのスクリプトサーバをもはや参照し
なくなるだけである。スクリプトファクトリは、サーバ
が動いている限り常に利用可能であるので、管理インタ
ーフェイスを置くのに（例えば、サービス特性を変更す
るのに）最良の候補にもなることに注意されたい。

【００４９】ＳＬＩとスクリプトの間のインターフェイ
スは、非同期であるように且つＴＣＡＰプリミティブ
（ＢＥＧＩＮ、ＩＮＶＯＫＥ、ＲＥＳＵＬＴ、…）で定
義される。要件の一つが既存のＩＮ製品ソフトウェアを
再使用することであるので、このオプションは有利であ
る。もう一つのオプションは、ＩＮＡＰプリミティブで
このインターフェイスを定義することである。

【００５０】ＣＯＲＢＡオブジェクト、（ＣＯＲＢＡ）
サーバ及び工程の差異は明確にしなければならない。Ｃ
ＯＲＢＡオブジェクトはインターフェイスを実行し、Ｃ
ＯＲＢＡサーバ内で動く。ＣＯＲＢＡサーバ自体はホス
ト（またはノード）上で動く一つの工程である。この定
義は、スクリプトと呼出しの間の関係に重要である。現
在のＡＬＣＡＴＥＬＩＮ製品の実施においては、スク
リプトは異なった呼出しを扱う工程であり、そのそれぞ
れについて異なった呼出しのコンテキストを維持する。
これは性能を理由として行われ、各呼出しについて個別
の工程（スクリプト）を開始するにはある程度時間がか
かる。

【００５１】これらのアーキテクチャにおいては、同様
のアプローチを採用できるが（一つのスクリプトがｎ個
の呼出しを扱う）、スクリプトは多重のコンテキストを
有するという事実はそれほど明白ではなく、多重のスク
リプト（それぞれが一つの呼出しを扱う）を備えたＣＯ
ＲＢＡサーバを有することにより、性能の問題に対処す
ることが可能である。従って、このアーキテクチャにお
いては、ホストが一つ以上のＣＯＲＢＡサーバを動か
し、それぞれが特定の呼出しを扱う異なったスクリプト
オブジェクトをそれぞれのサーバが動かすことがより好
ましい。

【００５２】ＣＯＲＢＡサーバは現在のＩＮ製品におけ
るスクリプトに類似しているが、多重のコンテキストを
扱う問題はアプリケーションのプログラマからＣＯＲＢ
Ａプラットフォームに移される。

【００５３】このアーキテクチャのシーケンスにおける
第二のアーキテクチャとしての更なるステップは、スク
リプトオブジェクトをその構成部分に分解することであ
る。公知のように、ＩＮサービスは、サービスロジック
グラフにおけるノードである多数のＳＩＢとして設計さ
れている。スクリプトの実行はＳＩＢを実行すること
と、データとＳＳＰから入る応答に応じて次のＳＩＢに
移動することとを意味する。これを（ＳＣＥからの）一
個のモノリシックなソフトウェアとして設計する代わり
に、ＳＩＢに協力する条件で設計することができる。公
知のように、ＩＮ能力は１にセットされており、ＳＩＢ
はそれらをそのまま使うようには十分に定義されていな
い。これにより、ＩＮプラットフォームのプロバイダは
標準的なものから派生する独自の一連のＳＩＢを有する
ことになり、ＳＩＢからのソフトウェアはプラットフォ
ームの中で再使用できなくなる。

【００５４】ＳＩＢがＣＯＲＢＡオブジェクトとして定
義されている場合には、この状況は破壊され、サービス
プロバイダは既存のＳＩＢ（ソースコード）を再使用し
て、独自のサービスを設計することができるであろう。

【００５５】独立したＣＯＲＢＡオブジェクトとしてＳ
ＩＢを有することは、異なった場所でＳＩＢを実施する
可能性を提示する。（分散データベースを使って、また
はＣＯＲＢＡオブジェクトを使って）スクリプトまたは
ＳＩＢが実行されている場所にデータを届ける代わり
に、データが置かれているマシンでＳＩＢを開始するこ
とができるであろう。これは利益をもたらす。ＳＩＢを
離れた場所から実行する制御実体（スクリプト）がある
スキームあるいは、制御がＳＩＢからＳＩＢへ渡される
スキームを考察することができる。

【００５６】第三のアーキテクチャは、ＳＳＰをＣＯＲ
ＢＡオブジェクトにもするという意味で、従来のＩＮ製
品と関係を断つ。以前のアーキテクチャにおいては、信
頼性の理由で、ＣＯＲＢＡサーバは信頼できるＬＡＮ上
で相互接続されたマシンに配置されることがまだ必要で
ある。実際には、現在のＤＰＥインプレメンテーション
（ＴＣＰ／ＩＰ）を用いると、これはマシンを同じ場所
に置くことを意味する。実際にはＳＣＰとＳＳＰのサイ
トが異なった場所にあるので、この技術の制限は、ＳＳ
ＰをＤＰＥに置くことを妨げる。しかし、技術は発展
し、ＤＰＥプロバイダ（例えばＩＯＮＡ）はその製品を
他の転送プロトコル、例えば遠距離通信を目的とした＃
７リンクにポートする可能性を検討している。これが行
われた場合には、ＳＳＰをＣＯＲＢＡオブジェクトにす
るステップはそれほど大きくはない。この場合に、ＳＳ
Ｐオブジェクトがその役割を引き継ぐことができるの
で、ＳＬＩオブジェクトはもはや必要ないであろう。呼
出しが開始されると、呼出しはスクリプトファクトリを
参照して、スクリプトオブジェクト自体を生成するかを
問い合わせる。次にこのオブジェクトと直接に通信する
ことができる。この通信に使用される言語（ＴＣＡＰベ
ースのインターフェイスに入れられたＩＮＡＰ）も単純
化できる。このインターフェイスはＩＮＡＰプリミティ
ブの用語で定義できる（例えば、provide_instruction
(args), join(args)）。アプリケーションプログラマに
とってはＴＣＡＰレイヤが消えるので、これによりシス
テム設計および実施は改善（単純化）される。ＣＯＲＢ
Ａが使用される場合には、アプリケーションプログラマ
は通信のアプリケーションレイヤを気にかけるだけでよ
く、セッションレイヤを気にかけなくてよい（ＴＣＡＰ
が使用される場合）と言える。

【００５７】最終ステップは（ＴＩＮＡによって提案さ
れたように）ターミナルを拡張統合することである。こ
れは、ユーザの機器における大きな変更を意味する。し
かし、ますます多くのユーザが電話回線上でインターネ
ットに接続している事実を考慮した場合に、この変更は
実現不可能なことではない。ＤＰＥをターミナルに拡張
させるのに必要な技術はこれと同様である。この利点
は、ネットワークプロトコルへのターミナルが、ＤＴＭ
Ｆトーンを数字として渡すだけよりは遥かに豊富になり
うることであろう。

【００５８】上記のアーキテクチャは、特にＩＮプラッ
トフォームを更にスケーラブルにするためのソリューシ
ョンを提供する。既存の製品との相互作用及びそれから
の発展は重要であるので、我々は可能な発展のシナリオ
と見なされる一連のアーキテクチャを提示した。

【００５９】図６は、オブジェクト指向の環境ＣＯＲＢ
ＡにおいてオブジェクトインフラストラクチャＣＯＲＢ
ＡＯＲＢの最上部に形成される、数個のサーバＳＥＲ
Ｖ及びＲＥＰを備えたサービス制御ファシリティＳＣＰ
１を示す。

【００６０】異なったサーバは異なった処理ノードＰＲ
ＯＺ１及びＰＲＯＺ２で動く。ＳＣＰ１によって提供さ
れる各サービスは、一つ以上のサーバＳＥＲＶによって
実施される。サービスへの各呼出しは、対応するサーバ
ＳＥＲＶの一つによってファクトリを介して管理され
る、単一のＣＯＲＢＡオブジェクトである。ＳＳＰ１及
びＳＳＰ２はＣＯＲＢＡＯＲＢの最上部で数個のサー
バＳＥＲＶにアクセスしている。それはあたかも、数個
のサービス制御機能ＳＣＰにアクセスしているかのよう
である。リンクを提供するために、サービスレポジトリ
サーバＲＥＰが設計されている。

【００６１】新たなサービスセッションの要求時に、Ｓ
ＳＰ１はサービスレポジトリサーバＲＥＰにアクセスし
て、そのサービスセッションを実行するために利用可能
なサービスサーバＳＥＲＶを見つける。

【００６２】サービスレポジトリサーバへの情報の入力
は、ＩＮサービス名とサービスセッションキーで構成さ
れている。サービスファクトリの適合するオブジェクト
参照は、サービスレポジトリサーバによって返信され
る。

【００６３】サービスサーバは、セッションキーの抑制
に基づいてサービスレポジトリに登録される。従って、
キーを定義する言語は、新たなサーバを登録する場合に
はキーの定義を処理する申し出において定義されてお
り、ＳＳＰが問い合わせを行う場合にはキーを処理す
る。

【００６４】例として、アーキテクチャ３によるインプ
レメンテーションの手順は下記のとおりである。ＵＮＩ
ＸベースのＩＮリリースの既存アルカテル（Alcatel）
製品用に存在するクレジットカードコーリングサービス
を実施する。クレジットカードコールサービスは「典型
的な」ＩＮサービスであり、どのターミナルからの呼出
しも特定のカード番号に請求されることを可能にしてい
る。その呼出しを行うために、ユーザはカード番号、Ｐ
ＩＮコード及び呼出し先番号を入力しなければならな
い。入力されたデータが正しい場合には、呼出しは呼出
し先のアドレスに向けて完了し、ユーザのカードに請求
される。

【００６５】ＳＳＰシミュレーションスタブはクレジッ
トカードコール用のＴＣＡＰダイアログを生成するのに
使用された。ＳＳＰスタブは、ＳＳＰが送受信するのと
同じＴＣＡＰメッセージを送受信するＣＯＲＢＡオブジ
ェクトである。ＳＳＰスタブは異なった呼出しのシナリ
オをシミュレートすることができ、異なった呼出しのロ
ードを生成し任意の回数シナリオを繰り返すことができ
る。

【００６６】アーキテクチャを規定するＩＮ指向のサー
ビスにおけるＣＯＲＢＡの使用に関するもう一つの一般
的な問題は、ＣＯＲＢＡベースのＩＮのレガシーＩＮア
プリケーションとの相互作用である。

【００６７】この相互作用はアダプテーションを使用し
て達成することができる。これは、ＣＯＲＢＡベースの
インフラストラクチャが切換システム、すなわちＳＳＰ
のレガシーと通信できる方法に関連している。

【００６８】次の二つの可能なアプローチがある。

【００６９】１）ＳＳ．７とＴＣＡＰプリミティブのＩ
ＤＬインボケーション（invocation）へのマッピングを
提供する、アプリケーションレベルのブリッジであるア
ダプテーションユニットの定義。このアプローチはＣＯ
ＲＢＡ／ＣＭＩＰゲートウェイ［４］［５］のためにＸ
ｏＪＩＤＭグループによって採られるのと同様のアプロ
ーチである。これらの作業の結果は、ＩＤＬインターフ
ェイスへのＧＤＭＯ／ＡＳＮ．１の静的マッピングに特
に再使用することができる。

【００７０】既存のシステムへの影響を最小化するため
に、ＣＯＲＢＡはこのマッピングを達成するためのフレ
ームワークサービスやツールを提供すべきである。かか
るフレームワークの有用性によって、ＳＣＰやＨＬＲな
どの多様な既存のハードウェアとのＣＯＲＢＡベースの
ＩＮの相互作用が可能になる。

【００７１】かかるアプリケーションレベルのブリッジ
は、分散システムの障害となることなく、高い可用性と
高い性能によって特徴づけられるべきである。しかし、
要求される実時間の性能については、これは完全なＩＮ
ＣＯＲＢＡベースのシステムに向けた中間的なソリュ
ーションである。

【００７２】このアプローチは、ＭＡＰやＩＮＡＰなど
のアプリケーションレベルのプロトコルや、ＴＣＡＰレ
イヤに基づくその他のプロトコルを表すＩＤＬインター
フェイスを構築することを含む。ＴＣＡＰレイヤはＳＣ
ＣＰレイヤ上で「ＲＯＳＥのような」非同期のＲＰＣサ
ービスを提供する。ブリッジをＴＣＡＰに基づかせるこ
とは、ＩＳＵＰやＴＵＰなどの回路に関連した信号送信
プロトコルの使用をソリューションから除くことにな
る。

【００７３】ＸｏＪＩＤＭアプローチにおけるのと同様
に、専用のコンパイラによって行われる、ＩＮＡＰ／Ｔ
ＣＡＰ仕様のＩＤＬインターフェイスへの静的な翻訳が
あるべきである。従って、どのようなＩＮＡＰダイアレ
クトも適切なＩＤＬインターフェイスに変換することが
できる。これらのアプリケーションレベルのブリッジ
は、これらのＩＤＬ生成のインターフェイスを実施し、
ＩＤＬに派生する種類とそのＡＳＮ．１同等物との間の
変換を動的に行うであろう。

【００７４】プロトコル特定のブリッジを使用するＣＯ
ＲＢＡノードは、出ていくインボケーションと入ってく
るインボケーションの処理についてそれぞれ一つ、一般
的に二つのサーバを動かす。ＴＣＡＰは接続のないサー
ビスであるので、インボケーションを応答や例外に適合
させるために、ゲートウェイは状態を維持しなければな
らないであろう。

【００７５】２）環境特定インターＯＲＢプロトコル
（ＥＳＩＯＰ）としてのＳＳ７の使用。

【００７６】可能なソリューションはＳＳ７の最上部に
ＣＯＲＢＡＧＩＯＰをマップするか、ＳＳ７レイヤの
最上部に新たな拡張されたプロトコル（ＥＳＩＯＰ）を
構築することである。

【００７７】ＥＳＩＯＰソリューションは、ＧＩＯＰプ
ロトコル用のトランスポートとして基本的にＳＳ７を使
用するであろう。ＣＯＲＢＡオブジェクトは、ＣＯＲＢ
ＡＩＩＯＰを用いてインターネット上で見ることができ
るのと全く同じ方法で、ＳＳ７ネットワーク上で見るこ
とができるであろう。これはＯＲＢとして、既存のＳＳ
７インフラストラクチャをトランスポートとして使用す
ることを可能にするであろう。

【００７８】既存の信号送信ネットワークは、ＣＯＲＢ
Ａノードによって交換される種類のトラフィックを支援
するような大きさにはされなかったことに気づかれてい
るはずである。しかし、ＳＳ７ネットワークのフォール
トトレランスを促進することによって、このアプローチ
には潜在的な利益がある。

【００７９】ここでまず問題になるのは、このソリュー
ション用のＳＳ７プロトコルのアクセスレベルの選択で
ある。二つの主たる選択肢はＴＣＡＰとＳＣＣＰであ
る。

【００８０】ＩＣＡＰレベルでのＧＩＯＰＩＴは基本的にはＲＯＳＥのようなサービスであるか
ら、ＧＩＯＰメッセージを運ぶためにＴＣＡＰを使用す
ることは可能なはずである。ＴＣＡＰを利用するサービ
スは、ＡＳＮ．１モジュールを使ってその操作を定義し
なければならない。ＡＳＮ．１マクロは操作のセットで
ある、リクエスト、リプライ、キャンセルリクエスト、
ロケートリクエスト、ロケートリプライ、クローズコネ
クション及びメッセージエラーを定義するのに使われる
ことが考察される。これらの操作はＧＩＯＰプリミティ
ブに対応する。ゲートウェイは、ＧＩＯＰによって使用
される形式のＣＤＲフォーマットを、ＡＳＮ．１タイプ
を使用するトランスポート可能な形式に変換する（でき
れば、ＢＥＲエンコーディングを用いた不透明なバッフ
ァとして）ことに責任があるであろう。

【００８１】ＴＣＡＰをＥＳＩＯＰ用の基礎として使用
することは原則的に可能であるはずだが、これは次の理
由で適切ではない。

【００８２】・インプレメンテーションの複雑さ。

【００８３】・基本的なトランスポートに加えて、ＴＣ
ＡＰレイヤによって生ずるオーバヘッド。

【００８４】・プロトコルの非同期性。

【００８５】ＳＣＣＰレベルでのＥＳＩＯＰＳＳ７ＥＳＩＯＰを実施するための他の選択肢はＳＣ
ＣＰレベルにある。ＳＣＣＰはＯＳＩ−ＲＭネットワー
クレイヤの機能性に対応するサービスを提供する。これ
は、接続指向のモード及び接続なしのモードの両方で作
動することができる。ＥＳＩＯＰコードは、それ独自の
トランスポートレイヤの機能（例えば、エンドトゥーエ
ンドのフロー制御及びセグメンテーション／再組立）を
行うのに必要になるであろうが、ＳＣＣＰを使ってＧＩ
ＯＰメッセージを運ぶことは実現可能なはずである。Ｓ
ＣＣＰアドレス指定の「グローバルタイトル（global T
itle）」モードを使って、ＣＯＲＢＡノードをアドレス
指定することは可能なはずである。ＳＳ７ネットワーク
用のＥＳＩＯＰの基礎としてＳＣＣＰを使用することが
最良のアプローチであると思われる。

【００８６】以下の要件は、サービスセッションオブジ
ェクトが相互に作用するインフラストラクチャでの、オ
ブジェクト指向の環境にとっては有利である（ＣＯＲＢ
Ａ環境自体によって説明されている）。

【００８７】機能要件に関しては、ＣＯＲＢＡは下記の
ものを提供する。

【００８８】非同期インボケーションモデルとＯＲＢに
おけるグループ通信のための支援。

【００８９】セキュリティ、トランザクション及び応答
の機構を備えたＯＲＢを拡張するための適切なフック。

【００９０】ノード管理及び最小オブジェクトライフサ
イクルファシリティ。

【００９１】計算上及びエンジニアリングのイベントの
両方を取り込むためのタイムサービス及びネイティブモ
ニタリングファシリティ。

【００９２】柔軟なイベントトゥースレッドのマッピン
グを備えたマルチスレッド用の支援。

【００９３】ＣＯＲＢＡの非機能的な要件は以下に関係
する。

【００９４】ＩＮコンテキストにおいてＯＲＢが満たす
べき販売可能性とオブジェクト細分性のレベルを特定す
ること。

【００９５】−待ち時間、スループットなどに関してＯ
ＲＢが達成しなければならない性能レベルを特定するこ
と。

【００９６】−プラットフォームの時間的挙動を計測及
び文書化することにより、予測可能なＯＲＢコアを提供
すること。

【００９７】−ハードウェア及びソフトウェアに障害が
ある場合に、分散アプリケーションについて受け入れら
れる挙動を定義する要件を示す信頼性。この場合には、
二種類の信頼性を特定することができる。完全性の状態
及び可用性である。

【００９８】−複雑なアプリケーションの開発、配備及
び操作の簡易化を可能にする要件を示す管理可能性。こ
の場合には、ＣＯＲＢＡアプリケーションの保全可能
性、（再）環境設定可能性及び拡張可能性である。

【００９９】非同期のインボケーションモデルはＩＮア
プリケーションに共通して使用されている。従って、非
同期で選択的に等時性のインボケーションモデルがＯＲ
Ｂに求められる。ここでこの要求は、強制的なコールバ
ック（またはＯＲＢ「アップコール」タイプの機構）と
選択的に「フューチャー」タイプのプログラミングモデ
ルを組み込んだ軽量の非同期通信機構を潜在的に支援す
るクライアント側のプログラミングモデルである。

【０１００】同じオブジェクトについて、非同期及び同
期のモデルの両方が共存すべきである。最大並行レベル
は環境設定（例えばＱｏＳパラメータ）において定義さ
れ、要求を待ち行列させるか例外を返す可能性を有し
て、制御可能でなければならない。

【０１０１】基本的な障害の検出支援は、それを必要と
する何れのオブジェクトについても、ＯＲＢ実行時によ
って提供されるはずである。これは、暗黙のセットであ
りクライアントの工程において管理されるタイマーによ
って行うことができる。

【０１０２】柔軟性及び販売可能性ＯＲＢは多数のオブジェクトを扱うアプリケーションを
支援することができるべきであり、離れた場所にあるオ
ブジェクトへの多数の同時接続を支援することができる
べきである。

【０１０３】所与のカプセル（つまりユニックス工程）
における未使用の遠隔インターフェイスの参照のメモリ
費用は、標準的な言語ポインタ程度であるべきである。

【０１０４】典型的な遠距離通信環境は、空間（メモリ
のサイズ）と時間（オブジェクトのライフタイムと継
続）の両方において非常に異なった細分性のオブジェク
トからなる。スケーラブルなＯＲＢは、異なった細分性
のレベルにあるオブジェクトを支援し、小さく揮発性の
オブジェクト及び離れた場所にあるオブジェクトへの接
続の取り扱いに関連するオーバヘッドを最少にするべき
である。ＯＲＢのフォールトトレランスと信頼性のいく
つかを達成するために、ＣＯＲＢＡオブジェクトモデル
は、オブジェクトのグループまたはここで説明されたよ
うなグループ通信として世界的に知られているものを支
援するように強化することができる。

【０１０５】信頼性及び可用性信頼性の要件を達成するために、複製の分散オブジェク
トの概念をＣＯＲＢＡに導入することができる。従っ
て、アプリケーションの重要な構成部分は、複製された
オブジェクトを介して実施される。この複製の管理は、
所与のサーバオブジェクトと相互に作用するクライアン
トがそれが複製かどうか気づかないように、ＯＲＢによ
って自動的に扱うことができる。複製の程度は、同時発
生の故障の最大数で計測できる所望のレベルの信頼性、
典型とすることができる故障の性質（悪意か善意か）及
び完全性または可用性などの適切に求められる信頼性の
種類によって決定できる。高い可用性及びフォールトト
レランスの能力は、現在のＩＮシステムと同じ強靱さを
確実にするために、分散ＩＮシステムについてＣＯＲＢ
Ａによって提供されるべきである。

【０１０６】適時性の要件も複製サービスによって達成
できる。例えば、制限される必要があり遅れが予想され
るアプリケーションは、複製されたオブジェクトを介し
て実施されるであろう。各複製は、そのオブジェクトに
ついて定められた方法の全てを局所的に処理することが
できる。故障がない場合には、クライアントは方法イン
ボケーションへの応答の何れをもその結果として使用す
ることができる（この場合のインボケーションは同時に
行われる）。これを達成するために、ＯＲＢはアプリケ
ーションまたはサービスの要件に応じて、異なったプロ
ファイルのインプレメンテーションを可能にするモジュ
ラー構造を有するであろう。これらのプロファイル、基
礎にあるオペレーティングシステムによって提供される
リソースの障害となる。ＯＲＢモジュールの一つは、Ｏ
ＲＢ構造の下部レベルにある故障検出器になるであろ
う。そして、一定の限界値を超える応答インボケーショ
ンの遅れは故障に区分される。従って、クライアントは
信頼性を適時性とトレードオフすることができ、限界値
が短いほど、遅れに関する抑制は厳しくなる。十分な回
数だけオブジェクトを複製することにより、クライアン
トは適時性と信頼性の要件を同時に満たすことができ
る。

【０１０７】ここで、正確性、安全性及び活動性の特性
で複製サービスの要件を特定し、ＯＲＢコアの一部であ
る故障検出器モジュールを特定した。

【０１０８】性能ＩＮの性能は、サービスノードとインテリジェントペリ
フェラルについての１秒当たりの呼出し数と、信号送信
制御ポイントについての１秒当たりのトランザクション
の数で計測される。これらの呼出し及びトランザクショ
ンは、ＳＳＰとインテリジェントレイヤとの間で交換さ
れる多数のメッセージを含んでもよい。レガシーＩＮシ
ステムの実際の性能を得るために、ＩＮシステムにおけ
る分散処理の使用並びに地理的スケールでのその分散
（集中されていないＩＮシステム）について、ＯＲＢの
実時間の性能が求められる。ＩＮの分散システムについ
てより良い性能を達成するために、ＯＲＢの呼出しオー
バヘッドは削減すべきであり、待ち時間、スループット
などに関してＯＲＢが達成しなければならない性能レベ
ルは、定義して文書化すべきである。

【図面の簡単な説明】

【図１】本発明によるサービス制御ファシリティを含む
遠距離通信システムのアーキテクチャを表すブロック図
である。

【図２】遠距離通信システムの第一のオブジェクトアー
キテクチャを表すブロック図である。

【図３】遠距離通信システムの第二のオブジェクトアー
キテクチャを表すブロック図である。

【図４】遠距離通信システムの第三のオブジェクトアー
キテクチャを表すブロック図である。

【図５】遠距離通信システム用のサービス切換交換局の
オブジェクトアーキテクチャを表すブロック図である。

【図６】オブジェクトインフラストラクチャＣＯＲＢＡ
ＯＲＢの最上部に形成される、数個のサーバＳＥＲＶ
及びＲＥＰを備えたサービス制御ファシリティＳＣＰ１
を示す図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者アルバン・クチユリエフランス国、75013・パリ、リユ・オーギユスト・ペレ、14

Claims

【特許請求の範囲】

【請求項１】利用者の一人一人のためのサービスの実
行を要求するサービス呼出しが、遠距離通信ネットワー
クのサービス切換交換局に送られるか、遠隔通信ネット
ワークの数個のサービス切換交換局の一つに個々に送ら
れて、対応するサービス要求は個々のサービス呼出しを
受信している個々のサービス切換交換局によってサービ
ス制御ファシリティに送られる、遠距離通信ネットワー
クの利用者に少なくとも一つのサービスを提供する方法
において、サービス要求が、オブジェクト指向の計算環
境内のオブジェクトインフラストラクチャの最上部に形
成されたサービス制御ファシリティの複数のサーバの特
定の一つに送られることと、特定のサーバはサービスレ
ポジトリサーバとして働き、利用可能で個々のサービス
呼出しに対するサービスの制御を実行できる複数のサー
バのもう一つを決定することとを特徴とする方法。
【請求項２】異なったサービスがサービス制御ファシ
リティによって提供されることと、これらの異なったサ
ービスのそれぞれに関するサービスロジック機能は一つ
または数個のサーバの内部で実施されることとを特徴と
する請求項１に記載の方法。
【請求項３】特定のサーバは、個々のサービス呼出し
に関するサービスの実行を制御することができる、サー
ビスセッションオブジェクトを生成するサービスファク
トリオブジェクトのオブジェクト参照を決定することを
特徴とする請求項１に記載の方法。
【請求項４】サービスセッションオブジェクトは、こ
のファクトリオブジェクトを介してサーバの一つによっ
て管理されることを特徴とする請求項１に記載の方法。
【請求項５】個々のサービス要求について、オブジェ
クトインフラストラクチャを介して、オブジェクト指向
の計算環境において他のオブジェクトと相互作用し通信
することができる一つのサービスセッションオブジェク
トが生成され、個々のサービスセッションオブジェクト
は個々のサービス呼出しについてサービスの実行を制御
することを特徴とする請求項１に記載の方法。
【請求項６】特定のサーバは、名称とサービスセッシ
ョンキーを入力データとして受信し、サービスファクト
リオブジェクトの適合するオブジェクト参照を返信する
ことを特徴とする請求項１に記載の方法。
【請求項７】他のサーバはセッションキーの抑制に基
づいて特定のサーバに登録されることを特徴とする請求
項１に記載の方法。
【請求項８】特定のサーバは、同じサービスを実施す
るサーバとの間でロードの均衡を取ることを特徴とする
請求項１に記載の方法。
【請求項９】遠距離通信ネットワークの前記または個
々のサービス切換交換局は、インテリジェントネットワ
ークアーキテクチャの通信プロトコルに従って、前記ま
たは個々のサービス制御ファシリティと通信することを
特徴とする請求項１に記載の方法。
【請求項１０】複数のサーバはＣＯＲＢＡオブジェク
トインフラストラクチャの最上部で形成されることを特
徴とする請求項１に記載の方法。
【請求項１１】各サービスセッションオブジェクトの
生成は、ファクトリオブジェクトを介して管理されるこ
とを特徴とする請求項１に記載の方法。
【請求項１２】ファクトリオブジェクトはサービスセ
ッションオブジェクトに関するライフサイクル方針を実
施することを特徴とする請求項１１または請求項６に記
載の方法。
【請求項１３】ファクトリオブジェクトはサービスセ
ッションオブジェクトに関するデマンドライフサイクル
方針の生成を実施することを特徴とする請求項７に記載
の方法。
【請求項１４】ファクトリオブジェクトはサービスセ
ッションオブジェクトに関するデマンドライフサイクル
方針の始動を実施することを特徴とする請求項７に記載
の方法。
【請求項１５】サービスセッションオブジェクトのイ
ンターフェイス定義はＩＤＬ上にＴＣＡＰマップされて
いることを特徴とする請求項１に記載の方法。
【請求項１６】サービスセッションオブジェクトは直
接的に独自のメッセージインボケーションを受け取るこ
とを特徴とする請求項１に記載の方法。
【請求項１７】サービスセッションオブジェクトは、
前記または各サービス切換交換局からＩＮＡＰメッセー
ジをメッセージインボケーションとして受け取ることを
特徴とする請求項１に記載の方法。
【請求項１８】各サービスセッションオブジェクトは
独自のスレッドで動くことを特徴とする請求項１に記載
の方法。
【請求項１９】サービスロジック機能の実行を要求す
るサービス要求が、遠距離通信システムの少なくとも一
つのサービス切換交換局からサービス制御ファシリティ
によって受け取られる、遠距離通信システムのサービス
制御ファシリティ内でサービスロジック機能の実行を規
定する方法において、サービス要求はオブジェクト指向
の計算環境内のオブジェクトインフラストラクチャの最
上部に形成されたサービス制御ファシリティの複数のサ
ーバの特定の一つに送られることと、特定のサーバはサ
ービスレポジトリサーバとして働き、利用可能で個々の
サービス要求を実行できる複数のサーバのもう一つを決
定することとを特徴とする方法。
【請求項２０】遠距離通信ネットワークのサービス切
換交換局の少なくとも一つからサービス要求を受信する
手段を含み、それは遠距離通信ネットワークの利用者の
ためにサービスの実行を要求する、遠距離通信ネットワ
ークの一つまたは数個のサービス切換交換局に接続する
ためのサービス制御ファシリティであって、オブジェク
ト指向の計算環境内のオブジェクトインフラストラクチ
ャの最上部で形成された複数のサーバを含み、サービス
要求をサービス制御ファシリティの特定の一つに送る手
段を含み、サービスレポジトリサーバとして働く特定の
サーバを含み、利用可能であり個々のサービス要求を実
行することができる複数のサーバのもう一つを決定する
ことを特徴とするサービス制御ファシリティ。
【請求項２１】複数のサーバを処理する可変数の処理
ノードを含むことを特徴とする請求項１６に記載のサー
ビス制御ファシリティ。
【請求項２２】サービス要求を遠距離通信ネットワー
クのサービス切換交換局の少なくとも一つから受信する
手段を含み、それは遠距離通信ネットワークの利用者に
サービスの実行を要求する、遠距離通信ネットワークの
一つまたは数個のサービス切換交換局に接続されたサー
ビス制御ファシリティ用のサーバノードであって、サー
バノードは、オブジェクト指向の計算環境内のオブジェ
クトインフラストラクチャの最上部で形成されており、
オブジェクト指向の計算環境内のオブジェクトインフラ
ストラクチャの最上部で形成された複数のサーバノード
のもう一つを決定する手段を含み、それは利用でき個々
のサービス要求を実行できることを特徴とするサーバノ
ード。