【発明の詳細な説明】
インテリジェント遠隔通信網における資源利用可能性
本発明は遠隔通信網、とくに分散型計算機を使用する遠隔通信網に関する。
現在の遠隔通信網は、単純な電話接続に加えて多くの多様なサービスを提供す
ることが求められている。網を十分に使用するために、オペレータは網全域で潜
在的な顧客に対して多くのサービスを提供している。
フリーフォン(Freefone)（料金先方払いの電話サービス）のようなサービス、
発呼カード、割増し料金サービスのテレボーティング(televoting)：電話による
世論投票、およびデータ転送サービスとこれに類似するものは、各サービスに専
用の計算機を使用して提供される。テレボーティングのようなサービスを制限さ
れた期間に行なう限り、本質的に一過性であり、これらのサービスを専用計算機
を使用して提供するならば、高価な資源浪費を行うことになる。さらに、短期間
の間に専用サービスの特徴およびデータの場所に対して多数の呼が行われるとき
、専用計算機を使用すると網が混雑することになる。さらに、サービスを保護す
るために、各サービスに専用の多数のユニットが必要となる場合がある。これに
加えて顧客が多数のサービスを要求するときは、データを複写することになるの
で、例えば潜在的なデータメンテナンスの問題が生じる。
それぞれがプログラムを作成して多数の異なるサービスを提供できる計算機か
ら成る計算機網を使用することが提案されている。これによって一定のサービス
に専用の計算機ユニットが必要なくなるわけではないが、とくに新しいサービス
の提供をテストしているとき、高価な計算機を一層効果的に使用できるようにな
る。さらに、計算機を分散して配置することによって、網オペレータは特定のサ
ービスを網内の異なる位置で提供でき、それによって網内のトラヒックを一層均
等に分配することができる。
しかしながら、網オペレータは、同一計算機資源において応用が競合しないこ
と、および多数のサービスが要求され、それらが協働するとき、同時に十分な計
算機資源が利用可能であることを確実にする必要がある。
本発明によると、サービス生成施設および多数のプログラマブル資源を有する
計算機プラットフォームを含む遠隔通信網であり、該プログラマブル資源はそれ
ぞれ、サービス生成施設によって定められた複数の機能を含むサービスパッケー
ジ内に少なくとも１つの機能を供給することができ、制御手段がこのようなサー
ビスパッケージを定めるサービス生成施設からのデータに応答して、多数のプロ
グラマブル資源内でパッケージの機能を割当て、この割当てにしたがって遠隔通
信網で呼をサービスパッケージへ送り、サービス生成施設が将来実行する付加的
なサービスパッケージを定めるときには、サービス生成施設はデータを制御手段
へ送り、このデータが付加的なパッケージに必要な機能および資源と該機能およ
び資源が必要とされる時（時刻）とを定め、制御手段が特定の期間の間利用可能
な機能および資源と必要とされる機能および資源とを比較して、付加的なサービ
スパッケージを供給できるか否かを判断することを特徴とする遠隔通信網が提供
される。
ここで本発明にしたがう分散型計算機環境を添付の図面を引用して例示的に記
載する。
図１は、分散型計算機環境を使用する遠隔通信網の構成図である。
図２は、図１のインテリジェンス層を一層詳細に示す構成図である。
図３は、図２の計算機環境層を一層詳細に示す構成図である。
図４Ａおよび４Ｂは、特定のサービスに対する呼中に図１の網内で行われるデ
ータ交換を示す。
図５は、本発明にしたがって遠隔通信網で使用されるサービス生成環境の概略
的なブロック図である。
最初に図１を参照すると、本発明は主として遠隔通信網１において使用され、
該遠隔通信網１はインテリジェンスドメイン２、トランスポートドメイン３、お
よび顧客構内装置ドメイン４を含む。この“インテリジェント”網はオペレーシ
ョナルサポートシステム５（ＯＳＳ）によって管理される。
トランスポートドメイン３は、１または複数の遠隔通信網を含み、それにはス
イッチのある種類とスイッチのない種類とがある。本発明の目的について唯一記
載しておかなければならないことは、トランスポート領域３の網のタイプは重要
ではなく、データまたはＴＤＭ／ＰＣＭ音声網、移動網、データ網、あるいはそ
の他の管理された広帯域システムであってもよいことである。
ＯＳＳ５は、顧客サービス、網能力、およびインテリジェントドメイン２に対
するインターフェイスを管理して、全インテリジェント網１の全域で高レベルの
集中管理を行う。顧客構内装置ドメイン４は網１内で、顧客構内装置と種々のト
ランスポート網とサービスとの間にインターフェイスを有する。
繰り返すが、本発明の目的に対して、実際の顧客構内装置は本発明の構成に対
しては重要ではなく、単に顧客と提供される網サービスとの間のインターフェイ
スである。
ここで図２に関して、インテリジェントドメイン２は全応用21および計算機環
境22から成り、呼サービスおよび特徴に対してサービス管理機能を実行する。こ
れは、トランスポート網３とも接続して、完全に機能することができる。
ここで図３を参照すると、計算機環境２はカプセル化層221、分散型計算機環
境222、サポートインフラストラクチャ（または、“計算機プラットフォーム”
）223、および内部網形成構成224を含むと考えられる。
網形成構成224は、計算機環境22内でのデータ通信部31および外部トランスポ
ート網３とのインターフェイス（図３には示されていない）を設けている。した
がって、計算機環境は外部と通信するときに使用する通信技術から独立している
。
さらに、網形成224は、計算機環境22に対して網管理機能33およびオペレーシ
ョナルサポートシステム32を設けている。
計算機プラットフォーム223は、多数の汎用計算機34（その１つのみが図示さ
れている）およびそのそれぞれに関係するオペレーティングシステム35を含む。
計算機プラットフォームは物理的に広範囲に分散させることができ、計算機34を
共通の場所に配置する必要はないことに注意すべきである。
計算機を分散して配置することによって構成は、応用層21によって要求された
ときに実時間応用と関連する管理とを支援するように機能することができる。理
解されるように、計算機34の全てが同じタイプではない。とくに、一定のサービ
スに特定のハードウエアが必要なとき、ユニットごとに処理電力、メモリの利用
可能性、および接続される周辺装置が異なる。カプセル化層221は、分散型計算
機システム内で利用可能な資源の記録を維持する。このような資源には、特定の
トランスポートおよび音声周辺装置を含むことができ、例えば、カプセル化層は
このような資源に対して適切な応用プログラミングインターフェイス（ＡＰＩ）
を有する。カプセル化層221はＯＳＳサーバ36を有し、各ＡＰＩを介して資源を
管理する。
ここで分散型計算機環境層222に関して検討する。これは種々の機能を提供し
て、“走行時間”に顧客が要求する応用をトランスポート網（図２に参照符号３
で示されている）とリンクする。顧客は特定の応用が存在する場所を知る必要は
ない。したがってインテリジェント網では、分散型計算機環境22は統一性のある
（コヒーレントな）サービス応用を含み、これは例えば単一のコンピュータ34内
に存在する場合もあるし、異なる物理的なロケーションに存在する場合もある。
一定のサービス応用をシステム全体で複製できる場合もある。
ロケーション（位置決め）機能40はロケーションの透明性を与えて、物理的ロ
ケーションに対してアドレス可能な資源、サービス、および機能の論理名をマッ
プして、要求されたサービスを顧客に提供する。ロケーション機能40は（サービ
ス生成環境からアクセスするとき）トレーディング（取引き、商用）機能(tradi
ng functon)を含み、照会を特定の周辺装置またはサービスのタイプに合せて、
サービス提供を登録（またはキャンセル）する。例えばテレボーティングサービ
スのために音声アナウンスメントを行なうことができる周辺装置を要求して、マ
ルチフレケンシートーン応答を収集し記憶するとき、トレーディング機能は資源
機能と関係して、何れの物理的ロケーションで（該当するものがあるとき）サー
ビスを満足させることができるかを識別する。２以上のロケーションがサービス
を提供できるとき、資源制御機能41は負荷バランスおよびセキュリティのような
要素を検討して、何れのサービスを選択するかを判断する。
サービス生成要求および資源制御41の判断に応答して論理サービスが選択され
ると、ロケーション機能40はそのディレクトリを使用して論理サービスを物理的
アドレスにマップする。
ポリシイ（方針）サービス機能42およびセキュリティサービス機能43は、応用
および計算機資源へのアクセスを制御する。ポリシイサービス42は特定の故障に
関するユーザに固有のポリシイを保持する。したがってＯＳＳ（図１において参
照符号５で示されている）は機械の故障、リンクの故障、およびプロセスの故障
のときに実行される機能に命令する一方で、その他の状況（例えば網の混雑が発
生したときに、分散型計算機環境22はポリシイサービス42に照会することができ
る。
サービス品質（ＱｏＳ）要求もポリシイサービス機能42に含まれるので、シス
テムの１構成要素が要求を満たすことができないとき、システムは修正動作とし
て、計算機資源(223)を再割当てするか、または網アクセスに対する保護制御を
行って予め割当てられた資源に対する呼を制限することができる。
資源サービス41は、効果的で統一性のあるやり方でプラットフォーム資源223
の管理を行う。資源サービス41に含まれる機能は、監視、移動、制御、配置、優
先化、および負荷バランスを含む。
ここで次にこれらの各機能の特定の動作に関して検討する。
監視機能は、分散型計算機環境22の特性(behaviour)に関して検査を行う。監
視機能には、負荷または故障に対して集められた情報をフィルタする能力を含み
、重要なイベントが発生したときを判断する。監視機能は、ポリシイサービス42
を参照して適切な動作を行うように構成することができる。例えば、特定の名前
の機能がそのＱｏＳ（サービス品質）要求を満たすことができないとき、監視機
能はポリシイサーバ42から関係するポリシイステートメントを検査する。これが
サービスを別の領域へ移動すべきことを明記しているとき、監視機能はファクト
リ（工場）サービス(factory service)44に照会して、要求されるサービスの別
の段階を開始する。
移動機能は応用を別の場所に移動するためのものである。このサービスは別の
機械に含まれるか、または計算機プラットフォーム223内の同じ機械の同じ処理
の別の段階であってもよい。
制御機能は、提供されるサービスの開始および停止を調整する。これは呼を失
わないように、新しいサービスの開始および停止を行うことができる。
配置機能は、機械、現在動作している構成要素、通信リンク、およびデータメ
モリなどに関する計算機プラットフォーム22の現在のトポロジの配置マップを維
持する。
優先化機能は、特定のサービスに割当てられた優先度にしたがって応用をスケ
ジュールする。この機能は応用の優先度を判断しないが、応用の優先度を変更で
きる優先度機構を提供する。
負荷バランス機能は、サービスに対する現在のまたは予測される負荷に依存し
てサービスの特定の段階を要求する。とくに、サービスの２以上の段階が要求に
合うときに、トレーディング機能（上述で説明したもの）が特定のサービスのた
めのサービス生成施設に応答するとき、負荷バランス機能は使用できる最も適切
なサービスを判断する。
ファクトリサービス44は、サービス生成環境および資源機能41に応答して、サ
ービス応用の特定の段階を設定または停止する。例えば、計算機プラットフォー
ム内の特定のサービスの別の段階を要求して、このサービスに対して増大した要
求を満たすことを資源制御サービス41が判断したとき、資源制御サービス41はフ
ァクトリサービスに命令して、適切な機械34で適切な処理を開始する。同様に、
特定のサービスが最早必要ないとき、または特定の処理がデッドロックした、す
なわち最早機能しないと管理システムが判断したとき、ファクトリサービスはサ
ービスの特定の段階の動作を停止する責務を負う。
最後に、分散型計算機環境222内のデータ分配機能45によって、分散型データ
ベース管理システムは、計算機プラットフォーム内または計算機環境22内の種々
のデータベースにおいて分散され複製された全てのデータの単一の論理的視界を
示す。データ分配サービス機能内のデータ移動機能は、それを必要とするところ
の最も近くにデータを配置することを確実にする。この機能は分散型計算機環境
22においてデータ分配の断片化または複製を制御する。データ分散機能は、計算
機プラットフォーム223内で走行している応用によって要求されるデータの場所
が透明であることを確実にする。
分散型計算機環境222内にはイベント通知サービスもあり、予め決められイベ
ントに応答して、そのイベントが発生したことをそのような通知が要求されると
きに予め登録された資源に通知する。例えば、特定のサービスエンジンが、特定
の顧客に関してキャッシュされたデータを保持するとき、データサービスによっ
て保持されるデータの更新は、このサービスエンジンに更新を通知する。
図３のシステムの動作の理解を助けるために、プロプリエタ(proprietor)“０
８００”または“フリーフォン”サービスのようなサービスを検討する。
図４Ａおよび４Ｂを参照すると、各潜在的相互作用にシーケンスで番号を付け
られ、次のように動作を行うことができる：
５１ トランスポートサーバは、フリーフォン番号の変換を要求する呼を終了
する。トランスポートサーバは、この呼を処理することができるサービスエンジ
ンにこの呼を送らなければならないことを知っているが、それはこのようなサー
ビスエンジンの物理的アドレスを知らない。実行部はもちろんショートカットを
行なって、このような情報を“キャッシュ”することができる。ロケーションサ
ービスはサービスエンジンの物理的アドレスに要求される。トレーディング機能
を呼出して、要求されるフリーフォン番号の変換をサポートすることができる論
理サービスエンジンを戻す。この論理名は、ディレクトリサービスによって物理
的アドレスに変換される。繰り返すが、実行部は物理的アドレスをトレーダ内に
記憶することができ、（この場合）このトレーダはディレクトリサービスの使用
を必要としない。しかしながら、２以上の適切なサービスエンジンがあるので、
何れか１つを選択すべきである。トレーダは意志決定能力をもたないので、資源
制御サービス内の負荷バランス機能を使用しなければならない。これはまた、ポ
リシイサービス内のポリシイ機能を使用しなければならない場合もある。
５２ 負荷バランス機能はトレーダ（取引者）からサービスエンジンのリスト
を与えられ、使用する何れか１つを判断する。
５３ ポリシイ機能によって、負荷バランス機能が遭遇した特定の機能状態に
関するポリシイを供給することを要求する。
５４ ポリシイを戻す。
５５ 論理的サービスエンジンを識別するとき、その物理的アドレスを要求す
る。ロケーションサービス内のディレクトリ機能を使用する。
５５Ａ 段階51において、トレーディング機能は単一の論理的サービスエンジ
ンのみを識別して、要求されるサービスを提供するとき、上述の段階52乃至55は
必要なくなることに注意すべきである。
５６ サービスエンジンの物理的アドレスをトランスポートサーバに戻す。
５７ サービスエンジンを呼出す。これはサービスプロバイダのサービス論理
を処理する能力を有するが、その特定のフリーフォンの呼に対するサービス論理
をもたない。例えば０８００ ６４５７４３をダイヤルするとき、サービスエン
ジンは、ルート設定命令および関係する番号を含むサービスプロバイダ“６４５
７４３”のプロフィールを必要とする。例えば、時刻のルート設定、曜日のルー
ト設定、年内の第何週、自動呼分配、呼停止があり、これらはそれぞれ適切な宛
先番号および命令を含む。
５８ サービスエンジンはサービスプロバイダのプロフィールを必要とする。
データ分配サービスのアドレスを得て、プロフィールに関してそれに照会するこ
とが必要である。実行部はもちろん“よく知られた”アドレスに構成要素のイン
ターフェイスを保持することができ、トレーダを含む必要がない。このようなア
プローチの限界が示され、理解できるとき、これが幾つかの場合に許容可能なこ
とを証明することができる。
５９ 上記の５２に関して、このようなときでも、負荷バランス機能はデータ
分配サービスを要求する。
６０ 上記の５３に関して、このようなときでも、ポリシイ機能はデータ分配
サービスを要求する。
６１ データ分配サービスのポリシイを戻す。
６２ ５５に関して、このようなときでも、それはデータ分配サービスの物理
的アドレスを要求する。
６２Ａ 繰り返すが、トレーディング機能が単一の適切なデータ分配サービス
のみを識別するとき、段階59乃至62は不必要であり、トレーダはディレクトリ機
能と直接に相互作用する。
６３ ディレクトリ機能は、データ分配サービスの物理的アドレスをサービス
エンジンに戻す。
６４ サービスエンジンは、要求されたサービスプロバイダのプロフィールに
関してデータ分配機能を要求する。
６５ データ分配サービスは、プロフィール用のデータサービスを調べる。
（繰り返すが、トレーダを関連させることはできるが、もちろんデータ分配サー
ビスは実行部にデータサービスのアドレスを保持して、別のショートカットをと
ることができる）。
６６ 要求されたデータをデータ分配サービスに戻す。
６７ サービスエンジンによって要求されたデータを戻して処理し、ルート設
定命令（宛先番号を含む）を生成する。
６８ 適切なルート設定命令（宛先番号を含む）をトランスポートサーバに戻
す。
６９ 呼は特定の宛先にルート設定される。
上記の０８００およびフリーフォンサービスは、提供されるサービス中のたっ
た１種類のサービスである。インテリジェント網１を使用する別のサービスは応
用、例えばテレボーティング、テレメタリング、情報サービス、ホーム制御、オ
ンラインエンタテインメント、およびこれに類似するものを含む。
したがって、新しいタイプの各サービスが識別されるとき、適切な周辺装置お
よびソフトウエアを図１のインテリジェント層２内のどこかに配置することのみ
が必要である。
本発明の理解を容易にするために、サービス生成環境が現在どのように動作し
ているかを理解することが必要である。サービス生成環境は、個々の顧客によっ
て特定される顧客要求を網動作要求およびソフトウエア供給に変換する位置であ
る。
図５にはサービス生成環境が概略的に示されており、ここでこれを参照する。
このサービス生成環境は４つのレベルを有する。網レベル104（ハードウエア能
力）には、物理的な網のプラットフォームおよび周辺装置が配置されている。第
２のレベル103は網のプラットフォーム用のソフトウエアを含み、特徴を与える
。第３のレベル102は、特徴からサービスを構築し、第４のレベル101はサービス
パッケージを使用して、顧客の要求に応答してサービスを提供する。
したがってレベル101では、サービス生成環境内のワークステーションのオペ
レータは、顧客によって要求されるサービスに関して顧客情報を受領する。利用
可能なサービスパッケージを使用して、例えばフリーフォンサービスに関してす
でに説明した既存のサービスパッケージを修正することによって、オペレータは
顧客によって定められるサービスを提供することを要求する。この手続きはアイ
コンを使用して実行され、計算機のスクリーン上でそれらをリンクすることによ
って、ツールに適切なソフトウエアをアセンブルさせて、上述のようにファクト
り資源44を使用して、新しいサービス105を提供するときに、この新しいサービ
スを配置する。
顧客の要求が第１のレベルに合わないとき、顧客は新しいサービスを提供する
責務を負う製品定義チームに要求する。製品定義レベル102において、既存のソ
フトウエアとハードウエアとの組合せ構成は、利用可能なサービスの特徴を組合
せて、要求されるサービスパッケージを供給するか否かを判断すると考えられる
。これが当てはまるとき、新しい特徴の記載106が生成され、利用可能なサービ
スパッケージ107として配置される。
網における既存のサービスの特徴が、要求される新しいサービスパッケージを
供給するのに不適切であるとき、ソフトウエア開発チームに対して要求すること
ができる。
ソフトウエア開発段階103において、ソフトウエアチームはインテリジェント
網（図３の参照符号２参照）内で利用可能な資源の全てを検討して、要求される
特徴をもつソフトウエアを提供することが実際的であるか否かを判断する。これ
が当てはまるとき、新しいソフトウエア108を書込んで、要求される新しい特徴
を109に与えることができる。
ソフトウエア開発レベルが要求されるサービスを提供できないとき、網設計者
がハードウエア能力を網に付加して新しいサービスが提供できるようにすること
が必要な場合がある。
上述の説明は特徴的に反応的である、すなわちレベル101で顧客要求に応答す
る一方で、サービスプロバイダはいつでもサービスに対する要求を見越して相関
的な特徴および網能力を供給する段階を達成することができる。
サービス生成プロセスは、文献（BT Technology Journal vol 13，no.2，1995
年2月，80頁〜G D Turner著”Service Creation”）に詳細に記載されている。
ここで、以前は特定の顧客要求に応答するこのようなサービス生成のために、
特定の顧客に割当てられた特定のプラットフォームまたはサービスエンジンが生
成された。顧客に提供される資源の量またはサービス品質に関する既存の利用可
能率および網能力を考慮しなかったことに関して検討される。これはしばしば、
網プラットフォームおよびハードウエアを供給し過ぎたり、または資源を相当な
時間アイドル状態のままにして浪費したりすることになる。１つのタイプのサー
ビスを生成する間、網サービスを特定するとき、このサービスの動作要求も生成
される。このような要求はデータ規定の優先度、確実性（機械および呼時間応用
の両方）、非両立性の呼時間応用の識別、同時発生情報、デッドライン、呼時間
応用、寿命、動作要求、およびサービス品質の要求を含む（しかしながら、これ
らに制限する必要はない）。
優先（度）データは、網が混雑したとき、装置が故障したとき、または計算機
システムがデッドロックしたときに呼時間応用を選択またはこの選択を拒否する
ことができる。
機械の信頼性によって、呼時間応用を実行することができる計算機プラットフ
ォームにおいて機械の特徴を特定することができる。ここで記憶したデータはプ
ロセッサの利用可能率、メモリの利用可能率、および特定の機械に対する通信の
利用可能率に関する情報を含む。
別の方法で機械の信頼性を特定する代りに、呼時間応用の信頼性を使用するこ
とができる。これは、分散型計算機環境それ自身が呼時間応用を管理することを
特定する。分散型計算機環境222が故障が発生したときに資源を再割当てする能
力を考慮すると、これが好ましい選択肢であるときがある。
非両立性は同一機械で同時に実行すべきではない呼時間応用を定める。同時に
実行することを許可すべきではない別の呼時間応用のリストを供給することがで
きる。同じ呼時間応用がデッドロックになるか、または同じ周辺装置を競合して
使用することになり易いとき、このリストに含まれる応用は、同じ呼時間応用の
第２の段階にすることができる。
同時発生データは、応用内の多数のサブプログラムが同時に動作することを要
求するか否かを特定する。例えば、呼を行う一方で、呼時間応用は“スレッド(t
hread)”を広げてセキュリティサービスまたは監査サービスと相互作用する。デ
ッドラインを満たすのに必要なやり方で、それを動作させるのに必要な多数のス
レッドを特定することができる。
デッドライン（締切り）は、呼時間応用がその実行を完了しなければならない
期間を定める。呼時間応用は、網全体に転送される情報に時間的に依存する。こ
の情報は、例えば、図３の資源機能41内で使用することができる。
呼時間応用の寿命から、特定の応用を開始および終了する日付けと時刻が得ら
れる。サービスプロバイダは呼時間応用を判断し、網サービスを、例えば週１日
とか、または一日の特定の時間パターンで提供するかを選択することができる。
呼応用が存在することになる時を知ることによって、計算機プラットフォームお
よび網内で全体的な資源をよりよく利用することができる。
動作要求は、呼時間応用によって要求されることになる計算機資源を定められ
る。したがって、呼プロセッサユニット要求、入力／出力（ｉ／ｏ）、およびデ
ータサーバ動作を識別することが必要である。したがって、呼時間応用は、多数
の資源と相互作用することができ、この資源には例えばデータサーバ、ＯＳＳサ
ーバ、入力／出力サービス等が含まれる。呼時間応用がローカルデータメモリを
必要とするときの要件も、能力要求、例えば要求されるＭＩＰＳ値または“標準
”トランザクションと一緒に定めなければならない。
動作の要件によって、キャッシュすべきデータを識別することもできる。これ
は、例えば、データ分配サービスに対する別の応用を避けることによって、呼時
間応用の機能を向上することになる。
サービス品質（ＱｏＳ）情報は顧客が期待するサービスを実際に定める。例え
ば、ＱｏＳは、インテリジェント網２において５００ミリ秒の制限速度で呼を処
理するが、ときどき呼の処理に６００ミリ秒かかったときに、末端の顧客がこれ
に気付かない可能性が高いので、より長い制限速度を有することになる。しかし
ながら、網２内の呼がＱｏＳのデッドラインに合わなかったときを知ることが必
要である。これによって長期間の資源調節を行うことができる。
呼時間応用は常に独立した機械というわけではなく、網２が分散型汎用計算機
環境を提供する一方で、それが多数の標準型機械以外の機械を含むことができ、
再び図３を参照すると、資源機能41は特定された周辺装置および機械の何れが利
用可能であり、それがどこにあるかが分かることに注意すべきである。サービス
生成環境によって各応用に対して上記の記憶したデータを使用して、分散型計算
機環境22を効果的に使用することを確実にする。したがって、顧客がサービス生
成環境を要求して、特定の時間に特定のサービスを提供するとき、サービス生成
環境は分散型計算機環境222に情報を送る。分散型計算機環境がサービス品質お
よびデッドラインデータおよび応用の寿命を含むデータを使用して、呼時間応用
ダイヤリおよび計算機プラットフォームダイヤリを調べる。計算機プラットフォ
ームダイヤリは、計算機プラットフォーム223と関するスケジュールを含み、こ
れはプラットフォーム内で種々の機械の利用可能率を示し、サービス提供または
その他の目的の機械のダウンタイム、新しい機械への更新および導入、並びにそ
れに類似するものがスケジュールされている。プラットフォームダイヤリはさら
に機械の処理能力に対する有効電力の詳細を含み、この機械をグループ化してサ
ービス生成施設から受領した動作要求を満たすことができる。サービス生成環境
から受領した情報と呼時間応用ダイヤリおよび計算機プラットフォームダイヤリ
とを比較して、分散型計算機環境222は呼時間応用を受領したり、応用を拒絶し
たり、または代わりのより低いグレードのサービス品質を提供したりすることが
できる。
呼時間応用ダイヤリを非両立性の呼時間応用に対して検査して、呼時間応用を
受領したとき、更新を行って呼時間応用を訂正する要求を示すことにもなる。
呼時間応用を実行するときは、資源機能41を用いて記述したように分散型計算
機環境内のファクトリ機能４がこの応用を計算機プラットフォームにおいて開始
する。サービスの場所を示して、呼が網３から到達するとき、ロケーションブロ
ーカは呼を処理できる機械の物理的アドレスに呼をルート設定する。多数の計算
機34が特定のサービスに対して同じ応用を実行するとき、ロケーションブローカ
は、スケジューリングアルゴリズムにしたがって特定された機械のグループによ
って呼の分配を行う。第１の段階でサービス生成施設によって命令されるように
、呼時間応用を付加したり除去したりすることができる。１または複数の機械で
故障を検出したとき、前もってダウンロードした優先度データおよびＱｏＳ要求
にしたがって、資源機能421は別の両立性の機械において応用を確立することを
要求する。
上記のように、呼時間応用プログラムの配置を参照する一方で、プログラムを
環境222において常に利用可能にすることができ、サービス生成施設は、例えば
ダイヤルした番号を網の他の番号にマップするサービスデータを供給することに
よって、呼時間応用に関するデータを分布させる。この場合、タギング情報（す
なわち、ＱｏＳ、計算機の電力要求、など）をデータにタグすることもできる。
したがって、呼時間応用ダイヤリを使用して、計算機プラットフォーム資源の利
用可能率に分布されたサービスデータの要件をマップすることができる。
多数の計算機がそれぞれ特定のサービスに対する応用を実行する能力を有する
とき、呼時間応用ダイヤリの計算は、必要なＭＩＰＳ値を示すタグを使用して必
要なＣＰＵのサイクル数でサービスを実行することができる。これによって、特
定の機械で利用可能な計算機サイクルの総数まで計算機資源を割り当てることに
よって、実行時間環境がサービス生成環境内で機械の割当てを完了するよりも一
層効果的になるように、実行時間環境にサービスをマップすることができる。
─────────────────────────────────────────────────────
フロントページの続き
(81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，
ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ
Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ
，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，
ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ
Ｚ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ
，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ
，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，
ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，Ｉ
Ｌ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ
，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，
ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ
Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ
，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ
(72)発明者 マーティン、ポール
イギリス国、アイピー13・６エヌワイ、サ
フォーク、グレート・ビーリングス・ウッ
ドブリッジ、ホール・ファーム・ロード、
（番地なし）、コーチマンズ・コテージ
(72)発明者 コンディー、スティーブン・ジョン・トー
マス
イギリス国、アイピー12・２ピーエック
ス、サフォーク、エヌアール・ウッドブリ
ッジ、ブロムスウェル、スクール・レーン
（番地なし）、ザ・ビーチーズ