JPH11161475A

JPH11161475A - 情報処理システムのアーキテクチャ

Info

Publication number: JPH11161475A
Application number: JP10187894A
Authority: JP
Inventors: Jean Akriche; ジヤン・アクリツシユ; Jean-Marie Lanquetin; ジヤン−マリ・ランケタン; Alain Leteinturier; アラン・ルタンチユリエ; Sitbon Gerard; ジエラール・シトボン; Jean-Francois Touzan; ジヤン−フランソワ・トウザン
Original assignee: Bull SA
Current assignee: Bull SA
Priority date: 1997-07-02
Filing date: 1998-07-02
Publication date: 1999-06-18
Anticipated expiration: 2018-07-02
Also published as: FR2765702B1; EP0889399B1; DE69800428T2; FR2765702A1; EP0889399A1; JP3423220B2; US6305015B1; DE69800428D1

Abstract

(57)【要約】【課題】「オープン」及び「独自型」システムのアー
キテクチャの両方の利点を兼ね備えたアーキテクチャを
提供する。【解決手段】本発明による情報処理システムのアーキ
テクチャは、ソフトウェア製品の一つのセットを含む。
このセットは少なくとも一つのソフトウェア製品を含む
各ドメイン（２１−２３）に再分割される。各ドメイン
（２１−２３）はその識別子と、属性と、ドメインを構
成しているソフトウェア製品についてのデータとを含
む。これらのデータは一組の規則に応じてドメインのイ
ンストールおよび／または更新を可能にする。バージョ
ンに関する一貫性制御がこれらの外部製品の全部または
一部について行われる。システム（２）はそのオペレー
ティングシステム（２１）と動作モニタ（２３）のため
に少なくとも二つの特定ドメインを含む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は情報処理システムの
アーキテクチャに関する。

【０００２】より詳細には、英語で「mainframe（メイ
ンフレーム）」と呼ばれるタイプの大規模なシステムの
ためのアーキテクチャに関する。

【０００３】

【従来の技術】このようなシステムは非常に複雑であ
り、相互に協働するハードウェアならびにソフトウェア
の、きわめて多数のサブシステムを内蔵している。これ
らのシステムを構成しているソフト製品が数十万、ひい
ては数百万ものコード行にのぼることも稀ではない。

【０００４】このような状況の中で、解決するのがもっ
とも難しい問題の一つは、様々なコンポーネント間にお
ける一貫性と互換性を得ることである。それらのコンポ
ーネントを更新しなければならないとき（より最新のバ
ージョンへの移行、モジュールまたは機能の追加等）が
特にそうである。

【０００５】実際のところ、上述の本質的な複雑さのほ
かに、システムを構成している各種製品の供給元が（た
とえ共通の開発規則が設けられている）内部であれ、外
部（市販製品）であれ、ばらばらであることも考慮しな
ければならない。

【０００６】従来の技術においては、二つの主要タイプ
のアーキテクチャが存在している。

【０００７】第一のアーキテクチャは「独自（propriet
ary）型」と呼ばれるタイプに属している。この言葉が
指しているシステムとは、アーキテクチャが情報処理機
器メーカーによって設計されるシステムをいう。

【０００８】このようなアーキテクチャは、高度の統合
化がはかられているという基本的な特徴を有していると
ともに、一つのモノリシックなシステムの形を有してい
る。本明細書に添付されている図１はこのようなアーキ
テクチャを概略的に示している。

【０００９】システム１はソフトウェアシステムのモノ
リシックなセット１１と協働するハードウェアプラット
ホーム１０を含んでいる。これらのソフトウェアシステ
ムには、英語で「ＯＳ」と呼ばれるオペレーティングシ
ステム１１０と、システム機能を監視する管理システム
１１１と、生産システム１１２とを含むことができる。
生産システムは、たとえば、データベースマネジャ１１
３やトランザクションプロセッサ１１４を含むことがで
きる。ハードウェアプラットホーム１０は、データ処理
システムの通常の装置、すなわち詳述するまでもない
が、ＣＰＵ、主記憶装置、大容量の記憶装置等を含む。

【００１０】図１のシステムにおいては、セット１１の
すべてのコンポーネントが最初のインストールの際に、
また後日の更新（システム１のバージョンチェンジ）の
際にサポートされる。この種の環境の中では、システム
の一貫性はすべてのコンポーネント間のインターフェイ
スの全体的検証によって得られる。ユーザにとっては、
これらの措置によって、システムの発展とは無関係に、
システムの実質的なロバストネスが保証されることにな
る。また、これらの措置によって、システムの相次ぐバ
ージョンの容易なモニタリングが可能になる。さらに、
これらの措置によって、最高のアベイラビリティと操作
における高いセキュリティが確保される。なぜならば、
機能障害リスクが最小限に抑えられるからである。

【００１１】しかしその反面、重大な制約や欠点が存在
する。

【００１２】これらの制約や欠点は、システムがモノリ
シックである点に原因がある。変更すべきコンポーネン
トおよび／または追加すべき機能がいかなるものであろ
うとも、システム全体を変える必要がある。更新は全体
に及ばざるを得ない。

【００１３】この欠点を実際的に示すには、たとえば、
データベース管理ソフトウェア１１３だけの交換を希望
する、あるいはより最新のバージョンを呼び出して同ソ
フトウェア１１３を更新することを希望するユーザの例
を挙げることができる。この仮定では、システムの新し
いバージョン一式をインストールしなければならない。

【００１４】またこのことは、交換すべき、あるいは更
新すべきデータベース管理ソフトウェアが入っているこ
の新しいバージョンが入手可能であることが前提にな
る。

【００１５】最後に、このことは、非常に大型なシステ
ムの場合には一般に数日間データ処理システムが使えな
いという重大な事態を招く。

【００１６】従って、このタイプのアーキテクチャは比
較的フレキシビリティが乏しく、変更の可能性が限定さ
れている。

【００１７】第二のアーキテクチャは「オープン」タイ
プと呼ばれるタイプに属している。この言葉が指してい
るシステムとは、アーキテクチャが単一のメーカーによ
って規定されないシステムをいう。これらのシステム
は、特に「ＵＮＩＸ」（登録商標）タイプまたは類似タ
イプ、たとえば「ＡＩＸ」（登録商標）タイプのオペレ
ーティングシステムの出現に伴って現れた。

【００１８】明らかに、このタイプのアーキテクチャは
非常に有利である。なぜならば、一つの同じマシン上で
統一のとれていないソフトウェア、すなわち様々な供給
元のソフトウェアの共存を可能にするからである。

【００１９】このタイプのアーキテクチャについては、
ソフトウェアのインストールおよび／または更新はその
製品自体に関するものであり、システム全体に関するも
のではない。

【００２０】基本コンポーネントをいつでもインストー
ルあるいは更新できるので、「オープン」アーキテクチ
ャは少なくとも理論上では非常に大きなフレキシビリテ
ィと多大なアップグレードの容易性を提供する。

【００２１】実際のところ、このタイプのアーキテクチ
ャも欠点がないわけではない。特に、他のソフトウェア
コンポーネントとの良好な動作保証がまったく提供され
ない。つまり、様々な不適合が発生する可能性などがあ
る。

【００２２】だが、このタイプのアーキテクチャに固有
の欠点があるにもかかわらず、オープンアーキテクチャ
によるシステムはユーザにとって非常に有利である。

【００２３】その理由は、情報処理システムのユーザが
現在感じているニーズの全部または一部を満たしてくれ
るからである。そのうちには下記のものがある。

【００２４】− 自律性、すなわちシステムの一つの製
品、あるいは複数の製品を、システムの他の製品とは無
関係にアップグレードすることができること。

【００２５】− 並列性、すなわち同一製品の複数のバ
ージョンを同時に走らせることができること。

【００２６】− 互換性、すなわち製品や製品間インタ
ーフェイスの上位互換性の保証を当てにすることができ
ること。

【００２７】− システムの通常運転中での更新、すな
わち運転の停止なしに、あるいは少なくとも最低限の停
止で製品のバージョンをチェンジすることができるこ
と。

【００２８】− 元に戻す、すなわち万一問題がある場
合に、運転の停止なしに、製品を以前のバージョンに戻
すことができること。

【００２９】− アップグレード制御、すなわち自動化
された手順や簡易化された手順の実施によるアップグレ
ードプロセスが制御できること。

【００３０】− アップグレードおよびメンテナンスの
迅速性、すなわちアップグレード要請または修正要請か
ら現場での実質的なインストールまで最短時間を見込め
ること。

【００３１】

【発明が解決しようとする課題】本発明は従来技術の二
タイプのアーキテクチャの欠点を、それぞれの利点を保
持した上で解消することを目的とする。

【００３２】また、本発明は上述のユーザの諸ニーズに
十分に応えることも目的とする。

【００３３】

【課題を解決するための手段】そのために、一つの主要
な特徴によれば、本発明はドメインベースのアーキテク
チャを提案する。

【００３４】一つのドメインはシステムのソフトウェア
コンポーネントによって提供される機能のセットを一つ
にまとめる。このセットは固有の特性をもち、独立した
方法で変化する。つまり、システムは最低限の相互依存
性をもつドメインの一つのセットで構成される。これに
よって全体的な一貫性が保証される。

【００３５】換言するならば、インストールのフレキシ
ビリティと更新は制御可能なままの巨視的レベルで導入
される。すなわちドメインの内部において一貫性が確保
され続けられる。

【００３６】各ドメインは、どのようなドメインであろ
うとも、特にドメインに割り当てられる属性と記述子の
おかげで、ユーザ側から同一の方式で「見られる」。

【００３７】従って、本発明はソフトウェア製品の一つ
のセットと協働するハードウェアプラットホームを含む
情報処理システムのアーキテクチャであって、前記セッ
トがドメインと呼ばれるサブセットに再分割され、各ド
メインが少なくとも前記ソフトウェア製品の一つを含ん
でいること、また、各ドメインが決定された特定情報へ
のアクセスを可能にする記述子と呼ばれるサブセットを
含んでおり、前記情報が少なくともドメインの一つの識
別子と、それを含むソフトウェア製品を記述したデータ
とを含んでいること、さらに、所定の規則と前記の決定
された特定の情報に基づいて前記ドメインのインストー
ルおよび／または更新を可能にする手段が設けられてい
ることを特徴とするアーキテクチャを目的としている。

【００３８】本発明によるアーキテクチャは多数の利点
を有していることが認められる。そのうちには下記のも
のがある。

【００３９】− 更新のフレキシビリティ。システムの
全体的な更新を行う必要性がまったくない。更新はドメ
インごとに行うことができる。

【００４０】− マシンのアンアベイラビリティが低減
される。更新は複数の段階に分けて行うことができると
ともに、処理の停止を必要とするいくつかのドメインに
関する段階は時宜を選んで行うことができる。本発明の
ある有利な変形例においては、大半のドメインは処理が
一次コピー上で継続されている間中に二次コピー上で更
新できる。最終的な切換だけが、いくつかの特定のドメ
インについて処理の停止をもたらしうる。

【００４１】− バージョンチェンジのセキュリティ。
いくつかのドメインは二重発生的に機能することができ
るので、テスト段階や、万一問題がある場合に元に戻す
ことが可能である。

【００４２】− 更新時間の短縮。更新はドメインのレ
ベルにて行われるので、更新の実行を動作上の諸制約に
応じて検討することができるとともに、最善の計画をた
てることができる。

【００４３】− インストールされたコンフィギュレー
ションの選択のフレキシビリティ。ユーザは、場合によ
ってはありうる依存性やサポート条件およびメンテナン
ス条件によって課せられる諸制約の限度内だけにおい
て、自分に必要なドメインだけをインストールすること
ができるとともに、各ドメインのバージョンの変化を完
全に制御することができる。

【００４４】要するに、本発明によるアーキテクチャは
「独自型」および「オープン」のアーキテクチャの利
点、つまりロバストネス、アベイラビリティ、セキュリ
ティ、フレキシビリティおよびアップグレード能力を兼
ね備えることを可能にする。

【００４５】添付の図を参照しながら以下の説明を読む
ことによって、本発明はより良く理解され、他の特徴や
利点も明らかになるであろう。

【００４６】

【発明の実施の形態】では、図２を参照しながら、本発
明によるデータ処理システムのアーキテクチャについて
詳細に説明する。

【００４７】システム２は、先と同様に、ハードウェア
プラットホーム２０を含んでいる。ただし、本発明の重
要な特徴によれば、ソフトウェアおよびハードウェアの
セットはドメイン２１〜２３に細分される。より具体的
には、２２という全体的参照番号でまとめられているド
メインＤ₁、Ｄ₂、...、Ｄ_j、...、Ｄ_nの一つのセット
と、二つの特定ドメイン２１および２３とが存在する。
後者の二つのドメインとは、それぞれ、オペレーティン
グシステム（すなわち「ＯＳ」）やシステムの関連基本
ソフトウェアを提供するドメイン２１と、システム２の
動作モニタを提供するドメイン２３である。システム２
はハードウェアプラットホーム２０のほかに少なくとも
これらの二つのドメイン２１と２３を含んでいる。シス
テム２とその基本コンポーネントのセット、すなわち以
下で明瞭に説明されるように、各種ドメインとそれらが
提供する機能性を完全に識別するのは、システムの動作
モニタであるドメイン２３のバージョンである。

【００４８】ドメインを表示しているｊやｎといった符
号は純粋に任意のものであり、ｊは中間符号であり、ｎ
は少なくともシステムの当該コンフィギュレーション状
態におけるドメインの最大数を表している（ただし、特
定ドメイン２１および２３は含まれない）。

【００４９】その他のドメイン２２はオプションであ
り、ユーザの明確なニーズと当該アプリケーションに応
じてユーザによって選択される。以下においては、これ
らのドメインを「汎用ドメイン（general purpos domai
ns）」と呼ぶ。なぜならば、たとえそれらのドメインの
内容は異なっていようとも、後ほど明瞭に説明されるよ
うに、それらのドメインはシステム側から似通った方式
で「見られる」からである。従って、システム２はドメ
インレベルにおいて完全にモジュール式である。

【００５０】概念を明示する上で、次のようなドメイン
をシステムに実装することができる。システム管理機
能、バッチ処理機能、データベース管理機能、セキュリ
ティ機能、トランザクションプロセス管理機能および相
互操作性機能。

【００５１】ユーザのニーズを満たす決定されたシステ
ム２は所与の状態でインストールされる。換言するなら
ば、ドメインのコンフィギュレーションとバージョンが
明確に定義される。

【００５２】このインストールは次の二つの方法で得る
ことができる。

【００５３】− まず最初に、「キーインハンド（key-
in-hand）」と呼ぶことができる、すなわち工場でプレ
コンフィギュレーションがなされた、いわゆる初回イン
ストール。

【００５４】− 次に、運転現場におけるマシンの増分
式の更新。つまり、更新はニーズに応じて一つまたは複
数のドメインに関係する。しかし、知られている技術の
「独自型」のシステムとは異なり、システム全体２を変
更する必要はまったくない。

【００５５】実際には、二つの主要タイプの更新が存在
する。

【００５６】− いわゆる更新（すなわち英語では「ア
ップデート」）。つまり、初回インストールの対象にな
った、所与のドメインＤ_jに新しい機能もしくは修正分
を組み込むための、このドメインのより最新のバージョ
ンのインストール。この作業は特に当該ドメインのバー
ジョンのチェンジをもたらす。

【００５７】− 追加（すなわち英語では「アッドオ
ン」）。つまり、当初にインストールされなかった、あ
る特殊なドメイン、たとえばＤ_nの純粋かつ単純な追
加。

【００５８】また、一つまたは複数のドメインを削除で
きることも自明のことである。

【００５９】すべてのドメイン２１〜２３は、直接的
に、あるいは基本ドメイン、すなわちオペレーティング
システム２１を介して、ハードウェアプラットホーム２
０と協働する。同様に、すべての「汎用」ドメイン２２
は特定ドメイン２１および２３と協働する。（図２の）
上下方向のリンクはこの協働関係を示している。

【００６０】本発明の他の態様によれば、有利なこと
に、種々のドメイン２２は相互にもっとも大きな独立性
を有している。換言するならば、これらのドメイン間の
相互作用が最小になることが重要である。しかしなが
ら、一般に、ドメインＤ₁〜Ｄ_nのいくつかの間には関係
が存在している。これらの関係は（図２の）横方向のリ
ンクによって示されている。

【００６１】ドメインの数は実際にはアプリオリに限定
されるものではないが、妥当なドメイン数は１０未満で
あることが好ましい。いずれにせよ、この数は多くても
１０から２０までの範囲内におさまっていなければなら
ないであろう。

【００６２】さもなくば、複雑性が非常に顕著な形で増
大する。つまりｘ（ｘ−１）／２で表される関数。ここ
に、ｘはドメインの合計数である。この場合、本発明に
よるアーキテクチャによってもたらされる利点は大幅に
減少してしまう。

【００６３】では、ドメインＤ_jが構成する基本単位に
ついて、図３を参照しながらより詳しく説明する。この
図３は一つのドメイン、たとえば任意の符号ｊを持つド
メインＤ_jの構造を概略的に示している。

【００６４】ドメインＤ_jは、一つの独立して統合、イ
ンストールおよび更新される単位と定義することができ
る。この単位には、製品と呼ばれる、内部あるいは外部
の様々な供給元のソフトウェアまたはパッケージが含ま
れる。「内部」とは、「独自型」のアプリケーションの
ことをいう。また「外部」とは、市販のアプリケーショ
ンのことをいう。

【００６５】より明確には、一つのドメインは二つの主
要部分を含む。

【００６６】第一の部分４は参照番号４０〜４２によっ
て示されている、一つのドメインに固有な機能を提供す
る各種製品で構成される。たとえば、バッチ処理ドメイ
ンは少なくとも次のような機能を提供する。つまり、印
刷とバックアップの管理。

【００６７】第二の部分３はドメインとそのプロパティ
を記述したデータへのアクセスを可能にする「記述子」
と呼ぶことができる、ドメインＤ_jの特殊なインターフ
ェイスを構成する。

【００６８】ドメインＤ_jによって提供される機能は製
品によってサポートされる。これらの製品は、とりわ
け、それらがシステム２に統合される方法によって、ま
た、それらがインストールされ、実行される方法によっ
て、さらには、それらが場合によっては依存している他
の製品（すなわち他のドメイン）によって特徴付けられ
る。

【００６９】一つのドメインＤ_jは、同一特性をもつ、
あるいは少なくともコンパチブルな特性をもつ製品だけ
をまとめることができる。これらの特性は三つの属性、
すなわち挿入レベルと発生タイプ（occurrence type）
と依存性の形で製品に関連づけられる。

【００７０】従って、ドメインを構成している製品の統
一性上の理由により、システムについてその全体の中で
追求されている様々な有利な特徴を確保しているのは、
また保証しているのはドメインである。

【００７１】部分３、すなわち記述子は、従って、一つ
の特殊なドメインＤ_jを特徴付けている情報へのアクセ
ス、特にその名前とそのバージョンに関する識別子への
アクセスやそのコンポーネントのリストへのアクセスを
可能にしなければならない。また、一つのドメインＤ_j
は、先に述べたように、ある数の属性によって特徴付け
られる。これらの属性については、後ほど詳述する。上
述の基本操作を、すなわちドメインのインストールと更
新を行うことができるためには、これらの情報のすべて
が必要である。これらの情報はドメインを構成している
製品の動作モードについても記述する。

【００７２】本発明の好ましい実施形態においては、属
性の数は三つである。すなわち挿入レベルと発生タイプ
と依存性。

【００７３】挿入レベルは、特にインストール作業やと
りわけ更新作業の際に、ドメインを構成する製品がその
ドメインに統合される方法によって、すなわち、どの機
能特性が制御されるかによって特徴付けられる。

【００７４】概念を明示する上で、また本発明の実際的
な実施形態においては、四つの挿入レベルが定義され
た。

【００７５】これらのレベルは、それぞれの挿入レベル
Ｎ₀〜Ｎ₃の四つの任意なドメインを表している図４ａ〜
図４ｄによって概略的に示されている。

【００７６】最初に、留意すべきことであるが、ドメイ
ンを構成している製品は「独自型」と呼ばれた、メーカ
ー自身によって開発された製品、すなわち内部製品であ
ってもよいし、外部製品であってもよい。また、外部製
品はシステム２（図２）により良く適応されるために補
完されたものであってもよい。なお、この補完を付加さ
れた値という。

【００７７】この点を踏まえた上で、図４ａによって示
されている「レベル０」Ｎ₀は付加された値の皆無の外
部製品、たとえばＰ_0iおよびＰ_0jという符号によって示
されている外部製品しか含んでいない。システムから見
て、レベル０のドメインの製品Ｐ_0iまたはＰ_0jは、知ら
れている技術によるオープンシステムにおいて見られる
であろう製品と同じである。それらのインストールおよ
び／または更新の際にこれらの製品についていかなる制
御もなされない。

【００７８】実際のところ、レベル０のドメインは一つ
の疑似ドメインしか構成していない。また、製品、たと
えばＰ_0iおよびＰ_0jはシステムにインストールされた製
品であるが、厳密にいえば、本発明の特徴を有していな
い製品の一つのセットを構成していると考えることがで
きる。しかしながら、このレベルはシステムのユーザに
補足的なフレキシビリティを提供することを可能にす
る。

【００７９】図４ｂに示された「レベル１」Ｎ₁におい
ては、製品、たとえばＰ_1iおよびＰ_1jは、厳密にいえ
ば、システムに統合されていないが、少なくとも製品の
あるものについて、これらの製品への「付加された値
（added value）」の付与および／またはインストール
された製品のバージョンの制御が存在できる。

【００８０】図４ｂ（およびそれに続く図）では、実際
に統合されたコンポーネント、たとえば製品Ｐ_1jの制御
ルーチンＣＴＬ_1jを含むドメインの部分を象徴的に斜線
で表示した。一方、製品Ｐ_1iは（レベル０のケースと同
様に）まったく制御されない。

【００８１】製品Ｐ_1iおよびＰ_1jはそれらの元のパッケ
ージング（“packaging”）と、それらの設計者によっ
て定められたサポートとを保持する。これらの製品の更
新はドメインの更新とは無関係になされるとともに、上
述したように、データとの比較によって、あるいはあら
かじめ定められた規則を用いて制御されることもできる
し、制御されないこともできる。

【００８２】実際の実施形態として、基本ドメイン２１
（図２）はオペレーティングシステム、たとえば「ＡＩ
Ｘ」（登録商標）タイプの「ＯＳ」を提供する。この場
合、ドメイン２１は挿入レベル１にある。

【００８３】図４ｃは「レベル２」Ｎ２のドメインを示
している。このレベルにおいては、すべての製品、たと
えばＰ_2iおよびＰ_2jは統合されたルーチンＣｔｌ_2iおよ
びＣｔｌ_2jのコントロール下にある。この例外を除け
ば、「レベル２」Ｎ２は「レベル１」Ｎ１と完全に似通
っている。従って、「レベル２」の特徴について再度説
明する必要はない。

【００８４】図４ｄは「挿入レベル３」Ｎ３あるいはそ
れより上位のレベルのドメインを示している。このレベ
ルは本発明の特徴を十分に満たしている。実際のとこ
ろ、すべてのコンポーネント、たとえばＰ_3iおよびＰ_3j
はドメインの中に完全に統合される。このことは、図４
ｄにおいて、これらの製品を取り囲んでいる二重線によ
って象徴的に表示されている。

【００８５】もし外部製品の場合には、それらのパッケ
ージングは完全に再定義されるとともに、これらの製品
はシステムに固有な標準手順であって、かつインストー
ルされた製品についていかなる専門知識も必要としない
手順に従ってインストールされるし、更新される。もは
やインストールすべき、または更新すべき製品の唯一の
バージョン制御のような単純な制御のみが重要である。

【００８６】従って、この挿入レベルにおけるドメイン
は本発明の枠内で追求されているすべての有利な特徴、
すなわちロバストネス、アベイラビリティ、セキュリテ
ィ、フレキシビリティおよびアップグレード能力を十分
に保証することができる。

【００８７】一つの特殊なドメインＤ_j（図３）に関連
した第二の属性は発生タイプである。この属性は、一つ
の同じノード上に同時に共存させることができる、およ
び／または実行させることができるインスタンスの数
（number of instances）を特徴付ける。なお、ノード
とは、ある分散システムの一つのハードウェア要素をい
う。

【００８８】有利なことに、一つの同じドメインＤ_jを
構成しているすべての製品は同じ発生タイプを有してい
なければならない。もしそうでなければ、もっとも低い
発生タイプが取られる。

【００８９】三つの主要な発生タイプを定義することが
できる。

【００９０】− 以下「ＳＩＳＲ」（すなわちSingle I
ntall & Single Run）と呼ばれる第一の発生タイプは、
当該ドメインの単一発生と単一実行をなおさら可能にす
る。ドメインのバージョンの交換は、前のバージョンと
の交換によってしかなされ得ない。

【００９１】− 以下「ＭＩＳＲ」（すなわちMultiple
Intall & Single Run）と呼ばれる第二の発生タイプ
は、一つの同じノード上への当該ドメインの多重インス
トールを可能にするが、実行は常に単一である。各発生
はドメインの異なるバージョンに対応しているが、一つ
の製品の同一バージョンが一つのドメインのいくつかの
異なるバージョンの中で複数発生的に存在することがで
きる。

【００９２】− 以下「ＭＩＭＲ」（すなわちMultiple
Intall & Multiple Run）と呼ばれる第三の発生タイプ
は、一つの同じノード上への当該ドメインの多重インス
トールを可能にするとともに、多重実行も可能にする。

【００９３】一つのドメインに関連した発生タイプは多
大な重要性をもっている。なぜならば、その発生タイプ
によって更新中のシステムのアベイラビリティが直接条
件づけられるからである。

【００９４】「ＳＩＳＲ」タイプの発生では、当該ドメ
インの一つのインスタンスしか存在していなく、この新
しいインスタンスしか実行できなく、かつ少なくとも現
在有効なインスタンスを削除しない限り元に戻すことは
可能でない。さらに、ドメインの更新はシステムの完全
な停止が必要になりうるであろう。

【００９５】「ＭＩＳＲ」タイプの発生では、ドメイン
の変化に対応した複数のインスタンスが共存できる。た
だし、ある与えられた時点において実行可能なインスタ
ンスは一つだけである。しかしながら、実行されるイン
スタンスを選択することができる。従って、元に戻すこ
とが可能である。なぜならば、実行するインスタンスを
選択できるからである。換言するならば、更新を再度行
うことなく新しいインスタンスをストップすることが可
能である。古いインスタンスの削除は新しいインスタン
スのインストールから完全に非同期化されることができ
る。運転は更新の時間中継続できる。運転は、少なくと
も当該ドメインの製品に関して、新バージョンへの切換
時だけ中断されなければならない。

【００９６】「ＭＩＭＲ」タイプの発生では、複数のイ
ンスタンスが共存できるとともに、すべてのインスタン
スが同時に実行可能であるので、たとえば旧バージョン
上で運転を保持しながら、また新バージョン上でテスト
を行いながら、漸進的な方法で新バージョンを供用する
ことが可能になる。従って、新バージョンへの切換の完
全な制御が得られる。さらに、特段の制約がない限り、
このタイプの発生は当該製品の動作を中断することなし
に新バージョンのインストールを可能にする。

【００９７】従って、このタイプの発生は言及した有利
な特徴を確保するだけでなく、最高のフレキシビリティ
も提供する。

【００９８】最後に指摘しておかなければならないが、
「ＳＩＳＲ」タイプの初期発生を提供する外部製品は、
再パッケージングされることによって、たとえば「ＭＩ
ＳＲ」タイプ、ひいては「ＭＩＭＲ」タイプのより優れ
た発生を提供することができるようになるので、より有
利になる。

【００９９】一つの特殊なドメインＤ_j（図３）に関連
した第三の属性は依存性に関するものである。依存性は
当該ドメインＤ_jの製品の良好な動作上存在している必
要があるシステム２（図２）の一つまたは複数の他のド
メインＤ₁〜Ｄ_nを指し示す。ドメインＤ_jの依存性はこ
のドメインを構成している各製品のレベルにて識別され
る全ての依存性によって構成される。

【０１００】本発明のアーキテクチャの有利な特徴を得
るには、同一依存性をもつ製品のみを一つの同じドメイ
ンにまとめる方が有利である。基本ドメインと呼ばれる
ドメイン（図２：２１）と動作モニタドメイン（図２：
２３）はシステムの心臓部を構成しており、他のすべて
のドメインＤ₁〜Ｄ_nはこれらの二つの特定ドメインに対
して依存性を有している。最後に、ドメインが「ＭＩＳ
Ｒ」あるいは「ＭＩＭＲ」タイプの多重発生をもつなら
ば、その個々の発生間において絶対に依存性が存在して
いてはならない。

【０１０１】では、ドメインＤ_jの実際の構成例につい
て詳述する。

【０１０２】この実際の例では、ドメインは一つのオブ
ジェクト階層に従って構成される。この編成は、狭義に
は、挿入属性がレベル３（図４ｄ参照）であるドメイン
にしか適用されないか、あるいは、挿入レベル１および
２のドメイン（図４ｂおよび図４ｃ参照）については、
完全に統合された製品（これらの図の斜線部）に適用さ
れる。

【０１０３】では、単純化のため一つの製品Ｐ_iしか含
んでいないドメインＤ_jについて、図５ａおよび５ｂを
参照しながら以下考察する。当然のことながら、これら
の措置は複数の製品を含んでいるドメインにも適用され
る。実際のところ、ドメインの基本構造が、図５ｂによ
ってより具体的に示されているように、製品であること
は明らかである。また、一つのドメインには、一つまた
は複数の製品が含まれる。

【０１０４】しかしながら、本発明の有利な実施形態に
おいて、四つのレベルをもつ階層構造について特筆する
ことができる。

【０１０５】第一のレベルはいわゆる製品Ｐ_iである。
それはある与えられた機能を提供する一つの統一のとれ
たセットである。製品は第二の階層レベルを構成する
（図５ａに示されている例では三つの）モジュールＭ_i1
〜Ｍ_i3のセットまたは「パッケージ」で構成される。

【０１０６】従って、第二のレベルはモジュールＭ_i1〜
Ｍ_i3をまとめる。モジュールＭ_i1〜Ｍ_i3は製品Ｐ_iの一
つの統一のとれた機能サブセットであり、（図５ａで示
されている例では）ファイルセットＦＳ_i1、ＦＳ_i2およ
びＦＳ_i31とＦＳ_i32のセットで構成される。

【０１０７】これらの二つのレベルは、第一の外部ビジ
ビリティレベルＮＶｅ、すなわちドメインＤ_jの更新お
よび／またはその初回インストールに対してユーザ側か
ら「見ることのできる」第一のレベルを構成する。

【０１０８】かくして、ドメインＤ_jの製品の全部また
は一部、ならびにそれらの製品を構成しているモジュー
ルの全部または一部を、当然これらの製品に関係した一
貫性の諸制約を考慮した上でインストールすることが可
能である。

【０１０９】第三のレベルはファイルセットＦＳ_i1、Ｆ
Ｓ_i2およびＦＳ_i31とＦＳ_i32をまとめる。ファイルセッ
トはモジュールによって提供される機能性の全部または
一部の実施に寄与するファイルのセットである。モジュ
ール、たとえばモジュールＭ_i1およびＭ_i2はそれぞれ単
一のファイルセットＦＳ_i1およびＦＳ_i2しか含むことが
できない。一方、二つ以上のファイルセットを含むこと
ができるモジュールもある。それは二つのファイルセッ
トＦＳ_i31とＦＳ_i32を含んでいるモジュールＭ_i3がその
ケースである。

【０１１０】第四のレベルはファイル自体Ｆ_i11、
Ｆ_i12、Ｆ_i21、Ｆ_i22、Ｆ_i31、Ｆ_i321およびF_i322で構
成される。各ファイルセットは一つあるいは複数のファ
イルを含むことができる。

【０１１１】第三と第四のレベルは通常の使用時ではユ
ーザ側から見ることのできない内部ビジビリティレベル
ＮＶｉを構成する。しかし、更新はこのレベルに関係す
る。

【０１１２】製品の基本構造は階層的であるので、次の
規則が順守されなければならない。

【０１１３】− モジュールは製品に、しかも単一製品
に属しており、かつ少なくとも一つのファイルセットを
含んでいること。

【０１１４】− ファイルセットはモジュールに、しか
も単一モジュールに属しており、かつ少なくとも一つの
ファイルを含んでいること。

【０１１５】− ファイルはファイルセットに、しかも
単一ファイルセットに属していること。

【０１１６】ドメインＤ_jは製品とモジュールの一つの
セットであり、常に、また少なくとも一つのモジュール
とドメインＤ_jを記述した一つの特定のファイルセット
とを含む。この特定ファイルセットは少なくともドメイ
ンＤ_jの他のすべてのファイルセットのリスト、すなわ
ち名前とバージョン番号が含まれた一つのやはり特定の
ファイルを含む。この特定ファイルは、入れ物としての
役割に加え、ドメインＤ_jの一貫性を保証するのに役立
つ。実際のところ、本発明の一つの特徴によれば、ドメ
インＤ_jの他のすべてのファイルセットは特定のファイ
ルセットに依存していると宣言される。ドメインＤ_jに
属するある任意のファイルセットのインストールまたは
更新は、少なくとも制御された、あるいは統合された製
品に関しては（挿入レベル１〜３）、ドメインのバージ
ョンがそれを許す場合にのみ可能である。

【０１１７】また、ファイルセットの利用は該当する挿
入レベルに応じて異なる。

【０１１８】挿入レベル３のドメインでは、ファイルセ
ットは製品の実行可能なプログラムで構成される。

【０１１９】挿入レベル１または２のドメインでは、フ
ァイルセットは、「付加された値」を有するものを除
き、製品そのものを含んでいない。なぜならば、これら
の製品は供給元が外部であるので、ドメインの外にある
からである。それらのファイルセットはそれらについて
記述するのに、またインストールおよび／または更新の
際にバージョン制御を行うのに役立つのみである。一般
に、外部製品のインストールについては、ドメインのフ
ァイルセットが実効的なインストールの際に実行され、
かつ実際の製品との照合を行う「スクリプト」の形での
ユーティリティプログラムを含んでいる必要がある。ま
た、これらのスクリプトは製品のいわゆるインストール
またはその更新を開始させることもできる。

【０１２０】図６によって概略的に示されている本発明
の特殊な実施形態では、システム２はサービスドメイン
あるいは「ツール」ドメインと呼ぶことができる、第三
の特定ドメイン２４を含むことができる。

【０１２１】このドメインは、特に、ドメインＤ₁〜Ｄ_n
の全部または一部のインストールおよび／または更新を
可能にする、また各ドメインの中において、内部製品で
あるか、すなわちドメインの中にアプリオリに完全に統
合された製品であるか、外部製品であるかを問わず、製
品の全部または一部のインストールおよび／または更新
を可能にする、やはり特定のソフトウェア製品あるいは
ユーティリティプログラムを含む。なお、これらの外部
製品はドメインに関連した挿入レベルに応じて、制御さ
れる場合とされない場合とがある。勿論、このドメイン
の中に存在しているインストールおよび更新ツールまた
は「エンジン」はドメインＤ₁〜Ｄ_nと、ならびに基本ド
メイン２１および動作モニタドメイン２３と、またより
具体的には、それらの記述子セット３と相互に作用す
る。インストールはドメイン２４および／または記述子
セット３に記録された規則に従って行われる。

【０１２２】図３を再度参照するならば、記述子と呼称
されたセット３は、少なくとも、ドメインＤ_jの名前と
バージョンが含まれたレコード３０、このドメインに関
連した諸属性を記述したレコード３１、ドメインの内容
の記述のレコード３２へのアクセスや、ドメインの、ま
たドメインを構成している製品の一組のインストールお
よび更新規則へのアクセスを可能にする。図５ａを参照
して説明したように、各ドメインＤ_jは他のファイルセ
ットのリスト、すなわち少なくともそれらの名前とバー
ジョン番号が含まれた一つの特定ファイルセットを含
む。また、これらの情報はスクリプトによって、またド
メインの外にある製品のインストールおよび更新規則に
よって補完されることもできる。

【０１２３】上述の情報は一つの定められたドメインの
内部に分配されることができるにもかかわらず、このド
メインは、たとえアクセスされる情報の内容がドメイン
ごとに異なっていても、すべてのドメインのための標準
インターフェイスを構成する記述子セット３を介して同
一に外部から「見られる」。

【０１２４】以上の説明から、ドメインの構成とドメイ
ンの主な使用規則を次のように要約することができる。

【０１２５】− 各ドメインはファイルセットの一つの
セットで構成される。また、これらのファイルセット自
体はモジュールや製品ごとにまとめることができる。

【０１２６】− 各ドメインはその名前とバージョンを
決める一つの特定ファイルセットを含む。

【０１２７】− すべてのドメインは別個のファイルセ
ットで構成される。すなわち、換言するならば、二つの
任意の異なるドメインは異なるファイルセットのみを含
む。

【０１２８】− ドメインのファイルセットの変化、つ
まりこのドメインのあるバージョンから次のバージョン
への変化は「上位互換性」と呼ばれる規則を順守しなけ
ればならない。すなわち、バージョンｍに代わるバージ
ョンファイルセットｍ＋１（ここに、ｍは任意）は、変
化しなかった他のファイルセットのどれ一つにおいても
いかなる後退（regression）をも引き起こさない。

【０１２９】− 機能依存性はファイルセットレベルで
定義されるが、これらの機能依存性はドメインレベルで
全体的に可視化される（依存性属性）。

【０１３０】以上の説明を読むことにより、本発明が頭
書の諸目的を十分に達成していることが容易にわかる。

【０１３１】本発明は、「オープン」と呼ばれるシステ
ムのアーキテクチャの利点の本質的部分と、「独自型」
と呼ばれるシステムのアーキテクチャの利点とを、すな
わち堅固性、使用可能性、セキュリティ、フレキシビリ
ティおよびアップグレード能力を兼ね備えることを、そ
れらのアーキテクチャの欠点をもつことなく可能にして
いる。

【０１３２】本発明は、外部製品をそれらに固有な手順
に従って、最低限の（バージョン）制御で、ひいては一
切の制御なしにインストールしたり、更新したりするの
にまさに適している。勿論、一切の制御なしのケースで
は、またこれらの製品のみについては、「オープン」シ
ステムによってもたらされるコンフィギュレーションと
類似した環境が提供される。この選択肢はより大きなフ
レキシビリティを得ることを可能にするが、「独自型」
システムに関連したすべての利点が得られない。しか
し、当該製品は、もしそれらが存在するならば、本発明
に固有のドメインベースのアーキテクチャによって明確
にインデックス化されることができるし、問題の発生リ
スクもその範囲が明確に限定される。最後に指摘してお
くべきことであるが、外部製品については、たとえ「付
加された値」なしでも、バージョン制御の対象になって
いれば、この制御によって前記リスクは限定される。

【０１３３】なお、明白なことであるが、本発明はとり
わけ図２〜図６に関連して明瞭に説明した実施形態だけ
に限定されない。特に、システムを構成しているドメイ
ンの数および／またはそれらのドメインの構成は、情報
処理システムの明確な適用やユーザの固有ニーズに全面
的に依存している。

【図面の簡単な説明】

【図１】従来技術による「独自型」のアーキテクチャを
示す概略図である。

【図２】本発明によるアーキテクチャの一つの実施形態
を示す概略図である。

【図３】図２のアーキテクチャの基本構成要素である一
つのドメインの構造を示す概略図である。

【図４ａ】各種のドメインを示す第１の図である。

【図４ｂ】各種のドメインを示す第２の図である。

【図４ｃ】各種のドメインを示す第３の図である。

【図４ｄ】各種のドメインを示す第４の図である。

【図５ａ】ドメインの一つの階層構成例を示す第１の図
である。

【図５ｂ】ドメインの一つの階層編成例を示す第２の図
である。

【図６】一つの特殊なドメインと、システムの他のドメ
インとのその関係を示す図である。

【符号の説明】

２システム２０ハードウェアプラットホーム２１基本（システム）２２ドメイン（Ｄ₁、Ｄ₂、Ｄ_j、Ｄ_n）２３動作モニタ

───────────────────────────────────────────────────── フロントページの続き (72)発明者アラン・ルタンチユリエフランス国、75012・パリ、ブルバール・シユルト、14 (72)発明者ジエラール・シトボンフランス国、94400・ビトリー、リユ・ガニエ、12 (72)発明者ジヤン−フランソワ・トウザンフランス国、91300・マシー、アレ・アルベール・トマ、30

Claims

【特許請求の範囲】

【請求項１】ソフトウェア製品のセットと協働するハ
ードウェアプラットホーム（２０）を含む情報処理シス
テムのアーキテクチャであって、前記セットがドメイン
と呼ばれるサブセット（２１−２４）に再分割され、各
ドメインが少なくとも前記ソフトウェア製品（４０−４
２）の一つを含んでいること、また、各ドメイン（２１
−２４）が特定の決定された情報（３０−３２）へのア
クセスを可能にする記述子と呼ばれるサブセット（３）
を含んでおり、前記情報が少なくともドメインの一つの
識別子（３０）と、それを含むソフトウェア製品を記述
したデータ（３２）とを含んでいること、さらに、所定
の規則から、また前記特定の決定された情報（３０−３
２）から前記ドメイン（２１−２４）のインストールお
よび／または更新を可能にする手段が設けられているこ
とを特徴とするアーキテクチャ。
【請求項２】前記識別子（３０）が少なくともドメイ
ンの名前とバージョンの情報を含むことを特徴とする請
求項１に記載のアーキテクチャ。
【請求項３】前記ソフトウェア製品が二つのカテゴ
リ、すなわち前記ドメイン（２１−２４）に完全に統合
されたと言われるソフトウェア製品を表しており、かつ
システム（２）に共通な、標準化されたインストールお
よび更新規則に従う第一カテゴリと、特定のインストー
ルおよび更新規則を保持している、外部製品と呼ばれる
種々雑多な製品を表している第二のカテゴリとに属して
いることを特徴とする請求項１に記載のアーキテクチ
ャ。
【請求項４】前記特定の決定された情報がさらに前記
ドメイン（２１−２４）に関連した特定の機能特性を記
述した、これらのドメインに関する一連の属性（３１）
を含むことを特徴とする請求項１に記載のアーキテクチ
ャ。
【請求項５】第一の属性が「挿入レベル」と呼ばれる
属性であって、所定のスケールに従って、一つの所与の
ドメイン（Ｄ_j）を構成している前記ソフトウェア製品
（Ｐ_0i〜Ｐ_3j）の統合および制御レベルを表しているこ
とを特徴とする請求項３および４に記載のアーキテクチ
ャ。
【請求項６】前記挿入レベルのスケールが上位レベル
（Ｎ３）を含んでおり、この上位レベルについて前記の
すべてのソフトウェア製品がシステム（２）に共通な、
標準化された前記のインストールおよび更新規則に従う
完全に統合されたと言われるソフトウェア製品（Ｐ_3i〜
Ｐ_3j）であることを特徴とする請求項５に記載のアーキ
テクチャ。
【請求項７】前記挿入レベルのスケールが中間レベル
（Ｎ₀〜Ｎ₂）を含んでおり、これらのレベルについて前
記ソフトウェア製品（Ｐ_0i〜Ｐ_2j）の全部または一部が
外部製品と呼ばれる製品であること、また、少なくとも
これらの外部ソフトウェア製品（Ｐ_1i、Ｐ_2i、Ｐ_2j）の
一部がバージョン情報と呼ばれる情報に関連しているこ
と、さらに、これらのソフトウェア製品を一つの所与の
ドメイン（Ｄ_j）にインストールする、および／または
それらを更新する際に一貫性検査を行うために前記特定
情報と比較する手段が設けられていることを特徴とする
請求項５に記載のアーキテクチャ。
【請求項８】第二の属性が「発生タイプ」と呼ばれる
属性であって、前記システム（２）上にインストールさ
れることができる、また共存することができる一つの所
与のドメイン（Ｄ_j）のインスタンス数と、これらのイ
ンスタンスの同時実行の可能性の有無との組み合わせを
表していることを特徴とする請求項３および４に記載の
アーキテクチャ。
【請求項９】発生タイプが全部で三つであること、す
なわちシステム（２）への前記の決定されたドメイン
（Ｄ_j）の単一インストールと単一実行の可能性を提供
する第一発生タイプと、多重インストールと単一実行の
可能性を提供する第二発生タイプと、多重インストール
と多重実行の可能性を提供する第三発生タイプであるこ
とを特徴とする請求項８に記載のアーキテクチャ。
【請求項１０】第三の属性が「依存性」と呼ばれる属
性であって、一つの決定されたドメイン（Ｄ_j）のソフ
トウェア製品の全部または一部の動作のために前記シス
テム（２）の中に必ず存在していなければならない少な
くとも一つの別のドメインを指し示すことを特徴とする
請求項３および４に記載のアーキテクチャ。
【請求項１１】一つの所与のドメイン（Ｄ_j）を構成
しているソフトウェア製品についての前記データがこの
ドメインの内容を記述した一つのリストと、ドメイン
の、またドメインを構成している前記ソフトウェア製品
の一組のインストールおよび更新規則とを含むことを特
徴とする請求項１に記載のアーキテクチャ。
【請求項１２】前記システム（２）がオペレーティン
グシステムソフトウェアを提供する基本ドメインと呼ば
れる少なくとも一つの第一の特定ドメイン（２１）を含
むことを特徴とする請求項１から１１のいずれか一項に
記載のアーキテクチャ。
【請求項１３】前記システム（２）がシステムの動作
モニタを提供する少なくとも一つの第二の特定ドメイン
（２３）を含むことを特徴とする請求項１２に記載のア
ーキテクチャ。
【請求項１４】前記システム（２）が、さらに、前記
ドメイン（２１）の、また前記ドメイン（２１）を構成
しているソフトウェア製品の全部または一部のインスト
ールおよび／または更新を可能にする少なくともソフト
ウェアツールを含んだサービスドメインと呼ばれる一つ
の第三の特定ドメイン（２４）を含むことを特徴とする
請求項１３に記載のアーキテクチャ。
【請求項１５】前記ドメイン（Ｄ_j）が四つのレベル
をもつ一つの階層構造を有しており、ソフトウェア製品
（Ｐ_i）が第一のレベルを表しており、各製品（Ｐ_i）が
第二のレベルを表している少なくとも一つのモジュール
（Ｍ_i1−Ｍ_i3）を含み、各モジュール（Ｍ_i1−Ｍ_i3）が
少なくとも第三のレベルを表している少なくとも一つの
ファイルセット（ＦＳ_i1−ＦＳ_i32）を含み、各ファイ
ルセット（ＦＳ_i1−ＦＳ_i32）が第四のレベルを表して
いる少なくとも一つのファイル（Ｆ_i11−Ｆ_i322）を含
むこと、及び、一つの決定されたファイルが単一ファイ
ルセットにだけ属しており、一つのファイルセットが単
一モジュールに属しており、一つのモジュールが単一ソ
フトウェア製品に属していることを特徴とする請求項１
から１４のいずれか一項に記載のアーキテクチャ。
【請求項１６】ドメイン（Ｄ_j）の各々がドメインの
前記識別子の、またドメインを構成しているソフトフェ
ア製品についての前記データの記録のために一つの特定
のファイルセットをもつ少なくとも一つのモジュールを
含むことを特徴とする請求項１５に記載のアーキテクチ
ャ。
【請求項１７】外部製品と呼ばれるソフトウェア製品
に関連したファイルセットがこれらの外部ソフトウェア
製品を記述したデータで、かつ一つの決定されたドメイ
ンへのそれらのインストールおよび／またはこのドメイ
ンの中でのそれらの更新の際にそれらのバージョンの制
御を可能にするデータを含むことを特徴とする請求項１
５に記載のアーキテクチャ。
【請求項１８】一つの所与のドメイン（Ｄ_j）の中に
存在している前記ファイルセットが別個のものであるこ
とを特徴とする請求項１５から１７のいずれか一項に記
載のアーキテクチャ。