(57)【特許請求の範囲】
【請求項１】
記憶装置と、
第１のシステムエレメントと、
第２のシステムエレメントと、
前記第２のシステムエレメントの属性への前記第１のシステムエレメントの関与であって前記第１のシステムエレメントが前記第２のシステムエレメントの前記属性が変更されたことを知りたいという関与を、前記第２のシステムエレメントの前記属性に対応する少なくとも１つのコールバック関数と共に前記記憶装置に保存し、前記第２のシステムエレメントの前記属性が変更されたことが通知されると、前記第２のシステムエレメントの前記属性に対応づけて前記記憶装置に記憶された前記各コールバック関数を呼び出す属性ブローカーと、
を備えることを特徴とするクライアントサーバシステム。
【請求項２】
記憶装置と、
第１のシステムエレメントと、
第２のシステムエレメントと、
前記第２のシステムエレメントの属性への前記第１のシステムエレメントの関与であって前記第１のシステムエレメントが前記第２のシステムエレメントの前記属性が変更されたことを知りたいという関与を、前記第２のシステムエレメントの前記属性に対応する少なくとも１つのコールバック関数と共に前記記憶装置に保存し、前記第２のシステムエレメントの前記属性が変更されたことが通知されると、前記第２のシステムエレメントの前記属性に対応づけて前記記憶装置に記憶された前記各コールバック関数を呼び出す属性ブローカー手段と、
を備えることを特徴とするクライアントサーバシステム。
【請求項３】
記憶装置と、第１のシステムエレメントと、第２のシステムエレメントと、を備えるクライアントサーバシステムにおいて、
前記第２のシステムエレメントの属性への前記第１のシステムエレメントの関与であって前記第１のシステムエレメントが前記第２のシステムエレメントの前記属性が変更されたことを知りたいという関与を、前記属性に対応する少なくとも１つのコールバック関数と共に記憶装置に保存する工程と、
前記第２のシステムエレメントの前記属性が変更されたことが通知されると、、前記属性に対応づけて前記記憶装置に記憶された前記各コールバック関数を呼び出す工程と、
を含むシステムエレメントの属性変更保存方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明はシステムコンフィギュレーション属性の取り扱い及び保存に関する。特に、この発明はクライアントサーバシステムにおけるサーバオブジェクトの属性としてのコンフィギュレーション情報の保存と変更を通してダイナミックコンフィギュレーションを可能とすることに関する。
【０００２】
【従来の技術】
典型的には、システムコンフィギュレーションはスタティックなプロセスであり、このためコンフィギュレーションを変更し、そのシステムを再起動しなければならない。システムの中には、システムコンフィギュレーション情報を保存するためにしばしば登録値が使用されるものがある。これらの値の１つが変わると、ネットワーク（あるいはシステム）プロセスは停止され、その変更を有効なものとするため再起動されなければならない。
【０００３】
同様に、図１に示すように、ＵＮＩＸ上では、例えば、コンフィギュレーションファイル１２０（典型的には／ｅｔｃ／＊．ｃｏｎｆにおいて見られる）がしばしば使用されて、システム１００におけるネットワーク１１０及び様々なシステムエレメント（あるいはインフラストラクチャーファシリティー）１３０、１４０、１５０のコンフィギュレーション情報が保存される。これらのシステムエレメント１３０、１４０、１５０の１つがそのコンフィギュレーションを変更すると、対応するコンフィギュレーションファイル１２０が編集され、システム１００はその変更を有効なものとするためプロセスを再起動しなければならない。
【０００４】
このシステムコンフィギュレーションのスタティックな性質は、コンフィギュレーション情報がシステム始動時にのみアクセスされることによるものである。コンフィギュレーションファイル１２０及びレジストリエントリーはダイナミックコンフィギュレーション性能には適していない。というのはいつ変更が生じたのかを知ることが困難だからである。典型的には、真のダイナミックコンフィギュレーションが実行されるとすると、情報はその情報が必要とされるたびにポール（再読み取り）される必要がある。しかしながら、この情報が必要とされる頻度のため、典型的にはこの型のポールを行うのは禁止される。
【０００５】
オブジェクトを基本とするクライアントサーバシステムでは、クライアントはサーバオブジェクト上でコンフィギュレーション属性を設定し、コンフィギュレーション情報を保存及び変更することができる。
【０００６】
【発明が解決しようとする課題】
しかしながら、低レベルのインフラストラクチャーファシリティ（例えば、ネーミング、セキュリティ、ファイルアクセスなど）はしばしばコンフィギュレーション情報を要求し、オブジェクトコードは典型的にこのインフラストラクチャーの上に構築される。循環を避け正確なレイヤー化を維持するためには、インフラストラクチャーファシリティはオブジェクトコードを使用することができないあるいはオブジェクトコードに依存することができない。このため、インフラストラクチャーはサーバオブジェクトにアクセスして必要なコンフィギュレーション属性を得ることができない。
【０００７】
本発明は上記実情に鑑みてなされたもので、システムエレメントが必要なコンフィギュレーション属性を得ることができるクライアントサーバシステムおよび属性変更保存方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
請求項１に記載の発明に係るクライアントサーバシステムは、記憶装置と、第１のシステムエレメントと、第２のシステムエレメントと、前記第２のシステムエレメントの属性への前記第１のシステムエレメントの関与であって前記第１のシステムエレメントが前記第２のシステムエレメントの前記属性が変更されたことを知りたいという関与を、前記第２のシステムエレメントの前記属性に対応する少なくとも１つのコールバック関数と共に前記記憶装置に保存し、前記第２のシステムエレメントの前記属性が変更されたことが通知されると、前記第２のシステムエレメントの前記属性に対応づけて前記記憶装置に記憶された前記各コールバック関数を呼び出す属性ブローカーと、を備えることを特徴とする。
【０００９】
請求項２に記載の発明に係るクライアントサーバシステムは、記憶装置と、第１のシステムエレメントと、第２のシステムエレメントと、前記第２のシステムエレメントの属性への前記第１のシステムエレメントの関与であって前記第１のシステムエレメントが前記第２のシステムエレメントの前記属性が変更されたことを知りたいという関与を、前記第２のシステムエレメントの前記属性に対応する少なくとも１つのコールバック関数と共に前記記憶装置に保存し、前記第２のシステムエレメントの前記属性が変更されたことが通知されると、前記第２のシステムエレメントの前記属性に対応づけて前記記憶装置に記憶された前記各コールバック関数を呼び出す属性ブローカー手段と、を備えることを特徴とする。
【００１０】
請求項３に記載の発明に係るシステムエレメントの属性変更保存方法は、記憶装置と、第１のシステムエレメントと、第２のシステムエレメントと、を備えるクライアントサーバシステムにおいて、前記第２のシステムエレメントの属性への前記第１のシステムエレメントの関与であって前記第１のシステムエレメントが前記第２のシステムエレメントの前記属性が変更されたことを知りたいという関与を、前記属性に対応する少なくとも１つのコールバック関数と共に記憶装置に保存する工程と、前記第２のシステムエレメントの前記属性が変更されたことが通知されると、前記属性に対応づけて前記記憶装置に記憶された前記各コールバック関数を呼び出す工程と、を含むことを特徴とする。
【００１１】
【発明の実施の形態】
本発明の実施の形態に係るサーバクライアントシステムは、他のシステムエレメントが印刷管理システムからコンフィギュレーション属性の変更を得ることができるように属性ブローカーを備える。属性ブローカーは２つのメソッド、登録メソッド及び通知メソッド、を提供し、コンフィギュレーションの変更の通信を容易にする。登録メソッドは特別の属性中の１つの関与を示すために他のシステムエレメントから呼び出されてもよい。属性についての関与を登録する際、システムエレメントはコールバック関数を提供してもよい。属性ブローカーは登録済みのすべての属性リストを保持してもよく、各登録属性に対しコールバック関数の組を保持してもよい。
【００１２】
サーバコンフィギュレーション属性が変更される時はいつでも、サーバオブジェクトは通知メソッドを用いて属性情報をその属性中に関与を登録したシステムエレメント全てに属性情報を提供してもよい。属性の通知を受信すると、属性ブローカーはその属性のためにコールバック関数が登録されているかどうかチェックしてもよい。登録されていれば、属性ブローカーは各コールバック関数を呼び出してもよい。その後、コールバック関数のインプリメンテーションはシステムエレメントが必要なときに使用する仮想メモリにコンフィギュレーション属性値を保存してもよい。
【００１３】
以下に示す実施の形態は、印刷システムにおけるシステム属性の変更を取り扱うために属性ブローカーを使用することを説明するものである。しかしながら、印刷システムにおける本発明の使用は例示に過ぎない。属性ブローカーの使用はどのクライアントサーバシステムに適用してもよい。
【００１４】
システムコンフィギュレーション情報は、他のシステムエレメントに対しても有効な特定のシステムエレメントに関する情報を含むため、エレメント間の通信が可能である。このコンフィギュレーション情報は印刷管理システムの抽象的なエンティティ、あるいはオブジェクトを定義するまたは特徴づける属性の型で保存される。通常、従来のシステムでは、コンフィギュレーション情報が変更されると、システムは再起動されなければならない。
【００１５】
図２は属性ブローカー２２０を使用する印刷管理システム２００の例を示したものである。図面では、属性ブローカー２２０は単一の独立型ユニットとして示されているが、属性ブローカー２２０の関数は個々のシステムエレメント制御ユニットを介して分散されていてもよい。
【００１６】
システム２００のエレメントの１つ、例えばシステムエレメント１３０、１４０、１５０の１つなど、がそのコンフィギュレーションを変更すると、コンフィギュレーションの変更はネットワーク１１０を介して属性ブローカー２２０に渡される。例えば１つのシステムエレメント１３０が、いつ他の特別なシステムエレメント１４０がそのコンフィギュレーションを変更するかについて関与している場合、システムエレメント１３０は属性ブローカー２２０を用いてその関与を登録（あるいは保存）する。システムエレメント１３０がその関与をコールバック関数を供給することによりシステムエレメント１４０のコンフィギュレーション変更において登録すると、そのような関数はコンフィギュレーション情報を取り出し、それを仮想メモリに保存する、あるいはそれをディスクに書き込む、あるいは入力パラメータを用いて幾つかの他の関数を呼び出してもよい。属性ブローカー２２０はその後システムエレメント１３０の関与をその関連するコールバック関数と共に仮想メモリ２４０に保存する。この情報はまた、例えば、属性ブローカー２２０の内部記憶ユニットあるいはシステムエレメント１３０の外部記憶ユニットに保存してもよい。
【００１７】
属性ブローカー２２０は、オブジェクトコードあるいはオブジェクトデータベースへの依存性を要求することなく、システムエレメント１３０、１４０、１５０が特定の属性とアクセスできるように設計される。しかしながら、１つの属性を維持するコード次第で、公にその属性を通知されようがされまいが、またいつ通知されようが、属性ブローカー２２０の起動はダイナミックにコンフィギュレーション可能なシステムエレメント１３０、１４０、１５０の要求に基づいている。ダイナミックコンフィギュレーションのためのメカニズムの１つはサーバｃｆｇ−ｘｘｘ属性を介するものである。しかしながら、システムエレメント１３０、１４０、１５０はサーバオブジェクトコードに依存することはできない。このため、属性ブローカー２２０は、サーバインタフェースに依存せずにサーバコンフィギュレーション属性にアクセスする簡易なインダイレクションメカニズムを提供する。
【００１８】
属性ブローカー２２０がシステムエレメント１３０、１４０、１５０とサーバコード間のブローカーとして作用する場合、システムエレメント１３０、１４０、１５０は標準プリントＸチェンジ（ＰｒｉｎｔＸｃｈａｎｇｅ）ダイナミックコンフィギュレーションメカニズム（すなわち、“ｐｄｓｅｔ  −ｃ  ｓ  −ｘｃｆｇ−ｘｘｘ＝ｙｙｙ＜ｓｅｒｖｅｒＮａｍｅ＞”）を用いてダイナミックコンフィギュレーションを有することが可能である。この簡易なインダイレクションはちょうど２つの関数を提供することにより実行される。第１の関数ＣＦＧ＿Ｒｅｇｉｓｔｅｒ（）により、特定の属性あるいは属性の組を観察するのに関与を有するシステムエレメント１３０、１４０、１５０のどれもがコールバック関数を登録することができ、そのコールバック関数は特定の属性が通知されると呼び出される。第２の関数、ＣＦＧ＿Ａｄｖｅｒｔｉｓｅ（）により、どのオブジェクトも特定の属性または属性の組を通知することができる。
【００１９】
属性は変更されると（サーバコンフィギュレーション属性のように）いつ通知されてもよい。しかしながら、属性をいつ通知するかについては通知オブジェクトコード次第である。例えば、属性値の一定の変更があったときのみ通知すべき場合（例えばサーバの状態が休止に変更する）がある。
【００２０】
例えば、システムエレメント１３０が、サーバ＃１５のためのロギング関数に対するファイルパスがいつ変更されたかを知りたい場合、システムエレメント１３０は属性ブローカー２２０を用いてその関与を登録する。システムエレメント１３０はコールバック関数を提供し、その関数によりファイルパスがそのシステムのログファイルのために使用されるようにそのパスを設定され、システムエレメント１３０の関与と共にサーバ＃１５のためのロギングファイルパスに保存されている。
【００２１】
システム２００のエレメントがそのコンフィギュレーションを変更するといつでも、そのエレメントはネットワーク１１０を介して属性ブローカーに通知してもよい。属性ブローカー２２０はこの変更を通知する。属性ブローカーは仮想メモリ２４０において、そのシステムエレメント１３０、１４０、１５０のためのコンフィギュレーションにおける変化について関与があるかどうかをチェックする（すなわち、コールバック関数が登録されているかどうかを確認するためにチェックする）。属性ブローカー２２０が特別のエレメントコンフィギュレーションにおいて登録された関与があると判断すると、属性ブローカーは関与するシステムエレメント１３０、１４０、１５０により登録された登録済みコールバック関数を全て呼び出す。
【００２２】
上記実施例では、システム２００において、オブジェクトのインプリメンテーションは、属性の変更を知っているコードであり、属性ブローカー２２０を呼び出すことによりサーバ＃１５のログファイルパスが変更されたことを通知する選択を有する。それから、属性ブローカー２２０は、仮想メモリ２４０に保存されたデータを調査しサーバ＃１５のログファイルパスに登録した関与を有するシステムエレメント１３０、１４０、１５０を探し出す。サーバ＃１５のログファイルパスに登録した関与を有するシステムエレメント１３０、１４０、１５０のいずれかが見出されると、属性ブローカー２２０はコールバック関数を呼び出す。それから、関係するシステムエレメント１３０、１４０、１５０は属性ブローカー２２０から通知を受信し、サーバ＃１５のためのログファイルパスが変更された事実に気付く。
【００２３】
例えば、システムエレメント１３０、１４０、１５０の１つがそのコンフィギュレーションを変更したが他のどのシステムエレメント１３０、１４０、１５０も関与を登録していなければ、属性ブローカー２２０は仮想メモリ２４０をチェックした後、コールバック関数が登録されていないことを見出し、そのため他のどのシステムエレメント１３０、１４０、１５０もアクションをとらない。
【００２４】
図３は属性ブローカー２２０の例示的なブロック図である。属性ブローカー２２０はメモリー３１０と、ネットワークインタフェース３２０と、制御装置３３０と、データベースインタフェース３４０と、システムエレメントインタフェース３５０とを含む。システムエレメント１３０、１４０、１５０の１つがそのコンフィギュレーションを変更すると、コンフィギュレーションの変更はネットワークインタフェース３２０を介して制御装置３３０に伝達され、データベースインタフェース３４０を介してメモリ３１０または仮想メモリ２４０に保存される。但し、属性ブローカーが分散システムの一部である場合、コンフィギュレーションの変更は保存のためにシステムエレメントインタフェース３５０を介して伝達される。
【００２５】
例えば、１つのシステムエレメント１３０が他の特別なシステムエレメント１４０がいつそのコンフィギュレーションを変更するかに関与がある場合、システムエレメント１３０はネットワークインタフェース３２０経由でネットワークを介して制御装置３３０にコールバック関数を設定することによりその関与を登録する。それから、属性ブローカー２２０はシステムエレメント１３０の関与をその関連するコールバック関数と共に仮想メモリ２４０に、あるいはデータベースインタフェース３４０を介して保存する。
【００２６】
システムエレメント１３０、１４０、１５０の１つがそのコンフィギュレーションを変更する場合、ネットワークインタフェース３２０を介して制御装置３３０に通知してもよい。制御装置３３０はデータベースインタフェース３４０を介して仮想メモリ２４０をチェックしシステムエレメント１３０、１４０、１５０に対するコンフィギュレーションの変化に関与はないか確認する。制御装置３３０が特別のシステムエレメント１３０、１４０、１５０コンフィギュレーションにおいて登録された関与があると判断すると、制御装置３３０は関係するシステムエレメント１３０、１４０、１５０により登録された登録コールバック関数の全てをネットワーク１１０及びネットワークインタフェース３２０を介して呼び出す。
【００２７】
図４は登録メソッドのプロセスの流れ図である。ステップＳ３１０で始まり、制御はステップＳ３２０まで続く。次に、ステップＳ３２０で、システムエレメント１３０、１４０、１５０は１つの属性に関与を表し、属性ブローカー２２０にコールバック関数を設定する。その後、ステップＳ３３０で、属性ブローカー２２０は属性関与をコールバック関数と共に仮想メモリ２４０に保存する。制御はステップＳ３４０に進み終了する。
【００２８】
図５は通知メソッドのプロセスの流れ図である。ステップＳ４１０で始まり、制御はステップＳ４２０まで続き、そこで属性ブローカー２２０がネットワーク１１０からシステムエレメント１３０、１４０、１５０の１つがそのコンフィギュレーションを変更したという通知を受信する。ステップＳ４３０では、属性ブローカー２２０は仮想メモリ２４０内の通知された属性に対するコールバック関数が登録されているかどうか判断する。通知された属性に対しコールバック関数が登録されていれば、制御はステップＳ４４０まで進み、属性ブローカー２２０はコールバック関数を呼び出す。その後、制御はステップＳ４５０まで進み終了する。
【００２９】
しかしながら、属性ブローカー２２０が仮想メモリ２４０には通知された属性に対するコールバック関数は登録されていないと判断すると、制御はステップＳ４５０までジャンプし終了する。
【００３０】
図２及び３に示すように、以上で概略を述べたように、属性ブローカーのインプリメンテーションはプログラム汎用コンピュータ上で行われるのが好ましい。しかしながら、属性ブローカーのインプリメンテーションはまた、専用コンピュータ、プログラムマイクロプロセッサあるいはマイクロ制御装置と周辺集積回路素子、ＡＳＩＣあるいは他の集積回路、ハードウエア組み込みの電子回路あるいは論理回路、例えば離散素子回路、プログラム可能な論理素子、例えばＰＬＤ、ＰＬＡ、ＦＧＰＡまたはＰＡＬ、などの上で実行することもできる。一般に、属性ブローカーのインプリメンテーションを実行するためには、有限状態機械が図４及び５に示した流れ図及び以上で説明した実施例を実行することができるどのような装置も使用することができる。
【図面の簡単な説明】
【図１】  ネットワーク、コンフィギュレーションファイル、システムエレメント間の従来の相互作用を示す図である。
【図２】  ネットワーク、属性ブローカー、システムエレメント間の相互作用を示す図である。
【図３】  属性ブローカーの例示的なブロック図である。
【図４】  登録メソッドのフローチャートである。
【図５】  通知メソッドのフローチャートである。
【符号の説明】
１１０  ネットワーク、１３０、１４０、１５０  システムエレメント、２２０  属性ブローカー、３１０  メモリ、３２０  ネットワークインタフェース、３３０  制御装置、３４０  データベースインタフェース、３５０  システムエレメントインタフェース。
【図１】
0004263305.tif 000002
【図２】
0004263305.tif 000003
【図３】
0004263305.tif 000004
【図４】
0004263305.tif 000005
【図５】
0004263305.tif 000006