(57)【要約】異なるシステム製品またはソフトウェア・ソリューションとの一貫性のあるインターフェースを提供するシステムおよび方法は、当該の異なるシステム製品またはソフトウェア・ソリューション（管理機能）が配置されている１個以上のシステム・ユニットまたは機器を含む。要求に対してサービスを提供可能な管理機能を含む特定のシステム・ユニットまたは機器に関連付けられた管理機能ゲートウェイに対してサービス要求を行なうことができる。管理機能ゲートウェイは、当該の特定管理機能に関連付けられた管理機能スポンサーを選択して、当該の特定管理機能から要求されたサービスを起動する。
2005523520.tif 000002
【特許請求の範囲】
【請求項１】
複数の管理機能との一貫性のあるインターフェースを提供するシステムであって、
少なくとも１個のシステム・ユニットと、
管理機能ゲートウェイと、
複数の管理機能スポンサーと、
複数の管理機能とを含み、
前記管理機能ゲートウェイが１個以上の前記システム・ユニットに接続され、
前記複数の管理機能スポンサーの各管理機能スポンサーが１個の管理機能ゲートウェイに接続され、
前記複数の管理機能の各々が前記複数の管理機能スポンサーの１個に接続されているシステム。
【請求項２】
前記複数の管理機能の各管理機能が、各々のインターフェースにより前記複数の管理機能スポンサーの１個に接続されている、請求項１に記載のシステム。
【請求項３】
前記システム・ユニットのうち１個がデータ保存機器を含む、請求項１に記載のシステム。
【請求項４】
前記複数の管理機能が複数のシステム製品を含む、請求項１に記載のシステム。
【請求項５】
前記複数の管理機能が複数のソフトウェア・ソリューションを含む、請求項１に記載のシステム。
【請求項６】
複数の管理機能との一貫性のあるインターフェースを提供するシステムであって、
サービス要求メッセージを生成する手段と、
少なくとも１個のシステム・ユニットに関連付けられたゲートウェイへ前記サービス要求メッセージを送信する手段と、
前記サービス要求メッセージに含まれるサービス要求を満たすべく複数の管理機能のうち１個が利用可能か否かを判定する手段と、
前記管理機能が利用可能な場合、前記管理機能に関連付けられたスポンサーを選択する手段と、
前記管理機能とともにサービスを起動する手段とを含むシステム。
【請求項７】
前記複数の管理機能の中の管理機能を、インターフェースを介して前記スポンサーに接続する手段を更に含む、請求項６に記載のシステム。
【請求項８】
前記複数の管理機能が複数のシステム製品を含む、請求項６に記載のシステム。
【請求項９】
前記複数の管理機能が複数のソフトウェア・ソリューションを含む、請求項６に記載のシステム。
【請求項１０】
複数の管理機能との一貫性のあるインターフェースを提供する方法であって、
少なくとも１個のシステム・ユニットに関連付けられたゲートウェイでサービス要求メッセージを受信するステップと、
複数の管理機能のうち１個の管理機能が前記サービス要求メッセージに含まれるサービス要求を満たすべく利用可能か否かを判定するステップと、
利用可能な場合、前記管理機能に関連付けられたインターフェースを含むスポンサーを選択するステップと、
前記インターフェースを介して前記管理機能と共に前記サービスを起動するステップとを含む方法。
【請求項１１】
サービス要求メッセージを生成するステップがＸＭＬメッセージを生成するステップを含む、請求項１０に記載の方法。
【請求項１２】
ＸＭＬメッセージ用いて、起動されたサービスの結果をサービス要求元へ返すステップを更に含む、請求項１０に記載の方法。
【請求項１３】
サービス要求メッセージを生成するステップがユーザーにより実行される、請求項１０に記載の方法。
【請求項１４】
前記複数の管理機能の管理機能がサービス要求メッセージに含まれるサービス要求を満たすべく利用可能か否かを判定するステップが、前記ゲートウェイに関連付けられた複数の管理機能スポンサーへ記述メッセージを送信するステップを含む、請求項１０に記載の方法。
【請求項１５】
前記インターフェースが管理機能用に製品固有のインターフェースを含む、請求項１０に記載の方法。
【請求項１６】
前記選択ステップがゲートウェイにより実行される、請求項１０に記載の方法。
【請求項１７】
前記起動ステップがスポンサーにより実行される、請求項１０に記載の方法。
【請求項１８】
少なくとも１個のシステム・ユニットがデータ保存機器を含む、請求項１０に記載の方法。
【請求項１９】
前記ゲートウェイが管理機能ゲートウェイを含む、請求項１０に記載の方法。
【請求項２０】
前記スポンサーが管理機能スポンサーを含む、請求項１０に記載の方法。
【請求項２１】
前記複数の管理機能が複数のシステム製品を含む、請求項１０に記載の方法。
【請求項２２】
前記複数の管理機能が複数のソフトウェア・ソリューションを含む、請求項１０に記載の方法。
【請求項２３】
複数の管理機能との一貫性のあるインターフェースを提供するソフトウェアであって、前記ソフトウェアがコンピュータ可読媒体に搭載されていて、実行時において、
少なくとも１個のシステム・ユニットに関連付けられたゲートウェイでサービス要求メッセージを受信し、
複数の管理機能のうち１個の管理機能が、サービス要求メッセージに含まれるサービス要求を満たすべく利可能か否かを判定し、
利用可能な場合、前記管理機能に関付けられたインターフェースを含むスポンサーを選択し、
前記管理機能と共に前記サービスを起動するべく動作可能であるソフトウェア。
【請求項２４】
前記インターフェースを介して前記スポンサーに前記複数の管理機能うちの１個を接続すべく更に動作可能である、請求項２３に記載のソフトウェア。
【請求項２５】
前記複数の管理機能が複数のシステム製品を含む、請求項２３に記載のソフトウェア。
【請求項２６】
前記複数の管理機能が複数のソフトウェア製品を含む、請求項２３に記載のソフトウェア。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は一般に、データリソース管理に関し、特に既存のコンピュータシステム管理製品またはソフトウェア・ソリューションとの一貫性のある管理インターフェースを提供するシステムおよび方法に関する。
【背景技術】
【０００２】
コンピュータシステムの管理は企業活動における重要な要素であるとともに、ソフトウェア市場で最も成長の早い分野の一つでもある。発売および購入される製品（例えばソフトウェアやハードウェア）の量が増える中で、説明責任を求める圧力が増大しつつある。発売されるハードウェアやソフトウェアを購入するために費やされている膨大な支出、並びに受託者責任を示すべくコスト管理を求める圧力が増大しつつある中で、説明責任に対するニーズが増大しており、そのため企業活動においてシステム管理が果たす役割が増している。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
異なる種類のツールを寄せ集めて利用する従来のシステム管理手法はコスト面で非効率であることがわかっている。その理由は、これら別々の管理ツールの利用に伴うコストが、管理を必要とするハードウェアやソフトウェアになされた初期投資を通常上回る管理コストを生じさせるためである。使用するツールの各々の性能が異なり、あるものは管理目的を達成するために用いる必要があるため、使用するツールの数を減らすことは多くの場合可能でない。この問題に対処する別の従来方法としてインターフェース標準の定義または提案（Ｉｎｔｅｒｆａｃｅ  Ｓｔａｎｄａｒｄ  Ｄｅｆｉｎｉｔｉｏｎｓ  ｏｒ  Ｐｒｏｐｏｓａｌｓ）の推進があるが、これらは最終的には支持されて、時間をかけて（例えば標準への準拠を求める顧客の圧力に対応して）既存製品の新バージョンに実装されるものである。
【課題を解決するための手段】
【０００４】
本開示は、既存技術とのインターフェースを提供する標準の技術を実現することが可能な機構について記載している。一実施形態において、既存製品および関連技術に対し、新規の通信プロトコルやメッセージ構成の導入や開発、あるいはそれらの製品や技術に大規模な変更を加える必要なしに標準に基づく一貫性のあるインターフェースを提供する。
【０００５】
従って、異種の製品またはソフトウェア・ソリューションに一貫性のあるインターフェースを提供するシステムおよび方法は、当該異種システム製品またはソフトウェア・ソリューション（管理機能）が配置されている１個以上のシステム・ユニットまたは機器を含んでいてよい。要求に対してサービスを提供可能な管理機能を含む特定のシステム・ユニットまたは機器に関連付けられた管理機能ゲートウェイに対してサービス要求を求めることができる。管理機能ゲートウェイは、当該特定管理機能に関連付けられた管理機能スポンサー（ｉｎｓｔｒｕｍｅｎｔ  ｓｐｏｎｓｏｒ）を選択して、当該特定管理機能から要求されたサービスを起動する。管理機能スポンサーは、要求元と、そのサービス要求を満たすことができる特定の管理機能との間で製品固有（ｐｒｏｄｕｃｔ−ｓｐｅｃｉｆｉｃ）のインターフェースを提供する。管理機能スポンサーは、要求元に対し、メッセージ・ペイロード内の適当なインターフェースおよび管理機能ゲートウェイを介してサービス結果を返すことができる。実施形態の一例において、メッセージ・ペイロードはＸＭＬメッセージを含んでいてよい。
【０００６】
本開示をより完全に理解すべく、添付の図面と合わせて以下の説明を参照する。
【発明を実施するための最良の形態】
【０００７】
詳細な説明
図１に、実施形態の一例を実施すべく利用可能なシステム１０の例を示す。システム１０は、複数のシステム・ユニットまたは機器１２ａ〜１２ｎを含む。このようなシステム・ユニット１２ａ〜１２ｎを４個示すが、これは説明目的のためだけであり、任意の適当な個数のシステム・ユニット１２を用いてもよい。この例の場合、システム・ユニット１２ａ〜１２ｎは同様に構成されていてよい。しかし、各システム・ユニット１２ａ〜１２ｎに提供されたシステム製品、ソフトウェアまたは管理機能運用は、データ保存機器等の異なる製品やソリューションであってよい。
【０００８】
各システム・ユニット１２ａ〜１２ｎは、管理機能ゲートウェイ１４を含んでいてよい。管理機能ゲートウェイ１４は、主にディスパッチャ（例えばオブジェクト要求の仲介役）として機能し、所与のシステム・ユニットまたは機器１２ａ〜１２ｎ上の全ての管理機能スポンサー１６ａ〜６ｎへアクセスさせることができる。本質的に、管理機能ゲートウェイ１４は、管理機能スポンサー１６ａ〜１６ｎへのアクセスが得られる中央通路として機能する。このような３個の管理機能スポンサー１６ａ〜１６ｎを示すが、本開示はこれに限定されるものではなく、任意の適当な個数の管理機能スポンサー１６を用いてよい。各管理機能スポンサー１６ａ〜１６ｎは、所与のシステム・ユニットまたは機器１２ａ〜１２ｎ上の管理機能ゲートウェイ１４に対する従属エージェントとして機能することができる。管理機能スポンサー１６ａ〜１６ｎは主として、管理機能スポンサーが作用すべく設計されている特定のシステム製品またはソフトウェア・ソリューションの機能へアクセスを許す管理機能ゲートウェイ１４への標準インターフェースを提示すべく機能する。各管理機能スポンサー１６ａ〜１６ｎは、知識プロバイダの実行可能なインスタンス化として機能可能であり、既存システム製品がクライアントとのインターフェースを提供することができる。このように、各管理機能スポンサーは、実際の知識ジェネレータまたはサービスプロバイダとしての役割を果たすことができる。
【０００９】
知識プロバイダとは、特定のポータルサーバーから起動されて、特定のシステムマネージャ・ポートレットが要求した情報およびサービスへアクセスさせることが可能なアプリケーションである。ポートレットとは、ポータルのユーザーが各種のシステム管理関連作業にアクセスできるようにするポータルウインドウである。ポータルサーバーは、ポータルサーバー・アプリケーションを実行している機器であってよい。
【００１０】
基本知識プロバイダとは、管理機能運用レイヤ１８ａ〜１８ｎの単一アプリケーションが提供する１個以上の適当なインターフェースの直接呼出しにより、サービスへアクセスさせる知識プロバイダである（例えば基本知識プロバイダは、単一の管理機能スポンサー１６ａ〜１６ｎに要求することができる）。複合知識プロバイダとは、管理機能運用レイヤ１８ａ〜１８ｎの複数の単一アプリケーションが提供する１個以上の適当なインターフェースの直接呼出しにより、サービスへアクセスさせる知識プロバイダである（例えば複合知識プロバイダは多数の管理機能スポンサー１６ａ〜１６ｎに要求することができる）。
【００１１】
各管理機能運用レイヤ１８ａ〜１８ｎは、クライアント・アプリケーション２０が（例えば管理機能スポンサー１６ａ〜１６ｎを通じて）インターフェースを持つことが可能な既存のシステム製品またはソフトウェア・ソリューションとして機能することができる。このように、管理機能運用レイヤ１８ａ〜１８ｎ内のシステム製品またはソフトウェア・ソリューションの機能はポートレットを介して要求されて、関係する製品、ソフトウェア、または管理機能の実際のタスクを実行することができる。管理機能スポンサーは、クライアントのサービス要求を果たすべく、適当な管理機能運用レイヤまたは製品１８ａ〜１８ｎを起動することができる。
【００１２】
動作時において、ユーザーまたはクライアント・アプリケーション２０は、１個以上のシステム・ユニット１２ａ〜１２ｎ上の既存システム製品、ソフトウェア・ソリューション、または関連技術とのインターフェースの確立を試みる。実施形態の一例として、システム１０は、システム管理者に対し、多くの異なるシステム技術（データ保存、セキュリティ、ネットワーク制御等）向けに、かつ異なるプラットフォームにまたがって、システム管理手順の閲覧、実行、報告、分析、監視、自動化を行なう共通インターフェースを提供することが可能なウェブベースのポータルであると考えてよい。アプリケーション２０は、関係する製品に付随するサービスに対する要求の種類を記述する標準メッセージを生成することができる。例えば、アプリケーション２０は出されている要求を記述するための拡張可能マークアップ言語（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）（ＸＭＬ）メッセージ生成することができる。このメッセージは、一般にメッセージ・ペイロード（または、ＸＭＬメッセージの場合、「ＸＭＬメッセージ・ペイロード」）と呼ばれる場合がある。ＸＭＬメッセージ・ペイロードの内容として、関連するシステム製品、ソフトウェア・ソリューションまたは管理機能とのトランザクションまたはサービス要求に関連付けられた問い合わせおよびフォーマット基準を共に構成するＸＭＬタグおよび値が含まれていてよい。製品との通信またはサービス要求を含み得るメッセージ・ペイロードは、インターフェースを確立したい製品が動作中であるシステム・ユニット１２ａ〜１２ｎへ送信することができる。メッセージ・ペイロードは、例えば標準タイプ・メッセージ用のＨＴＴＰ１．１または通常より高いセキュリティレベルでの取扱いを要するメッセージ・ペイロード用のＨＴＴＰＳ１．１等の標準メッセージ送信プロトコルを用いて、アプリケーション２０からインターネット（例えばネットワーク１９）を介してシステム・ユニット（または機器）１２ａ〜１２ｎのポートへ送信することができる。アプリケーション２０から送信されたメッセージ・ペイロードを受信するシステム・ユニット１２ａ〜１２ｎのポートは、管理機能ゲートウェイ１４により接続されてサービス提供を行なうことができる。
【００１３】
ネットワーク１９は、ユーザー（例えば２０）を１個以上のシステム・ユニットまたは機器１２ａ〜１２ｎに接続可能な公共および／または専用ネットワークの任意の適当な組合せを含んでいてよい。実施形態の一例において、ネットワーク１９は、ユーザー２０をシステム・ユニットまたは機器１２ａ〜１２ｎに接続するインターネットおよび任意の適当なローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・ネットワーク（ＭＡＮ）または広域ネットワーク（ＷＡＮ）を含んでいてよい。
【００１４】
管理機能ゲートウェイ１４は、到来メッセージ・ペイロードを調べて、アプリケーション２０からのメッセージ・ペイロード内の要求に対するサービスを実行するためにどの管理機能スポンサー１６ａ〜１６ｎを選択して起動すべきかを決定することができる。好適には、各管理機能スポンサー１６ａ〜１６ｎは、要求されたタスクを実行すべく起動可能な特定のシステム製品、ソフトウェア・ソリューションまたは管理機能運用レイヤ１８ａ〜１８ｎの管理機能に関連付けることができる。選択された管理機能スポンサー１６ａ〜１６ｎは次いで、要求されたタスクの実行に適したシステム製品、ソフトウェア・ソリューションまたは管理機能を起動することができる。特徴的なのは、選択された管理機能スポンサー１６ａ〜１６ｎが、要求されたタスクの実行に要する任意の製品固有のインターフェースも提供するように構成可能な点である。
【００１５】
上述のように、管理機能ゲートウェイ１４は、クライアント・アプリケーション２０からの要求に対するサービスの実行に適した管理機能スポンサー１６ａ〜１６ｎを選択して起動することができる。実施形態の一例として、各管理機能スポンサー１６ａ〜１６ｎはソフトウェアで実行可能であって、動的リンクライブラリ（Ｄｙｎａｍｉｃ  Ｌｉｎｋ  Ｌｉｂｒａｒｙ）（ＤＬＬ）、コンポーネント・オブジェクト・モデル（Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）（ＣＯＭ）オブジェクト（例えばビジュアル・ベーシック（Ｖｉｓｕａｌ  Ｂａｓｉｃ）（ＶＢ）、オブジェクト連携および埋め込み（Ｏｂｊｅｃｔ  Ｌｉｎｋｉｎｇ  ａｎｄ  Ｅｍｂｅｄｄｉｎｇ）（ＯＬＥ）、ＯＬＥカスタム制御（ＯＬＥ  Ｃｕｓｔｏｍ  ｃｏｎｔｒｏｌ）（ＯＣＸ）、アクティブＸ（ＡｃｔｉｖｅＸ）等）、Ｊａｖａクラス、およびＶＢスクリプト（ＶＢ  Ｓｃｒｉｐｔ）のうち少なくとも一つのフォーマットで、プロセス外アプリケーションまたはプロセス内アプリケーションとして動作可能である。各管理機能スポンサー１６ａ〜１６ｎの能力および特性に関する付帯情報は、集中アクセス可能な登録機関（図示せず）に保存されていてよい。登録機関は、管理機能スポンサー１６ａ〜１６ｎに関する登録情報をユニバーサル・ディスクリプション、ディスカバリー＆インテグレーション（ＵＤＤＩ）その他のウェブベースのサービスディレクトリを提供すべく提供するための接続点としての役割を果たすことができる。
【００１６】
登録情報は、各管理機能スポンサー１６ａ〜１６ｎ用のデジタル署名を含んでいてよい。デジタル署名は、管理機能ゲートウェイ１４によりロードまたは起動されている特定の管理機能スポンサー１６ａ〜１６ｎが改ざんされていないことを保証するために、所与のプラットフォームまたはシステム・ユニット１２ａ〜１２ｎの管理機能ゲートウェイ１４が（例えばオプションとして）用いることができる。このように、実施形態の一例として、管理機能スポンサー１６ａ〜１６ｎを支援すべく、ＤＬＬ群、ＣＯＭオブジェクト、Ｊａｖａクラス等のデジタル署名のためにマイクロソフト（Ｍｉｃｒｏｓｏｆｔ）の署名コード機構を用いてもよい。
【００１７】
管理機能運用レイヤ１８ａ〜１８ｎの適当なシステム製品またはソフトウェア・ソリューションを起動するために、管理機能ゲートウェイ１４がメッセージ・ペイロードを選択された管理機能スポンサー１６ａ〜１６ｎへ送信する際に、管理機能ゲートウェイ１４は選択された管理機能スポンサーに付帯メッセージ情報を、各種の方法のうちの少なくとも一つによりロードすることができる。このように、管理機能ゲートウェイ１４が用いるロード方法は、関係する管理機能スポンサー１６ａ〜１６ｎのプラットフォームおよび処理タイプに応じて異なっていてよい。例えば、選択された管理機能スポンサー１６ａ〜１６ｎがウィンドウズ（Ｗｉｎｄｏｗｓ）ベースのプラットフォームでプロセス外メソッドのために用いられる場合、管理機能ゲートウェイ１４は適当なＣＯＭオブジェクト（例えばＣＯＭは、暗黙的にＮＴ生成プロシージャを設けることができる）のインスタンス化することにより、選択された管理機能スポンサーに付帯メッセージ情報をロードすることができる。別の例として、選択された管理機能スポンサー１６ａ〜１６ｎがユニックス（ＵＮＩＸ）ベースのプラットフォームでプロセス外メソッドのために用いられる場合、管理機能ゲートウェイ１４は、共有ライブラリおよび／またはＦｏｒｋまたはＥｘｅｃコマンドを介して、選択された管理機能スポンサーに付帯メッセージ情報をロードすることができる。
【００１８】
しかし、選択された管理機能スポンサー１６ａ〜１６ｎがＷｉｎｄｏｗｓベースまたはＵＮＩＸベースのプラットフォームでプロセス内メソッドのために用いられる場合、管理機能ゲートウェイ１４は、選択された管理機能スポンサー１６ａ〜１６ｎが管理機能ゲートウェイ１４の制御の下でスレッド（例えば他の部分とは独立に実行可能なプログラムの一部）として実行可能なように、付帯情報を含むスレッドを生成して、そのスレッドのインスタンス化することにより、選択された管理機能スポンサーに付帯メッセージ情報をロードすることができる。
【００１９】
上述のように、各管理機能スポンサー１６ａ〜１６ｎは、ユーザー（例えばクライアント・アプリケーション２０）が要求するシステムまたはソフトウェア機能を識別する管理機能ゲートウェイ１４を介して到達するメッセージ・ペイロード（例えばＸＭＬメッセージ・ペイロード）を受容することができる。各管理機能スポンサー１６ａ〜１６ｎはまた、管理機能ゲートウェイ１４を介して要求元（例えばアプリケーション２０）へメッセージ（例えばＸＭＬメッセージ・バッファ）を出力することができる。具体的には、管理機能ゲートウェイ１４と管理機能スポンサー１６ａ〜１６ｎとの間でメッセージを送信すべく用いられる機構は、用いられる管理機能スポンサーのプラットフォームや処理タイプに応じて異なっていてよい。例えば、管理機能スポンサー１６ａ〜１６ｎがＷｉｎｄｏｗｓベースのプラットフォームでプロセス外メソッドのために用いられる場合、ＣＯＭ遠隔プロシージャ・コール（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ）（ＲＰＣ）機構を用いて管理機能ゲートウェイ１４が開始したプロセスへメッセージに送信することができるが、他の局面ではマスター・エージェントの（例えば管理機能ゲートウェイの）サービスとは別個に実行される。クライアント・プログラムはＣＯＭ  ＲＰＣを用いて適当な引数とともに、メッセージをサーバーへ送信することができ、サーバーはプログラムの実行結果を含むメッセージを返すことができる。別の例として、管理機能スポンサー１６ａ〜１６ｎがＵＮＩＸベースのプラットフォームでプロセス外メソッドのために用いられる場合、管理機能スポンサーは「Ｆｏｒｋ」または「Ｅｘｅｃ」コマンドを介して起動することができる。このように、管理機能スポンサーは、「ｓｔｄｉｎ」フィールドから到来メッセージ（例えばＸＭＬメッセージ）を読んで、「ｓｔｄｏｕｔ」フィールドに書き込むことにより応答メッセージを出力することができる。しかし、管理機能スポンサー１６ａ〜１６ｎが立ち上げ時にプロセス内メソッド（例えばＷｉｎｄｏｗｓベースまたはＵＮＩＸベースのプラットフォームで）に用いられる場合、到来バッファ（例えばｃｈａｒ＊ｉｎｂｕｆｆ）にハンドルまたはポインタを渡し、別のポインタを外出バッファ（例えばｃｈａｒ＊ｏｕｔｂｕｆｆ）に渡してもよい。
【００２０】
以下は、管理機能スポンサー１６ａ〜１６ｎを起動すべく管理機能ゲートウェイ１４が使用可能なＵＮＩＸベースのコードの例である。
Loadlib(bebSubAjent.dll)
Beb.InvokeSub(“INIT”)
wait for inbound data
if for bebAgent
beb.InvokeSub(“INVOKE”,ib,ob);
sendRply(ob);
beb.InvokeSub(“FREE”,ob);
continue;
【００２１】
以下は、管理機能ゲートウェイ１４からのメッセージを受容して応答すべく管理機能スポンサー１６ａ〜１６ｎが使用可能なコードの例である。
fn:bebSubAject.dll
long_declspec(dllexport)_cdeclInvokeSub(
PCHAR szFunction,
...
)
{
va_list argptr;
if(stricmp(szFunction,“INITIALIZE”)==0){
return(ss.Initialize());
}
else if(stricmp(szFunction,“TERMINATE”)==0){
return(ss.Terminate());
}
else if(stricmp(sxFunction,“INVOKE”)==0){
char* ibXml;
char** obXml;
va_start(argptr,szFunction);
ibXml=va_arg(argptr,char*);
obXml=va_arg(argptr,char**);
va_end(argptr);
return(ss.Invoke(ibXml,obXml));
}
else if(stricmp(szFunction,“FREE”)==0){
char*obj;
va_start(argptr,szFunction);
obj=va_arg(argptr,char*);
va_end(argptr);
return(ss.Free(obj));
}
return 400;
}
【００２２】
各管理機能スポンサー１６ａ〜１６ｎは、管理機能ゲートウェイ１４から１個以上のメッセージ・ペイロード（例えばＸＭＬメッセージ・ペイロード）を介して起動可能な複数の機能やメソッドを実行することができる。例えば、管理機能スポンサー１６ａ〜１６ｎは、少なくとも以下のメソッドを実行することができる。
【００２３】
「Ｄｅｓｃｒｉｂｅ」メソッドを用いて、エージェントに対し自身の情報を提供するよう求めることができる。例えば、「Ｄｅｓｃｒｉｂｅ」メソッドが管理機能ゲートウェイ１４へ送信送された場合、管理機能ゲートウェイは自身と、管理機能ゲートウェイが稼動中の機器（システム・ユニット１２ａ〜１２ｎ）に管理機能ゲートウェイに関連付けられて現在インストールされている全ての管理機能スポンサーと、管理機能ゲートウェイが稼動中の機器上で管理機能ゲートウェイが検知可能な全ての製品またはソフトウェア・ソリューションとを記述したメッセージで応答することができる。「Ｄｅｓｃｒｉｂｅ」メソッドが管理機能スポンサーへ送信された場合、管理機能スポンサーは自身を記述することができる。以下は、そのようなＤｅｓｃｒｉｂｅメソッドのコードの例である。
accepts
<Method=describe/>
returns:
<Version=string/>
<ProdInterfaceInfo=(ProdInterfaceType*)
<PlatformInfo=string/>
<CanIssueAsyncNotify=string />        (y,n)
<ReqDTDVersionID=(Version*)Version of Request
DTD this instrument sponsorsupports
<RespDTDVersionID=(Version*)Version of
Response DTD this instrumentsponsor supports
ProdInterfaceType(ProdName,Release,SubStat,
Active)
Name    CDATA Required
ReleaseCDATA Required
SubStat Number(1,0)(1=instrument
sponsorinstalled,0=instrument sponsor
not installed)
Active Number(1,0)(1=Active,
0=Inactive)
Version(VersionInfo)
VersionInfo CDATA
【００２４】
「ＡｓｙｎｃＮｏｔｉｆｙＳｅｔＤｅｓｔｉｎａｔｉｏｎ」メソッドを用いて、管理機能スポンサー１６ａ〜１６ｎに対し、非同期通知をどこへ送ればよいかを示すことができる。以下は、ＡｓｙｎｃＮｏｔｉｆｙＳｅｔＤｅｓｔｉｎａｔｉｏｎメソッド用に使用可能なコードの例である。
accepts<Method=AsyncNotifySetDestination>
<AsyncNotifySetDestinationType=string/>
(trap,http)
<AsyncNotifySetDestinationTargets=string/>
(machine namelip addr, port;machine
namelip addr, port; etc.)
<AsyncNotifySetDestinationPort=string/>(port)
returns<AsyncNotifySetDestinationStatus=string/>
(success,failure)
<AsyncNotifySetDestinationReason=string/>
(explanationfor failure)
【００２５】
「ＳｈｏｗＧｒａｍｍａｒ」メソッドを用いて、自身とインターフェースを確立する方法に関する情報を提供するようエージェントに依頼することができる。以下は、ＳｈｏｗＧｒａｍｍａｒメソッド用に使用可能なコードの例である。
accepts
<Method=ShowGrammer/>
returns:
<ResponseType=string/>    (URL,DTD,SCHEMA)
<ResponseGrammar=string/>
【００２６】
「Ｉｎｉｔ」メソッドを用いて、エージェントに開始を指示することができる。通常、このメソッドは、管理機能ゲートウェイが管理機能スポンサーにメッセージ・ペイロードをロードしている際に管理機能スポンサーへ送信することができる。以下は、Ｉｎｉｔメソッド用に使用可能なコードの例である。
accepts
<Method=Term/>
returns:
<InitStatus=string/>
【００２７】
「Ｔｅｒｍ」メソッドを用いて、システム終了するようエージェントに指示することができる。このメッセージは通常、管理機能ゲートウェイが（例えばクライアント・アプリケーションまたはシステム管理者により）管理機能スポンサーを停止させるように指示された際に、管理機能ゲートウェイから管理機能スポンサーへ送信することができる。以下は、Ｔｅｒｍメソッド用に使用可能なコードの例である。
accepts
<Method=Term/>
returns:
<InitStatus=string/>
【００２８】
「Ｃｏｎｆｉｇｕｒｅ」メソッドを用いて、管理機能スポンサーの調整可能な設定について設定や問い合わせを行なうことができる。管理機能スポンサー向けに元の設定値が設定されている場合、これらの値は関係するプラットフォーム上で当該管理機能スポンサーをそれ以降リスタートさせる際に遵守される。特徴的なのは、単一のメッセージで複数の設定がなされている場合、関係する管理機能スポンサーはこれらの設定をすべて同時に有効にすることを求められる点である。新しい設定値を設定する試みのいずれかが失敗したならば、全ての値をＣｏｎｆｉｇｕｒｅメソッドが起動される前の設定値にロールバックすることができる。以下は、Ｃｏｎｆｉｇｕｒｅメソッド用に使用可能なコードの例である。
accepts
<Method=ConfigureSub/>
<ConfigurePolarity=(ConfigPolarity*)
<ConfigureSetting=(ConfigureVariable*)
returns:
<ConfigureStatus=string/>(success,
failure)
<ConfigureStatusReason=string/>(explanation
for failure)
ConfigurePolarity(Polarity)
Polarity Number (1,0) (0=GET, 1=Set)
Polarity CDATA      (Valid valuesare get or set)
ConfigureVariable(VarName,VarValue)
VarName CDATA
VarValue CDATA
【００２９】
「Ｉｎｖｏｋｅ」メソッドを用いて、管理機能スポンサー１６ａ〜１６ｎがユーザーに代わって実行することができるサービス（例えば情報検索、ポリシー管理、動作起動等）を要求することができる。以下は、Ｉｎｖｏｋｅメソッド用に使用可能なコードの例である。
accepts
<Method=InvokeSub,InstallProd,DeinstallProd,
InitProd,TermProd,CallProd>
<method specific grammar> 
returns:
<InvokeStatus=string/>
【００３０】
「Ａｕｔｈｅｎｔｉｃａｔｅ」メソッドを用いて、管理機能スポンサー１６ａ〜１６ｎへ証明を送信して、続いてユーザー（例えばクライアント・アプリケーション２０）から送られるサービス要求を管理機能スポンサーが許可すべきか否かを判定するために認証させることができる。好適には、管理機能ゲートウェイ１４を認証するのではなく、Ａｕｔｈｅｎｔｉｃａｔｅメソッドが、管理機能ゲートウェイを介して管理機能スポンサーにサービスを提示するサービス要求元を認証することができる。要求元が認証されたならば、関係する管理機能スポンサーによりＭＡＣ  ＡｄｄｒまたはＩＰ  Ａｄｄｒ（または要求元を識別可能な他のトークン）をローカルにキャッシュまたは保存することができる。続いて、管理機能スポンサーは、ローカル・キャッシュから証明を検索し、検索された証明情報に基づいてアクセスを決定することができる。このように、管理機能ゲートウェイ１４および全てのデジタル署名されたエージェントは、管理機能スポンサー１６ａ〜１６ｎの署名を確認することができる。以下は、Ａｕｔｈｅｎｔｉｃａｔｅメソッド用に使用可能なコードの例である。
accepts
<Method=Authenticate/>
<UserID=userid string/>
<Password=password/>
returns:
<AuthenticateStatus=string/>
【００３１】
図２は、実施形態の一例を実施するために利用できる方法１００の例を示す。ステップ１０２で、クライアントまたはユーザー（例えば２０）が、特定のシステム製品またはソフトウェア・ソリューションに対するサービス要求を含むメッセージ・ペイロード（例えばＸＭＬメッセージ・ペイロード）を生成する。ステップ１０４で、クライアントまたはユーザーは、１個以上のシステム・ユニットまたは機器１２ａ〜１２ｎのポータルに関連付けられたアドレスへメッセージ・ペイロードを送信する。例えば、このアドレスは、ユーザーが指定しても、あるいは出される要求の種類に基づいて決定してもよい。
【００３２】
ステップ１０６で、サービス要求を含むメッセージ・ペイロードの受信に応答して、１個以上の管理機能ゲートウェイ１４（例えば、特定のシステム・ユニットまたは機器１２ａ〜１２ｎに関連付けられた）が、その管理機能ゲートウェイに関連付けられた管理機能スポンサー１６ａ〜１６ｎへ「Ｄｅｓｃｒｉｂｅ」メソッドを送信する。ステップ１０８で、管理機能スポンサー１２ａ〜１２ｎを介して要求に対するサービスを行なう適当なシステム製品またはソフトウェア・ソリューション（管理機能）が利用可能であるとの判定に応答して、管理機能ゲートウェイ１４は要求に対するサービスを行なう管理機能スポンサーを選択する。ステップ１１０で、選択された管理機能スポンサー１２ａ〜１２ｎは、そのシステム製品またはソフトウェア・ソリューション用の製品固有のインターフェースを介して管理機能運用レイヤ１８ａ〜１８ｎから、関連付けられたシステム製品またはソフトウェア・ソリューション（管理機能）を起動する。例えば、適当なシステム製品またはソフトウェア・ソリューションが管理機能運用レイヤに管理機能１８ａとして存在する場合、管理機能ゲートウェイ１４は、管理機能スポンサー１６ａ（例えば管理機能１８ａに直接関連付けられた）を選択して、出されたサービス要求を当該管理機能が満たすべく設計された適当なインターフェースを介して当該管理機能を起動することができる。ステップ１１２で、選択された管理機能スポンサー１６ａ〜１６ｎが、要求元へ（例えば管理機能ゲートウェイ１４を介して）サービス結果を含むメッセージ・ペイロードを送信することができる。
【００３３】
添付の図面および上述の詳細説明を通じて好適な実施形態について記載してきたが、本開示が開示された実施形態に限定されず、請求の範囲により開示および規定される本発明の概念から逸脱することなく、各種の再構成、変更、および代替が可能である点を理解されたい。
【図面の簡単な説明】
【００３４】
【図１】実施形態の一例を実施すべく利用可能なシステムの例を示す。
【図２】実施形態の一例を実施すべく利用可能な方法の例を示す。
【図１】
2005523520.tif 000003
【図２】
2005523520.tif 000004
【国際調査報告】
2005523520.tif 000005
2005523520.tif 000006
2005523520.tif 000007