JPH10510377A

JPH10510377A - コンピュータ制御されたシステム

Info

Publication number: JPH10510377A
Application number: JP8517544A
Authority: JP
Inventors: グスタブスベンソン，ラルス; ウルリクイエンセン，ラルス; − ロスト，アンナナエミィインゲボルグホルテ; ミカエルサミュエルソン，ボ
Original assignee: テレフオンアクチーボラゲツトエルエムエリクソン（パブル）
Priority date: 1994-12-09
Filing date: 1995-12-08
Publication date: 1998-10-06
Also published as: FI972408A7; CN1097786C; FI972408L; WO1996018145A2; BR9509887A; EP0796469A2; CA2206928A1; AU4277096A; WO1996018145A3; CN1169194A; NO972598L; MX9704001A; AU699695B2; KR100421796B1; SE9404296D0; NO972598D0; KR980700606A; FI972408A0

Abstract

(57)【要約】コンピュータ制御されたシステムが処理アーキテクチャを含む。この処理アーキテクチャは、相互に作用し合い、制御システムと作用し合い、このアーキテクチャ外の世界と作用し合う協同処理として実行されるアプリケーションプログラムを提供する。処理実例（送り手、Ｐ１、Ｐ２、Ｐ３）は分配ユニット（Ａ−Ｆ、Ｒ、Ｓ）によって制御システムプロセッサ（ＣＰ１、ＣＰ２、ＣＰ３）に跨って分配される。

Description

【発明の詳細な説明】コンピュータ制御されたシステム発明の技術分野本発明は、概略的に言って、例えば電気通信ネットワークにおけるネットワーク要素に含まれる種類のコンピュータ制御されたシステムに関する。電気通信ネットワークは、ネットワーク要素、即ち、ネットワークユーザにネットワークサービスを提供するのに協力し合うシステムで構成される。１ネットワーク要素によってサポートされる多数の異なるサービスは、そのネットワーク要素内のコンピュータシステムによって記憶され処理されるソフトウェアによって大部分は認識される。そのコンピュータシステムは、ネットワークとサービスに関連するデータを記憶し、サービスを制御し、宅内施設装置や他のネットワーク要素と相互に作用し、局所伝送・交換ハードウェアを制御する。物理的装置の観点からそのコンピュータシステムを見ると、そのコンピュータシステムハードウェアは、主に、多数の異なる装置組立品の間に分割された、多数の通信的に連結され協力し合うプロセッサと大容量記憶装置から構成される。関連技術の説明欧州特許405,829は、そのソフトウェアがオブジェクトの形式の独立したソフトウェア成分により実行される電気通信システムに関する。ランタイムシステム中の機能ランタイムリンカは、それらオブジェクトを記録し、それらオブジェクトのデータへのデータポインタを記憶する。他のオブジェクトと通信するため、供給元オブジェクトがそのランタイムシステムにメッセージを送る。そのメッセージは供給先オブジェクトの方法の名称と識別とを含む。そのランタイムシステムは単一プロセッサにのみ働くか、あるいは、オブジェクト群に働き、もしその供給先オブジェクトがランタイムシステムによりサーブされたオブジェクト群に属するならば、方法の識別とデータポインタとによりその供給先オブジェクトを呼び出す。供給先オブジェクトが他のあるプロセッサ上に位置している場合には、そのランタイムシステムは他の複数のプロセッサにそのメッセージを同報する。メッセージを受け取る各プロセッサにおいて、ランタイムシステムはそのリンカテーブルからそのメッセージの供給先オブジェクトの記号名を検索し、見つかれば、メッセージ中の方法識別とランタイムリンカ中のデータポインタ情報とに基づいて供給先オブジェクトを呼び出す。プロセッサ間メッセージは供給元プロセッサ供給先を含み、各プロセッサのランタイムシステムは、プロセッサ間メッセージを受け取ったとき、供給元プロセッサの名称と供給元オブジェクトの記号名を記憶する。米国特許4,901,231には、複数のプロセッサにわたって実行するマルチプロセッサシステムが記載されている。１プロセッサにおけるユーザ処理は、他のプロセッサ中のシステムリソースにアクセスすることができる。あるユーザ処理が局所ファイルにアクセスするとき、そのアクセスは、例えば、ユーザファイルテーブルによってなされる。そのユーザ処理が遠隔ファイルにアクセスするときには、ポートテーブルを経てそのポートテーブルにより識別された仮想チャンネルを越えて部分処理へアクセスがなされた後に、その部分処理のユーザファイルテーブルとシステムファイルテーブルとを経てアクセスがなされる。米国特許5,187,790は、少なくとも１個のサーバ処理と複数個のクライアント処理を含む複数個の一斉稼働処理を行うコンピュータシステムに関する。各処理はオブジェクトアクセス権を示す識別リストを有する。各オブジェクトは、そのオブジェクトにアクセスしうるプロセッサを決定するために使用される識別を持つアクセス判別リストを有する。概要いずれのコンピュータ制御されたシステムも、少なくとも１個のプロセッサ上で実行する制御プログラムを有する。今日、アプリケーション開発が容易であること、システムが非常に高い有用性を有すること、その容量等をアップグレードするのが容易であること、というようなシステムに対する多数の要求が存在する。そのような要求に応じる方法は、システムを、アプリケーション領域の問題のみをアプリケーションプログラマに残しつつ大部分の共通問題点に気を付けるようになっている制御システムプラットホーム上でアプリケーションをプログラムする重層アーキテクチャで設計することである。そのようなアーキテクチャでは、アプリケーションプログラムは多くのオペレーティングシステムソフトウェアと共に協同処理として実行される。複数のプロセッサをその処理アーキテクチャ中に適応させるのは、少々厄介である。プロセッサを単にリソース提供者と見なすと、オペレーティングシステムはアプリケーションプログラムから個々のプロセッサが見えないようにしてあたかも１つの大きなプロセッサというイメージを与えることが求められる。一方、異なるプロセッサ、即ち、システムを外界に繋ぐハードウェア装置を制御する、それら自身の特性と特別な能力を持つ異なるプロセッサが存在するということは、アプリケーションプログラムを異なる処理へモデリングするために最も重要な条件である。プロセッサを扱う際に、プロセッサにより提供されるリソースをできるだけ効率良く利用する様にシステムを構築することが、また、必要である。しかしながら、これは、制御システムが個々のプロセッサをアプリケーションプログラマからできるだけ見えないようにすることを止めさせるようなことがあってはいけない。それゆえ、プログラマの観点からは、制御システムが、プロセッサに実行・メモリリソースと、 −持続的なデータ記憶のためのデータベース、 −管理されたオブジェクトを実行するためのフレームワーク、 −タイマのような正常オペレーティングシステムサービスと時計、 −アプリケーションプログラムの管理、 −開始と再開手続きの制御、エラー回復、等というような異なるサービスとを手渡す均質なプラットホームとして見られるということが望ましい。本発明によるコンピュータ制御されたシステムは、上記データベースの異なる部分を取扱う多数の制御システムプロセッサからなる制御システムプラットホームと、プロセッサにより提供されるリソースを管理して制御システムにより提供される抽象概念を実行するオペレーティングシステムと、処理リソースの表現とから構成される処理アーキテクチャを含む。その処理アーキテクチャは、相互に作用し、かつ、制御システムやこのアーキテクチャ外の世界と作用し合う協同処理として実行されるアプリケーションプログラムを提供する。処理リソース表現の実例は、それぞれが処理例の群を形成する分配ユニットにより制御システムプロセッサ全体に分配される。これら分配ユニットは、特定の分配ユニットタイプに属し、各分配ユニットタイプはそのタイプの分配ユニットに共通な性質を示す。ここで処理とは１個の独立した実行ユニットを意味し、システム中の他のプロセッサが同時に何をしているかには拘わらずそのユニットがプログラムコードを実行するということを意味する。各処理はそれ自身の私的な状態を持つ。すなわち、１つの処理は他の処理に属するデータ上で直接働くことはできない。１つの処理は、その処理タイプの実例を形成する特定のタイプのものでありうる。その処理タイプはその処理がどの機能を持つかを決定する。異なるタイプの処理は異なることを行い、一方、同じタイプの実例は同じことを行うが異なるデータ上または異なるハードウェアユニット上で稼働する。処理実例は、プログラムコードを実行する物理処理実例と、抽象概念の形の論理処理実例とを含むことができる。あるシステム中のこの種の論理処理実例は、そのシステム中に存在している処理タイプとそれらの性質によって決定され、ハードウェア装置の意味ではそのシステムの構成によって決定される。分配ユニットは、論理処理実例と物理処理実例の両方をグループ分けすることができる。実例と分配ユニットとの関係が論理実例で表現されるから論理実例はグループ分けされ、またある分配ユニットがあるプロセッサに割り当てられているときその分配ユニットに関連する全ての物理処理実例がその特別なプロセッサ上で作られるから物理実例はグループ分けされる。さらに、処理は中央処理タイプを含み、各処理タイプに対して１つの論理処理実例が存在する。また、キーによって識別される実例を持つ処理タイプであることができ、各キー値に対して１つの論理処理実例が存在する。異なる処理タイプはそれら各キー上で異なるタイプを持つことができ、こうして、異なる数の論理処理実例を持つことができる。そのシステム自身中のソフトウェアによってインストールされた実例を持つ処理実例は、この処理タイプとともに密接に発展したデータベースオブジェクトタイプを持つことができる。そのデータベースオブジェクトタイプの１つの実例は、１つの論理処理実例に相当する。分配ユニットと今述べた種類の処理実例との関係は、処理タイプに対して次のように表現できる。中央処理タイプでは、それは些細なことである。なぜなら、たった１つの論理実例があるだけだからであり、その結果、たった１つの分配ユニットが存在できるだけだからである。その実例がキーによって識別される処理タイプでは、その数の分配ユニットが処理仕様とともに１つの定数として特定され、その関係は各キー値を分配ユニットの１つの上にマップするプログラムされたアルゴリズムとして表現される。実例がそのシステム自身中のソフトウェアによってインストールされた処理タイプでは、データベースオブジェクト間の関係によって表現されるように処理実例は分配ユニットにおいてグループ分けされる。処理は、さらに、制御システムが各論理実例に対して１つの物理実例が常にあることを確かめる静的処理タイプと、ある他の処理がそれと通信したいときに物理実例がつくられることを制御システムが単に確かめる動的処理タイプとを含むことができる。さらなる処理タイプには、２つの実例が協同するが、１つのシステム中の他の処理への１つの処理として働くときあるシステム活性の間を除いて各論理実例に対して１つの物理実例が存在する一意処理タイプと、１つの論理実例に対していくつかの物理実例が存在するかもしれない複製処理タイプとがある。一意処理では１つの分配ユニットが１つの信号プロセッサに一意的に割り当てられ、複製処理タイプでは１つの分配ユニットがいくつかのプロセッサ上で複製されうる。いくつかの処理タイプは、また、そのようなタイプがある共通種類のものであるなら、同じ分配ユニットタイプを共有することを許される。そのような種類は、中央静的一意処理タイプと、キーによる動的一意処理タイプと、中央静的複製処理タイプと、中央動的複製処理タイプと、インストールされた静的一意処理タイプとを含む。キーによる動的一意処理タイプの実例と、その処理実例と同じ１次キーを持つデータベースオブジェクト実例とは、必要に応じて、対応するキーを持つそのようなデータベースオブジェクトの１次複製を保持する同じプロセッサ上でそのような処理実例を実行するのを強要するために、同じ分配ユニットタイプを参照するようにされるのが好ましい。図面の簡単な説明次に添付図面を参照して本発明の実施例を説明する。第１図は電気通信ネットワークを概略的に示し、第２図は、例えば、第１図に示す種類のネットワーク要素のソフトウェア構造を概略的に示す図であり、第３図は第２図によるネットワーク要素に含まれる制御システムプラットホームの構造を概略的に示す図であり、第４図−第８図は異なる種類の処理タイプを示すためのプロセッサプールの概略図であり、第９図はネットワーク要素の概略ハードウェア図であり、第１０図は第９図によるネットワーク要素の概略管理図であり、第１１図は第９図によるネットワーク要素の概略リソース図であり、第１２図は第９図によるネットワーク要素に含まれる制御プロセッサ上での実行が意図された処理実例の分配を概略的に示し、第１３図と第１４図はある制御プロセッサ中の処理実例の、他の制御プロセッサに位置する処理実例からのアドレッシングを示し、第１３図はそれに含まれる分配ユニットを持つ３つのプロセッサの概略図であり、そして、第１４図は検索過程を示すフロー図である。実施例の詳細な説明第１図は基本ＴＭＮシナリオによる電気通信ネットワークを概略的に示す。１０２で示すネットワークは、ネットワークユーザにネットワークサービスを供給するように協同して働くネットワーク要素１０４からなる。１つのネットワーク要素によってサポートされる多数の異なるサービスは、大部分は、そのネットワーク要素内のコンピュータシステムによって記憶され処理されるソフトウェアによって実現される。そのコンピュータシステムは、ネットワークとサービスに関連するデータを記憶し、サービスを制御し、電話加入者装置１０６と１０８によって示される宅内施設装置や他のネットワーク要素と相互作用／通信し、局所伝送や交換ハードウェアを制御する。局所ネットワーク要素１１６の管理のためのオペレーションシステム１１４と同様、そのネットワークのためのオペレーションシステムは１１０と１１２で示す。そのコンピュータシステムを物理装置の観点から見ると、そのコンピュータシステムハードウェアは、主に、多数の異なる装置組立品間で分割された、多数の通信的に連結され協力し合うプロセッサと大容量記憶装置とを含む。いずれのコンピュータ制御されたシステムも、少なくとも１つのプロセッサ上で実行する制御プログラムを有する。今日、アプリケーション開発が容易であるべきだとか、システムが非常に高い有用性を持つべきだとか、その容量等をアップグレードするのが容易であるべきだ、とか言われるようなシステムに対する多数の要求が存在している。そのような要求に応じる方法は、システムを、アプリケーション領域の問題のみをアプリケーションプログラマに残しつつ大部分の共通問題点に気を付けるようになっている制御システムプラットホーム上でアプリケーションをプログラムする重層アーキテクチャで設計することである。そのようなアーキテクチャでは、アプリケーションプログラムや、オペレーティングシステムソフトウェアの大部分は、相互に作用し、制御システムと作用し、ハードウェア装置を介してシステムの外界と作用し合いながら処理で実行されるコードからなる。これは、ネットワーク要素２０２におけるソフトウェア実行環境の論理図である第２図に概略的に示されている。そのネットワーク要素２０２は、ライン２０４、例えば、入力ハードウェア装置２０６において終わる加入者ラインを、例えば、加入者ラインの接続用ライン回路の形で受け取るように示されている。出力ハードウェア装置は２０８で示している。多数の伝送チャンネルからなる幹線２１０は、ハードウェア装置２０８を経由してネットワーク要素２０２を出る。２１２では、スイッチが示されている。ネットワーク要素２０２中のソフトウェアシステムは破線により定義されるブロック２１４によって示されている。ブロック２１４はブロック２１６によって示される制御システムプラットホームと、２１８、２２０、２２２で示される相互に影響し合う処理とを含むように示されている。一例として、処理２１８は矢印２２４で示されるライン回路２０６の１つを制御し、処理２２２は矢印２２６で示されるライン回路２０８の１つを制御することが考えられる。処理２２０は、スイッチ２１２に向かう矢印２２８によって示されるように、これら２つのライン回路間の直通接続を制御する。第３図を参照すれば、制御システムプラットホーム２１４は実行・メモリリソースを提供する多数の制御プロセッサ３０２と、プロセッサ３０２によって提供されるリソースを管理し制御システムによって提供される抽象概念を実行するオペレーティングシステムソフトウェア３０４とから構成できる。３０６には、処理が共通リソースとして示されている。これ以降では、オペレーティングシステムについて話すときには、第３図に示す種類のオペレーティングシステムを参照し、「当該オペレーティングシステム」と呼ぶこととする。処理は、その処理タイプの実例を形成する特定のタイプのものでありうる。その処理タイプはその処理がどんな機能を持つかを決定する。同じタイプの実例が同じことを行うが異なるデータ上または異なるハードウェアユニット上で動作しているあいだ、異なるタイプの処理は異なることを行う。処理実例を、その処理概念の異なる様相を表現するために、論理または物理処理実例として特徴付けることができる。１つの論理処理実例はその処理自体以外の特定の実体、例えば、「機能」、ライン回路、加入者等、に関連する。１つの物理処理実例は、１つの論理実例を代表し、メモリ中に１つの状態を持ち、プログラムコードを実行する。用語「論理処理実例」は１つの抽象概念である。１つのシステム中のこの種の論理処理実例はそのシステム中に存在する処理タイプとそれらの性質とによって決定され、ハードウェア装置の観点ではそのシステムの構成によって決定される。それは、そのシステムの実行状態に関わらない一定の条件の問題である。１つの物理実例は１つの論理実例の「物質化」であるが、どの物理実例が１つのシステム中にあるかはどの論理実例があるかだけでなく現在のランタイム状況にも依存する。時間上では、異なる物理実例は同じ論理実例を代表することができ、そして、ある性質を持つ処理タイプに対しては、いくつかの物理実例が同時に同じ論理実例を代表することさえあるかもしれない。１つの処理タイプは、また、静的であることもできるし動的であることもできる。静的処理については、制御システムは各論理実例に対して１つの物理実例が常に存在することを確かめる。動的処理については、制御システムはある他の処理がそれと通信しようとしているときに１つの物理実例が作成されることを確かめるだけである。さらにその上、１つの処理タイプは「中央」タイプであることができる。この中央タイプの処理については、各処理タイプに対して正確に１つの論理処理実例が存在する。別のタイプの処理は１つのキーによって識別される実例を有する。この処理タイプについては、各キー値に対して１つの論理処理実例が存在する。異なる処理タイプはそれら各キー上で異なるタイプを持つことができ、こうして、異なる数の論理処理実例を持つことができる。キーにより、かつ、動的である一種の処理タイプについては、データベースと処理の「コアロケーション（共割当）」も存在できる。「コアロケーション（共割当）」の概念は次の背景を持つ。あるデータベースオブジェクトが更新されるとき、その実例を含むデータベースオブジェクト分配ユニットのある形式の複製中の写しを全て更新しなければならない。これは、情報をいくつかの制御プロセッサに転送しなければならないことを意味する。しかしながら、更新を行う処理実例が同じ制御プロセッサ上でデータベース分配ユニット複製の１つとして実行するならば、その情報転送は最小化される。ある処理実例がキー付き処理タイプであり、同じ１次キーを持つあるデータベースオブジェクト実例をその処理実例として頻繁に更新するならば、処理タイプとデータベースオブジェクトタイプの両方から同じ分配ユニットタイプを参照して１次複製を保持する制御プロセッサ上で常に実行するように強制できる。このコアロケーション（共割当）は、それらタイプが同じキータイプを共有することと、その処理タイプがキー付きで動的な種類のものであることを要求する。さらに別の処理タイプはデータベースオブジェクトに関連する実例を持つことができる。その実例が制御プロセッサ自身のソフトウェアによってインストールされる処理タイプについては、その処理タイプとともに密接に展開されるデータベースオブジェクトタイプがこうして存在する。そのとき、そのデータベースオブジェクトタイプの１つの実例は、１つの論理処理実例に対応する。最後に、１つの処理タイプは一意的であることができるし、または、複製された実例を持つこともできる。２つの実例が協力し合っているがそのシステム中の他の処理に対して１つの処理として働いている場合、そのタイプが「一意的」性質を持つときにはあるシステム活性の間以外は各論理実例に対してたかだか１つの物理実例があるだけである。そのタイプが「複製された」性質を持つときには、各論理実例に対して同時にいくつかの不等位の物理実例が存在するかもしれない。この性質は「中央」性質と結合できるだけである。静的なそのような処理タイプについては、多数のプロセッサの各々の上で１つの物理実例が作成されることを意味する。動的なそのようなタイプについては、その論理実例がアドレス指定される毎に１つの新しい物理実例が作成されるということを意味する。１つの処理が別のプロセッサ上で遠隔操作を行おうとしているとき、特別な論理処理実例または特別な物理処理実例のどちらかを識別することによって他の処理をアドレス指定する。論理処理実例を識別することが可能であるためには、その処理タイプおよび異なる実例間の相違、あるタイプのキー値、またはデータベースオブジェクトの参照を知ることが必要である。１つのタイプの処理は特別な他のタイプの処理と協力し合うように設計されているので、これはそう問題とはならない。しかしながら、「未知」の論理実例を包括的な論理実例識別子を通じて、例えば、データベースからそのような識別子を検索することによって識別することも可能である。その後、この識別子は、識別する実例の知識を有するある他の処理から書き込まれることとなる。物理処理実例を識別するために、包括的な物理処理識別子に対してデータタイプが存在する。これら識別子または処理実例参照は、その物理実例が存在している間は有効であり、その物理実例自身がデータベース中に記憶したり遠隔操作を通じて他のプロセッサに送ったりすることによってその参照を利用可能にするならば、他のプロセッサによって利用することができる。「中央」処理実例またはキーで識別される実例は、別のネットワーク要素中のある処理からアドレス指定できる。それから、その別のネットワーク要素は、アドレス指定された処理を実行するネットワーク要素を識別するネットワークアドレスを供給しなければならない。デフォルトでは、同じネットワーク要素中の処理のみがアドレス指定できる。データベースオブジェクトによって識別された処理実例は、１つのネットワーク要素内でのみアドレス指定できる。上記検討した処理タイプの性質は、処理タイプ仕様中の設計言語で特定されねばならない。こうして、この仕様は以下を特定する。 −タイプ名 −静的か動的かということ −１次キーのタイプ −実例を複製できるか否か −１次キーを持つタイプについて、分配限界または分配ユニット仕様への参照 −インストールされるタイプについて、分配ユニット仕様への参照３つの異なる処理タイプを特定する処理タイプ仕様の例は以下に与えられる。 PROCESS TYPE ResouceHandler IS STATIC; END PROCESS TYPE ResourceHandler; PROCESS TYPE TrafficControl IS DYNAMIC; PRIMARY KEY key: SubscriberNumber; DISTRIBUTION LIMIT 1000; END PROCESS TYPE TrafficControl; PROCESS TYPE LIC＿Handler IS STATIC; PRIMARY KEY key: REFERENCE TO LIC＿Data; DISTRIBUTED AS LIC＿Board; END PROCESS TYPE LIC＿Handler; １つの物理処理実例は常に１つの、そして唯一のプロセッサ上で実行される。１つの実例を作成する際には、その制御システムはその実例をどのプロセッサ上で作成すべきかということを、プロセッサを均等に利用するような方法で決定しなければならない。その制御システムは、また、遠隔操作等を適切な処理実例に向けるためその作成された実例に注意を払わねばならない。処理ベースで処理の上にこれを行うことは不可能であろう。あまりにも多くの実例があるからである。上記問題は、処理実例群を同じプロセッサ上に保つように使用する分配ユニットによって解決される。分配ユニットは、論理と物理両方の処理実例をグループ分けする。実例と分配ユニットとの間の関係は論理実例で表現されるから分配ユニットは論理実例をグループ分けし、また一方で、ある分配ユニットがあるプロセッサに割当てられているとき実際に起こるのはその分配ユニットに関連する全ての物理処理実例がその特別なプロセッサ上で作成されるということであるから、分配ユニットはまた物理実例をもグループ分けする。分配ユニットと処理実例との関係を表現する方法は処理タイプの性質に依存する。 −中央処理タイプについては、わずかである。１つの論理実例が存在するだけであるから、１つの分配ユニットが存在できるだけである。 −その実例がキーによって識別される処理タイプについては、分配ユニットの数が処理仕様とともに定数として特定されなければならないし、その関係は各キー値をそれら分配ユニットの１つの上にマップするプログラムされたアルゴリズムとして表現される。 −実例がインストールされる処理タイプについては、分配ユニットは同様にインストールされ、処理実例と分配ユニット実例との関係はインストール中に設定される。分配ユニットがいくつかのプロセッサ上で複製されるか否かは、分配ユニットがグループ分けする処理の性質に依存する。一意的処理については、１つの分配ユニットがまた一意的に１つの単一のプロセッサに割当てられる。一方、複製された処理タイプについては、１つの分配ユニットがいくつかのプロセッサ上で複製されうる。当該オペレーティングシステム上のアプリケーションは、コードを実行する多数の協力し合う処理から構成され、処理のメモリ中に１つの状態を持ち、持続的にデータベースにデータを記憶する。１つの処理実例は１つの制御プロセッサ上のみで実行されるが、その制御プロセッサに関係なく他の処理と通信できる。機能性を達成するには、当該オペレーティングシステム上のアプリケーションの設計者は、装置プロセッサを含むハードウェア装置をそこで動かそうとする際、物理的制限以外の如何なる分配様相についても考える必要はない。プロセッサ間の通信は、当該オペレーティングシステムによって透過的に運転される。アプリケーション設計者は、処理構造とデータベース使用法を設計するときとソフトウェアの構成に関してネットワーク技術者に指示を与えるときの両方に良い特性を得るためハードウェア分配を考慮しなければならない。異なるサブネット中の制御プロセッサの機能の協同操作は、情報をいくつかの通信チャンネルに跨って流さなければならないので、勿論、サブネット内や１つの制御プロセッサ内の協同操作より高価で時間がかかる。当該オペレーティングシステムは、どの制御プロセッサ上で処理実例を捜すべきかを知ることによって、処理間通信とデータベース操作とを適切な制御プロセッサに向けながらアプリケーションプログラムからは見えないようにする上記で参照した分配透過性を具現する。上記で指摘したように、当該オペレーティングシステムがもしそれぞれの単一処理実例が割当てられた場所を実際に見失わないようにしたならば、大きなオーバヘッドになろう。そのオーバヘッドは上記分配ユニット概念を通して削減される。このアプローチによる有利さは、当該オペレーティングシステムが必要なのは著しく少ない数の分配ユニットを見失わないということだけである。１つの分配ユニットは特定の分配ユニットタイプのものである。１つの分配ユニットタイプは、そのタイプの分配ユニットの共通性質、即ち、処理実例のタイプと共割当てされたデータベースオブジェクト実例のタイプ、もしあるならば、そのグループと少しばかりの他の特性、多くの場合、システムに存在するタイプの分配ユニットの正確な数を表す。いかに分配ユニットが複数の制御プロセッサに跨って分配されているかということは、分配ユニットタイプを制御プロセッサの分配プールに割り当てるという観点でシステムを構築するときに述べられる。その分配プールは制御プロセッサの理論的に任意なグループ分けである。１つの分配プール中には任意の数の制御プロセッサが存在していても良いし、１つの制御プロセッサが任意の数のプールの部分であっても良い。各分配ユニットタイプについては、対応する仕様でなければならず、その仕様においては、分配ユニットタイプの性質は処理タイプ仕様と同様の設計言語で明示されねばならない。この仕様は以下を特定する。 −タイプ名 −処理実例のタイプ −共割当てされたデータベースオブジェクト実例のタイプ −そのタイプの分配ユニットの数３つの異なる分配ユニットタイプの例は以下に与えられる。中央処理タイプ： DISTRIBUTION UNIT TYPE Central＿DUT IS PROCESS TYPE Central ＿PT; END; キー付きの処理タイプ： DISTRIBUTION UNIT TYPE Keyed＿DUT IS PRIMARY KEY key: KeyType; DISTRIBUTION LIMIT 100; PROCESS TYPE Keyed ＿PT: END; 共割当てされたデータベースと処理 DISTRIBUTION UNIT TYPE Coallocated＿DUT IS PRIMARY KEY key: KeyType; DISTRIBUTION LIMIT 100; PROCESS TYPE Coallocated ＿PT; OBJECT TYPE Coallocated＿OT; END; 上記仕様と共存する仕様 PROCESS TYPE Central＿PT IS STATIC; DISTRIBUTED AS Central DUT; END; PROCESS TYPE Keyed＿PT IS DYNAMIC; PRIMARY KEY key: KeyType; DISTRIBUTED AS Keyed ＿DUT; END; PROCESS TYPE Coallocated＿PT IS DYNAMIC; PRIMARY KEY key: KeyType; DISTRIBUTED AS Coallocated ＿DUT; END; OBJECT TYPE Coallocated ＿OT IS PRIMARY KEY key: KeyType; DISTRIBUTED AS Coallocated ＿DUT; END; タイプが同じ種類のものであるなら、同じ分配ユニットタイプを共有するいくつかの処理タイプがあっても良い。各種類の処理タイプについては、１つの分配ユニットタイプの１つの分配プールへの割当は、わずかに異なることを意味する。このことは、前に述べた処理タイプの種類に関して第４図−第８図を参照してより詳しく述べる。中央、静的かつ一意処理タイプである第１の種類を第４図に示す。第４図は、１つの分配プールに属する３つの制御プロセッサ４０２、４０４、４０６を概略的に示す。このタイプについては、たった１つの処理実例４０８があり、それゆえ、たった１つの分配ユニット４１０がある。当該オペレーティングシステムはそのプール中の制御プロセッサの１つ、即ち、図示の例ではプロセッサ４０４を選ぶ。そのプロセッサには分配ユニット４１０が割り当てられ、そのプロセッサ上で処理実例４０８が実行される。そのプロセッサ４０４が誤動作すると、当該オペレーティングシステムは別の制御プロセッサ、即ち、例ではプロセッサ４０２、４０６の１つをプールから選び、そのプロセッサ上で処理を再開する。キー付き、動的かつ一意の処理タイプである第２の種類を第５図に示す。第５図は、１つの分配プールに属する３つのプロセッサ５０２、５０４、５０６を概略的に示す。プロセッサ５０２は２つの分配ユニット５０８、５１０を含むように示されている。プロセッサ５０４は２つの分配ユニット５１２、５１４を含むように示されている。プロセッサ５０６は２つの分配ユニット５１６、５１８を含むように示されている。分配ユニットの各々は３つの論理処理実例を含み、その実例の内あるものは物理実例に「物質化」されていて良い。なぜなら、ある他の処理はそのサービスに到達するためにそれと通信したがっていたからである。これは第５図に次のように例示されている。分配ユニット５０８については、３つの「純」論理実例が５０８₁₁から５０８₁₃に示されている。分配ユニット５１０については、２つの論理実例が５１０₁₁、５１０₁₂に、１つの物理実例が５１０_ph1にそれぞれ示されている。分配ユニット５１２は、１つの論理実例５１２₁₁と、２つの物理実例５１２_ph1、５１２_ph2とを含むように示されている。分配ユニット５１４は、２つの論理実例５１４₁₁、５１４₁₂と、１つの物理実例５１４_ph1とを含むように示されている。分配ユニット５１６は、２つの論理実例５１６₁₁、５１６₁₂と、１つの物理実例５１６_ph1とを含むように示されている。分配ユニット５１８は、２つの論理実例５１８₁₁、５１８₁₂と、１つの物理実例５１８_ph1とを含むように示されている。このタイプについては、アプリケーションプログラマは、分配ユニットの数を固定する分配限界（この例では分配限界は６である）と、処理実例を識別するキーを特定の分配ユニットを識別する数に翻訳する機能とを提供しなければならない。当該オペレーティングシステムは、第５図に示すように、そのプールにある制御プロセッサに跨って均等に分配ユニットを広げ、もしある制御プロセッサに事故が生じると、その制御プロセッサ上の分配ユニットをプール中の残りの制御プロセッサに移動させ、事故の制御プロセッサが再び機能すれば元に戻す。処理実例が動的であるから、当該オペレーティングシステムは、ある処理実例がそれへの対話を設定することによってアドレス指定されると、１つの物理実例を開始するだけであろう。故障中の制御プロセッサ上で実行している実例は自動的には再開されない。中央、静的かつ複製された処理タイプである第３の種類を第６図に示す。そのような処理タイプでは、当該オペレーティングシステムが分配プール中の全ての制御プロセッサに複製し各制御プロセッサ上で１つの処理実例を開始するであろうたった１つの分配ユニットがある。これは第６図に示していて、その図では、同じプールに属する３つの制御プロセッサ６０２、６０４、６０６がそれぞれ１つの複製された分配ユニット６０８、６１０、６１２を含み、そして、その各処理はそれぞれ６１４、６１６、６１８で示されている。６２０で示す第４のプロセッサは他のプロセッサのプールには属さず、それゆえ、複製された分配ユニットを何も受け取ってはいない。万一、制御プロセッサ６０２、６０４、６０６の１つが故障すると、その上で実行中の実例は、その制御プロセッサが再び機能するまで、消えてしまう。１つの複製された処理タイプがアドレス指定されると、送り手は特に実例の１つではないような複製された処理タイプを指摘することだけができる。当該オペレーティングシステムは送り手に「最も近い」制御プロセッサ上の実例を選ぶ。即ち、その制御プロセッサ上に１つ存在するならば同じ制御プロセッサ上で、さもなければ同じサブネット内で、またさもなければ任意の場所から選ぶ。もしいくつかの制御プロセッサが等しく「近い」ならば、当該オペレーティングシステムは無作為に選ぶ。こうして複製された処理の実例の内部状態は互いに独立しているということに注目されたい。当該オペレーティングシステムはそれら状態を互いに矛盾しないように保つことはしないであろう。中央、動的かつ複製された処理タイプである第４の種類を第７図に示す。第７図は、同じプールのうちの１つに属する３つの制御プロセッサ７０２、７０４、７０６を示す。当該オペレーティングシステムは、その分配プール中のすべての制御プロセッサ上で７０８、７１０、７１２で示される１つの単一分配ユニットを複製して、そのような処理がアドレス指定される度にプール中の制御プロセッサの１つの上で新しい処理実例を開始する。処理実例７１４、７１６は複製された分配ユニット７０８中に示され、複製された分配ユニット７１０は３つの処理実例７１８、７２０、７２２を含むように示されている。複製された分配ユニット７０６は単一処理実例７２４を含む。選ばれる制御プロセッサは、静的かつ複製された処理タイプと同様、送っている処理の位置に依存する。インストールされ、静的かつ一意の処理タイプである第５の種類を第８図に示す。第８図は、１つのプールに属する３つの制御プロセッサ８０２、８０４、８０６を示す。制御プロセッサ８０４、８０６は１つのグループを形成する。その分配ユニットタイプを１つの分配プールに割り当てるのは、その分配ユニットタイプに接続されたタイプの処理実例がそのプール中の任意の制御プロセッサ上でインストールされて良いことを意味するに過ぎない。しかしながら、ランタイム中でインストールされるまでは、分配ユニットも処理実例も存在しない。１つの分配ユニットをインストールするには、第８図に示すように１つのプロセッサグループを選択しなければならない。１つのプロセッサグループは構成データから構築される制御プロセッサのグループである。８０８で示される分配ユニットがインストールされると、当該オペレーティングシステムは、これも分配ユニットタイプが割り当てられた分配プールの一部である選ばれたプロセッサグループの中で、制御プロセッサの１つ、例ではプロセッサ８０４、を選ぶ。こうしてインストールされた分配ユニット８０８内で、例として８１０、８１２で示される処理実例はまたランタイム中で加えられる。当該オペレーティングシステムは、選ばれた制御プロセッサの分配ユニット中の処理実例を開始し、そして、もし現在選ばれている制御プロセッサが故障すると他のものを選び処理をそこで再開する。当該オペレーティングシステムは実際の物理的制限を知らないので、適切なプロセッサグループを作成することはアプリケーション設計者やネットワーク技術者にとっての事項である。インストールされた処理実例はハードウェアリソースを示す管理されたオブジェクト実例に常に密接に関係し、そして、１つのハードウェアリソースが１つのシステムに加えられると、通常は１つの処理実例がそのリソースを制御または運転することが必要になる。ハードウェアリソースは、恐らく、ある方法で管理する必要があり、それゆえ、そのリソースを表す管理されたオブジェクト実例が作成される。処理とその分配ユニットのインストールは、それゆえ、しばしば管理されたオブジェクトの作成と関連してなされる。そのハードウェアリソースを表す管理されたオブジェクトと他のハードウェアリソースを表す管理されたオブジェクトとの関係から、選ぶべき適切なプロセッサグループが得られる。上記と第９図−第１２図とを参照して、模範的インストールの場合を説明する。第９図はネットワーク要素のハードウェア図であり、第１０図はそのネットワーク要素の管理図であり、第１１図はそのネットワーク要素のリソース図であり、第１２図はそのネットワーク要素に含まれる制御プロセッサ上で実行しようとする処理実例の分配を概略的に示す。プロセッサグループの目的は、ハードウェア構成における物理的制限に対処してインストールされた処理実例が実行しようとしている制御プロセッサを抑制することである。第９図のネットワーク要素中、装置９０２、９０４はそれぞれブロックＤ１、Ｄ２に含まれて示されている。ブロックＤ１、Ｄ２はそれぞれスイッチ９０６に接続された多数の装置のそれぞれを代表するものである。装置９０２、９０４を含むこれら装置はその装置と同じスイッチ９０６に接続された制御プロセッサ９０８、９１０から到達できるのみである。別のスイッチ９１２は、それぞれブロックＤ３、Ｄ４に含まれるように示された２つの制御プロセッサ９１４、９１６と２つの装置９１８、９２０をそこへ接続している。ブロックＤ３、Ｄ４は装置９１８、９２０を含んでいて、スイッチ９１２に接続された多数の装置を表すようにしている。第１０図の対応管理図では、プロセッサ９０８、９１０、９１４、９１６、装置９０２、９１８、９２０及び第９図に示すスイッチ９０６、９１２が第１０図の対応要素として同じ参照番号に添字ＭＯを与えられ、管理されたオブジェクトによって表されている。同様に、第１１図の対応リソース図では、第１０図で管理されたオブジェクトによって表したのと同じプロセッサ、装置、スイッチが、第１０図の対応要素と同じ参照番号に添字ＲＯを付加したリソースオブジェクトによって表されている。第１０図は、分配プールを表す管理されたオブジェクト１００２がどのようにプロセッサ管理されたオブジェクト９０８_MO、９１０_MO、９１４_MO、９１６_MOをグループ分けするかを示す。その分配プールには分配ユニットタイプが割り当てられるが、それを第１２図を参照して以下にさらに詳しく述べる。管理されたオブジェクト９０８_MO、９１０_MOはスイッチ管理されたオブジェクト９０６_MOに接続され、装置管理されたオブジェクト９０２_MOもまたそこへ接続される。管理されたオブジェクト９１４_MO、９１６_MOはスイッチ管理されたオブジェクト９１２_MO に接続され、装置管理されたオブジェクト９１８_MO、９２０_MOもまたそこへ接続される。第１１図の対応リソース図では、第１１図のリソースをそれぞれ表すリソースオブジェクトが第１０図の管理されたオブジェクトと同様に組織されている。しかしながら、第１１図のリソース図は、また、制御プロセッサ９１８、９２０を１つのグループとして表すリソースオブジェクト９２４_ROだけでなく、制御プロセッサ９０８、９１０を１つのグループとして表すリソースオブジェクト９２２_RO を含む。管理されたオブジェクト１００２によって表せられる分配プールには、第１２図に１２０２で概略的に示す分配ユニットタイプが割り当てられ、一例として、ブロック１２０４から１２１８によって示されるこのタイプの分配ユニットを含む。それら分配ユニットは各ブロック中４角形で示す多数の処理実例を含む。こうして、分配ユニット１２０４、１２０６はそれぞれ装置Ｄ１を取扱い、制御プロセッサ９０８上で実行するためインストールされた１つの処理実例グループを形成する。装置９０２を取扱う処理実例は１２２０で示している。分配ユニット１２０８、１２１０はそれぞれ装置Ｄ２を取扱い、制御プロセッサ９１０上で実行するためインストールされた１つの処理実例グループを形成する。装置９０４を取扱うための処理実例は１２２２で示されている。分配ユニット１２１２、１２１４はそれぞれ装置Ｄ３を取扱い、制御プロセッサ９１４上で実行するためインストールされた１つの処理実例グループを形成する。装置９１８を取扱うための処理実例は１２２４で示されている。分配ユニット１２１６、１２１８はそれぞれ装置Ｄ４を取扱い、制御プロセッサ９１６上で実行するためインストールされた１つの処理実例グループを形成する。装置９２０を取扱うための処理実例は１２２６で示されている。スイッチ９０６または９１２に接続された装置を取扱う処理実例は、リソースオブジェクト９２２_RO、９２４_ROによってサポートされた制御プロセッサの前記グループ分けによりそのスイッチに接続された制御プロセッサ９０８、９１０または９１８、９２０上でそれぞれ実行しなければならない。こうして、もし新しい装置９２８がスイッチ９０６に追加されたならば、その新しい装置を取扱う処理実例が同様に制御プロセッサ９０８、９１０のいずれかの上で実行するようインストールされ、選択されねばならない。それゆえ、その新しい装置を表すリソースオブジェクト９２８_ROがインストールされ、矢印９３０に示すリソースオブジェクト９２２_ROに接続されねばならないし、その新しい処理実例は制御プロセッサ９０８、９１０上で実行しようとする１つの処理実例のグループを形成する分配ユニットに割り当てねばならない。一例として、そういう新しい処理実例は、プロセッサ９１０上で実行するためインストールされるように、例えば、第１２図の１２２８で示す。１つの制御プロセッサ中の処理実例を、別の制御プロセッサ中に位置する処理実例からアドレス指定することを第１３図、第１４図を参照して記述する。第１３図は３つの制御プロセッサＣＰ１、ＣＰ２、ＣＰ３を示す。制御プロセッサＣＰ１は２つの分配ユニットＡ、Ｂを含むように示されている。制御プロセッサＣＰ２は分配ユニットＣ、Ｄ、Ｒ、Ｓを含むように示されている。制御プロセッサＣＰ３は分配ユニットＥ、Ｆ、Ｒ、Ｓを含むように示されている。分配ユニットＲ、Ｓは、それらに割り当てられた複製された第３、第４の種類のいずれかの処理実例を持つように想定される。１つの制御プロセッサにおける１つの処理が別の制御プロセッサに位置していても良い別の処理上の操作を呼び出すことができるように、アドレッシング情報が必要である。そのようなアドレッシング情報は、次のように、テーブルによって提供される。各制御プロセッサは、それと関連し、すべての制御プロセッサに共通であり、かつその制御プロセッサ上のすべての分配ユニットの分配を示す第１のテーブルと、自分自身の分配ユニットを指す第２のテーブルとを有する。プロセッサＣＰ１、ＣＰ２、ＣＰ３の各々について、第一のテーブルはＴ１で示され、第２のテーブルはそれぞれＴ２_CP1、Ｔ２_CP2、Ｔ２_CP3で示される。図でわかるように、第１のテーブルＴ１では第１列中の各行に分配ユニットを示し、第２列には第１列中の分配ユニットが位置するプロセッサを示す。こうして、テーブルＴ１の行２から、分配ユニットＣ、Ｄが制御プロセッサＣＰ２上に位置するということが分かる。第２テーブルＴ２は、各行に分配ユニットを示す第１列と、同じ行にその分配ユニットへのポインタを与える第２列とを有する。これは、テーブル２の各行から対応する分配ユニットに向かう矢印から容易に分かる。各矢印は、それが指し示す分配ユニットと同じ識別文字によって示されている。さらにその上、各分配ユニットはその処理実例へのポインタを含む自身のテーブルＴ３を有する。第１３図では、このテーブルはプロセッサＣＰ２上の分配ユニットＤに対してだけテーブルＴ３_Dとして示されている。図でわかるように、分配ユニットＤは３つの処理実例Ｐ１、Ｐ２、Ｐ３を含む。テーブル３は、これらの処理実例をそれぞれ示す３行からなる第１列と、それぞれの行からの矢印が対応する処理実例へのポインタを示す第２列とを含む。このように、分配ユニットＲ、Ｓに割り当てられた処理実例を識別する分配ユニットＲ、Ｓと関連する、図面に示されないテーブルも存在する。テーブルＴ１、Ｔ２、Ｔ３はオペレーティングシステムの一部を形成する。次に、いくつかの模範的なアドレッシングの場合を述べる。第１３図の制御プロセッサＣＰ１上の分配ユニットＢ中の処理実例送り手は遠隔操作を制御プロセッサＣＰ２に存在する処理実例の１つ、例えば、処理実例Ｐ２上、または、プロセッサＣＰ２、ＣＰ３中の分配ユニットＲ、Ｓのいずれかに割り当てられた処理実例上で行うのが好ましい。第１４図は、当該処理実例を見つけることができるオペレーティングシステムによって行われる検索過程を示すフロー図である。第１３図の分配ユニットＢに位置し、先へ送るべき処理実例を捜している処理実例送り手からのメッセージがそのフロー図の開始点１４０２に現れる。その検索はテーブルＴ１によりステップ１４０４から開始される。検索すべき処理実例が分配ユニットＤに位置する処理実例Ｐ２であるならば、テーブルＴ１の行２はこの分配ユニットがプロセッサＣＰ２上で見付かるということを明らかにする。これによれば、ステップ１４０６は処理実例が自身のプロセッサ上の分配ユニットに位置することができるという場合を消去する。もし検索すべき処理実例が複製されるタイプのものであるならば、テーブルＴ１はプロセッサＣＰ２、ＣＰ３上で見つかるということを最終行で明らかにする。ステップ１４０８では、その処理実例が複製されるか否かを決定する。もし複製されるならば、オペレーティングシステムはステップ１４１０で制御プロセッサＣＰ１、ＣＰ２のうちの、送り処理の送り手に「最も近い」もの、または、第３、第４の種類の処理について前に述べたようにそれらが等しく「近い」ならば任意のものを選ぶ。もし複製されないなら、ステップ１４１０は素通りする。検索する処理実例がＰ２なら、ステップ１４１２はメッセージをステップ１４１４に送る。ステップ１４１４でプロセッサＣＰ２に関連するテーブルＴ２_CP2 は行２で分配ユニットＤへのポインタを識別する。ステップ１４１６はメッセージをステップ１４１８に送る。ステップ１４１８で、テーブルＴ３_Dは行２で処理実例Ｐ２へのポインタを識別する。ステップ１４２０では、処理実例が動的か静的かを決定する。もし動的なら、ステップ１４２２は処理実例がキー付きか複製されるかを決定する。もしキー付きなら、その処理タイプがキー付き、動的かつ一意的であると決定する。ステップ１４２４では、「開始？」と訊いて、その論理実例が物理実例へと物質化されたか否かを決定する。もし否なら、ステップ１４２６でその処理実例を開始し、メッセージをステップ１４２８で先に送る。もし物理実例なら、矢印１４３０により示すようにフローを続けてメッセージをステップ１４２８へ送る。静的処理実例の疑いがあるということがステップ１４２０で分かったなら、フローはステップ１４２２、１４２４、１４２６を素通りして矢印１４３２によって示されるようにステップ１４２８へと続く。もしステップ１４２２での答えが「複製される」であるならば、これは中央、動的かつ複製されるタイプの実例であるということ、および新しい物理タイプが物質化されねばならないということを意味する。それゆえ、フローはステップ１４２４を素通りして矢印１４３４によりステップ１４２６へと続く、即ち、オペレーティングシステムはアドレス指定された処理実例を開始する。

───────────────────────────────────────────────────── フロントページの続き (72)発明者ホルテ − ロスト，アンナナエミィインゲボルグスウェーデン国エス − 124 72 バンドハーゲン，グランスハムマルスガタン 213 (72)発明者サミュエルソン，ボミカエルスウェーデン国エス − 113 26 ストックホルム，フレイユガタン 42

Claims

【特許請求の範囲】１．データベースの異なる部分を取扱うための多数の制御システムプロセッサからなる制御システムプラットホームと、該プロセッサにより提供されるリソースを管理しその制御システムにより提供される抽象概念を履行するオペレーティングシステムと、処理リソースの表現とから構成される処理アーキテクチャを含むコンピュータ制御されたシステムであって、前記処理アーキテクチャは、相互に作用し合い、前記制御システムと作用し合い、このアーキテクチャ外の世界と作用し合う協同処理として実行されるアプリケーションプログラムを提供し、処理リソース表現の実例が分配ユニットにより前記多数の制御システムプロセッサに跨って分配され、各分配ユニットはそれぞれ１つの処理実例グループを形成し、前記分配ユニットは特定の分配ユニットタイプに属し、各分配ユニットタイプはそのタイプである各分配ユニットに共通な性質を表す、ようにしたコンピュータ制御されたシステム。２．前記処理実例がプログラムコードを実行する物理処理実例と、抽象概念の形式の論理処理実例であって、１システム中の論理処理実例の種類は該システムに存在する処理タイプと、それらの性質と、ハードウェア装置の観点での該システムの構成とによって決定される論理処理実例と、を含む請求項１に記載のシステム。３．分配ユニットが論理処理実例と物理処理実例との両方をグループ分けし、実例と分配ユニットとの関係が論理実例の意味で表現される故に論理実例をグループ分けし、また、１つの分配ユニットが１つのプロセッサに割当てられているときその分配ユニットに関連するすべての物理処理実例が特定のプロセッサ上で作成される故に物理実例をグループ分けする、請求項２に記載のシステム。４．前記プロセッサは各処理タイプに対して１つの論理処理実例が存在する中央処理タイプと、各キー値に対して１つの論理処理実例が存在し、異なる処理タイプがそれら各キー上で異なるタイプを持つことができ、それゆえに異なる数の論理処理実例を持つことができる、１つのキーにより識別される実例を持つ処理タイプと、前記システム自身中のソフトウェアによってインストールされる実例を持つ処理タイプであって、該処理タイプとともに密接に展開されるデータベースオブジェクトタイプが存在し、該データベースオブジェクトタイプの実例は一つの論理処理実例に対応する、処理タイプと、を含む請求項１−３のうちのいずれか１つに記載のシステム。５．各処理タイプに対して、分配ユニットと処理実例との関係が、中央処理タイプに対しては、わずかであり、ただ１つの論理実例が存在するゆえにただ１つの分配ユニットが存在することができ、その実例がキーにより識別される処理タイプに対しては、分配ユニットの数が処理仕様とともに定数として特定され、その関係が各キー値を分配ユニットの１つの中へマップするプログラムされたアルゴリズムとして表現され、その実例がシステム自身の中にあるソフトウェアによってインストールされる処理タイプに対しては、処理実例がデータベースオブジェクト間の関係により表現されるように分配ユニット中でグループ分けされる、というように表現される請求項４に記載のシステム。６．前記処理が各論理実例に対して常に１つの物理実例が存在することを制御システムが確実にする静的処理タイプと、ある他の処理がそれと通信しようとしているときただ１つの物理実例が作成されることを制御システムが確実にする、動的処理タイプと、を含む請求項１−５のいずれか１つに記載のシステム。７．前記処理が２つの実例が協同するが１つのシステム中の他の処理に１つの処理として働くときあるシステム活性の間以外は各論理実例に対して１つの物理実例が存在する、一意的処理タイプと、１つの論理実例に対していくつかの物理実例が存在しうる、複製される処理タイプと、を含む請求項１−６のいずれか１つに記載のシステム。８．一意的処理に対して、１つの分配ユニットが単一のプロセッサに一意的に割り当てられ、複製される処理タイプに対しては、１つの分配ユニットがいくつかのプロセッサ上で複製されうる、請求項７に記載のシステム。９．タイプが１つのある共通種類のものであるなら、いくつかの処理タイプに同じ分配ユニットタイプを共有することが許されるシステムであって、これらの種類は中央、静的かつ一意的処理タイプと、キー付き、動的かつ一意的処理タイプと、中央、静的かつ複製される処理タイプと、中央、動的かつ複製される処理タイプと、インストールされ、静的かつ一意的処理タイプと、からなる請求項４、５、６、７、８のいずれか１つに記載のシステム。１０．キー付き、動的かつ一意的処理タイプの１つの実例と、同じ１次キーを処理実例として持つ１つのデータベースオブジェクト実例とが必要に応じて対応するキーを持つデータベースオブジェクトの１次複製を保持する同じプロセッサ上で処理実例を強制的に実行するため同じ分配ユニットタイプを参照させられる、請求項９に記載のシステム。