JP7373587B2 - Ｄｂｍｓにおけるサービス管理 - Google Patents

Description

本発明は、データベース管理システム（ＤＢＭＳ）に関連しており、より詳細には、ＤＢＭＳとの関連におけるサービスの管理に関連している。

ＤＢＭＳとの関連において、データは、多くの場合、さまざまなタスクに関して、複製されるか、分析されるか、チェックされるか、またはその他の方法で処理される必要がある。これらのタスクの一部は、サービスの形態で実装される。一部のサービスは、ＤＢＭＳの不可欠な部分として提供されることがあるが、他のサービスは、例えばＤＢＭＳのプラグインまたはアドオンのインストール時に、後で追加されることがある。一部のサービスは、ユーザの明示的な照会のみに応答してインスタンス化されることがあり、他のサービスは、バックグラウンドで実行されるデーモンの形態で実装されることがある。例えば、ＩＢＭのＩＢＭ Ｄｂ２ Ａｎａｌｙｔｉｃｓ Ａｃｃｅｌｅｒａｔｏｒ（ＩＤＡＡ）は、「コンフィギュレータ」または「トレーサ」のようなインフラストラクチャ・サービスを備え、カタログ内のメタデータへのアクセスを提供するサービスを備え、例えば「システム保守」デーモンによってスケジュールされるバックグラウンド・サービスをさらに備える。

ＤＢＭＳに統合されるサービスの種類の異質性のため、および一部のサービスが、ユーザ固有の必要性に従って、ＤＢＭＳのインストール後に追加されることがあるため、ＤＢＭＳによって提供されるすべてのデータ処理サービスの管理が複雑になり、間違いを起こしやすいタスクになる。この状況は、多くの場合、例えばサービスのインスタンス化中またはシャットダウン中に、異なるサービス間に複雑な依存関係が存在するということによって、さらに複雑化する。さらに悪いことに、一部のサービスは遅延インスタンス化に基づいて実装される。これは、特定のサービスがインスタンス化される時間を前もって予測できないということを意味する。

従来技術のＤＢＭＳの現在の状態は、ＤＢＭＳによってサポートされているすべてのサービスのリストを作成する単一の中心的ソフトウェア・コードを使用する。単一のソース・コード・ファイルに含まれるサービスのこの中央リストは、古くなりやすいため、維持するのが困難である。例えば、ＤＢＭＳの実行時に、１つまたは複数の追加のサービスを含んでいる新しいプログラム・ライブラリがＤＢＭＳに読み込まれるときに、このリストは古くなる。このリストがソース・コード内で指定される場合、各ソース・コードの変更時に、各コードが再コンパイルされる必要がある。したがって、ＤＢＭＳによってサポートされているサービスのインスタンス化およびシャットダウンを調整するために、サービスの中央リストを使用することは、間違いを起こしやすく、複雑であり、非常に多くの時間を必要とする。

複数のサービスのインスタンス化を指定して調整する中央リストまたはファイルのさらに別の否定的側面は、多数のサービス（例えば、数百または数千ものサービス）を管理する必要がある場合に、それらのファイルが非常に複雑になる傾向があるということである。この場合、異なるサービスの依存関係を中心的に指定するソース・コードが、プログラマによって識別するのが困難である循環依存関係を含むということが、発生することがある。そのような循環依存関係は、無限ループおよびプログラムの不具合をもたらすことがある。

加えて、サービスのインスタンス化を調整するための中央リストの使用は、サービスの遅延インスタンス化と組み合わさって、リソース消費の増加という不利益に関連する。予測できない時点でサービスが遅延インスタンス化される場合のサービスのインスタンス化のエラーを防ぐため一般的方針は、遅延インスタンス化される特定のサービスによって必要とされることがあるＤＢＭＳを開始するときに、初期設定によってすべてのサービスをインスタンス化することである。この方針は、遅延インスタンス化に関連するエラーを防ぐのに役立つことがあるが、サービスが不必要にインスタンス化されることがあるため、ＣＰＵおよびメモリのリソースの消費を増やす。例えば、ユーザの照会に応答して遅延インスタンス化されるサービスの正しいインスタンス化を単に保証するために、特定のサービスがインスタンス化される場合、このサービスは、遅延インスタンス化されたサービスに関するユーザの照会がこれまで受信されない場合のような状況において、リソースを不必要に消費することがある。

したがって、現在のＤＢＭＳにおけるサービス管理は、扱いにくく、間違いを起こしやすいタスクであり、多くの場合、プログラムの不具合、ＣＰＵおよびメモリの多くの消費、ならびにソース・コードを変更して再コンパイルせずに新しいサービスおよびプログラム・ライブラリを統合できない、柔軟性のないシステムをもたらす。

本発明は、独立請求項において指定されるように、ＤＢＭＳ内の複数のサービスを管理するためのコンピュータ実装方法、コンピュータ可読ストレージ媒体、および対応するコンピュータ・システムに関連している。本発明の実施形態は、従属請求項において与えられる。本発明の実施形態は、相互に排他的でない場合、互いに自由に組み合わせられ得る。

１つの態様では、本発明は、ＤＢＭＳ内の複数のサービスを管理するためのコンピュータ実装方法に関連している。サービスは、ＤＢＭＳによって管理されているデータベースに格納されているか、または格納されるために受信されたデータを処理するようにそれぞれ構成される。この方法は、ＤＢＭＳに動作可能なように結合されたサービス・マネージャを提供することと、ＤＢＭＳの実行時に、自動的かつ動的に複数のサービスをサービス・マネージャに登録することと、サービス・マネージャによって、複数の登録されたサービスのうちの異なるサービス間の依存関係を自動的に管理することとを含む。

さらに別の態様では、本発明は、プログラム命令が具現化されているコンピュータ可読ストレージ媒体に関連しており、これらのプログラム命令は、プロセッサに、ＤＢＭＳ内の複数のサービスを管理するための方法を実行させるように、プロセッサによって実行可能である。サービスは、ＤＢＭＳによって管理されているデータベースに格納されるか、または格納されるために受信されたデータを処理するようにそれぞれ構成される。この方法は、ＤＢＭＳ内の複数のサービスを管理することを含む。サービスは、ＤＢＭＳによって管理されているデータベースに格納されているか、または格納されるために受信されたデータを処理するようにそれぞれ構成される。この方法は、ＤＢＭＳに動作可能なように結合されたサービス・マネージャを提供することと、ＤＢＭＳの実行時に、自動的かつ動的に複数のサービスをサービス・マネージャに登録することと、サービス・マネージャによって、複数の登録されたサービスのうちの異なるサービス間の依存関係を自動的に管理することとを含む。

さらに別の態様では、本発明は、ＤＢＭＳおよびＤＢＭＳに動作可能なように結合されたサービス・マネージャを備えているコンピュータ・システムに関連している。サービス・マネージャは、ＤＢＭＳの実行時に、自動的かつ動的に複数のサービスをサービス・マネージャに登録するように構成され、これらのサービスは、ＤＢＭＳによって管理されているデータベースに格納されているか、または格納されるために受信されたデータを処理するようにそれぞれ構成される。サービス・マネージャは、複数の登録されたサービスのうちの異なるサービス間の依存関係を自動的に管理するようにさらに構成される。

以下では、次の各図面を単に例として参照し、本発明の実施形態をより詳細に説明する。

ＤＢＭＳおよびサービス・マネージャを備えているコンピュータ・システムを示す図である。 ＤＢＭＳおよびサービス・マネージャを備えているコンピュータ・システムをさらに示す図である。 ＤＢＭＳ内のサービスを管理するための方法のフローチャートである。 複数のサービスの依存関係を示す図である。 より大きいシステム・アーキテクチャにおけるサービスおよびサービス・マネージャの統合を示す図である。 サービス・クラスのソース・コードのセクションを示す図である。 サービスを実装するために使用される複数のオブジェクトおよびインターフェイス・クラスのソース・コードのセクションを示す図である。

本発明の実施形態は、特に、サービスの一部に遅延インスタンス化を使用することとの関連において、システムの柔軟性および保守性を高め、リソースの消費を減らす、ＤＢＭＳ内の複数のサービスを管理するためのシステムおよび方法を提供するという利点を有することができる。最先端のサービス管理方法に関連する技術的不利益の一部またはすべてを防ぐことができる。

本発明の実施形態は、ＤＢＭＳの実行時に、１つまたは複数のサービスをそれぞれ含んでいるライブラリを動的に読み込み、中央ファイルを手動で変更すること、またはコードを再コンパイルすること、あるいはその両方を必要とせずに、ＤＢＭＳ内の新しいサービスをインスタンス化できるようにすることができる。

本発明の実施形態は、ＤＢＭＳによってサポートされているサービスの単一の中央リストに基づく最先端のサービス管理方法の多くの技術的な否定的側面を防ぐことができ、すべてのサービスがＤＢＭＳに自動的に追加され、実行時にそれ自身をサービス・マネージャに登録するため、有利であることがある。したがって、どのソース・コードを変更して再コンパイルすることも、不要になる。さらに、サービス・マネージャが、自動的に追加されたサービスの依存関係を含む、サービスの依存関係を自動的に維持するため、特定のサービスがインスタンス化される前に、前述の特定のサービスによって必要とされるすべてのサービスがサービス・マネージャによってインスタンス化されるということが、保証される。これによって、ＤＢＭＳの実行時に新しいサービスを自動的に登録するように適応されたサービス・マネージャによって依存関係が管理されるため、初期設定による多すぎるサービスのインスタンス化を防ぎ、サービスのインスタンス化中のエラーを防ぐことを、可能にすることができる。

実施形態によれば、この方法は、サービス・マネージャへのサービスのうちの１つの登録中に、サービス・マネージャによって、登録される１つのサービスによって必要とされる１つまたは複数の他のサービスを自動的に識別することと、依存関係が、登録されるサービスの依存関係および必要な他のサービスの依存関係も含むように、複数の登録されたサービス、登録されるサービス、および１つのサービスの登録中に識別されたサービスの間の依存関係を更新することとをさらに含む。

例えば、登録される特定のサービスによって必要とされる１つまたは複数の他のサービスは、前述の特定のサービス内（例えば、サービスのソース・コード内）で指定することができ、または前述の特定のサービスの機能によってサービス・マネージャに動的に提供することができ、あるいはその両方が可能である。例えば、この機能は、例えばサービスのソース・コード内またはサービスに関連するクラス・ファイル内で指定された必要なサービスのクラス名を各文字列に変換するように構成されたサービスによって作成された文字列のリストを返すｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数であることができる。これらの文字列は、特定のサービスがインスタンス化される前に、必要なサービスを登録するために、任意選択的に、必要なサービスを動的にインスタンス化するためにも、サービス・マネージャによって引数として使用されてよい。

これは、登録される１つのサービスによって必要とされる１つまたは複数のサービスのクラス名が、中央管理された構成ファイル内ではなく、サービス自体の内部で明示的または暗黙的に指定されるため、有利であることがある。これによって、中央ファイル内の数百または数千もの多くのサービスの依存関係のグローバルな管理が回避されるということを、保証することができる。サービスを管理する（登録する、初期化する、またはシャットダウンする、あるいはその組み合わせを実行する）ためにサービス・マネージャによって引数として使用される文字列へのサービスのクラス名の自動変換は、サービス名の標準的かつ確定的使用を保証できるため、有利であることがある。

好ましい実施形態によれば、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数は、呼び出されたときに、１つまたは複数の必要なサービスのクラス名を各文字列に変換することと、１つまたは複数の文字列をコンパイラによってチェック可能なオブジェクトに変換することと、コンパイラによってチェック可能なオブジェクトを、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を呼び出したサービス・マネージャに返すこととを実行するように構成される。

コンパイラに知られている種類のデータ・オブジェクトへのクラスのソース・コード内で指定されたクラス名の自動変換の使用は、コンパイル時および任意選択的に設計時に、特定のサービスが正しく参照されたかどうかをコンパイラがチェックできるようにすることができる。これは、プログラミング／ソフトウェア開発中のタイプミス、サービスの循環依存関係、またはサービス名の重複、あるいはその組み合わせを防ぐことに役立つことがある。

特定のサービスの依存関係が変化した場合に、ＤＢＭＳの中央サービス・リポジトリを更新する必要がなく、ＤＢＭＳのソース・コードを再コンパイルする必要もない。加えて、特定の解析サービスまたは数学的サービスのライブラリを必要とするようにサービスが変更された場合、いずれにせよ、このサービスのソース・コードを変更し、再コンパイルすることが必要になることがある。しかし、本発明の実施形態によれば、そのような追加のサービスをＤＢＭＳに読み込むことは、中央サービス・リポジトリのどのような手動による変更または再コンパイルも必要としない。反対に、一部の最先端のシステムでは、サービスのソース・コードに加えて、サービスの中央リストを含んでいるＤＢＭＳのソース・コード、または少なくともサービスのこの中央リストも、更新することが必要になるであろう。

実施形態によれば、サービス・マネージャは、動的に読み込まれたサービスを登録することと、サービス・マネージャに登録されたすべてのサービスの依存関係を含んでいる動的に更新されたデータ構造に従って、新たに読み込まれサービスのうちの１つまたは複数を適切な順序でインスタンス化することとを実行するように適応される。サービスは、どのソース・コードまたは中央構成ファイルも手動で更新することを必要とせずに、必要に応じて動的にインスタンス化され、シャットダウンされ得る。例えば、サービス・マネージャは、ＤＢＭＳの実行時に、１つまたは複数の新しいサービスを含んでいるライブラリをＤＢＭＳに動的に読み込むように、構成され得る。このライブラリは、特定のアクション（例えば、何かのデータのＯＬＡＰ解析、例えば、特定の統計クラスタリング分析）を実行できることを保証するために、ＤＢＭＳに読み込まれる。ライブラリの読み込みは、明示的なユーザのアクションによってトリガーされてよい。読み込まれたライブラリ内の新しいサービスは、読み込まれたライブラリの一部、またはすでに登録されたサービス全体の一部、あるいはその両方であることもあれば、ないこともある他のサービスに対する依存関係を有してよい。実行時のサービス・ライブラリの読み込みは、サービス・クラスおよびインターフェイスを介して、読み込まれたライブラリに含まれているサービスの登録を自動的にトリガーすることができる。一部の例示的な例では、サービスのソース・コードは、他の必要なサービスのインスタンス化をトリガーするコンストラクタ・メソッドまたはその他のメソッド（「関数」とも呼ばれる）の呼び出しを含む。サービス・マネージャは、登録されるサービスの依存関係を識別するために、登録プロセス中に登録されるすべてのサービスのｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓメソッドを呼び出すように構成され得る。サービス・マネージャは、サービス・マネージャによって管理されているサービス全体の依存関係を更新するように構成される。

本発明の実施形態は、サービス・マネージャまたはＤＢＭＳが起動するときに、サービス・マネージャがすべてのサービスを認識する必要がないという利点をさらに有することができる。むしろ、後で要求に応じて、サービスを追加することができる。登録が自動的に実行されるように、かつサービスをインスタンス化し、依存関係をさらに導入／登録するための任意の方法を可能にするコールバック・メカニズムが提供されるように、ＤＢＭＳに動的に読み込まれたサービスは、読み込みおよび登録プロセス中にサーバ・マネージャと情報をやりとりする。すべてのサービスがソース・コード内のハードコーディングによって前もって登録される必要がある中央構成ファイルまたはクラスを回避することができ、それによって、システムの柔軟性および保守性を大きく高める。

実施形態によれば、依存関係の管理は、サービスのうちの特定のサービスがサービス・マネージャによってインスタンス化されるときに、この特定のサービスによって必要とされるすべてのサービスがすでにインスタンス化されているように、依存関係に従ってサービスをインスタンス化することを含む。

実施形態によれば、サービスのうちの１つまたは複数は、遅延インスタンス化されるサービスである。

実施形態によれば、複数のサービスの少なくとも一部は、製品製造プロセスのワークフロー内のステップを表す。少なくとも一部の依存関係は、製品製造プロセスに関わるか、または製品製造プロセスによって処理される、機器の依存関係、ワークフローの依存関係、材料の依存関係、または物理的オブジェクトの供給の依存関係、あるいはその組み合わせを表す。

例えば、ＤＢＭＳは、企業資源計画（ＥＲＰ：Enterprise Resource Planning）システムによって生成されて使用されるデータを含んでいる１つまたは複数のデータベースを管理するために使用され得る。多くのＥＲＰシステムの主要な機能は、「資材所要量計画」および「製造資源計画」である。

資材所要量計画（ＭＲＰ：Material requirements planning）は、製造プロセスを管理するために使用される製造計画、スケジューリング、および在庫管理などの計算タスクを含む。ＭＲＰシステムまたはサブシステムは、通常、材料が製造に使用可能であり、製品が顧客への配達に使用可能であることを確認する機能と、蓄えられる可能な最低レベルの材料および製品を維持する機能と、製造活動、配達スケジュール、および購入活動を計画する機能とのうちの１つまたは複数を実装する。

製造資源計画（ＭＲＰ ＩＩ：Manufacturing resource planning）は、製造会社のすべてのリソースの効果的計画に関わる計算タスクを含む。ＭＲＰ ＩＩは、販売台数での業務計画、財務計画に対処することができ、「仮定」の質問に回答するシミュレーション機能および閉ループＭＲＰの拡張を備えることができる。ＭＲＰ ＩＩシステムまたはサブシステムは、通常、基準日程生産計画（ＭＰＳ：master production schedule）の生成および更新、品目マスタ・データ（技術データ）の管理、製造資源データおよびその他の技術的製造データの管理、資材所要量計画（ＭＲＰ）、能力計画または能力所要量計画（ＣＲＰ：capacity requirements planning）などの機能のうちの１つまたは複数を実装する。

現在、ますます多くの製造会社が、長期間にわたって変更も修正もされない（「在庫がある」）商品を製造しなくなっている。顧客の要求における頻繁な変化のため、それらの会社は、顧客の嗜好が向かうどの新しい方向にも追従して、製造プロセスを素早く簡単に調整できる必要がある。特に、最終的に納品される自動車がほぼ唯一の製品になるように、自動車製造業者が注文プロセスの間に多くの特徴の変更を可能にする場合など、顧客が、自分が購入したい製品を「設計する」機会を好む場合、製造プロセスの計画および必要なリソースの管理は、非常に複雑になり、維持するのが困難になる。ＭＲＰもしくはＭＲＰ ＩＩシステムまたはサブシステムのさまざまな機能は、ＤＢＭＳの不可欠な部分であるサービスとして、または例えばプログラム・ライブラリの形態でＤＢＭＳに後で読み込まれるサービスとして、実装され得る。ライブラリが読み込まれ、ライブラリに含まれているサービスが登録されるか、またはインスタンス化されるか、あるいはその両方が実行される時間は、予測不可能であることがある。したがって、ＥＲＰシステムは、数百または数千もの多くのサービスを含んでいることがあり、それらのサービスの管理は、非常に複雑なタスクである。

本発明の実施形態は、膨大な数のサービスを調整することも可能にすることができ、それらのサービスの数および相対的依存関係は、適切な製造プロセスが保証されるような方法で、前もって予測することができない。サービス・マネージャへの個別のサービスおよびそれらの各依存関係の自動化された動的な登録に基づいて、サービスの登録が分散して実行されるため、製造プロセスのための材料およびリソースを計画することにおける依存関係の管理および更新が、非常に容易になるであろう。登録されたサービスの中央リストを手動で維持する必要はない。

さらに別の実施形態によれば、サービス・マネージャによって管理されているサービスの少なくとも一部は、製造工場のワークフローにおいてサービスおよびプロセスをシャットダウンして再起動するためのサービスを含む。サービス・マネージャによって自動的に抽出されたか、またはその他の方法で動的に、自動的に受信された個別のサービス内で指定されたサービスの依存関係は、製造工場のサービスおよびプロセスをシャットダウンして再起動するための物理的要件の依存関係および個別のプロセスの依存関係を反映する。サービス・マネージャは、例えば保守タスクまたはサービス・タスクを実行するために、一時的シャットダウンおよび製造工場のサービスへの復帰を自動的に調整する。多くの工場では、上流システムがオフラインまたはオンラインになることを可能にするために、システムを特定の順序でシャットダウンまたは起動する必要がある。例えば、飲料製造の保守では、水を高圧蒸気に変換するシステムの前に、水を供給するシステムを起動し、それに続いて清浄蒸気を生成するシステムを起動することが極めて重要である。ワークフローの停止を防ぐため、製造プロセスに関わる機械に対する損傷を防ぐため、および製造される商品の品質の悪化を防ぐために、サービス・マネージャによって、効率的な方法で、計画された一時的シャットダウンに関わるすべてのステップが調整される。途中でのどのような停止にも、スケジュールおよび予算を危険にさらすドミノ効果があることがある。そのような製造工場の複雑さおよびサイズを前提として、機器、消耗品、製品、部品、およびプロセスの間のすべての依存関係を調整することは、些細な活動ではない。本発明の実施形態は、物理的オブジェクト（例えば、機器、商品、中間生成物、または機械）を、ＤＢＭＳに読み込まれるサービスとして表すことを可能にすることができる。各新しい機器、各動的に生成された製品または中間生成物、あるいは各必要なその他の物理的オブジェクト（機械、部品、その他の中間生成物、または消耗品）は、各サービスにおけるサービス要件の形態で指定され得る。したがって、ＤＢＭＳに読み込まれたサービスが、サービス・マネージャで自動的に登録されるときに、ワークフローの高度に動的な適応、ならびに個別のサービスおよびワークフローのタスクのインスタンス化の調整が実行され得る。サービスの手動で管理される中央リストに基づいて、最新の高度に動的な製造プロセスによって必要とされる柔軟性を実現することはできなかった。すべてのサービスまたは少なくとも多くのサービスが、シングルトンとして実装されることが好ましい。

実施形態によれば、依存関係の管理は、１つまたは複数のサービスのうちのいずれか１つがシャットダウンされる前に、前述の１つのサービスに依存しているすべてのサービスがシャットダウンされるまで、この１つのサービスのシャットダウンが遅延されるように、依存関係に従ってサービスのうちの１つまたは複数をシャットダウンすることを含む。

これによって、サービスのシャットダウンが、シャットダウンされるサービスに依存していることがある他のサービスに悪影響を与えないことを保証することができる。例えば、複雑な製造プロセスでは、特定のプロセスのシャットダウンが別のプロセスを中断するが、人間オペレータがこの依存関係を認識していないことがあるというリスクが存在する。本発明の実施形態は、他のサービスがこのサービスをもはや必要としなくなるまで、このサービスのシャットダウンが遅延されるため、例えば、人間オペレータの誤ったシャットダウン・コマンドによって引き起こされた、複雑な製造プロセスの望ましくないシャットダウンまたは不具合が防がれることを保証することができる。

実施形態によれば、サービスの各々は、シングルトン設計パターンに従って実装される。例えば、サービスの各々は、シングルトンとして実装され得る。

これによって、製造プロセスに関わる機械、消耗品、製品、および中間生成物が、「物理的な単一のインスタンス・オブジェクト」でもあると見なされるという事実を反映することができる。

実施形態によれば、サービスの依存関係は、１つまたは複数の有向非環状グラフ（ＤＡＧ：directedacyclic graphs）の形態で表される。

これは、グラフ（例えば、ツリー）が素早くトラバースされることができ、循環依存関係が容易に検出されることができるという利点を有することができる。

実施形態によれば、サービスの依存関係は、サービス・マネージャによるＤＢＭＳの実行時に管理され、継続的に更新される単一のデータ構造で表される。依存関係の更新は、特に、サービス・マネージャでサービスが新たに登録されるときに、実行される。

一部の実施形態によれば、複数のサービスのうちの１つまたは複数またはすべては、「ｇｅｔＳｅｒｖｉｃｅＩｎｓｔａｎｃｅ」を含む。このメソッドは、サービス・マネージャによってアクセス可能であり、プライベート・メンバー、キャッシュされたシングルトン・サービス・インスタンスがすでに初期化されているかどうかをサービス・マネージャがチェックできるようにする。初期化されている場合、既存のサービス・インスタンスがサービス・マネージャにすぐに返される。初期化されていない場合、新しいサービス・インスタンスが作成され、メンバー変数に配置され、最初の使用にちょうど間に合うように、呼び出し元（例えば、サービス・マネージャ）に返される。

実施形態によれば、この方法は、追加のサービスをＤＢＭＳに追加することを含む。この追加は、ＤＢＭＳの実行時に追加のサービスをサービス・マネージャに登録することと、依存関係が既存のサービスおよび追加のサービスの依存関係を表すように、サービスの依存関係を自動的に更新することとを含む。

例えば、追加のサービスの登録は、さらにサービスを含むことができるプログラム・ライブラリの一部であることができる。このライブラリは、他のサービスが、このライブラリに含まれているサービスを利用できるように、またはこのライブラリ内のサービスが、サービス・マネージャによってすでにインスタンス化されているか、もしくは少なくともサービス・マネージャに登録されているサービスを利用できるように、あるいはその両方であるように、ＤＢＭＳの実行時にＤＢＭＳに読み込まれる。

実施形態によれば、サービス・マネージャへのサービスの登録は、分散された登録プロセスの形態で実装される。分散された登録プロセスを使用するということは、ＤＢＭＳも、ＤＢＭＳに機能的に結合された任意のその他のシステムも、手動で作成されて維持される登録されたサービスのリストを含まず、使用することもないということを意味する。

実施形態によれば、サービスの依存関係は、サービス内で（例えば、サービスのソース・コード内で）指定され、サービス・マネージャへのサービスの登録時にサービス・マネージャに伝達される。例えば、サービスを実装するクラス・ファイルのソース・コードは、このサービスによって必要とされる１つまたは複数の他のサービスのクラス名のリストを含むことができる。サービス・マネージャは、少なくとも１つのサービスの登録時にリストを構文解析することと、構文解析されたリストに従って依存関係を更新することとを実行するように構成される。

追加または代替として、複数のサービスの各々が、サービスをサービス・マネージャに登録するための機能を備える。例えば、サービスを実装するサービス・クラスまたはサービスによって実装されたインターフェイス・クラスが、この機能を備えることができる。サービスの登録に使用される機能は、例えば、「ｒｅｇｉｓｔｅｒＳｅｒｖｉｃｅ」関数であることができる。

実施形態によれば、複数のサービスの各々は、ｉｎｓｔａｎｔｉａｔｅＳｅｒｖｉｃｅ関数およびｓｈｕｔｄｏｗｎＳｅｒｖｉｃｅ関数を備える。ｉｎｓｔａｎｔｉａｔｅＳｅｒｖｉｃｅ関数およびｓｈｕｔｄｏｗｎＳｅｒｖｉｃｅ関数は、サービス・マネージャによってアクセス可能である（すなわち、呼び出されることができる）。例えば、これらの関数は、パブリック関数であることができる。この方法は、サービス・マネージャによって、依存関係に従って複数のサービスのインスタンス化およびシャットダウンを動的に調整するために、複数のサービスのｉｎｓｔａｎｔｉａｔｅＳｅｒｖｉｃｅ関数およびｓｈｕｔｄｏｗｎＳｅｒｖｉｃｅ関数を使用することをさらに含む。ＤＢＭＳによって管理されている複数のサービスのｉｎｓｔａｎｔｉａｔｅＳｅｒｖｉｃｅ関数およびｓｈｕｔｄｏｗｎＳｅｒｖｉｃｅ関数は同一である（すなわち、同じ関数名および同じ引数のリストを有する）のが好ましいが、具体的な実装はサービスごとに異なってよい。これによって、サービス・マネージャが、少数のコマンドを使用して多数のサービスのインスタンス化およびシャットダウンを自動的に制御できるようになるため、多数のサービスの保守および管理を容易にする。

実施形態によれば、複数のサービスの各々は、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を備える。ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数は、サービス・マネージャによってアクセス可能である。ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数は、１つまたは複数の必要なサービスの名前を返すように構成される。各必要なサービスは、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を備えている前述のサービスがインスタンス化される前にインスタンス化される必要があるサービスである。複数のサービスの各々の登録は、サービス・マネージャによって、登録されるサービスのｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を呼び出すことと、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数によって返された必要なサービスの名前が、すでに登録されたサービスを識別するかどうかを自動的にチェックすることと、サービス・マネージャによって、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数によって返された、まだ登録されていないサービスを含むすべてのサービスの登録を自動的に実行することとを含む。

例えば、サービス・マネージャは、ローカルまたはリモートのサービス・ライブラリ内の、必要であるがまだ登録されていないサービスの名前を検索してよい。

実施形態によれば、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数の実行は、呼び出されたときに、１つまたは複数の必要なサービスのクラス名を各文字列に変換することと、１つまたは複数の文字列をコンパイラによってチェック可能なオブジェクトに変換することと、コンパイラによってチェック可能なオブジェクトを、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を呼び出したサービス・マネージャに返すこととを含む。

事実上、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数は、識別されたクラス名を、コンパイラによる自動化されたオブジェクト・タイプのチェックを可能にすることもできる標準化された（「標準的な」）方法で変換する。

一部の実施形態によれば、サービス・マネージャは、複数のサービスのうちのいずれか１つのインスタンス化の前にも、このサービスのｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を呼び出すように構成される。サービス・マネージャは、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数によって返された必要なサービスの名前が、すでにインスタンス化されているサービスを識別するかどうかをチェックすることと、サービス・マネージャによって、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数によって返された、まだインスタンス化されていない識別された必要なサービスのｉｎｓｔａｎｔｉａｔｅＳｅｒｖｉｃｅ関数を自動的に呼び出すこととを実行するように構成される。しかし、他の実施形態では、登録プロセス中に、サービス・マネージャによって管理されているサービスのすべての依存関係がすでに識別され、別のデータ構造（例えば、有向非環状グラフ、ツリー、またはツリーのセット）に格納されているため、サービス・マネージャは、サービスをインスタンス化することの準備においてｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を呼び出さない。サービス・マネージャは、特定のサービスがインスタンス化される前に、依存関係データ構造を分析することと、対象のサービスがインスタンス化される前に、インスタンス化される対象のサービスによって必要とされるすべてのサービスを自動的にインスタンス化することとを実行するように構成される。これは、必要なサービスが登録されるときに、サービス・マネージャによって第２および第３のレベルの要件が自動的に考慮され、グローバルな依存関係データ構造に統合されるため、各サービスが、必要なサービスの限定されたセットのみを指定する必要があり、これらの第２および第３のレベルでの依存関係について心配する必要がなく、すなわち、「必要なサービス」によって必要とされるサービスを指定する必要もないという利点を有することができる。

実施形態によれば、サービス・マネージャは、少なくともサービスを登録するときに依存関係を更新するように構成される。依存関係を更新することは、依存関係が、登録されるサービスの依存関係および必要な他のサービスの依存関係も含むように、複数の登録されたサービス、登録されるサービス、および１つのサービスの登録中に識別された「必要な」サービスの間の依存関係を更新することを含む。

依存関係は、サービス・マネージャによって管理されている１つまたは複数のデータ構造に格納され得る。データ構造は、例えば、有向非環状グラフまたは有向非環状グラフのセットであることができる。他の実施形態例では、依存関係を表すデータ構造は、リスト、またはリストのセット、あるいは複数のサービスの依存関係をエンコードするのに適した任意のその他の種類のデータ構造であることもできる。

実施形態によれば、複数のサービスのうちの少なくとも１つは、少なくとも１つのサービスによって必要とされる１つまたは複数の他のサービスを指定する。これらのサービスは、「必要なサービス」とも呼ばれる。１つまたは複数の他のサービスの指定は、コンパイル時にコンパイラによってチェックされるクラス名のリストの形態を有することができる。サービス・クラスが必要なサービスの名前を含んでいて、コンパイラが、必要なサービスの名前に一致する名前を持つクラスを識別できない場合に、サービス・クラスのコンパイル時にエラーがスローされる。

最先端のサービス管理システム（例えば、https://www.codeproject.com/Articles/5794/Registry-of-Singletonsを介してオンラインで使用可能な「ｃｏｄｅ ｐｒｏｊｅｃｔ」）は、サービスの自動登録を処理せず、サービス間の依存関係の管理に対処しない。加えて、それらのシステムは、文字列（すなわち、サービスをコンパイルするように構成されたコンパイラによってチェックすることができない、構文において指定されたソース・コード内または別のファイル内の表現）によってサービスを識別する。サービスを一意に登録するための文字列の使用に関連する問題は、サービスを表す各文字列が、グローバルに一意である必要があるということである。さらに、タイプミスが、サービスのソース・コードがコンパイルされてテストされる前に識別できないエラーをもたらすことがある。したがって、サービスのソース・コード内で必要なサービスの名前を指定するために無形式の文字列を使用することは、間違いを起こしやすく、バグが（検出されたとしても）かなり後に検出される状況につながる可能性がある。

反対に、本発明の前述した実施形態は、他のサービスのクラス名を直接使用し、それらのクラス名を、１つまたは複数の必要なサービスを示すことができるコンパイラによってチェック可能なオブジェクトに変換する。これは、特定のサービスのソース・コードが、この特定のサービスによって必要とされる１つまたは複数の他のサービスのクラス名のリストを含むということを意味する。クラス名は、クラス名が、登録されたサービス全体のうちの１つのクラス名と同一であるかどうかをチェックすることをコンパイラに強制する構文で、特定のサービスのソース・コードに含まれる。サービスのソース・コード内で必要なサービスを指定することによって、コンパイラ自身が使用している識別子と全く同じ識別子を使用することは、コンパイル時および任意選択的に設計時にすでに、コンパイラによって無効なサービスへの参照が事前にチェックされるという利点を有することができる。不明なサービス・クラス名が、サービス・クラスの現在コンパイルされているコードまたは変更されたコードに含まれている場合、コンパイラは、コンパイル時にエラーをスローするか、または設計時にアンダーラインまたはその他の形式のテキストの強調表示効果を作成する。

実施形態によれば、サービスをプログラムするための使用される設計時の環境は、コンパイラを使用して、サービスの設計時に、コンパイラに知られている既存のサービス・クラスに一致しないサービス・クラス名を記述しているサービスのソース・コードのセクションを識別するように適応される。この場合、設計時の環境は、設計時にサービス・クラスのソース・コード内のサービス・クラス名を自動的に強調表示するように構成される。

これは、サービスのソース・コード内で指定された必要なサービスの名前と、必要なサービスを表すか、または実装するか、あるいはその両方であるクラスの実際の名前との不一致をもたらすタイプミスおよびその他のエラーが、設計時にすでに自動的に検出されるため、有利であることがある。これによって、可能な最も早い段階でエラーが自動的に識別されるため、サービス開発プロセスを大きく加速することができる。

実施形態によれば、サービス・マネージャは、ＤＢＭＳの拡張アプリケーション（アドオンまたはプラグイン）として実装されるアプリケーションのコンポーネントであるか、またはＤＢＭＳの不可欠なコンポーネントである。

例えば、ＤＢＭＳの不可欠なコンポーネントは、ＤＢＭＳの主要な機能の一部であり、ＤＢＭＳの開発者または供給者によって最初に提供されるときに、ＤＢＭＳの一部として提供される、プログラム・コンポーネントまたは機能であることができる。サービス・マネージャをＤＢＭＳの不可欠な部分として提供することは、動的な自動登録およびＤＢＭＳに読み込まれる新しいサービスの依存関係チェックのサポートをＤＢＭＳがすでに提供しているため、有利であることがある。

サービス・マネージャをＤＢＭＳのプラグインまたはアドオンとして提供することは、他のサービスとの依存関係が自動的に考慮され、既存のサービスの依存関係に統合されるように、新しいサービスを自動的かつ動的にＤＢＭＳに読み込む能力によって、既存のＤＢＭＳを補完することを可能にするために、有利であることがある。

実施形態によれば、この方法は、
（ａ）ＤＢＭＳによって、特定のサービスに対するサービス要求を受信することと、
（ｂ）サービス・マネージャによって、複数のサービスのうちの要求されたサービスを識別することと、
（ｃ）サービス・マネージャによって、要求されたサービスによって必要とされる登録されたサービスのうちの１つまたは複数の他のサービスを識別することとをさらに含み、
－ 識別された１つまたは複数の他のサービスの各々について、
ｉ．この他のサービスがすでにインスタンス化されているかどうかをチェックし、
ｉｉ．この他のサービスがすでにインスタンス化されている場合、ステップｃで識別された次のサービスに進み、
ｉｉｉ．この他のサービスがまだインスタンス化されていない場合、この他のサービスをインスタンス化し、ステップｃで識別された次のサービスに進む。

これは、ＤＢＭＳにサブミットされたユーザの要求に応答して遅延インスタンス化されることがあるサービスが、インスタンス化されていないが必要な他のサービスによってプログラムの不具合を引き起こさずにインスタンス化されることを保証するように、サービス・マネージャが適応されるため、有利であることがある。

一部の実施形態によれば、サービス・マネージャは、依存関係を、依存関係によって定義された論理的並べ替え順序を有するデータ構造に格納するように構成される。サービスの依存関係を表すデータ構造内のサービスの論理的並べ替え順序は、サービス・マネージャによって管理されている複数のサービスのインスタンス化およびシャットダウンを調整するために使用され得る。例えば、周知のアルゴリズムを使用して明示的に、または２つ前の段落で説明された疑似コードにおいて指定されているような深さ優先探索を実行することによって暗黙的に、トポロジー的並べ替え順序が決定され得る。

「遅延インスタンス化」という用語は、本明細書において使用されるとき、オブジェクトが最初に必要とされるまで、オブジェクト（この場合はサービス）の作成を遅延させる方策のことである。遅延インスタンス化は、特に、オブジェクトまたはその他のリソースのインスタンス化のことを指す、遅延評価の一種である。遅延インスタンス化されたサービスを提供することによって、オブジェクトのインスタンス化の影響が、システムの起動段階に集中せずに、時間において分散されるため、ＤＢＭＳの起動速度を改善することができ、したがって、応答時間の中央値が大幅に改善され得る。

「サービス」という用語は、本明細書において使用されるとき、さまざまなクライアントまたはクライアントとして機能するさまざまなプログラム・ルーチンがさまざまな目的に再利用することができる目的を有する、ソフトウェア機能またはソフトウェア機能のセットに関連している。「サービス」は、ＤＢＭＳによって管理されているデータベースに現在格納されているデータ、またはＤＢＭＳによって管理されているデータベースに格納されるべきデータ、あるいはその両方を処理するためのソフトウェア機能であるのが好ましい。例えば、サービスは、デジタル病理画像をクラスター化するように適応されたクラスタリング・アルゴリズムであることができる。別のサービスは、対象の特定の特徴を高度に予測するデータ・セット内のパラメータのサブセットを識別するように構成された主成分分析サービスであることができる。サービスの別の例は、例えば、特定の商品の製造中に使用される消耗品の数、特定の製造ステップにおいて消費されるエネルギーおよび水の量を示すレポートなどの、特定の形態のレポートであることができる。このレポートは、特定のユーザもしくはユーザ・グループに固有であることができ、またはその他の要因に依存してよく、あるいはその両方であってよい。このレポートは、データベースに格納されたデータ（例えば、製造に関連するデータ）を分析することによって動的に生成され得る。実施形態によれば、サービスは、ユーザまたは別のソフトウェア機能がサービスを呼び出すことができるようにするインターフェイスを含んでよい。

「登録されたサービス」とは、本明細書において使用されるとき、名前（またはその他の識別子）および（もしあれば）他のサービスとの依存関係がサービス・マネージャに伝達されたサービスのことである。結果として、サービス・マネージャは、登録されたサービスおよび（もしあれば）それに必要なサービスを、すべての登録されたサービスの依存関係を表すために使用されるデータ構造に統合している。

「サービス・マネージャ」は、本明細書において使用されるとき、複数のサービスを管理するように構成された１つのソフトウェアである。このソフトウェアは、スタンドアロン・アプリケーション、プログラム・モジュール、プログラム・ルーチン、プログラム機能、ソフトウェア・クラス、またはこれらの２つ以上の組み合わせであることができる。

「コンパイラによってチェック可能なオブジェクト」とは、本明細書において使用されるとき、コンパイラが、コンパイル時および任意選択的に設計時にも、１つまたは複数の一貫性チェックを実行できるようにする、タイプ（例えば、特定のオブジェクト・クラス）および任意選択的に追加の特徴が割り当てられたデータ・オブジェクトのことである。一貫性チェックは、例えば、データ・オブジェクトに割り当てられたタイプが、コンパイラに知られているオブジェクト・タイプのリストに含まれているかどうかのチェックを含むことができる。

「データベース」とは、本明細書において使用されるとき、特定の種類のデータベース照会によるデータの取り出しをサポートするか、またはそのようなデータの取り出しに対して最適化された、特定の定義されたデータ構造の形態でメモリ内または不揮発性ストレージ・ボリューム上に構造化された電子情報（「データ」）の集合のことである。このデータは、通常、データベース・テーブル内に論理的に構造化される。データベースは、特に、リレーショナル・データベース（例えば、列指向データベースまたは行指向データベース）であることができる。

「データベース管理システム（ＤＢＭＳ：database management system）」とは、本明細書において使用されるとき、データベースの定義、作成、照会、更新、および管理を可能にするように設計されたソフトウェア・アプリケーションのことである。ＤＢＭＳの例は、ＩＢＭ Ｄｂ２ ｆｏｒ ｚ／ＯＳ、ＭｙＳＱＬ、ＰｏｓｔｇｒｅＳＱＬ、ＩＢＭ Ｄｂ２ Ａｎａｌｙｔｉｃｓ Ａｃｃｅｌｅｒａｔｏｒ（ＩＤＡＡ）などである。

「データベース照会」または「照会」とは、本明細書において使用されるとき、ＤＢＭＳによって管理されているデータベースに格納されたデータの取り出し、更新、格納、または分析、あるいはその組み合わせを実行するためのコマンドのことであり、このコマンドは、ＤＢＭＳのインターフェイスの構文で指定される。例えば、この構文はＳＱＬであることができる。

「テーブル」とは、本明細書において使用されるとき、ＤＢＭＳによって管理されているデータベース・テーブルのことである。

「モジュール」とは、本明細書において使用されるとき、情報技術（ＩＴ：information-technology）フレームワーク内で特定の機能を実行するように構成された１つのハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせのことである。例えば、モジュールは、１つまたは複数の他のモジュールを含んでいる、スタンドアロン・ソフトウェア・アプリケーション、またはソフトウェア・アプリケーションのサブモジュールもしくはサブルーチンであることができる。

「シングルトン・パターン」とは、本明細書において使用されるとき、クラスのインスタンス化を「単一の」インスタンスに制限し、そのインスタンスへのグローバルなアクセスを提供する、ソフトウェア設計パターンのことである。それに応じて、「シングルトン」とは、特定のタイプのソフトウェア・オブジェクト（例えば、前述のソフトウェア・オブジェクトによって表されて実装された特定のタイプのサービス）の１つのインスタンスのみが同時にインスタンス化されることが保証されるように実装された、ソフトウェア・オブジェクトのことである。

図１は、１つまたは複数のプロセッサ１０４およびＤＢＭＳ１０２を備えているコンピュータ・システム１００を示している。例えば、コンピュータ・システムは、標準的なコンピュータ・システム（例えば、デスクトップ・コンピュータ・システムまたはサーバ・コンピュータ・システム）または分散コンピュータ・システム（例えば、クラウド・コンピュータ・システム）であることができる。ＤＢＭＳは、任意の種類のＤＢＭＳであることができる。例えば、ＤＢＭＳ１０２は、リレーショナルＤＢＭＳであることができる。ＤＢＭＳは、カラム・ストアＤＢＭＳ、ロー・ストアＤＢＭＳ、階層的ＤＢＭＳなどであることができる。例えば、ＤＢＭＳは、ＩＢＭ Ｄｂ２、ＭｙＳＱＬ、Ｏｒａｃｌｅ、ＰｏｓｔｇｒｅＳＱＬ、ＩＢＭのＤｂ２ Ａｎａｌｙｔｉｃａｌ Ａｃｃｅｌｅｒａｔｏｒ ｆｏｒ Ｄｂ２（ＩＤＡＡ）などのＤＢＭＳのうちの１つであることができる。コンピュータ・システムは、ＤＢＭＳ１０２に動作可能なように結合されたサービス・マネージャ１０６を備えている。

コンピュータ・システム１００は、ＤＢＭＳに動作可能なように結合されたサービス・マネージャ１０６をさらに備えている。

「ＤＢＭＳに動作可能なように結合されたサービス・マネージャ」という表現は、本明細書において使用されるとき、例えば、サービス・マネージャが、ＤＢＭＳを各実行時環境として使用するサービスを管理するように構成されているため、ＤＢＭＳの機能的に不可欠な部分であるということを意味することができる。

サービス・マネージャは、図３に示され、図１および３の両方の要素を参照することによって以下で説明される方法を実行するように構成される。

サービス・マネージャ１０６は、ＤＢＭＳをインストールしてインスタンス化することによって、例えばＤＢＭＳの不可欠なコンポーネントとして、ステップ３０２で提供され得る。代替として、サービス・マネージャは、ＤＢＭＳがインスタンス化された後に、ステップ３０２で提供され得る。例えば、サービス・マネージャは、ＤＢＭＳのプラグインまたはアドオンに含まれることができ、サービス・マネージャの機能は、前述のプラグインまたはアドオンがコンピュータ・システム１００上でインストールされてインスタンス化された場合に提供される。

サービス・マネージャ１０６は、ＤＢＭＳの実行時に、ステップ３０４で複数のサービス１０８～１１４、２０８～２１４を自動的かつ動的にサービス・マネージャに登録するように構成される。例えば、１つまたは複数のサービスを含んでいる新しいプログラム・ライブラリがＤＢＭＳに読み込まれるときに、ライブラリに含まれているサービスがサービス・マネージャに自動的に登録される。追加または代替として、ＤＢＭＳがインスタンス化されるときに、ＤＢＭＳの不可欠な部分であるサービスがサービス・マネージャ１０６に自動的に登録される。サービスの各々は、ＤＢＭＳ１０２によって管理されている１つまたは複数のデータベース１１６～１２２のうちの１つに格納されているか、または格納されるために受信されたデータを処理するように構成された、１つのプログラム論理（「ソフトウェア」）である。

サービス・マネージャ１０６は、ステップ３０６で複数の登録されたサービスのうちの異なるサービス間の依存関係１０７を自動的に管理するように構成される。例えば、新しいサービスの登録中に、サービス・マネージャが、登録されるサービスによって必要とされる１つまたは複数の他のサービスを識別し、更新された依存関係が、現在登録されているサービスに関するサービスの依存関係も反映するように、依存関係を更新する。同様に、サービスが登録解除された場合も、依存関係が更新される。依存関係１０７は、例えば、サービス・マネージャによって管理され、サービス・マネージャのみによってアクセスできるデータ構造であることができる。例えば、依存関係１０７は、ツリーまたはツリーのセットであることができ、ノードがサービスを表し、親ノードを子ノードに接続するエッジが、親ノードによって表されたサービスと子ノードによって表された必要なサービスの間の依存関係を表す。サービス・マネージャは、特定のノードによって表されたサービスがインスタンス化される前に、この特定のノードのすべての直接的子ノードおよび間接的子ノードによって表されたサービスがインスタンス化されることを保証するように構成され得る。

サービス１０８～１１４は、ＤＢＭＳのユーザまたは機能によって明示的に呼び出される１つまたは複数のデーモンおよび１つまたは複数のサービスを含むことができる。サービスの各々は、シングルトンとして実装されるが、サービスの１つのインスタンスのみが同時にインスタンス化されることを保証する任意のその他のソフトウェア・パターンが同様に使用されてよく、そのためシングルトン設計パターンは、唯一の可能な実装の選択肢ではない。

例えば、サービスは、ＩＢＭのＩＤＡＡ内のさまざまな構成パラメータの設定をトレースし、問い合わせるように構成されたカタログ・マネージャ・サービスを含むことができる。サービスは、前述した機能「トレース」および「構成」を提供するためにカタログ・マネージャ・サービスによって使用されるトレーサ・サービスおよびコンフィギュレータ・サービスをさらに含むことができる。トレーサ・サービスは、コンフィギュレータ・サービスに依存する。つまり、カタログ・マネージャ・サービスを起動して使用するには、トレーサ・サービスがすでにインスタンス化されていることが必須である。しかし、トレーサ・サービスが構成サービスに依存するため、最初に構成サービスがインスタンス化され、次にトレーサ・サービスがインスタンス化され、最後にカタログ・マネージャ・サービスがインスタンス化される必要がある。さまざまなサービス間の複雑であることが多い依存関係のため、適切な順序でサービスをインスタンス化することが重要になる。

最先端の方法によれば、サービスのインスタンス化の適切な順序は、次のように保証される。中心的クラス「イニシャライザ」が提供され、ＤＢＭＳのサービスの各々のソース・コードには、ハードコードされた次の行が現れる。
“registerService<Configurator>();
registerService<Tracer>();
registerService<CatalogManager>();

しかし、前述した最先端の方法に従ってサービスを適切な順序でグローバルにインスタンス化するための中心的クラスの使用は、インスタンス化の適切な順序を保証しない。例えば、ユーザの要求に従う一部のサービスの遅延インスタンス化は、予測不可能な時間的順序で受信されることがある。例えば、ライブラリをＤＢＭＳに読み込むことによって、実行時にサービスがシステムに追加される場合、中心的クラスのソース・コードを更新し、クラスおよび場合によってはＤＢＭＳ全体を再コンパイルする必要がある。バックグラウンド動作（いわゆるデーモン）を実行する一部のサービスは、インスタンス化されるために明示的な外部のトリガーを必要とする。加えて、サービスのインスタンス化イベントの順序を明示的に指定する中心的クラスまたはその他のソース・コードは、サービスの数が特定のしきい値を超える場合、複雑になりすぎて維持することができない。例えば、複数のサービス間の循環依存関係が発生し、識別することが困難なエラーを実行時に引き起こすことがある。そのような中央レジストリを維持することは重荷であり、開発者は、多くの場合、中央レジストリを回避するための対策を講じる。例えば、一部の他のサービスのインスタンス化の一部として１つまたは複数のサービスをインスタンス化することによって、インスタンス化チェーンが構築された。これは、すべてのサービス間の（部分的に）手動でコード化された依存関係グラフにつながり、したがって、コードを維持することがより複雑かつ困難になる。

反対に、本発明の実施形態によれば、サービスが、ＤＢＭＳの実行時に、自分自身をサービス・マネージャに動的に登録する。サービス・マネージャは、例えばスレッドセーフな方法で、ＤＢＭＳ１０２のすべてのサービスのインスタンス化およびシャットダウンを処理して調整し、サービス・マネージャおよびサービスの各々は、分離した単一のスレッドにおいて、それぞれ実行できる。サービス１０８～１１４の各々のインスタンス化およびシャットダウン中に、サービス・マネージャ１０６は、サービス間の依存関係を順守することを保証する。サービス・マネージャへのサービスの自動化された登録および依存関係の自動化された更新は、ＤＢＭＳが多数のサービスを確実にサポートできるようにする。自動化された登録および依存関係の更新のさらなる技術的利点は、いずれかの登録されたサービスにアクセスするすべてのコードが、使用可能なサービスに常に依存することができることである。サービスをチェックして遅延インスタンス化するための性能オーバーヘッドが発生しない。

サービスの各々は、シングルトンとして実装されるのが好ましく、つまり、単一のソフトウェア・オブジェクトが作成され、その後、ＤＢＭＳの他のサービスまたは機能によって使用可能にされるのが好ましい。

図２は、サービス・マネージャ１０６およびＤＢＭＳ２０２を備えているコンピュータ・システム２００の代替の実施形態を示している。システム２００は、１つまたは複数のプロセッサ２０４、ＯＬＴＰ ＤＢＭＳ２０３（例えば、ＩＢＭのＤｂ２）、およびＯＬＡＰ ＤＢＭＳ（例えば、ＩＢＭのＩＤＡＡ２０２）を備えている。２つのＤＢＭＳ２０３、２０２は、同じコンピュータ・システム２００上または異なるコンピュータ・システム上でホストされ得る。ＯＬＴＰ ＤＢＭＳ２０３は、書き込み照会を実行するように最適化された照会オプティマイザを備え、一方、ＯＬＡＰ ＤＢＭＳ２０２は、分析的読み取り照会を実行するように最適化された照会オプティマイザを備える。ＯＬＴＰ ＤＢＭＳ２０３は、例えば、ｚ－ＯＳ用のＤｂ２、Ｏｒａｃｌｅデータベース、ＰｏｓｔｇｒｅＳＱＬまたはＭｙＳＱＬ ＤＢＭＳなどであることができる。ＯＬＡＰ ＤＢＭＳ２０２は、例えば、ＩＤＡＡであることができる。コンピュータ・システム２００は、ＯＬＴＰ ＤＢＭＳのデータベース２２８、２３０に格納されているデータを、ＯＬＡＰ ＤＢＭＳのデータベース２１６～２２２に複製するように構成された複製エンジン２３２を備えることができる。コンピュータ・システムは、ＯＬＴＰ ＤＢＭＳ２０３にアクセスしている任意のデータベース照会を分析し、照会（特に、複雑な分析的照会）の一部をＯＬＡＰ ＤＢＭＳに転送するように構成された、照会ディスパッチャ・モジュールをさらに備えることができる。照会ディスパッチャは、ＯＬＴＰ ＤＢＭＳ上よりも速く、またはより少ない計算リソースを使用して、ＯＬＡＰ ＤＢＭＳ上で照会を実行できるかどうかを予測しようとする。この場合、照会ディスパッチャは、データベース照会を、実行するためにＯＬＡＰ ＤＢＭＳに転送する。照会をサブミットしたクライアントは、通常、照会がＯＬＴＰ ＤＢＭＳまたはＯＬＡＰ ＤＢＭＳのいずれで実行されたかを知らされない。ＯＬＡＰ ＤＢＭＳは、統計的評価、クラスタリングおよび分類タスク、画像分割、さまざまなユーザ、目的、およびデータのサブセットのための複雑なレポートなどの分析的照会を実行するようにそれぞれ構成された複数のサービス２０８～２１４を含むことができる。

ＯＬＡＰ ＤＢＭＳ２０２は、数百または数千ものサービス２０８～２１４を備えることができる。サービスの一部は、最初からＤＢＭＳ２０２の不可欠な部分であることができる。他のサービスは、後で、例えばＤＢＭＳ２０２の所有者が、すでに統合されたサービスの対象ではない何らかの種類のデータ分析タスクを実行することを決定したときに、ＤＢＭＳに読み込まれ得る。サービス・マネージャ１０６は、膨大な数のサービスおよびそれらのサービスの各相互依存関係１０７を完全に自動的に管理して維持するように適応され、それによって、ＤＢＭＳ２０２およびそのサービスが安定して動作することを保証し、依存関係またはサービスのインスタンス化の時間的順序あるいはその両方の手動の指定に関連するエラーを防ぐことができることも保証する。

図３は、図１の図の説明においてすでに説明されたＤＢＭＳ内の複数のサービスを管理するための方法のフローチャートを示している。例えば、ステップ３０２は、サービス・マネージャ１０６をすでに含んでいるＤＢＭＳをインストールすることによって、またはすでにインストールされているＤＢＭＳ２０２を実行時環境として使用して、サービス・マネージャを含んでいるプラグインをインストールすることによって、実行され得る。

１つの実施形態では、ＤＢＭＳ１０２、２０２が起動される。ＤＢＭＳを起動することは、１つまたは複数のサービス・ライブラリをＤＢＭＳに読み込むことと、サービス・マネージャ１０６を起動することとを含む。次のステップでは、サービス・マネージャが、ＤＢＭＳ１０２、２０２の起動時に読み込まれたライブラリに含まれているサービスを登録する。この登録プロセスは、登録される各サービスの依存関係の識別と、サービス・マネージャによって維持されている中央の依存関係データ構造１０７へのすべての識別された依存関係の格納とを含む。それによって、サービス・マネージャは、循環依存関係がこのデータ構造１０７に発生していないことをチェックする。加えて、ＤＢＭＳの起動中に、さらなる初期化ステップが実行され得る。

ＤＢＭＳ１０２、２０２が起動した後に、サービス・マネージャ１０６は、必要に応じて個別のサービスをインスタンス化するように適応される。例えば、サービス・マネージャは、ユーザが、特定のサービスを実行するための照会をサービス・マネージャに直接サブミットできるようするユーザ・インターフェイスを備えることができる。他の実施形態では、サービス・マネージャは、ＤＢＭＳ１０２、２０２へのインターフェイスを備え、特定のサービスに関するユーザの要求を、ＤＢＭＳ１０２、２０２を介して間接的に受信する。この場合、ＤＢＭＳ１０２、２０２は、各ユーザ・インターフェイス１２４、２２４を備えている。通常、ユーザ・インターフェイス１２４、２２４は、ユーザが、例えば特定のクラスタリング・アルゴリズム、特定のレポートなどの、特定のサービスを要求できるようにする非ＳＱＬインターフェイスである。サービス・マネージャによって維持されているすべてのサービスが、ユーザによってアクセス可能でなくてよく、ユーザによって要求されなくてよい。例えば、一部のサービスは、ユーザが実際に興味を持つより高いレベルのサービスによって要求される、バックグラウンドのデーモンであることができる。

ＤＢＭＳがインスタンス化されるときに、サービスの一部も自動的にインスタンス化され得る。自動化されたインスタンス化は、サービス・マネージャによって管理される。例えば、サービス・マネージャまたはサービス・マネージャを呼び出す別のクラスのｍａｉｎ（）メソッドは、ＤＢＭＳのインスタンス化時に自動的にインスタンス化されるべきサービスのリストを含んでよい。サービス・マネージャは、これらの「早期のインスタンス化」のサービスのうちの１つが、任意の追加のサービスを必要とするかどうかを決定するために、依存関係データ構造１０７を評価し、追加のサービスを必要とする場合、「早期のインスタンス化」のサービスがインスタンス化される前に、これらの必要な追加のサービスも自動的にインスタンス化する。追加の必要なサービスのうちの１つがまだサービス・マネージャに登録されていない場合、サービス・マネージャは、事前に定義されたローカルまたはリモートのリポジトリ内で（例えば、サービス・ライブラリのセットを含むローカルまたはリモートのディレクトリ内で）、追加の必要なサービスの名前を検索するように構成される。検索において検出されたサービスは、次に、ＤＢＭＳに自動的に読み込まれ、サービス・マネージャに自動的に登録される。これらの新たに動的に登録されたサービスの依存関係は、前述したようにやはり自動的に分析され、「早期のインスタンス化」のサービスによって必要とされるすべてのサービスが、サービス・マネージャによってＤＢＭＳに自動的に読み込まれ、インスタンス化されるまで、事前に定義されたリポジトリからのさらなるライブラリの自動化された検索および読み込みをトリガーしてよい。

ＤＢＭＳのインスタンス化後に、ＤＢＭＳは、従来技術において知られているように、データベース照会およびデータ分析タスクを処理するために使用されてよい。その後、サービス・マネージャは、ユーザから、またはＤＢＭＳから、あるいは任意のその他のクライアント・ソフトウェアから、特定のサービスに関する要求を受信してよい。要求されたサービスは、「早期にインスタンス化された」サービスのうちの１つでなくてよく、したがって、照会を受信する瞬間には、インスタンス化されていなくてよい。サービス・マネージャは、要求されたサービスが起動して正しく動作できるようになる前にインスタンス化される必要がある１つまたは複数の必要なサービスを識別するために、要求されたサービスと他のサービス１０８～１１４、２０８～２１４の間の依存関係１０７を評価する。要求されたサービスが、まだサービス・マネージャに登録されていないサービスを必要とする場合、サービス・マネージャは、ローカルまたはリモートのライブラリ・リポジトリ内で必要なサービスの検索を開始し、検索において検出された必要なサービスを自動的に読み込み、登録する。新しいサービスが登録された場合、新たに登録されたサービスの依存関係を含むように依存関係１０７が更新される。次に、サービス・マネージャは、前述の必要なサービスのうちのいずれか１つを自動的にインスタンス化し、その後、要求されたサービスをインスタンス化する。インスタンス化されたサービスは、ＤＢＭＳによって管理されているデータベースに格納されたデータを処理するため、およびサービス要求に対する応答としてデータ処理結果を返すために、使用される。

サービス・マネージャは、特定のサービスのシャットダウンを自動的にトリガーすることもできる。例えば、サービスＳ１は、第１の商品Ｇ１を製造するための特定の機械Ｍの使用を含む製造ステップＭＳ１を表してよい。サービスＳ２は、第２の商品Ｇ２を製造するための同じ特定の機械Ｍの使用を含む製造ステップＭＳ２を表してよい。機械Ｍは、第１の商品Ｇ１および第２の商品Ｇ２を製造するために同時に使用することができないため、サービスＳ１およびＳ２は相互に排他的である。サービスＳ２が要求された場合、Ｓ２がインスタンス化される前に、サービスＳ１をシャットダウンする必要がある。サービス・マネージャは、例えば、Ｓ１が完了するまでＳ２のインスタンス化を遅延させ、商品Ｇ１が製造されるとすぐに、Ｓ１を能動的にシャットダウンすることができる。

依存関係データ構造１０７における依存関係の識別または依存関係データ構造１０７の更新あるいはその両方は、サービス・マネージャに登録されたすべてのサービスのすべての依存関係を表す依存関係ツリーに対して深さ優先探索を使用して実行され得る。

図４は、本発明の実施形態に従って複数のサービスの依存関係を示している。図４に示されている実施形態によれば、各サービスは、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドを含んでいるシングルトン・クラス４０４として実装され、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドは、各サービス（シングルトン・オブジェクト）の単一のインスタンス・オブジェクトへの参照を返す。より詳細には、ｇｅｔＩｎｓｔａｎｃｅ（）メソッドは、インターフェイス４０６への参照を返し、一方、サービスの実際の実装４０８は隠蔽される。図４に示されているクラスおよびインターフェイスのセットは、呼び出しコード内でインターフェイスを使用することを強制せず、アーキテクチャは、特定のサービスのインターフェイス４０６を、そのサービスがシングルトンとして扱われるという事実から分離する。図４に示されているシングルトン・クラス４０４、インターフェイス４０６、および実際のサービスの実装４０８の間の分離は、任意選択的である。図４に示されているソフトウェア・アーキテクチャには、きれいな設計という利点があるが、単一のクラス内で、シングルトン４０４、インターフェイス４０６、または実装４０８、あるいはその組み合わせが可能である。例えば、シングルトン４０４およびインターフェイス４０６を組み合わせることができ、またはインターフェイス４０６および実装４０８を組み合わせることができ、またはこれら３つをすべて組み合わせることができる。シングルトン、インターフェイス、および実装の分離は、シングルトンとして処理されるインターフェイス４０６に、異なる実装を使用することを可能にする。これによって、ソフトウェアのテストを容易にする。例えば、実際の実装の代わりにテスト・オブジェクト（「模擬オブジェクト」）が使用される場合、図４に示されたクラス設計は、テスト段階および「実際の」使用事例において、異なる単一のインスタンスをシングルトン４０４に提供することを可能にする。

図５は、システム・アーキテクチャ全体においてサービスおよびサービス・マネージャ（そのクラスおよびインターフェイスが、例えば図４に示されているように実装され得る）がどのように統合されるかを示している。「シングルトン・インスタンス」５０４、４０６は、インターフェイス５０８、４０６および実際のサービスの実装５１４、４０８について知っている。シングルトン・インスタンス５０４、４０６は、それ自身をサービス・マネージャ５０２（「シングルトン・マネージャ」と呼ばれることもある）に登録する責任を負う。

サービス・マネージャ５０２は、他のサービスの要件に従ってサービスのインスタンス化およびシャットダウンを制御するために、各サービスを「知る」必要がある。サービス・マネージャ５０２は、サービスを表す各シングルトン５０６のインスタンス化に対処するため、サービス・マネージャは、サービスのインターフェイス５０８ごとに単一のオブジェクトを作成するために、どの実装クラスがインスタンス化されるべきかを知る必要がある。さらに、各サービスのシングルトン５０６は、例えばＤＢＭＳに読み込まれるときに、またはＤＢＭＳを起動するときに、それ自身をサービス・マネージャ５０２に登録する。

サービス・マネージャ５０２は、インスタンス化を完了し、サービスのその後のアクセスおよび使用を可能にするために、サービスのシングルトン５０６のインスタンス化を実際に実行し、その後、その結果得られた単一のインスタンス化されたサービス・オブジェクトがシングルトン・クラス５０６に格納される。（シングルトン・インスタンスに対応する）サービス（例えば、バックグラウンド・ジョブを使用するか、またはバックグラウンド・ジョブとして実装されるサービス５１２、およびバックグラウンド・ジョブを使用せず、バックグラウンド・ジョブとして実装されないサービス５１０）に対するさまざまな改良が存在してよい。

実施形態によれば、これは、サービス・クラスのソース・コード内またはサービスに関連付けられた別のクラスの機能のソース・コード内で単一のグローバル変数を作成することによって達成される。例えば、単一のグローバル変数は、サービスの（実装の．ｃｐｐファイル内で）実装５１４を定義するコードのすぐ隣に作成され得る。単一のグローバル変数は、登録されるサービスを（サービスの．ｃｐｐファイル内で）定義するコード内にも作成され得る。単一のグローバル変数は、サービス・マネージャに登録されてサービス・マネージャによって管理される特定のサービスを表す。ＤＢＭＳまたはＤＢＭＳのプラグインもしくはアドオンの起動中に（またはライブラリが読み込まれる間に）この変数が作成されるときに、この変数のタイプまたはクラスのコンストラクタが実行される。このコンストラクタは、サービス・マネージャへの、この変数によって表されたサービスの登録に対処する。したがって、サービス・マネージャはサービス・オブジェクトを認識し、サービスに固有の変数がグローバル変数であるため、この変数の存在が常に保証される。そのため、サービス・マネージャは、特定のサービスおよびその実装にアクセスし、特定の実装の種類を使用して、インスタンス化、シャットダウン、およびサービスの現在の状態の照会のようなアクションを実行することができる。

好ましい実施形態によれば、各サービスは、そのサービスが他のどのサービスを必要としているかを知っている。例えば、他のサービスのクラス名が実装クラス５１４のソース・コード内に記述されているため、サービスの実装クラス５１４は、そのサービスがコード内で他のどのサービスにアクセスするかを知っている。これらの他サービスは、このサービスの「必要なサービス」とも呼ばれる。

サービスがサービス・マネージャに自動的に登録されるときに、サービス・マネージャは、登録中に、登録されていないサービスの依存関係を導出するために、登録されるサービスの「ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ（）」関数を呼び出す。Ｃ＋＋コードでは、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数は、例えば次の形態を有することができる。
Class MyImplementation: public MyInterface{
public:
using ServicePrerequisites =services::ServicePrerequisites <Tracer, MyOtherServices>;
virtual auto doSomething()->voidoverride {
…
}
};

「ＳｅｒｖｉｃｅＰｒｅｒｅｑｕｉｓｉｔｅｓ」は、必要なサービスのリストであり、これらのサービスの名前が、コンパイル時および任意選択的に設計時にも、コンパイラによってチェックされ得る。「ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ」関数に加えて、サービス・クラスは、サービス・クラスによって表されたか、または実装されたか、あるいはその両方であるサービスをサービス・マネージャが初期化およびシャットダウンすることを可能にするメソッドを含むことができる。サービス・クラスは、特定のサービスの中央の入り口点として機能するが、実際には、サービスの一部の機能は、他のクラスに実装され得る。

実施形態によれば、ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ（）関数の呼び出しに応答してサービス・マネージャによって自動的に取得されたサービスの依存関係が、すべての登録されたサービスのすべての依存関係を含むデータ構造を自動的に更新することに使用される。

実施形態によれば、さまざまなサービスの実装がサービス・マネージャに登録され、加えて、サービス・マネージャは、ＤＢＭＳの実行時に、現在使用されているサービスの実装の何らかの変更を自動的に通知される。代替として、新しい実装が依存関係を全く有していない場合（例えば、模擬オブジェクトの場合であることができる）、サービスの新しい単一のインスタンスを作成し、ｖｏｉｄ ｓｅｔＩｎｓｔａｎｃｅ（．．．）のようなメソッドを使用して、このインスタンスをシングルトン・クラス５０６に格納することができる。このメソッドは、シングルトン・サービス・インスタンス・インターフェイス５０４によって実行され得る。これは、依存関係がすべて最新であることを保証するために追加のステップが不要であるため、有利であることがある。

一部の実施形態によれば、インスタンス化段階の間に、サービス・マネージャは、（例えば、ユーザの明示的な要求のために、または別の明示的に要求されたサービスが依存しているために）必要とされる特定のサービスがすでにインスタンス化されていることを決定してよい。この場合、サービス・マネージャは、既存のサービス・インスタンスへの参照またはポインタを返し、このサービスのインスタンスをさらに作成しない。さらに、すでにインスタンス化されているサービス・オブジェクトが呼び出しプロセスに渡された場合、サービスがすでにインスタンス化されているということは、依存関係のすべてがすでに満たされているはずであるいうことを意味するため、サービス・マネージャは、要求されたサービスの依存関係をチェックしない。

実施形態によれば、サービス・マネージャへの新しいサービスの登録は、プロセス起動中に新しいサービスのシングルトン・サービス・インスタンスのグローバル変数が作成されるときに、またはサービスごとに読み込まれた各ライブラリがインスタンス化されるときに、自動的に実行される。新しいサービスの登録中に、サービス・マネージャは、新しいサービスの表現を、新しいサービスとすでに登録されたサービスの間の依存関係を表すデータ構造１０７に追加する。例えば、サービスの依存関係は、１つまたは複数の有向非環状グラフ（例えば、ツリーまたはツリーのセット）を含むデータ構造の形態で表され得る。新しいサービスは、このグラフ内の追加のノードとして表され、グラフ内の新しいノードの位置は、新しいサービスと既存のサービスの間の依存関係を表す。

好ましい実施形態によれば、サービス・マネージャは、新しいサービスの依存関係が循環依存関係を導入するかどうかを判定するために、新しいサービスの登録中に依存関係を自動的に分析する。例えば、グラフに循環がないかどうかをチェックするために、種々のツリー横断アルゴリズムが使用されてよい。循環依存関係が識別された場合、新しいサービスの登録が終了され、エラー・イベントまたは警告メッセージあるいはその両方が生成される。分析の結果が、新しいサービスおよびその依存関係が循環依存関係を作成しないということである場合にのみ、新しいサービスが登録され、任意選択的にインスタンス化も行われる。

サービス・マネージャは、異なるサービスを登録する順序を知らないため、登録によって、サービス・マネージャにまだ登録されていない必要なサービスを識別することができる。この場合、必要なサービスも登録されるまで、依存関係のチェックが延期され、必要なサービスの登録は、サービス・マネージャによって自動的にトリガーされる。後で必要なサービスが登録されるときに依存関係が自動的にチェックされるため、任意の循環依存関係についての依存関係のチェックを延期することは問題にならない。

追加または代替として、サービスのインスタンス化段階の間に、サービスの依存関係の分析が実行される。サービスの登録時ではなくサービスのインスタンス化時に依存関係のチェックが実行される場合、ライブラリが任意の順序で読み込まれてよく、ライブラリがライブラリの論理的依存関係に一致しない時間的順序で読み込まれた場合のエラー・イベントまたは警告メッセージの生成をトリガーしないため、ＤＢＭＳへのさまざまなサービス・ライブラリの読み込みを容易にすることができる。依存関係がサービスのインスタンス化時にのみチェックされ、読み込みプロセス中にＤＢＭＳのオペレータが論理的依存関係を考慮する必要がないため、さまざまなサービス・ライブラリを任意の順序でＤＢＭＳに読み込むプロセスが容易にされる。

図６は、シングルトンとして実装されたサービスを指定するサービス・クラスのソース・コードの一部を示しており、このコードは、静的メソッドｉｎｉｔｉａｌｉｚｅ（）、ｓｈｕｔｄｏｗｎ（）、およびｇｅｔＰｒｅｒｅｑｕｉｓｉｔｅｓ（）を含むサービスの定義を含んでおり、それによって、ｇｅｔＰｒｅｒｅｑｕｉｓｉｔｅｓ（）はｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を表している。この実装の否定的側面は、必要なサービスが、文字列として返され、ソース・コード内で、コンパイラによってチェックされない（無形式の）文字列として指定される必要があることである。より良い実装の選択肢が、図７に示されている。

図７は、サービスのより好ましい表現のソース・コードの一部を示している。図７Ａは、サービスの実装クラスによって実装される抽象インターフェイスを示しており、この実装クラスのソース・コードが図７Ｂに部分的に示されている。このサービスはシングルトンとして実装され、このシングルトンの実装は、必要なサービスのコンパイラによってチェック可能なオブジェクトを返すように構成されたｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓメソッドを定義しなければならない。このコンパイラによってチェック可能なオブジェクトは、この例では「ＳｉｎｇｌｅｔｏｎＰｒｅｒｅｑｕｉｓｉｔｅｓ」と呼ばれる。サービス・マネージャは、図７Ａに部分的に示された抽象インターフェイスのメソッドを介してサービスを初期化およびシャットダウンする。これらのメソッドは、サービス・クラスによって継承されるｉｎｉｔｉａｌｉｚｅ（）、ｓｈｕｔｄｏｗｎ（）のような静的メソッドであってよい。文字列の代わりにコンパイラによってチェック可能なオブジェクトを返すメソッドは、プログラマがサービスのソース・コード内で必要なサービス・クラスを指定するときに発生することがある誤字、名前の重複、およびクラス名の不一致に対する堅牢性を高めるという技術的利点をもたらす。

図７Ｃは、抽象インターフェイスが、登録オブジェクト「ＲｅｇｉｓｔｅｒＳｉｎｇｌｅｔｏｎ」を返すように構成された関数「ｒｅｇｉｓｔｅｒＭｙＳｉｎｇｌｅｔｏｎ｛｝」も含むことができるということを示している。登録オブジェクトは、例えば．ｃｐｐファイル内で定義された、グローバル変数でなければならない。これによって、サービスがインスタンス化される前に、サービスを登録できるということを保証する。登録オブジェクトは、それ自身をサービス・マネージャに知らせる。登録オブジェクトは、サービスの実装をインターフェイスに結び付けるが、実装の完全なカプセル化および隠蔽を保証する。

本発明は、システム、方法、またはコンピュータ・プログラム製品、あるいはその組み合わせであってよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を含むコンピュータ可読ストレージ媒体を含んでよい。コンピュータ可読ストレージ媒体は、命令実行デバイスによって使用するための命令を保持および格納できる有形のデバイスであることができる。コンピュータ可読ストレージ媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、またはこれらの任意の適切な組み合わせであってよいが、これらに限定されない。コンピュータ可読ストレージ媒体のさらに具体的な例の非網羅的リストは、ポータブル・フロッピー（Ｒ）・ディスク、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）、読み取り専用メモリ（ＲＯＭ：read-only memory）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ：erasable programmable read-only memoryまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：static random access memory）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：compact disc read-only memory）、デジタルバーサタイルディスク（ＤＶＤ：digital versatile disk）、メモリ・スティック、フロッピー（Ｒ）・ディスク、パンチカードまたは命令が記録されている溝の中の隆起構造などの機械的にエンコードされるデバイス、およびこれらの任意の適切な組み合わせを含む。本明細書において使用されるとき、コンピュータ可読ストレージ媒体は、それ自体が、電波またはその他の自由に伝搬する電磁波、導波管またはその他の送信媒体を伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、あるいはワイヤを介して送信される電気信号などの一過性の信号であると解釈されるべきではない。本明細書に記載されたコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体から各コンピューティング・デバイス／処理デバイスへ、あるいはネットワーク（例えば、インターネット、ローカル・エリア・ネットワーク、広域ネットワーク、または無線ネットワーク、あるいはその組み合わせ）を介して外部コンピュータまたは外部ストレージ・デバイスへダウンロードされ得る。このネットワークは、銅伝送ケーブル、光伝送ファイバ、無線送信、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはその組み合わせを備えてよい。各コンピューティング・デバイス／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェイスは、コンピュータ可読プログラム命令をネットワークから受信し、それらのコンピュータ可読プログラム命令を各コンピューティング・デバイス／処理デバイス内のコンピュータ可読ストレージ媒体に格納するために転送する。本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ：instruction-set-architecture）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、あるいは、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組み合わせで記述されたソース・コードまたはオブジェクト・コードのいずれかであってよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で全体的に実行すること、ユーザのコンピュータ上でスタンドアロン・ソフトウェア・パッケージとして部分的に実行すること、ユーザのコンピュータ上およびリモート・コンピュータ上でそれぞれ部分的に実行すること、あるいはリモート・コンピュータ上またはサーバ上で全体的に実行することができる。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）または広域ネットワーク（ＷＡＮ：wide area network）を含む任意の種類のネットワークを介してユーザのコンピュータに接続されてよく、または接続は、（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに対して行われてよい。一部の実施形態では、本発明の態様を実行するために、例えばプログラマブル論理回路、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ：field-programmable gate arrays）、またはプログラマブル・ロジック・アレイ（ＰＬＡ：programmable logic arrays）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を利用することによって、電子回路をカスタマイズするためのコンピュータ可読プログラム命令を実行してよい。本発明の態様は、本明細書において、本発明の実施形態に従って、方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して説明される。フローチャート図またはブロック図あるいはその両方の各ブロック、ならびにフローチャート図またはブロック図あるいはその両方に含まれるブロックの組み合わせが、コンピュータ可読プログラム命令によって実装されるということが理解されるであろう。これらのコンピュータ可読プログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作を実施する手段を作り出すべく、汎用コンピュータ、専用コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供されて機械を作り出すものであってよい。これらのコンピュータ可読プログラム命令は、命令が格納されたコンピュータ可読ストレージ媒体がフローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作の態様を実施する命令を含む製品を含むように、コンピュータ可読ストレージ媒体に格納され、コンピュータ、プログラム可能なデータ処理装置、または他のデバイス、あるいはその組み合わせに特定の方式で機能するように指示できるものであってもよい。コンピュータ可読プログラム命令は、コンピュータ上、その他のプログラム可能な装置上、またはその他のデバイス上で実行される命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作を実施するように、コンピュータ、その他のプログラム可能なデータ処理装置、またはその他のデバイスに読み込まれてもよく、それによって、一連の動作可能なステップを、コンピュータ上、その他のプログラム可能な装置上、またはコンピュータ実装プロセスを生成するその他のデバイス上で実行させる。図内のフローチャートおよびブロック図は、本発明の種々の実施形態に従って、システム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、および動作を示す。これに関連して、フローチャートまたはブロック図内の各ブロックは、規定された論理機能を実装するための１つまたは複数の実行可能な命令を備える、命令のモジュール、セグメント、または部分を表してよい。一部の代替の実装では、ブロックに示された機能は、図に示された順序とは異なる順序で発生してよい。例えば、連続して示された２つのブロックは、実際には、含まれている機能に応じて、実質的に同時に実行されるか、または場合によっては逆の順序で実行されてよい。ブロック図またはフローチャート図あるいはその両方の各ブロック、ならびにブロック図またはフローチャート図あるいはその両方内のブロックの組み合わせは、規定された機能または動作を実行するか、または専用ハードウェアとコンピュータ命令の組み合わせを実行する専用ハードウェアベースのシステムによって実装されるということにも注意する。

前述した特徴の可能性のある組み合わせは、次の通りであることができる。
特徴の組み合わせＦＣ１：請求項１の特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ２：請求項１および２の特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ３：請求項３の特徴および特徴の組み合わせＦＣ１～ＦＣ２のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ４：請求項４の特徴および特徴の組み合わせＦＣ１～ＦＣ３のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ５：請求項５の特徴および特徴の組み合わせＦＣ１～ＦＣ４のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ６：請求項６の特徴および特徴の組み合わせＦＣ１～ＦＣ５のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ７：請求項７の特徴および特徴の組み合わせＦＣ１～ＦＣ６のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ８：請求項８の特徴および特徴の組み合わせＦＣ１～ＦＣ７のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ９：請求項９の特徴および特徴の組み合わせＦＣ１～ＦＣ８のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ１０：請求項１０の特徴および特徴の組み合わせＦＣ１～ＦＣ９のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ１１：請求項１１の特徴および特徴の組み合わせＦＣ１～ＦＣ１０のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ１２：請求項１２の特徴および特徴の組み合わせＦＣ１１の特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ１３：請求項１３の特徴および特徴の組み合わせＦＣ１～ＦＣ１２のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ１４：請求項１４の特徴および特徴の組み合わせＦＣ１３の特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ１５：請求項１５の特徴および特徴の組み合わせＦＣ１～ＦＣ１４のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ１６：請求項１６の特徴および特徴の組み合わせＦＣ１～ＦＣ１５のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ１７：請求項１７の特徴および特徴の組み合わせＦＣ１～ＦＣ１６のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ１８：請求項１８の特徴および特徴の組み合わせＦＣ１～ＦＣ１７のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。
特徴の組み合わせＦＣ１９：請求項１９の特徴および特徴の組み合わせＦＣ１～ＦＣ１８のうちのいずれか１つの特徴を含んでいる特徴の組み合わせ。

Claims (17)

1. コンピュータの情報処理により、ＤＢＭＳ（１０２、２０２）内の複数のサービス（１０８～１１４、２０８～２１４）を管理する方法であって、前記サービスが、前記サービスの各々がシングルトン設計パターンに従って実装され、前記ＤＢＭＳによって管理されているデータベース（１１６～１２２、２１６～２２２）に格納されているか、または格納されるために受信されたデータを処理するようにそれぞれ構成されており、前記方法が、
   － 前記ＤＢＭＳに動作可能なように結合されたサービス・マネージャ（１０６）を提供することと（３０２）、
   － 前記ＤＢＭＳの実行時に、自動的かつ動的に前記複数のサービスを前記サービス・マネージャに登録することと（３０４）、
   － 前記サービス・マネージャによって、前記複数の登録されたサービスのうちの異なるサービス間の依存関係を自動的に管理すること（３０６）であって、前記サービスのうちの特定のサービスが前記サービス・マネージャによってインスタンス化されるときに、前記特定のサービスによって必要とされるすべてのサービスがすでにインスタンス化されているように、前記依存関係に従って前記サービスをインスタンス化する、前記依存関係を自動的に管理することを含む、方法。
2. 前記サービスの少なくとも一部が、製品製造プロセスのワークフロー内のステップを表し、少なくとも一部の依存関係が、前記製品製造プロセスに関わるか、または前記製品製造プロセスによって処理される、機器の依存関係、ワークフローの依存関係、材料の依存関係、または物理的オブジェクトの供給の依存関係、あるいはその組み合わせを表す、請求項１に記載の方法。
3. 前記依存関係の前記管理が、前記依存関係に従って前記サービスのうちの１つまたは複数をシャットダウンすることを含み、前記１つまたは複数のサービスのうちのいずれか１つがシャットダウンされる前に、前記１つのサービスに依存しているすべてのサービスがシャットダウンされるまで、起動順序と逆の順序でシャットダウンする、請求項１ないし２のいずれか一項に記載の方法。
4. 前記サービスの前記依存関係が、１つまたは複数の有向非環状グラフ（ＤＡＧ）の形態で表される、請求項１ないし３のいずれか一項に記載の方法。
5. 追加のサービスを前記ＤＢＭＳに追加することをさらに含み、前記追加することが、
   － 前記ＤＢＭＳの実行時に、前記追加のサービスを前記サービス・マネージャに登録することと、
   － 前記依存関係が既存のサービスおよび前記追加のサービスの依存関係を表すように、前記サービスの前記依存関係を自動的に更新することを含む、請求項１ないし４のいずれか一項に記載の方法。
6. 前記サービス・マネージャへの前記サービスの前記登録が、分散された登録プロセスの形態で実装される、請求項１ないし５のいずれか一項に記載の方法。
7. 前記複数のサービスの各々が、前記サービスを前記サービス・マネージャに登録するためのメソッドを含んでいるインターフェイスを実装する、請求項１ないし６のいずれか一項に記載の方法。
8. 前記複数のサービスの各々がｉｎｓｔａｎｔｉａｔｅＳｅｒｖｉｃｅ関数およびｓｈｕｔｄｏｗｎＳｅｒｖｉｃｅ関数を備え、前記ｉｎｓｔａｎｔｉａｔｅＳｅｒｖｉｃｅ関数および前記ｓｈｕｔｄｏｗｎＳｅｒｖｉｃｅが前記サービス・マネージャによってアクセス可能であり、前記方法が、
   － 前記サービス・マネージャによって、前記依存関係に従って前記複数のサービスの前記インスタンス化およびシャットダウンを動的に調整するために、前記複数のサービスの前記ｉｎｓｔａｎｔｉａｔｅＳｅｒｖｉｃｅ関数および前記ｓｈｕｔｄｏｗｎＳｅｒｖｉｃｅ関数を使用することをさらに含む、請求項１ないし７のいずれか一項に記載の方法。
9. 前記複数のサービスの各々がｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を備え、前記ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数が前記サービス・マネージャによってアクセス可能であり、前記ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数が、１つまたは複数の必要なサービスの名前を返すように構成されており、各必要なサービスが、前記ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を備えている前記サービスがインスタンス化される前にインスタンス化される必要があるサービスであり、前記複数のサービスの各々の前記登録が、
   － 前記サービス・マネージャによって、登録される前記サービスの前記ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を呼び出すことと、
   － 前記ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数によって返された前記必要なサービスの前記名前が、すでに登録されたサービスを識別するかどうかを自動的にチェックすることと、
   － 前記サービス・マネージャによって、前記ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数によって返された、まだ登録されていないサービスを含むすべてのサービスの登録を自動的に実行することを含む、請求項１ないし８のいずれか一項に記載の方法。
10. 前記ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数が、呼び出されたときに、
    － 前記１つまたは複数の必要なサービスのクラス名を各文字列に変換することと、
    － １つまたは複数の前記文字列をコンパイラによってチェック可能なオブジェクトに変換することと、
    － 前記コンパイラによってチェック可能なオブジェクトを、前記ｇｅｔＲｅｑｕｉｒｅｄＳｅｒｖｉｃｅｓ関数を呼び出した前記サービス・マネージャに返すことを実行するように構成される、請求項９に記載の方法。
11. 前記複数のサービスのうちの少なくとも１つが、前記少なくとも１つのサービスによって必要とされる１つまたは複数の他のサービスを指定し、前記１つまたは複数の他のサービスの前記指定が、コンパイル時にコンパイラによってチェックされるクラス名のリストの形態を有し、サービス・クラスが必要なサービスの名前を含んでいて、前記コンパイラが、前記必要なサービスの前記名前に一致する名前を持つクラスを識別できない場合に、前記サービス・クラスのコンパイル時にエラーがスローされる、請求項１ないし１０のいずれか一項に記載の方法。
12. 前記サービス・クラスが必要なサービスの前記名前を含んでいて、前記コンパイラが、前記必要なサービスの前記名前に一致する名前を持つクラスを識別できない場合に、設計時にサービス・クラスのプログラム・コード内で、前記必要なサービスの前記名前が強調表示される、請求項１１に記載の方法。
13. － 前記サービス・マネージャへの前記サービスのうちの１つの登録中に、前記サービス・マネージャによって、登録される前記１つのサービスによって必要とされる１つまたは複数の他のサービスを自動的に識別することと、
    － 前記依存関係が、登録される前記サービスの依存関係および前記必要な他のサービスの依存関係も含むように、前記複数の登録されたサービス、登録される前記サービス、および前記１つのサービスの前記登録中に識別された前記サービスの間の前記依存関係を更新することとをさらに含む、請求項１ないし１２のいずれか一項に記載の方法。
14. 前記サービス・マネージャが、前記ＤＢＭＳの拡張アプリケーション（アドオンまたはプラグイン）として実装されるアプリケーションのコンポーネントであるか、または前記ＤＢＭＳの不可欠なコンポーネントである、請求項１ないし１３のいずれか一項に記載の方法。
15. （ａ）前記ＤＢＭＳによって、特定のサービスに対するサービス要求を受信することと、
    （ｂ）前記サービス・マネージャによって、前記複数のサービスのうちの前記要求されたサービスを識別することと、
    （ｃ）前記サービス・マネージャによって、前記要求されたサービスによって必要とされる前記登録されたサービスのうちの１つまたは複数の他のサービスを識別することとをさらに含み、
    － 前記識別された１つまたは複数の他のサービスの各々について、
    ｉ．前記他のサービスがすでにインスタンス化されているかどうかをチェックし、
    ｉｉ．前記他のサービスがすでにインスタンス化されている場合、ステップｃで識別された次のサービスに進み、
    ｉｉｉ．前記他のサービスがまだインスタンス化されていない場合、前記他のサービスをインスタンス化し、ステップｃで識別された次のサービスに進む、請求項１ないし１４のいずれか一項に記載の方法。
16. 請求項１ないし１５に記載の何れか１項に記載の方法の各ステップを、コンピュータ・ハードウェアによる手段として構成した、コンピュータ・システム。
17. 請求項１ないし１５に記載の何れか１項に記載の方法の各ステップを、コンピュータに実行させる、コンピュータ・プログラム。

Images