JP4159181B2 - サービス属性管理装置 - Google Patents
サービス属性管理装置 Download PDFInfo
- Publication number
- JP4159181B2 JP4159181B2 JP14310199A JP14310199A JP4159181B2 JP 4159181 B2 JP4159181 B2 JP 4159181B2 JP 14310199 A JP14310199 A JP 14310199A JP 14310199 A JP14310199 A JP 14310199A JP 4159181 B2 JP4159181 B2 JP 4159181B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- attribute
- directory
- management apparatus
- setting unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/2871—Implementation details of single intermediate entities
Description
【０００１】
【発明の属する技術分野】
本発明は、分散システム上で提供されるサービス属性の管理技術に関するものである。
【０００２】
【従来の技術】
図２に、当該分散システムの基本構成を示す。ここで、分散システムは、分散オブジェクトとして実現されるサービス１と、分散オブジェクト環境中のサービス一覧を保持するサービス・ディレクトリ２と、クライアント３とから構成されてなる。
【０００３】
分散オブジェクトとして実現されるサービス１は、サービス・インタフェース１Ａを有する。ここで、サービス・インタフェース１Ａは、クライアント３がサービス１を利用する際に使用するインタフェースである。
【０００４】
サービス・ディレクトリ２は、分散オブジェクト環境中で提供されているサービスのサービス・インタフェースの実アドレス２Ａとサービスの情報を表す属性２Ｂとを保持する機能を提供する。ここで、属性２Ｂとしては、サービスを提供する部署名や建物名、フロア、部屋名などが保持される。
【０００５】
また、サービス・ディレクトリ２は、サービスの種類とサービスに関連付けらている属性の情報とを検索キーに用い、サービス・インタフェース１Ａの実アドレスを検索する機能を提供する。サービス・ディレクトリ２も分散オブジェクトとして実現されており、サービス・ディレクトリ２のサービス・インタフェース２Ｃを持つ。サービス・ディレクトリ２のサービス・インタフェース２Ｃは、一般に、サービスの登録、サービスの登録削除、サービスの検索等の機能を定義する。
【０００６】
一般に、サービス１は、サービスをクライアント３が利用できるようにするため、分散オブジェクト環境中に起動されているサービス・ディレクトリ２を検出し、自らのサービス・インタフェース１Ａの実アドレス２Ａをサービス・ディレクトリ２に登録する。この際、サービス１に関連した属性２Ｂも併せて設定する。
【０００７】
サービス・ディレクトリ２の検出には、ネットワークのマルチキャスト機能が用いられる。サービス・ディレクトリ２を検出する側は、サービス・ディレクトリ探索メッセージをマルチキャスト機能を用いて送出する（図２(1) ）。
【０００８】
一方、当該サービス・ディレクトリ探索メッセージを検出したサービス・ディレクトリ２は、サービス・ディレクトリ探索応答メッセージを検出したメッセージの送信元に返す（図２(2) ）。このサービス・ディレクトリ探索応答メッセージには、サービス・ディレクトリ２のサービス・インタフェース２Ｃの実アドレスが含まれている。
【０００９】
この後、サービス・ディレクトリ探索応答メッセージを受信した側は、当該メッセージに含まれていたサービス・ディレクトリ２のサービス・インタフェース２Ｃにアクセスし、サービス１の登録や登録削除、検索等を行う（図２(3) ）。
【００１０】
クライアント３は、特定のサービスを利用する場合、まず、分散オブジェクト環境中に起動されているサービス・ディレクトリ２を検出し（図２(4)(5)）、その後、サービス・ディレクトリ２のサービス・インタフェース２Ｃにアクセスし（図２(6) ）、その目的とするサービス１のサービス・インタフェース１Ａの実アドレスを検索する。その後、クライアント３は、検索の結果取得されたサービス・インタフェース１Ａの実アドレスを使用し、サービスを利用する（図２(7) ）。
【００１１】
このように、サービス・ディレクトリ２の検索により、サービス・インタフェースの実アドレスを取得する分散オブジェクトの環境下では、サービス・ディレクトリ２に登録されるサービス毎の属性が、的確な検索を実現する上で非常に大きな役割を果たしている。
【００１２】
例えば、企業内システムの場合であれば、部署名やオフィスの場所などの情報が、サービス毎に関連付けられる属性として大きな役割を果たす。このとき、サービス１の利用を求めるクライアント３は、サービス・ディレクトリ２に対して検索の対象となるサービスの種類（サービス・インタフェースの種類）、部署名、場所名等を指定することで、希望した部署、場所で提供されるサービスのサービス・インタフェース１Ａの実アドレスを取得する。
【００１３】
【発明が解決しようとする課題】
ところで、上述のサービス・ディレクトリ２にサービスの属性２Ｂを設定するのは、サービス１のサービス・インタフェース１Ａの実アドレスを登録するサービス自身か第３者のいずれかである。ここで、第３者としては、例えば、システム管理者が考えられる。
【００１４】
ところが、サービス自身による属性の登録では、サービスごとに登録される属性が異なる事態が生じるのを避け得ず、サービス間における属性の一貫性を保証できないという問題がある。
【００１５】
一方、第３者がサービス毎に登録すべき属性を設定する方法は、サービス間における属性の一貫性を維持するのに有効であるが、かかる設定作業は手作業によって行われているため、登録すべきサービスが増大するのに伴い当該設定作業に膨大な労力を要するという問題があった。また、新しくサービスを登録する際には、そのサービスに適した属性をその都度設定しなければならず、システム管理者にかかる負担が非常に大きいという問題があった。
【００１６】
本発明は以上の課題を考慮してなされたもので、分散オブジェクトとして実現されるサービスの属性の自動設定を可能とし、しかも設定される属性に一貫性を持たせることが可能なサービス属性管理装置の実現を目的とする。
【００１７】
【課題を解決するための手段】
かかる課題を解決するため、本発明においては、分散オブジェクトとして実現されるサービスの属性を、管理情報としてサービス・ディレクトリに保持するサービス属性管理装置に、以下の機能を設ける。すなわち、予め設定されたサービスの提供に不可欠な属性を設定条件として有し、サービス・ディレクトリに新規に登録されたサービスから新規サービス登録通知を受け取り、その新規サービス登録通知に含まれる属性のうち設定条件に合致する属性をサービス・ディレクトリに登録させる属性として決定する属性設定部を有することを特徴とするサービス属性管理装置。
【００１８】
このように、本発明の場合には、サービスから通知のあった属性の全てがそのまま登録されるのでなく（全ての場合もあるが）、属性設定部が設定条件に合致したものだけをサービス・ディレクトリに登録すべきものとして決定する。すなわち、システム管理者は、複数のサービスに対し設定条件を一つ定めるだけで良。かくして、サービス・ディレクトリには、いずれのサービスに対しても、設定条件で定めた属性が自動的に登録されることになる。
【００１９】
【発明の実施の形態】
（Ａ）第１の実施形態
（Ａ−１）システム構成
以下、本発明に係るサービス属性管理装置の第１の実施形態例を説明する。図１に、当該サービス属性管理装置を備える分散システムの機能ブロック構成を示す。なお、図１に示す構成は、実装上のハードウェア構成又はソフトウェア構成を限定するものではない。
【００２０】
図１においては、本実施形態に係るサービス属性管理装置に相当する装置を、属性設定装置１０として表している。属性設定装置１０は、ネットワーク・インタフェース１ｍ（ｍ＝１、２、３）と、パケット種別判定部２ｍ（ｍ＝１、２、３）と、サービス・ディレクトリ３ｍ（ｍ＝１、２、３）と、属性設定部４ｍ（ｍ＝１、２、３）と、ルーティング機能部５０とからなる。
【００２１】
なお、図１では、ネットワークインタフェース１ｍ、パケット種別判定部２ｍ及びサービス・ディレクトリ３ｍのそれぞれが３つづつ設けられる場合について表しているが、言うまでも無くこれは一例であり、適用するシステムに応じて任意の数の機能部を設けることができる。
【００２２】
図１の説明に戻る。１つのネットワーク・インタフェース１ｍに対しては、それぞれ１つのパケット種別判定部２ｍとサービス・ディレクトリ３ｍとが設けられている。ここで、ネットワーク・インタフェース１ｍは、それぞれネットワークアドレス（図２の２Ｃに相当する実アドレス）を持ち、サブネットワーク６ｍ（ｍ＝１、２、３）との間におけるメッセージの送受信を担当する。なお、ネットワーク・インタフェース１ｍにおいて受信されたメッセージは、パケット種別判定部２ｍに送られる。
【００２３】
パケット種別判定部２ｍは、それぞれ対応するネットワーク・インタフェース１ｍから渡されたメッセージをルーティング機能部５０に転送する機能と共に、当該メッセージが対応するネットワーク・インタフェース１ｍ宛のメッセージであるか又はサービス・ディレクトリ探索メッセージであるかをパケットのヘッダ情報から判定する機能を有する。
【００２４】
仮に、当該メッセージが対応するネットワーク・インタフェース１ｍ宛のメッセージであるか又はサービス・ディレクトリ探索メッセージである場合、パケット種別判定部２ｍは、当該メッセージの情報をサービスディレクトリ３ｍに対して通知する。この場合は、ルーティング機能への転送は行わない。
【００２５】
サービス・ディレクトリ３ｍは、当該サービス・ディレクトリ３ｍのサービス・インタフェース３ｍＣのネットワークアドレス（実アドレス）をサービス側に通知する機能部である。
【００２６】
すなわち、サービス・ディレクトリ３ｍは、パケット種別判定部２ｍからサービス・ディレクトリ探索メッセージを受け取ると、サービス・ディレクトリ探索応答メッセージを作成し、ネットワーク・インタフェース１ｍに送出する。このとき、応答メッセージとして、当該サービス・ディレクトリ３ｍにおけるサービス・インタフェース３ｍＣの実アドレスが通知される。
【００２７】
また、サービス・ディレクトリ３ｍは、当該サービス・インタフェース３ｍＣへの接続を介して受信されたサービス登録要求メッセージによって当該サービスの登録があると、当該登録を新規サービス登録通知として属性設定部４ｍに渡す機能を有する。
【００２８】
属性設定部４ｍは、サービス・ディレクトリｍに登録されたサービスに関連して登録する属性を予め設定された設定条件に従って決定する機能部である。ここで、設定条件には、例えば、サービスが提供される部署名や建物名、フロア、部屋名など、サーバ上での処理に不可欠な属性が通常設定される。
【００２９】
ルーティング機能部５０は、ルーティング・テーブルを基に、ネットワーク・インタフェース１ｍから受け取ったメッセージを、適切なネットワーク・インタフェース１ｎ（ｎ＝ｍを含む。）を介して適切なサブネットワーク６ｍに転送する役割を果たす手段、すなわちルータである。
【００３０】
（Ａ−２）属性管理動作
続いて、本実施形態に係る属性設定装置１０により、分散オブジェクトとして実現されるサービスの属性がどのような手順を経て登録されるかについて説明する。本動作は、起動フェーズと運用フェーズとの２つのフェーズからなる。従って、以下の説明では、各フェーズ別に説明を行う。
【００３１】
（Ａ−２−１）起動フェーズの動作
起動フェーズは、本発明に係る属性設定装置１０の立ち上げ処理と、各種の設定処理とを実行するフェーズである。この起動フェーズでは、ネットワーク・インタフェース１ｍについてのネットワークアドレスの設定と、サービス・ディレクトリ３ｍの起動とが行われる。
【００３２】
ここで、サービス・ディレクトリ３ｍは、前記ネットワーク・インタフェース１ｍについてのネットワークアドレスを用い、当該サービス・ディレクトリ３ｍのサービス・インタフェースの実体を生成する。
【００３３】
また、属性設定部４ｍは、今後登録されるであろう各種のサービスについて登録すべき属性の設定を行う。この属性の設定は、予めシステム管理者が登録していおいた設定条件を読み出すことによって、又は、システム管理者への問い合わせによって行う。またこのとき、ルーティング機能部５０は、ルーティング・テーブルの登録を行う。
【００３４】
（Ａ−２−２）運用フェーズの動作
運用フェーズは、属性設定装置１０がサービス属性を実際に登録するフェーズである。この運用フェーズでは、サービス起動サブフェーズと属性設定サブフェーズの２つのサブフェーズが繰り返し（並列に行われても良い。）実行される。
【００３５】
以下、図３〜図５を用い、運用フェーズにおける属性設定装置１０のサービス属性登録動作を説明する。因みに、図３には、説明を簡単にするため、属性設定装置１０を構成するネットワークインタフェース１ｍ等の機能部が２つ設けられる場合について表している。
【００３６】
また、図３には、分散オブジェクトとして実現されるサービス１１１の起動される端末１００を表している。なお、当該端末１００は、サブネットワーク６１を介して属性設定装置１０に接続されているものとする。また、図４には、サービス起動サブフェーズ時における処理の流れを、図５には、属性設定サプフェーズ時における処理の流れをそれぞれ表している。
【００３７】
（ａ）サービス起動サブフェーズにおける動作
まず、サービス起動サブフェーズにおける動作を説明する。このサブフェーズでは、サブネットワーク６１に接続されている端末１００上でサービス１１１が起動される。サービス１１１は起動されると、自身を登録すべきサービス・ディレクトリ３１を検出するため、ネットワーク上のマルチキャスト機能を用いてサービス・ディレクトリ探索メッセージをサブネットワーク６１に送出する（図４(1) ）。
【００３８】
当該サービス・ディレクトリ探索メッセージは、ネットワーク・インタフェース１１で受信され、対応するパケット種別判定部２１に渡される（図４(2) ）。
【００３９】
パケット種別判定部２１は、当該メッセージをルーティング機能部５０へ転送すると共に（図４(3) ）、▲１▼当該メッセージの宛先がネットワーク・インタフェース１１のネットワークアドレスであるか、▲２▼当該メッセージがサービス・ディレクトリ探索メッセージであるかを判定する（図４のステップＳ１）。上記▲１▼及び▲２▼のいずれかである場合、パケット種別判定部２１は、当該メッセージの内容をサービス・ディレクトリ３１に渡す（図４(4) ）。
【００４０】
この説明の場合、当該メッセージはサービス・ディレクトリ探索メッセージである。従って、サービス・ディレクトリ３１は、サービス・インタフェース１１１Ａの実アドレスを含むサービス・ディレクトリ探索応答メッセージを作成する。
【００４１】
ここで、当該応答メッセージの宛先には、サービス・ディレクトリ探索メッセージの送信元が設定される。この応答メッセージは、ネットワーク・インタフェース１１に渡される（図４(5) ）。ネットワーク・インタフェース１１は、受け取った応答メッセージをサブネットワーク６１を通じてサービス１１１に宛てて送出する（図４(6) ）。
【００４２】
（ｂ）属性設定サブフェーズにおける動作
属性設定サブフェーズでは、サービス１１１がサービス・ディレクトリ探索応答メッセージを受信し、サービス・ディレクトリ３１のサービス・インタフェースの実アドレスを取得する。
【００４３】
このように実アドレスを取得すると、サービス１１１は、登録オペレーションを呼び出し、自身をそのサービス・インタフェース１１１Ａの実アドレスと共にサービス・ディレクトリ３１に登録する動作に移る。この際、サービス１１１に関連した属性も登録の対象となる。
【００４４】
この登録動作は、サービス登録要求メッセージの送信により実現される（図５(1)(2)）。当該メッセージはパケット種別判定部２１に与えられ、その種別が判定される（図５のステップＳ１）。
【００４５】
サービス・ディレクトリ３１は、サービス登録要求メッセージを受信すると（図５(3) ）、当該メッセージに含まれる新規のサービスを登録する（図５のステップＳ２）と共に、そのサービスの情報（例えば、サービス・インタフェース１１１Ａの実アドレス及び属性）を対応する属性設定部４１に通知する。この通知は、新規サービス登録通知として行われる（図５(4) ）。
【００４６】
属性設定部４１は、新規サービス登録通知を受信すると、受け取った情報の中からサービス１１１について登録すべき属性とその値を決定し、当該属性とサービスとの関連付けを行う（図５のステップＳ３及び(5) ）。ここで、サービスの属性として決定される項目は、属性設定部４１に固有の設定条件として予め決められている。このため、サービス毎に登録される属性が異なるようなことはなく、属性の一貫性が実現される。
【００４７】
なお、サービス１１１から受け取った情報の中に設定すべきとされている属性の全部が含まれていなかった場合には、属性設定部４１は、▲１▼エラーを通知する又は▲２▼設定すべきとされている属性のうち受け取った情報の中に含まれているものだけを最終的に登録すべき属性として決定するのいずれかを行う。
【００４８】
（Ａ−３）第１の実施形態の効果
上述のように、第１の実施形態によれば、サービス・ディレクトリ３ｍに登録するサービスの属性を属性設定部４ｍにより決定するようにしたことにより、いずれのサービスについても同一の属性が自動的に登録されるようにできる。すなわち、属性の一貫性を保証できる。
【００４９】
また、サービス・ディレクトリ３ｍ及び属性設定部４ｍのそれぞれを、ネットワーク・インタフェース１ｍ毎に設けたことにより、属性設定部４ｍにおける設定条件を相互に独立したものとでき、ネットワーク・インタフェース１ｍ別に登録される属性を管理することができる。
【００５０】
（Ｂ）第２の実施形態
（Ｂ−１）システム構成
以下、本発明に係るサービス属性管理装置の第２の実施形態例を説明する。図６に、当該サービス属性管理装置を備える分散システムの機能ブロック構成を示す。なお、図６に示す構成は、実装上のハードウェア構成又はソフトウェア構成を限定するものではない。
【００５１】
本実施形態と第１の実施形態との違いは、属性設定部４０の構成である。すなわち、第１の実施形態では、各ネットワーク・インタフェース１ｍ（ｍ＝１、２、３）について専用の属性設定部４ｍ（ｍ＝１、２、３）を設ける構成としたが、本実施形態では、属性設定部４０は複数のネットワーク・インタフェース１ｍ（ｍ＝１、２、３）に対して一つだけ設ける場合の構成について説明する。この点が両者の違いである。
【００５２】
なお、本実施形態に係る属性設定部４０には、その内部に対応関係テーブル４０Ａが設けられている。ここで、対応関係テーブル４０Ａは、サービス・ディレクトリ３ｍ（ｍ＝１、２、３）別の設定条件を記憶したテーブルである。属性設定部４０は、サービス・ディレクトリ３ｍからの新規サービス登録通知に含まれる識別子（サービス・ディレクトリの識別用）を検索キーに用いて対応する設定条件を読出し、最終的に登録する属性の決定を行うよう構成されている。
【００５３】
（Ｂ−２）属性管理動作
続いて、本実施形態に係る属性設定装置１０'により、属性の設定動作がどのように進行するかを説明する。ただし、この動作は、属性設定サブフェーズを除いて第１の実施形態における動作と同じである。従って、以下の説明では、相違点である属性設定サブフェーズについてのみ説明する。
【００５４】
この実施形態の場合もサービス１１１がサービス・ディレクトリ探索要求応答メッセージを受信し、サービス・インタフェース３１のサービス・インタフェースの実アドレスを取得することで当該フェーズ動作が開始される。
【００５５】
このようにサービス・ディレクトリ３１のサービス・インタフェースの実アドレスが取得されると、サービス１１１は、当該サービス・インタフェースの登録オペレーションを呼び出し、自身をそのサービス・インタフェース１１１Ａの実アドレスと共にサービス・ディレクトリ３１に登録する動作に移る。この際、サービス１１１に関連した属性も登録の対象となる。
【００５６】
この登録動作は、サービス登録要求メッセージの送信により実現される。当該メッセージはパケット種別判定部２１に与えられ、その種別が判定される。
【００５７】
サービス・ディレクトリ３１は、サービス登録要求メッセージを受信すると、当該メッセージに含まれる新規のサービスを登録すると共に、そのサービスの情報（例えば、サービス・インタフェース１１１Ａの実アドレス及び属性）と当該サービス・ディレクトリ３１の識別子を属性設定部４０に通知する。この通知は、新規サービス登録通知として行われる。この通知に、当該通知を行うサービス・ディレクトリの識別子が含まれる点が本実施形態に特有な動作である。
【００５８】
属性設定部４０は、新規サービス登録通知を受信すると、受け取った通知に含まれるサービス・ディレクトリの識別子をもとに対応関係テーブル４０Ａを検索し、当該識別子に対応するサービス・ディレクトリについて格納されている設定条件を読み出す。この後、属性設定部４０は、当該条件を基にサービス１１１から通知のあった情報の中から実際に登録する属性を決定する。
【００５９】
なお、設定条件は対応関係テーブル４０Ａに静的に格納されているか、又は対応関係テーブル４０Ａには属性を決定するルーチンへの参照が格納されており、当該ルーチンを起動することにより動的に決定される。
【００６０】
この後、属性設定部４０は、決定した属性とサービス１１１との関連付けを行う。このように、本実施形態の場合にも、サービスの属性として設定される項目は、属性設定部４０の対応関係テーブル４０Ａに予め設定されているため、一貫した属性の登録が可能となる。
【００６１】
（Ｂ−３）第２の実施形態の効果
このように、第２の実施形態の場合にも、属性設定サブフェーズにおける具体的な処理手法が異なるだけで、処理の結果に得られる登録内容は第１の実施形態の場合と同一なため、前述の第１の実施形態についての効果と同一の効果を得ることができる。
【００６２】
（Ｃ）第３の実施形態
（Ｃ−１）システム構成
以下、本発明に係るサービス属性管理装置の第３の実施形態例を説明する。図７に、当該サービス属性管理装置を備える分散システムの機能ブロック構成を示す。なお、図７に示す構成は、実装上のハードウェア構成又はソフトウェア構成を限定するものではない。
【００６３】
本実施形態と第１の実施形態との違いは、属性設定部４ｍ（ｍ＝１、２、３）がサービス・ディレクトリ３ｍ（ｍ＝１、２、３）に決定した属性を登録するのではなく、サービス１１１自身が決定した属性の登録を行う点である。
【００６４】
（Ｃ−２）属性管理動作
続いて、本実施形態に係る属性設定装置１０"により、属性の設定動作がどのように進行するかについて説明する。ただし、その動作は、属性設定サブフェーズを除いて第１の実施形態における動作と同じである。従って、以下の説明では、相違点である属性設定サブフェーズについてのみ説明する。また、図８に、本実施形態における属性設定サブフェーズで実行される処理の流れを示す。
【００６５】
この場合も、サービス１１１がサービス・ディレクトリ探索要求応答メッセージを受信し、サーピス・インタフェース３１のサービス・インタフェースの実アドレスを取得することで当該フェーズ動作が開始される。
【００６６】
このようにサーピス・ディレクトリ３１のサービス・インタフェースの実アドレスが取得されると、サービス１１１は、当該サービス・インタフェース１１１Ａの登録オペレーションを呼び出し、自身をそのサービス・インタフェース１１１Ａの実アドレスと共にサービス・ディレクトリ３１に登録する動作に移る。この際、サービス１１１に関連した属性も登録の対象となる。
【００６７】
この登録動作は、サービス登録要求メッセージの送信により実現される（図８(1)(2)）。当該メッセージはパケット種別判定部２１に与えられ、その種別が判定される（図８のステップＳ１）。
【００６８】
サービス・ディレクトリ３１は、サービス登録要求メッセージを受信すると（図８(3) ）、当該メッセージに含まれる新規のサービスを登録する（図８のステップＳ２）と共に、そのサービスの情報（例えばサービス・インタフェース１１１Ａの実アドレス及び属性）を属性設定部４１に通知する。この通知は、新規サービス登録通知として行われる（図８(4) ）。
【００６９】
属性設定部４１は、新規サービス登録通知を受信すると、受け取った情報の中からサービス１１１について登録すべき属性とその値を決定する（図８のステップＳ３）。なお、ここまでの処理は、第１の実施形態と同じである。
【００７０】
登録する属性が決定されると、属性設定部４１は、サービス・インタフェース１１１Ａの属性設定機能を用いて当該サービス１１１自身に決定した属性を通知する（図８(5)(6)(7) ）。ただし、この動作は、サービス・インタフェース１１１Ａが属性を設定する機能をサポートしていることが前提となる。
【００７１】
サービス１１１は、かかる決定した属性の通知を受信すると、自らが登録されているサービス・ディレクトリ３ｍに当該通知で与えられた属性の登録を実行する（図８(8)(9)(10)）。図８の例では、サービス１１１はサービス・ディレクトリ３１に当該属性の登録を行っている。
【００７２】
なお、当該サービス１１１が、他のサービス・ディレクトリにも登録されている場合には（図８の場合、サービス・ディレクトリ３ｎ（ｎ≠１，２，３））、サービス１１１は、決定された属性をサービス・ディレクトリ３ｎにも登録する（図８(11)）。ただし、当該サービス・ディレクトリ３ｎは、属性設定装置１０"とは無関係にネットワーク上で実行されているものとする。
【００７３】
（Ｃ−３）第３の実施形態の効果
このように、第３の実施形態の場合にも、属性設定サブフェーズにおける具体的な処理手法が異なるだけで、処理の結果に得られる登録内容は第１の実施形態の場合と同一なため、前述の第１の実施形態についての効果と同一の効果を得ることができる。
【００７４】
さらに、第１の実施形態では、属性設定部４ｍがサービス・ディレクトリ３ｍに設定された属性を直接操作したが、本実施形態の場合には、登録することに決定した属性の情報をそのサービス１１１自身に渡し、サービス自身が対応するサービス・ディレクトリ４ｍ及び４ｎに属性を登録するようにしたことにより、特定のサービスが複数のサービス・ディレクトリに登録されている場合でも、それらのサービス・ディレクトリ間でサービスの属性の一貫性を保証することができる。
【００７５】
（Ｄ）他の実施形態
なお、上述の実施形態においては、ルーティング機能部５０（すなわち、ルータ）を有する属性設定装置１０、１０'及び１０"について述べたが、本発明はルータヘの適用に限るものではない。例えば、レイヤ３スイッチや、ゲートウェイその他にも適用可能である。なお、スイッチを適用した場合には、実施形態例中のルーティング機能部５０はスイッチング機能部となる。
【００７６】
上述の実施形態例においては、分散オブジェクトであるサービスがそのサービス・インタフェースの実アドレスを、対応するサービス・ディレクトリ（例えば、サービス・ディレクトリ３１）に登録する場合について述べたが、サービス・インタフェースを実装したプロクシをサービス・ディレクトリに登録する場合にも適用し得る。なお、この明細書の特許請求の範囲においては、この「プロクシ」も含めた意味で「サービス」の用語を用いるものとする。
【００７７】
上述の実施形態においては、ネットワーク・インタフェース１ｍに対しサービスディレクトリ３ｍを一対一の関係で設ける場合について述べたが、複数のネットワーク・インタフェースに対して１つのサービス・ディレクトリを設けるようにしても良い。この場合も、属性設定部によって、サービス・ディレクトリに保存される属性の項目を統一できるため、保存されるサービス属性の一貫性を保証できるという効果を実現できる。
【００７８】
上述の実施形態においては、パケット種別判定部２ｍがルーティング機能部５０にメッセージを渡す構成としているが、ネットワーク・インタフェース１ｍが受信したメッセージを直接ルーティング機能部５０に渡す構成としても良い。
【００７９】
上述の実施形態においては、パケット種別判定部２ｍ、サービス・ディレクトリ３ｍ、属性設定部４ｍ、ルーティング機能５０などの機能部をそれぞれ分けて示したが、これは論理的な構成を機能ブロックとして示したものであり、実装上のハードウェア・ソフトウェア構成を示したものではない。
【００８０】
【発明の効果】
上述のように、本発明によれば、分散オブジェクトとして実現されるサービスの属性を、管理情報としてサービス・ディレクトリに保持するサービス属性管理装置に、予め設定されたサービスの提供に不可欠な属性を設定条件として有し、サービス・ディレクトリに新規に登録されたサービスから新規サービス登録通知を受け取り、その新規サービス登録通知に含まれる属性のうち設定条件に合致する属性をサービス・ディレクトリに登録させる属性として決定する属性設定部を有することにより、サービスの違いによらず同一の属性を自動的に登録可能とできる。
【図面の簡単な説明】
【図１】サービス属性管理装置の第１の実施形態例を示す図である。
【図２】分散システムの基本構成を示す図である。
【図３】動作説明に使用するサービス属性管理装置の実施形態例を示す図である。
【図４】サービス起動サブフェーズ時の処理の流れを示す図である。
【図５】属性設定サプフェーズ時の処理の流れを示す図である。
【図６】サービス属性管理装置の第２の実施形態例を示す図である。
【図７】サービス属性管理装置の第３の実施形態例を示す図である。
【図８】第３の実施形態例に係るサービス属性管理装置において実行される属性設定サプフェーズでの処理の流れを示す図である。
【符号の説明】
１…サービス、１Ａ…サービス・インタフェース、２…サービス・ディレクトリ、２Ａ…実アドレス、２Ｂ…属性、２Ｃ…サービス・インタフェース、３…クライアント、１０、１０'…属性設定装置、１１、１２、１３…ネットワーク・インタフェース、２１、２２、２３…パケット種別判定部、３１、３２、３３…サービス・ディレクトリ、４０、４１、４２、４３…属性設定部、４０Ａ…対応関係テーブル、５０…ルーティング機能部、６１、６２、６３…サブネットワーク、１００…端末、１１１…サービス、１１１Ａ…サービス・インタフェース。
【発明の属する技術分野】
本発明は、分散システム上で提供されるサービス属性の管理技術に関するものである。
【０００２】
【従来の技術】
図２に、当該分散システムの基本構成を示す。ここで、分散システムは、分散オブジェクトとして実現されるサービス１と、分散オブジェクト環境中のサービス一覧を保持するサービス・ディレクトリ２と、クライアント３とから構成されてなる。
【０００３】
分散オブジェクトとして実現されるサービス１は、サービス・インタフェース１Ａを有する。ここで、サービス・インタフェース１Ａは、クライアント３がサービス１を利用する際に使用するインタフェースである。
【０００４】
サービス・ディレクトリ２は、分散オブジェクト環境中で提供されているサービスのサービス・インタフェースの実アドレス２Ａとサービスの情報を表す属性２Ｂとを保持する機能を提供する。ここで、属性２Ｂとしては、サービスを提供する部署名や建物名、フロア、部屋名などが保持される。
【０００５】
また、サービス・ディレクトリ２は、サービスの種類とサービスに関連付けらている属性の情報とを検索キーに用い、サービス・インタフェース１Ａの実アドレスを検索する機能を提供する。サービス・ディレクトリ２も分散オブジェクトとして実現されており、サービス・ディレクトリ２のサービス・インタフェース２Ｃを持つ。サービス・ディレクトリ２のサービス・インタフェース２Ｃは、一般に、サービスの登録、サービスの登録削除、サービスの検索等の機能を定義する。
【０００６】
一般に、サービス１は、サービスをクライアント３が利用できるようにするため、分散オブジェクト環境中に起動されているサービス・ディレクトリ２を検出し、自らのサービス・インタフェース１Ａの実アドレス２Ａをサービス・ディレクトリ２に登録する。この際、サービス１に関連した属性２Ｂも併せて設定する。
【０００７】
サービス・ディレクトリ２の検出には、ネットワークのマルチキャスト機能が用いられる。サービス・ディレクトリ２を検出する側は、サービス・ディレクトリ探索メッセージをマルチキャスト機能を用いて送出する（図２(1) ）。
【０００８】
一方、当該サービス・ディレクトリ探索メッセージを検出したサービス・ディレクトリ２は、サービス・ディレクトリ探索応答メッセージを検出したメッセージの送信元に返す（図２(2) ）。このサービス・ディレクトリ探索応答メッセージには、サービス・ディレクトリ２のサービス・インタフェース２Ｃの実アドレスが含まれている。
【０００９】
この後、サービス・ディレクトリ探索応答メッセージを受信した側は、当該メッセージに含まれていたサービス・ディレクトリ２のサービス・インタフェース２Ｃにアクセスし、サービス１の登録や登録削除、検索等を行う（図２(3) ）。
【００１０】
クライアント３は、特定のサービスを利用する場合、まず、分散オブジェクト環境中に起動されているサービス・ディレクトリ２を検出し（図２(4)(5)）、その後、サービス・ディレクトリ２のサービス・インタフェース２Ｃにアクセスし（図２(6) ）、その目的とするサービス１のサービス・インタフェース１Ａの実アドレスを検索する。その後、クライアント３は、検索の結果取得されたサービス・インタフェース１Ａの実アドレスを使用し、サービスを利用する（図２(7) ）。
【００１１】
このように、サービス・ディレクトリ２の検索により、サービス・インタフェースの実アドレスを取得する分散オブジェクトの環境下では、サービス・ディレクトリ２に登録されるサービス毎の属性が、的確な検索を実現する上で非常に大きな役割を果たしている。
【００１２】
例えば、企業内システムの場合であれば、部署名やオフィスの場所などの情報が、サービス毎に関連付けられる属性として大きな役割を果たす。このとき、サービス１の利用を求めるクライアント３は、サービス・ディレクトリ２に対して検索の対象となるサービスの種類（サービス・インタフェースの種類）、部署名、場所名等を指定することで、希望した部署、場所で提供されるサービスのサービス・インタフェース１Ａの実アドレスを取得する。
【００１３】
【発明が解決しようとする課題】
ところで、上述のサービス・ディレクトリ２にサービスの属性２Ｂを設定するのは、サービス１のサービス・インタフェース１Ａの実アドレスを登録するサービス自身か第３者のいずれかである。ここで、第３者としては、例えば、システム管理者が考えられる。
【００１４】
ところが、サービス自身による属性の登録では、サービスごとに登録される属性が異なる事態が生じるのを避け得ず、サービス間における属性の一貫性を保証できないという問題がある。
【００１５】
一方、第３者がサービス毎に登録すべき属性を設定する方法は、サービス間における属性の一貫性を維持するのに有効であるが、かかる設定作業は手作業によって行われているため、登録すべきサービスが増大するのに伴い当該設定作業に膨大な労力を要するという問題があった。また、新しくサービスを登録する際には、そのサービスに適した属性をその都度設定しなければならず、システム管理者にかかる負担が非常に大きいという問題があった。
【００１６】
本発明は以上の課題を考慮してなされたもので、分散オブジェクトとして実現されるサービスの属性の自動設定を可能とし、しかも設定される属性に一貫性を持たせることが可能なサービス属性管理装置の実現を目的とする。
【００１７】
【課題を解決するための手段】
かかる課題を解決するため、本発明においては、分散オブジェクトとして実現されるサービスの属性を、管理情報としてサービス・ディレクトリに保持するサービス属性管理装置に、以下の機能を設ける。すなわち、予め設定されたサービスの提供に不可欠な属性を設定条件として有し、サービス・ディレクトリに新規に登録されたサービスから新規サービス登録通知を受け取り、その新規サービス登録通知に含まれる属性のうち設定条件に合致する属性をサービス・ディレクトリに登録させる属性として決定する属性設定部を有することを特徴とするサービス属性管理装置。
【００１８】
このように、本発明の場合には、サービスから通知のあった属性の全てがそのまま登録されるのでなく（全ての場合もあるが）、属性設定部が設定条件に合致したものだけをサービス・ディレクトリに登録すべきものとして決定する。すなわち、システム管理者は、複数のサービスに対し設定条件を一つ定めるだけで良。かくして、サービス・ディレクトリには、いずれのサービスに対しても、設定条件で定めた属性が自動的に登録されることになる。
【００１９】
【発明の実施の形態】
（Ａ）第１の実施形態
（Ａ−１）システム構成
以下、本発明に係るサービス属性管理装置の第１の実施形態例を説明する。図１に、当該サービス属性管理装置を備える分散システムの機能ブロック構成を示す。なお、図１に示す構成は、実装上のハードウェア構成又はソフトウェア構成を限定するものではない。
【００２０】
図１においては、本実施形態に係るサービス属性管理装置に相当する装置を、属性設定装置１０として表している。属性設定装置１０は、ネットワーク・インタフェース１ｍ（ｍ＝１、２、３）と、パケット種別判定部２ｍ（ｍ＝１、２、３）と、サービス・ディレクトリ３ｍ（ｍ＝１、２、３）と、属性設定部４ｍ（ｍ＝１、２、３）と、ルーティング機能部５０とからなる。
【００２１】
なお、図１では、ネットワークインタフェース１ｍ、パケット種別判定部２ｍ及びサービス・ディレクトリ３ｍのそれぞれが３つづつ設けられる場合について表しているが、言うまでも無くこれは一例であり、適用するシステムに応じて任意の数の機能部を設けることができる。
【００２２】
図１の説明に戻る。１つのネットワーク・インタフェース１ｍに対しては、それぞれ１つのパケット種別判定部２ｍとサービス・ディレクトリ３ｍとが設けられている。ここで、ネットワーク・インタフェース１ｍは、それぞれネットワークアドレス（図２の２Ｃに相当する実アドレス）を持ち、サブネットワーク６ｍ（ｍ＝１、２、３）との間におけるメッセージの送受信を担当する。なお、ネットワーク・インタフェース１ｍにおいて受信されたメッセージは、パケット種別判定部２ｍに送られる。
【００２３】
パケット種別判定部２ｍは、それぞれ対応するネットワーク・インタフェース１ｍから渡されたメッセージをルーティング機能部５０に転送する機能と共に、当該メッセージが対応するネットワーク・インタフェース１ｍ宛のメッセージであるか又はサービス・ディレクトリ探索メッセージであるかをパケットのヘッダ情報から判定する機能を有する。
【００２４】
仮に、当該メッセージが対応するネットワーク・インタフェース１ｍ宛のメッセージであるか又はサービス・ディレクトリ探索メッセージである場合、パケット種別判定部２ｍは、当該メッセージの情報をサービスディレクトリ３ｍに対して通知する。この場合は、ルーティング機能への転送は行わない。
【００２５】
サービス・ディレクトリ３ｍは、当該サービス・ディレクトリ３ｍのサービス・インタフェース３ｍＣのネットワークアドレス（実アドレス）をサービス側に通知する機能部である。
【００２６】
すなわち、サービス・ディレクトリ３ｍは、パケット種別判定部２ｍからサービス・ディレクトリ探索メッセージを受け取ると、サービス・ディレクトリ探索応答メッセージを作成し、ネットワーク・インタフェース１ｍに送出する。このとき、応答メッセージとして、当該サービス・ディレクトリ３ｍにおけるサービス・インタフェース３ｍＣの実アドレスが通知される。
【００２７】
また、サービス・ディレクトリ３ｍは、当該サービス・インタフェース３ｍＣへの接続を介して受信されたサービス登録要求メッセージによって当該サービスの登録があると、当該登録を新規サービス登録通知として属性設定部４ｍに渡す機能を有する。
【００２８】
属性設定部４ｍは、サービス・ディレクトリｍに登録されたサービスに関連して登録する属性を予め設定された設定条件に従って決定する機能部である。ここで、設定条件には、例えば、サービスが提供される部署名や建物名、フロア、部屋名など、サーバ上での処理に不可欠な属性が通常設定される。
【００２９】
ルーティング機能部５０は、ルーティング・テーブルを基に、ネットワーク・インタフェース１ｍから受け取ったメッセージを、適切なネットワーク・インタフェース１ｎ（ｎ＝ｍを含む。）を介して適切なサブネットワーク６ｍに転送する役割を果たす手段、すなわちルータである。
【００３０】
（Ａ−２）属性管理動作
続いて、本実施形態に係る属性設定装置１０により、分散オブジェクトとして実現されるサービスの属性がどのような手順を経て登録されるかについて説明する。本動作は、起動フェーズと運用フェーズとの２つのフェーズからなる。従って、以下の説明では、各フェーズ別に説明を行う。
【００３１】
（Ａ−２−１）起動フェーズの動作
起動フェーズは、本発明に係る属性設定装置１０の立ち上げ処理と、各種の設定処理とを実行するフェーズである。この起動フェーズでは、ネットワーク・インタフェース１ｍについてのネットワークアドレスの設定と、サービス・ディレクトリ３ｍの起動とが行われる。
【００３２】
ここで、サービス・ディレクトリ３ｍは、前記ネットワーク・インタフェース１ｍについてのネットワークアドレスを用い、当該サービス・ディレクトリ３ｍのサービス・インタフェースの実体を生成する。
【００３３】
また、属性設定部４ｍは、今後登録されるであろう各種のサービスについて登録すべき属性の設定を行う。この属性の設定は、予めシステム管理者が登録していおいた設定条件を読み出すことによって、又は、システム管理者への問い合わせによって行う。またこのとき、ルーティング機能部５０は、ルーティング・テーブルの登録を行う。
【００３４】
（Ａ−２−２）運用フェーズの動作
運用フェーズは、属性設定装置１０がサービス属性を実際に登録するフェーズである。この運用フェーズでは、サービス起動サブフェーズと属性設定サブフェーズの２つのサブフェーズが繰り返し（並列に行われても良い。）実行される。
【００３５】
以下、図３〜図５を用い、運用フェーズにおける属性設定装置１０のサービス属性登録動作を説明する。因みに、図３には、説明を簡単にするため、属性設定装置１０を構成するネットワークインタフェース１ｍ等の機能部が２つ設けられる場合について表している。
【００３６】
また、図３には、分散オブジェクトとして実現されるサービス１１１の起動される端末１００を表している。なお、当該端末１００は、サブネットワーク６１を介して属性設定装置１０に接続されているものとする。また、図４には、サービス起動サブフェーズ時における処理の流れを、図５には、属性設定サプフェーズ時における処理の流れをそれぞれ表している。
【００３７】
（ａ）サービス起動サブフェーズにおける動作
まず、サービス起動サブフェーズにおける動作を説明する。このサブフェーズでは、サブネットワーク６１に接続されている端末１００上でサービス１１１が起動される。サービス１１１は起動されると、自身を登録すべきサービス・ディレクトリ３１を検出するため、ネットワーク上のマルチキャスト機能を用いてサービス・ディレクトリ探索メッセージをサブネットワーク６１に送出する（図４(1) ）。
【００３８】
当該サービス・ディレクトリ探索メッセージは、ネットワーク・インタフェース１１で受信され、対応するパケット種別判定部２１に渡される（図４(2) ）。
【００３９】
パケット種別判定部２１は、当該メッセージをルーティング機能部５０へ転送すると共に（図４(3) ）、▲１▼当該メッセージの宛先がネットワーク・インタフェース１１のネットワークアドレスであるか、▲２▼当該メッセージがサービス・ディレクトリ探索メッセージであるかを判定する（図４のステップＳ１）。上記▲１▼及び▲２▼のいずれかである場合、パケット種別判定部２１は、当該メッセージの内容をサービス・ディレクトリ３１に渡す（図４(4) ）。
【００４０】
この説明の場合、当該メッセージはサービス・ディレクトリ探索メッセージである。従って、サービス・ディレクトリ３１は、サービス・インタフェース１１１Ａの実アドレスを含むサービス・ディレクトリ探索応答メッセージを作成する。
【００４１】
ここで、当該応答メッセージの宛先には、サービス・ディレクトリ探索メッセージの送信元が設定される。この応答メッセージは、ネットワーク・インタフェース１１に渡される（図４(5) ）。ネットワーク・インタフェース１１は、受け取った応答メッセージをサブネットワーク６１を通じてサービス１１１に宛てて送出する（図４(6) ）。
【００４２】
（ｂ）属性設定サブフェーズにおける動作
属性設定サブフェーズでは、サービス１１１がサービス・ディレクトリ探索応答メッセージを受信し、サービス・ディレクトリ３１のサービス・インタフェースの実アドレスを取得する。
【００４３】
このように実アドレスを取得すると、サービス１１１は、登録オペレーションを呼び出し、自身をそのサービス・インタフェース１１１Ａの実アドレスと共にサービス・ディレクトリ３１に登録する動作に移る。この際、サービス１１１に関連した属性も登録の対象となる。
【００４４】
この登録動作は、サービス登録要求メッセージの送信により実現される（図５(1)(2)）。当該メッセージはパケット種別判定部２１に与えられ、その種別が判定される（図５のステップＳ１）。
【００４５】
サービス・ディレクトリ３１は、サービス登録要求メッセージを受信すると（図５(3) ）、当該メッセージに含まれる新規のサービスを登録する（図５のステップＳ２）と共に、そのサービスの情報（例えば、サービス・インタフェース１１１Ａの実アドレス及び属性）を対応する属性設定部４１に通知する。この通知は、新規サービス登録通知として行われる（図５(4) ）。
【００４６】
属性設定部４１は、新規サービス登録通知を受信すると、受け取った情報の中からサービス１１１について登録すべき属性とその値を決定し、当該属性とサービスとの関連付けを行う（図５のステップＳ３及び(5) ）。ここで、サービスの属性として決定される項目は、属性設定部４１に固有の設定条件として予め決められている。このため、サービス毎に登録される属性が異なるようなことはなく、属性の一貫性が実現される。
【００４７】
なお、サービス１１１から受け取った情報の中に設定すべきとされている属性の全部が含まれていなかった場合には、属性設定部４１は、▲１▼エラーを通知する又は▲２▼設定すべきとされている属性のうち受け取った情報の中に含まれているものだけを最終的に登録すべき属性として決定するのいずれかを行う。
【００４８】
（Ａ−３）第１の実施形態の効果
上述のように、第１の実施形態によれば、サービス・ディレクトリ３ｍに登録するサービスの属性を属性設定部４ｍにより決定するようにしたことにより、いずれのサービスについても同一の属性が自動的に登録されるようにできる。すなわち、属性の一貫性を保証できる。
【００４９】
また、サービス・ディレクトリ３ｍ及び属性設定部４ｍのそれぞれを、ネットワーク・インタフェース１ｍ毎に設けたことにより、属性設定部４ｍにおける設定条件を相互に独立したものとでき、ネットワーク・インタフェース１ｍ別に登録される属性を管理することができる。
【００５０】
（Ｂ）第２の実施形態
（Ｂ−１）システム構成
以下、本発明に係るサービス属性管理装置の第２の実施形態例を説明する。図６に、当該サービス属性管理装置を備える分散システムの機能ブロック構成を示す。なお、図６に示す構成は、実装上のハードウェア構成又はソフトウェア構成を限定するものではない。
【００５１】
本実施形態と第１の実施形態との違いは、属性設定部４０の構成である。すなわち、第１の実施形態では、各ネットワーク・インタフェース１ｍ（ｍ＝１、２、３）について専用の属性設定部４ｍ（ｍ＝１、２、３）を設ける構成としたが、本実施形態では、属性設定部４０は複数のネットワーク・インタフェース１ｍ（ｍ＝１、２、３）に対して一つだけ設ける場合の構成について説明する。この点が両者の違いである。
【００５２】
なお、本実施形態に係る属性設定部４０には、その内部に対応関係テーブル４０Ａが設けられている。ここで、対応関係テーブル４０Ａは、サービス・ディレクトリ３ｍ（ｍ＝１、２、３）別の設定条件を記憶したテーブルである。属性設定部４０は、サービス・ディレクトリ３ｍからの新規サービス登録通知に含まれる識別子（サービス・ディレクトリの識別用）を検索キーに用いて対応する設定条件を読出し、最終的に登録する属性の決定を行うよう構成されている。
【００５３】
（Ｂ−２）属性管理動作
続いて、本実施形態に係る属性設定装置１０'により、属性の設定動作がどのように進行するかを説明する。ただし、この動作は、属性設定サブフェーズを除いて第１の実施形態における動作と同じである。従って、以下の説明では、相違点である属性設定サブフェーズについてのみ説明する。
【００５４】
この実施形態の場合もサービス１１１がサービス・ディレクトリ探索要求応答メッセージを受信し、サービス・インタフェース３１のサービス・インタフェースの実アドレスを取得することで当該フェーズ動作が開始される。
【００５５】
このようにサービス・ディレクトリ３１のサービス・インタフェースの実アドレスが取得されると、サービス１１１は、当該サービス・インタフェースの登録オペレーションを呼び出し、自身をそのサービス・インタフェース１１１Ａの実アドレスと共にサービス・ディレクトリ３１に登録する動作に移る。この際、サービス１１１に関連した属性も登録の対象となる。
【００５６】
この登録動作は、サービス登録要求メッセージの送信により実現される。当該メッセージはパケット種別判定部２１に与えられ、その種別が判定される。
【００５７】
サービス・ディレクトリ３１は、サービス登録要求メッセージを受信すると、当該メッセージに含まれる新規のサービスを登録すると共に、そのサービスの情報（例えば、サービス・インタフェース１１１Ａの実アドレス及び属性）と当該サービス・ディレクトリ３１の識別子を属性設定部４０に通知する。この通知は、新規サービス登録通知として行われる。この通知に、当該通知を行うサービス・ディレクトリの識別子が含まれる点が本実施形態に特有な動作である。
【００５８】
属性設定部４０は、新規サービス登録通知を受信すると、受け取った通知に含まれるサービス・ディレクトリの識別子をもとに対応関係テーブル４０Ａを検索し、当該識別子に対応するサービス・ディレクトリについて格納されている設定条件を読み出す。この後、属性設定部４０は、当該条件を基にサービス１１１から通知のあった情報の中から実際に登録する属性を決定する。
【００５９】
なお、設定条件は対応関係テーブル４０Ａに静的に格納されているか、又は対応関係テーブル４０Ａには属性を決定するルーチンへの参照が格納されており、当該ルーチンを起動することにより動的に決定される。
【００６０】
この後、属性設定部４０は、決定した属性とサービス１１１との関連付けを行う。このように、本実施形態の場合にも、サービスの属性として設定される項目は、属性設定部４０の対応関係テーブル４０Ａに予め設定されているため、一貫した属性の登録が可能となる。
【００６１】
（Ｂ−３）第２の実施形態の効果
このように、第２の実施形態の場合にも、属性設定サブフェーズにおける具体的な処理手法が異なるだけで、処理の結果に得られる登録内容は第１の実施形態の場合と同一なため、前述の第１の実施形態についての効果と同一の効果を得ることができる。
【００６２】
（Ｃ）第３の実施形態
（Ｃ−１）システム構成
以下、本発明に係るサービス属性管理装置の第３の実施形態例を説明する。図７に、当該サービス属性管理装置を備える分散システムの機能ブロック構成を示す。なお、図７に示す構成は、実装上のハードウェア構成又はソフトウェア構成を限定するものではない。
【００６３】
本実施形態と第１の実施形態との違いは、属性設定部４ｍ（ｍ＝１、２、３）がサービス・ディレクトリ３ｍ（ｍ＝１、２、３）に決定した属性を登録するのではなく、サービス１１１自身が決定した属性の登録を行う点である。
【００６４】
（Ｃ−２）属性管理動作
続いて、本実施形態に係る属性設定装置１０"により、属性の設定動作がどのように進行するかについて説明する。ただし、その動作は、属性設定サブフェーズを除いて第１の実施形態における動作と同じである。従って、以下の説明では、相違点である属性設定サブフェーズについてのみ説明する。また、図８に、本実施形態における属性設定サブフェーズで実行される処理の流れを示す。
【００６５】
この場合も、サービス１１１がサービス・ディレクトリ探索要求応答メッセージを受信し、サーピス・インタフェース３１のサービス・インタフェースの実アドレスを取得することで当該フェーズ動作が開始される。
【００６６】
このようにサーピス・ディレクトリ３１のサービス・インタフェースの実アドレスが取得されると、サービス１１１は、当該サービス・インタフェース１１１Ａの登録オペレーションを呼び出し、自身をそのサービス・インタフェース１１１Ａの実アドレスと共にサービス・ディレクトリ３１に登録する動作に移る。この際、サービス１１１に関連した属性も登録の対象となる。
【００６７】
この登録動作は、サービス登録要求メッセージの送信により実現される（図８(1)(2)）。当該メッセージはパケット種別判定部２１に与えられ、その種別が判定される（図８のステップＳ１）。
【００６８】
サービス・ディレクトリ３１は、サービス登録要求メッセージを受信すると（図８(3) ）、当該メッセージに含まれる新規のサービスを登録する（図８のステップＳ２）と共に、そのサービスの情報（例えばサービス・インタフェース１１１Ａの実アドレス及び属性）を属性設定部４１に通知する。この通知は、新規サービス登録通知として行われる（図８(4) ）。
【００６９】
属性設定部４１は、新規サービス登録通知を受信すると、受け取った情報の中からサービス１１１について登録すべき属性とその値を決定する（図８のステップＳ３）。なお、ここまでの処理は、第１の実施形態と同じである。
【００７０】
登録する属性が決定されると、属性設定部４１は、サービス・インタフェース１１１Ａの属性設定機能を用いて当該サービス１１１自身に決定した属性を通知する（図８(5)(6)(7) ）。ただし、この動作は、サービス・インタフェース１１１Ａが属性を設定する機能をサポートしていることが前提となる。
【００７１】
サービス１１１は、かかる決定した属性の通知を受信すると、自らが登録されているサービス・ディレクトリ３ｍに当該通知で与えられた属性の登録を実行する（図８(8)(9)(10)）。図８の例では、サービス１１１はサービス・ディレクトリ３１に当該属性の登録を行っている。
【００７２】
なお、当該サービス１１１が、他のサービス・ディレクトリにも登録されている場合には（図８の場合、サービス・ディレクトリ３ｎ（ｎ≠１，２，３））、サービス１１１は、決定された属性をサービス・ディレクトリ３ｎにも登録する（図８(11)）。ただし、当該サービス・ディレクトリ３ｎは、属性設定装置１０"とは無関係にネットワーク上で実行されているものとする。
【００７３】
（Ｃ−３）第３の実施形態の効果
このように、第３の実施形態の場合にも、属性設定サブフェーズにおける具体的な処理手法が異なるだけで、処理の結果に得られる登録内容は第１の実施形態の場合と同一なため、前述の第１の実施形態についての効果と同一の効果を得ることができる。
【００７４】
さらに、第１の実施形態では、属性設定部４ｍがサービス・ディレクトリ３ｍに設定された属性を直接操作したが、本実施形態の場合には、登録することに決定した属性の情報をそのサービス１１１自身に渡し、サービス自身が対応するサービス・ディレクトリ４ｍ及び４ｎに属性を登録するようにしたことにより、特定のサービスが複数のサービス・ディレクトリに登録されている場合でも、それらのサービス・ディレクトリ間でサービスの属性の一貫性を保証することができる。
【００７５】
（Ｄ）他の実施形態
なお、上述の実施形態においては、ルーティング機能部５０（すなわち、ルータ）を有する属性設定装置１０、１０'及び１０"について述べたが、本発明はルータヘの適用に限るものではない。例えば、レイヤ３スイッチや、ゲートウェイその他にも適用可能である。なお、スイッチを適用した場合には、実施形態例中のルーティング機能部５０はスイッチング機能部となる。
【００７６】
上述の実施形態例においては、分散オブジェクトであるサービスがそのサービス・インタフェースの実アドレスを、対応するサービス・ディレクトリ（例えば、サービス・ディレクトリ３１）に登録する場合について述べたが、サービス・インタフェースを実装したプロクシをサービス・ディレクトリに登録する場合にも適用し得る。なお、この明細書の特許請求の範囲においては、この「プロクシ」も含めた意味で「サービス」の用語を用いるものとする。
【００７７】
上述の実施形態においては、ネットワーク・インタフェース１ｍに対しサービスディレクトリ３ｍを一対一の関係で設ける場合について述べたが、複数のネットワーク・インタフェースに対して１つのサービス・ディレクトリを設けるようにしても良い。この場合も、属性設定部によって、サービス・ディレクトリに保存される属性の項目を統一できるため、保存されるサービス属性の一貫性を保証できるという効果を実現できる。
【００７８】
上述の実施形態においては、パケット種別判定部２ｍがルーティング機能部５０にメッセージを渡す構成としているが、ネットワーク・インタフェース１ｍが受信したメッセージを直接ルーティング機能部５０に渡す構成としても良い。
【００７９】
上述の実施形態においては、パケット種別判定部２ｍ、サービス・ディレクトリ３ｍ、属性設定部４ｍ、ルーティング機能５０などの機能部をそれぞれ分けて示したが、これは論理的な構成を機能ブロックとして示したものであり、実装上のハードウェア・ソフトウェア構成を示したものではない。
【００８０】
【発明の効果】
上述のように、本発明によれば、分散オブジェクトとして実現されるサービスの属性を、管理情報としてサービス・ディレクトリに保持するサービス属性管理装置に、予め設定されたサービスの提供に不可欠な属性を設定条件として有し、サービス・ディレクトリに新規に登録されたサービスから新規サービス登録通知を受け取り、その新規サービス登録通知に含まれる属性のうち設定条件に合致する属性をサービス・ディレクトリに登録させる属性として決定する属性設定部を有することにより、サービスの違いによらず同一の属性を自動的に登録可能とできる。
【図面の簡単な説明】
【図１】サービス属性管理装置の第１の実施形態例を示す図である。
【図２】分散システムの基本構成を示す図である。
【図３】動作説明に使用するサービス属性管理装置の実施形態例を示す図である。
【図４】サービス起動サブフェーズ時の処理の流れを示す図である。
【図５】属性設定サプフェーズ時の処理の流れを示す図である。
【図６】サービス属性管理装置の第２の実施形態例を示す図である。
【図７】サービス属性管理装置の第３の実施形態例を示す図である。
【図８】第３の実施形態例に係るサービス属性管理装置において実行される属性設定サプフェーズでの処理の流れを示す図である。
【符号の説明】
１…サービス、１Ａ…サービス・インタフェース、２…サービス・ディレクトリ、２Ａ…実アドレス、２Ｂ…属性、２Ｃ…サービス・インタフェース、３…クライアント、１０、１０'…属性設定装置、１１、１２、１３…ネットワーク・インタフェース、２１、２２、２３…パケット種別判定部、３１、３２、３３…サービス・ディレクトリ、４０、４１、４２、４３…属性設定部、４０Ａ…対応関係テーブル、５０…ルーティング機能部、６１、６２、６３…サブネットワーク、１００…端末、１１１…サービス、１１１Ａ…サービス・インタフェース。
Claims (8)
- 分散オブジェクトとして実現されるサービスの属性を、管理情報としてサービス・ディレクトリに保持するサービス属性管理装置において、
予め設定されたサービスの提供に不可欠な属性を設定条件として有し、上記サービス・ディレクトリに新規に登録されたサービスから新規サービス登録通知を受け取り、その新規サービス登録通知に含まれる属性のうち上記設定条件に合致する属性を上記サービス・ディレクトリに登録させる属性として決定する属性設定部を有することを特徴とするサービス属性管理装置。 - 請求項１に記載のサービス属性管理装置において、上記属性設定部が参照する設定条件は任意に設定可能とする、ことを特徴とするサービス属性管理装置。
- 請求項１に記載のサービス属性管理装置において、上記サービス・ディレクトリは、ネットワーク・インタフェース毎設けられている、ことを特徴とするサービス属性管理装置。
- 請求項２に記載のサービス属性管理装置において、上記属性設定部は、ネットワーク・インタフェース毎設けられたサービス・ディレクトリのそれぞれに対応して設けられており、それぞれにおける設定条件は個別に設定可能である、ことを特徴とするサービス属性管理装置。
- 請求項２に記載のサービス属性管理装置において、上記属性設定部は、ネットワーク・インタフェース毎に設けられたサービス・ディレクトリに対して共通に設けられており、各サービス・ディレクトリについての属性の登録は、対応関係テーブルに記憶した各サービス・ディレクトリに対応する設定条件に基づいて個別に実行される、ことを特徴とするサービス属性管理装置。
- 請求項１〜５のいずれかに記載のサービス属性管理装置において、上記属性設定部が決定した属性は、当該属性設定部により該当するサービス・ディレクトリに登録される、ことを特徴とするサービス属性管理装置。
- 請求項１〜５のいずれかに記載のサービス属性管理装置において、上記属性設定部が決定した属性は、当該属性の通知を受けたサービスにより該当するサービス・ディレクトリに登録される、ことを特徴とするサービス属性管理装置。
- 請求項７に記載のサービス属性管理装置において、サービスが複数のサービス・ディレクトリに登録されている場合、上記属性設定部が決定した属性の通知を受けたサービスは、当該複数のサービス・ディレクトリに対し属性を通知する、ことを特徴とするサービス属性管理装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP14310199A JP4159181B2 (ja) | 1999-05-24 | 1999-05-24 | サービス属性管理装置 |
| US09/576,803 US6625605B1 (en) | 1999-05-24 | 2000-05-23 | Service attribute management system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP14310199A JP4159181B2 (ja) | 1999-05-24 | 1999-05-24 | サービス属性管理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000330851A JP2000330851A (ja) | 2000-11-30 |
| JP4159181B2 true JP4159181B2 (ja) | 2008-10-01 |
Family
ID=15330943
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP14310199A Expired - Fee Related JP4159181B2 (ja) | 1999-05-24 | 1999-05-24 | サービス属性管理装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6625605B1 (ja) |
| JP (1) | JP4159181B2 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5850518A (en) * | 1994-12-12 | 1998-12-15 | Northrup; Charles J. | Access-method-independent exchange |
| US7562127B2 (en) * | 2001-04-03 | 2009-07-14 | Nippon Telegraph And Telephone Corporation | Contents additional service inquiry server for identifying servers providing additional services and distinguishing between servers |
| US8780770B2 (en) | 2002-05-13 | 2014-07-15 | Misonimo Chi Acquisition L.L.C. | Systems and methods for voice and video communication over a wireless network |
| US7852796B2 (en) | 2002-05-13 | 2010-12-14 | Xudong Wang | Distributed multichannel wireless communication |
| US20030212821A1 (en) * | 2002-05-13 | 2003-11-13 | Kiyon, Inc. | System and method for routing packets in a wired or wireless network |
| US7941149B2 (en) | 2002-05-13 | 2011-05-10 | Misonimo Chi Acquistion L.L.C. | Multi-hop ultra wide band wireless network communication |
| US7957356B2 (en) * | 2002-05-13 | 2011-06-07 | Misomino Chi Acquisitions L.L.C. | Scalable media access control for multi-hop high bandwidth communications |
| US6772247B2 (en) * | 2002-11-19 | 2004-08-03 | Intel Corporation | Circuit for merging and aligning prepend data and payload data |
| US20060072482A1 (en) * | 2004-10-06 | 2006-04-06 | Nokia Corporation | Service routing |
| US8175613B2 (en) | 2006-08-04 | 2012-05-08 | Misonimo Chi Acquisitions L.L.C. | Systems and methods for determining location of devices within a wireless network |
| JP4861484B2 (ja) * | 2006-12-07 | 2012-01-25 | ミソニモ チ アクイジションズ エル．エル．シー． | タイムスロット及びチャネルを割り当てるシステム及び方法 |
| CN105827438B (zh) * | 2016-03-11 | 2019-03-15 | 广东亿迅科技有限公司 | 一种自动设置apn的方法 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3552258B2 (ja) * | 1993-12-27 | 2004-08-11 | 株式会社日立製作所 | 分散計算機システム及びその情報管理方法 |
| US6144661A (en) * | 1996-02-05 | 2000-11-07 | Kabushiki Kaisha Toshiba | Network node apparatus and virtual connection control method for providing various service attributes in multicast communication |
| JPH10171681A (ja) * | 1996-12-10 | 1998-06-26 | Fujitsu Ltd | オブジェクト指向装置管理システム |
| JPH1196062A (ja) * | 1997-09-19 | 1999-04-09 | Hitachi Ltd | ディレクトリ・アクセス方法 |
| US6366954B1 (en) * | 1998-05-14 | 2002-04-02 | Sun Microsystems, Inc. | Method and data format for exchanging data between a Java system database entry and an LDAP directory service |
| US6366913B1 (en) * | 1998-10-21 | 2002-04-02 | Netscape Communications Corporation | Centralized directory services supporting dynamic group membership |
-
1999
- 1999-05-24 JP JP14310199A patent/JP4159181B2/ja not_active Expired - Fee Related
-
2000
- 2000-05-23 US US09/576,803 patent/US6625605B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US6625605B1 (en) | 2003-09-23 |
| JP2000330851A (ja) | 2000-11-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7437479B2 (en) | Position identifier management apparatus and method, mobile computer, and position identifier processing method | |
| JP4592184B2 (ja) | 静的な識別子が付され、かつネットワークに断続的に接続される装置へのアクセス方法および装置 | |
| US7228359B1 (en) | Methods and apparatus for providing domain name service based on a client identifier | |
| US6895429B2 (en) | Technique for enabling multiple virtual filers on a single filer to participate in multiple address spaces with overlapping network addresses | |
| US6694375B1 (en) | Communications network and method having accessible directory of user profile data | |
| JP4762658B2 (ja) | インターネット・マルチメディア・サブシステム（ｉｍｓ）ネットワーク内の分散ｓｌｆルーティング機能を提供するための方法および装置 | |
| JP4159337B2 (ja) | 仮想ネットワーク名の解決方法 | |
| US6151331A (en) | System and method for providing a proxy FARP for legacy storage devices | |
| JP4159181B2 (ja) | サービス属性管理装置 | |
| US6801952B2 (en) | Method and devices for providing network services from several servers | |
| US20120124087A1 (en) | Method and apparatus for locating naming discrepancies | |
| JP2003208365A (ja) | 適応ディスパッチャを有する仮想ネットワーク | |
| US7219161B1 (en) | Techniques for network address and port translation for network protocols that do not use translated ports when requesting network resources | |
| JP3609948B2 (ja) | マルチプロトコルネットワーク管理方法、マルチプロトコルネットワーク管理プロキシサーバシステム、マルチプロトコルアドレス管理サーバシステム、および、マルチプロトコルネットワーク管理システム | |
| JP2000341325A (ja) | 通信アドレスの変化する通信端末器に対してホスト名を固定してアクセスする方法、この方法を用いたダイナミックｉｐ用ｄｎｓシステム、及びそのシステムに使用されるｄｎｓサーバ装置 | |
| US6625256B1 (en) | Failover mechanisms for remote networked phones | |
| JP2003110594A (ja) | Ｉｐアドレス通知方法及び端末間の接続方法 | |
| JPH08307451A (ja) | データ伝送システム及び方法 | |
| JPH104407A (ja) | ネットワーク管理装置および方法 | |
| JP2004070753A (ja) | 論理アドレスサービス起動方法及び論理アドレス管理装置及びアプリケーション実行装置及び論理アドレスサービス管理プログラム及び論理アドレスサービス起動プログラム及び論理アドレスサービス管理プログラムを格納した記憶媒体及び論理アドレスサービス起動プログラムを格納した記憶媒体 | |
| JP3781020B2 (ja) | 論理アドレスサービス起動方法及び論理アドレス管理装置及びアプリケーション実行装置及び論理アドレスサービス管理プログラム及び論理アドレスサービス起動プログラム及び論理アドレスサービス管理プログラムを格納した記憶媒体及び論理アドレスサービス起動プログラムを格納した記憶媒体 | |
| JP3801115B2 (ja) | 論理アドレスサービス起動方法及びシステム及び論理アドレスサービス起動プログラム及び論理アドレスサービス起動プログラムを格納した記憶媒体 | |
| Schmitz | MBS Network Plugin Documentation | |
| CA2246133C (en) | Method and devices for providing network services from several servers | |
| JPS61136336A (ja) | マルチネツトワ−クシステムにおける他系エンドノ−ド情報取得方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050222 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050422 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060110 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060310 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20060323 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20060630 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080715 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110725 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120725 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130725 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |