(57)【要約】【課題】複数のサーバ・ソフトウェアとの通信を行うクライアント・ソフトウェアにおいて、サーバ・ソフトウェアをステートレスに保ち、かつ異なる複数のサーバ・ソフトウェアに対応できる画面表示システム、画面表示方法及びプログラムを提供する。【解決手段】サーバ１３０は、１以上の機能と、機能に対応するメタ情報と、を関連付けて保持するメタ情報記憶部１３２、１以上のメタ情報と、ウィザードの画面構成を示すウィザード情報と、を関連づけて保持するウィザード情報記憶部１３３を有する。クライアント１００は、メタ情報記憶部１３２から、実行すべき機能に関連付けられたメタ情報を取得する機能呼出部１１１、ウィザード情報記憶部１３２から、メタ情報に関連付けられたウィザード情報を取得するウィザード取得部１１４、ウィザード情報に基づき、ウィザードの画面を生成する画面遷移管理部１１３を有する。【選択図】図１
2014178856.tif 000002
【特許請求の範囲】
【請求項１】
クライアントがサーバと通信を行って、所定の機能を実行するための、複数の画面からなるウィザードを生成する画面表示システムであって、
前記サーバは、
１以上の機能と、前記機能に対応するメタ情報と、を関連付けて保持するメタ情報記憶部と、
１以上の前記メタ情報と、前記ウィザードの画面構成を示すウィザード情報と、を関連づけて保持するウィザード情報記憶部と、を有し、
前記クライアントは、
前記メタ情報記憶部から、実行すべき機能に関連付けられた前記メタ情報を取得する機能呼出部と、
前記ウィザード情報記憶部から、前記メタ情報に関連付けられた前記ウィザード情報を取得するウィザード取得部と、
前記ウィザード情報に基づき、前記ウィザードの前記画面を生成する画面遷移管理部と、を有する
画面表示システム。
【請求項２】
クライアントが、サーバ及び前記サーバから独立したリポジトリと通信を行って、所定の機能を実行するための、複数の画面からなるウィザードを生成する画面表示システムであって、
前記サーバは、
１以上の機能と、前記機能に対応するメタ情報と、を関連付けて保持するメタ情報記憶部を有し、
前記リポジトリは、
１以上の前記メタ情報と、前記ウィザードの画面構成を示すウィザード情報と、を関連づけて保持するウィザード情報記憶部を有し、
前記クライアントは、
前記メタ情報記憶部から、実行すべき機能に関連付けられた前記メタ情報を取得する機能呼出部と、
前記ウィザード情報記憶部から、前記メタ情報に関連付けられた前記ウィザード情報を取得するウィザード取得部と、
前記ウィザード情報に基づき、前記ウィザードの前記画面を生成する画面遷移管理部と、を有する
画面表示システム。
【請求項３】
前記クライアントはさらに、
前記メタ情報に基づき、前記実行すべき機能にかかる前記ウィザードを生成すべきか否かを判別する判別部を有し、
前記ウィザード取得部は、前記ウィザードを生成すべき場合に、前記ウィザード情報記憶部から、前記メタ情報に関連付けられた前記ウィザード情報を取得する
請求項１又は２記載の画面表示システム。
【請求項４】
前記クライアントはさらに、
前記画面遷移管理部が生成した前記ウィザードの前記画面を表示するとともに、表示した前記画面に入力された入力情報を、前記サーバに送信する画面表示部を有し、
前記サーバはさらに、
前記入力情報に基づき、前記実行すべき機能を実行する管理機能実行部を有する
請求項１乃至３いずれか１項記載の画面表示システム。
【請求項５】
前記画面表示システムは、ＪＭＸ（Ｊａｖａ  Ｍａｎａｇｅｍｅｎｔ  Ｅｘｔｅｎｓｉｏｎｓ）プラットフォームを利用して形成され、
前記機能はＭＢｅａｎのオペレーションであり、
前記メタ情報はＭＢｅａｎＯｐｅｒａｔｉｏｎＩｎｆｏである
請求項１乃至４いずれか１項記載の画面表示システム。
【請求項６】
前記判別部は、ＭＢｅａｎＯｐｅｒａｔｉｏｎＩｎｆｏに特定のフィールドが存在するか否かを検査することにより、前記ウィザードを生成すべきか否かを判別する
請求項３記載の画面表示システム。
【請求項７】
前記画面遷移管理部は、ＭＢｅａｎＯｐｅｒａｔｉｏｎＩｎｆｏの前記特定のフィールドに関連付けられたＭＢｅａｎＩｎｆｏの配列を取得し、各ＭＢｅａｎＩｎｆｏに基づいて、前記ウィザードを構成する１つの前記画面を生成する
請求項１乃至６いずれか１項記載の画面表示システム。
【請求項８】
クライアントが、
サーバのメタ情報記憶部から、実行すべき機能に関連付けられたメタ情報を取得する機能呼出ステップと、
サーバのウィザード情報記憶部から、前記メタ情報に関連付けられたウィザード情報を取得するウィザード取得ステップと、
前記ウィザード情報に基づき、ウィザードの画面を生成する画面遷移管理ステップと、を有する
画面表示方法。
【請求項９】
クライアントが、
サーバのメタ情報記憶部から、実行すべき機能に関連付けられたメタ情報を取得する機能呼出ステップと、
前記サーバから独立したリポジトリのウィザード情報記憶部から、前記メタ情報に関連付けられたウィザード情報を取得するウィザード取得ステップと、
前記ウィザード情報に基づき、ウィザードの画面を生成する画面遷移管理ステップと、を有する
画面表示方法。
【請求項１０】
請求項８又は９記載の画面表示方法を、クライアント・コンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画面表示システム、画面表示方法及びプログラムに関し、例えば複数のサーバ・ソフトウェアとの通信を行うクライアント・ソフトウェアにおいて画面を表示する技術に関する。
【背景技術】
【０００２】
クライアント・サーバ型のコンピュータシステムにおいては、サーバ・ソフトウェアとクライアント・ソフトウェアとが通信を行うことにより、所定の情報処理を実行する。
【０００３】
多くのクライアント・ソフトウェアは、ユーザに対する画面表示、ユーザによる画面上での入力、及び画面遷移等を含む対話型ソフトウェアである。このようなクライアント・ソフトウェアにおける表示画面の生成方法としては、従来より以下の２つの方法が知られている（特許文献１、特許文献２）。
【０００４】
１つの方法は、サーバ・ソフトウェアが表示画面の生成、画面遷移の管理を行うものである。言い換えると、クライアント・ソフトウェアの画面表示や画面遷移に関して、サーバ・ソフトウェアがステートフルとなる。この場合、クライアント・ソフトウェア、例えばウェブブラウザ等は、サーバ・ソフトウェアが生成する画面を表示するだけで良いため、様々な異なる種類のサーバ・ソフトウェアに特段の工夫を要せず対応できるという利点がある。一方、サーバ・ソフトウェア側に高負荷や通信障害等の事象が発生すると、クライアント・ソフトウェア側において画面表示や画面遷移が正常に行えなくなるという欠点がある。
【０００５】
他の方法は、クライアント・ソフトウェアが表示画面の生成、画面遷移の管理を行うものである。この場合、サーバ・ソフトウェア側では画面生成や画面遷移の管理のための負荷が発生せず、またクライアント・ソフトウェア側ではサーバ・ソフトウェア側の障害等に影響されることなく画面生成や画面遷移の管理が行えるという利点がある。一方、クライアント・ソフトウェア側では、サーバ・ソフトウェア側の仕様に適合させて、生成画面及び画面遷移を設計、実装する必要があるため、様々な異なる種類のサーバ・ソフトウェアに対応することが困難であるという欠点がある。とりわけ、クライアント・ソフトウェアの設計方針や、クライアント・ソフトウェアを動作させている環境の運用管理方針等によっては、クライアント・ソフトウェアを新たな種類のサーバ・ソフトウェアに対応するための追加モジュール等の導入を容易に実施できないという実態がある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平１１−２８２６５８号公報
【特許文献２】特開２００７−２７９９７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述の問題は、近年広く利用されているクラウド・コンピューティング等において特に顕著となる。クラウド・コンピューティングにおいては、例えば数百台のサーバ・コンピュータ上で、様々なサーバ・ソフトウェアが動作している。クラウド・コンピューティング・システムの管理者は、このような多数のサーバ・コンピュータで動作するサーバ・ソフトウェアを管理しなければならない。
【０００８】
複数のサーバ・ソフトウェアの管理においては、一般に、これらのサーバ・ソフトウェアを少なくとも１つのクライアントから統一的に管理できる、管理ソフトウェアというクライアント・ソフトウェアが利用される。管理者は、管理ソフトウェアが表示する画面を操作することによって、管理対象のサーバ・ソフトウェアに対して設定の変更を行ったり、所定の機能の実行を指示することができる。特に、入力項目が多い複雑な機能を実行すべき場合、管理ソフトでは、複数画面を遷移しながら情報を入力していくウィザードと呼ばれるユーザ・インタフェースが利用されることが一般的である。
【０００９】
ところが、複数の異なるサーバで利用されているサーバ・ソフトウェアに複数の異なるバージョンが存在する場合等においては、ウィザードが取り扱うべき入力項目も、サーバ・ソフトウェアにより異なることがある。また、あるバージョンのサーバ・ソフトウェアは、そもそも管理ソフトウェアのウィザードに対応する機能そのものを有していないこともある。
【００１０】
そのため、現実には、複数のサーバ・ソフトウェアを、ただ１つの管理ソフトウェアで管理することは困難であった。すなわち、複数のサーバ・ソフトウェアの全てが一定の機能や設定項目を有していることを前提として、管理ソフトウェアのウィザード等を作り込むことはできなかった。
【００１１】
このような問題に対し、従来提案されてきた解決策が上述の２つの方法、すなわち（１）サーバ・ソフトウェアで画面生成と画面遷移を実施する方法、及び（２）クライアント・ソフトウェアで画面生成と画面遷移を実施する方法である。これらの２つの方法について、特に画面にウィザードを含む場合を例として、改めて説明する。
【００１２】
（１）サーバ・ソフトウェアで画面生成と画面遷移を実施
サーバ・ソフトウェアが、クライアント・ソフトウェアが画面を表示するために必要な情報を生成する。クライアント・ソフトウェアは、基本的にサーバ・ソフトウェアから画面を表示するために必要な情報を取得して、画面を表示装置に出力するだけで良い。
【００１３】
クライアント・ソフトウェアがウィザードを含む場合、クライアント・ソフトウェアはまず、ウィザードの特定の画面を表示する。ユーザは、この画面に対して必要な情報を入力する。入力が完了し、「次へ」「完了」ボタン等が押下されると、クライアント・ソフトウェアはサーバ・ソフトウェアに対して入力された情報を転送するとともに、次の画面を要求する。サーバ・ソフトウェアはクライアント・ソフトウェアからのこの情報及び要求に応じて、ウィザードの次画面を表示させるために必要な情報を生成し、クライアント・ソフトウェアに送信する。
【００１４】
クライアント・ソフトウェアは、画面の表示、情報の入力、サーバ・ソフトウェアとの通信機能だけを備えていればよい。入力項目の内容が異なるなど、仕様の異なる別のサーバ・ソフトウェアの管理を行いたい場合には、クライアント・ソフトウェアは単に接続先のサーバ・ソフトウェアを変更すればよい。
【００１５】
この方法の典型的な実装例は、Ｗｅｂアプリケーションとして実装された管理ソフトウェアである。この管理ソフトウェアは、クライアント側でＷｅｂブラウザ上で動作する。管理ソフトウェアとしてのＷｅｂブラウザは、サーバ・ソフトウェアとしてのＷｅｂサーバに対して、画面を表示するために必要な情報であるＨＴＭＬを要求し、返送されてきたＨＴＭＬに基づいて画面表示を行う。管理ソフトウェアのユーザが、その画面に表示された入力フォームに従って情報を入力し、「次へ」ボタン等を押下すると、ＷｅｂブラウザはＷｅｂサーバに対し入力情報の送信及び次画面の要求を行う。Ｗｅｂサーバは、受信した入力情報等に基づいて、サーバ・ソフトウェアの機能の実行や設定の変更を実施し、次画面を表示するために必要な情報であるＨＴＭＬを生成し、生成したＨＴＭＬをクライアント・ソフトウェアに返信する。Ｗｅｂブラウザが異なるサーバを管理したい場合は、単に接続先のサーバ・ソフトウェアのＵＲＩを変更すればよい。
【００１６】
（２）クライアント・ソフトウェアで画面生成と画面遷移を実施
クライアント・ソフトウェアが、複数の異なるサーバ・ソフトウェアにそれぞれ対応する複数のモジュールを搭載する。各モジュールは、サーバ・ソフトウェアの仕様に応じた、クライアント・ソフトウェアにおける画面生成及び画面遷移を実施する。モジュールは、クライアント・ソフトウェアの一部として固定的に搭載するか、プラグインとしてクライアント・ソフトウェアに動的に搭載することができる。
【００１７】
クライアント・ソフトウェアは、あるサーバ・ソフトウェアを管理するために必要な、画面生成と画面遷移に関わる全ての情報を予め保持している。そのため、ウィザード実行中はサーバ・ソフトウェアと通信する必要はなく、必要な入力情報が全て揃った段階でサーバ・ソフトウェアに対して一度に情報を送信することができる。サーバ・ソフトウェアは、クライアント・ソフトウェアにおけるウィザードの実行には一切関わらず、単に最終的な入力情報をクライアント・ソフトウェアから受信するだけでよい。
【００１８】
しかしながら、（１）の方法では、サーバ・ソフトウェア側に高負荷や通信障害等の事象が発生すると、クライアント・ソフトウェア側において画面表示や画面遷移が正常に行えなくなるという問題があった。
【００１９】
一方、（２）の方法では、クライアント・ソフトウェア側は、サーバ・ソフトウェアの仕様に応じた複数のモジュールを開発、搭載する必要があるが、クライアント・ソフトウェアの設計方針や、クライアント・ソフトウェアを動作させている環境の運用管理方針等によっては、モジュールの導入を容易に実施できないという問題がある。
【００２０】
本発明は、このような問題点を解決するためになされたものであり、複数のサーバ・ソフトウェアとの通信を行うクライアント・ソフトウェアにおいて、サーバ・ソフトウェアをステートレスに保ち、かつ異なる複数のサーバ・ソフトウェアに対応できる画面表示システム、画面表示方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００２１】
本発明に係る画面表示システムは、  クライアントがサーバと通信を行って、所定の機能を実行するための、複数の画面からなるウィザードを生成する画面表示システムであって、前記サーバは、１以上の機能と、前記機能に対応するメタ情報と、を関連付けて保持するメタ情報記憶部と、１以上の前記メタ情報と、前記ウィザードの画面構成を示すウィザード情報と、を関連づけて保持するウィザード情報記憶部と、を有し、前記クライアントは、前記メタ情報記憶部から、実行すべき機能に関連付けられた前記メタ情報を取得する機能呼出部と、前記ウィザード情報記憶部から、前記メタ情報に関連付けられた前記ウィザード情報を取得するウィザード取得部と、前記ウィザード情報に基づき、前記ウィザードの前記画面を生成する画面遷移管理部と、を有するものである。
【００２２】
本発明に係る他の画面表示システムは、クライアントが、サーバ及び前記サーバから独立したリポジトリと通信を行って、所定の機能を実行するための、複数の画面からなるウィザードを生成する画面表示システムであって、前記サーバは、１以上の機能と、前記機能に対応するメタ情報と、を関連付けて保持するメタ情報記憶部を有し、前記リポジトリは、１以上の前記メタ情報と、前記ウィザードの画面構成を示すウィザード情報と、を関連づけて保持するウィザード情報記憶部を有し、前記クライアントは、前記メタ情報記憶部から、実行すべき機能に関連付けられた前記メタ情報を取得する機能呼出部と、前記ウィザード情報記憶部から、前記メタ情報に関連付けられた前記ウィザード情報を取得するウィザード取得部と、前記ウィザード情報に基づき、前記ウィザードの前記画面を生成する画面遷移管理部と、を有するものである。
【００２３】
本発明に係る画面表示方法は、クライアントが、サーバのメタ情報記憶部から、実行すべき機能に関連付けられたメタ情報を取得する機能呼出ステップと、サーバのウィザード情報記憶部から、前記メタ情報に関連付けられたウィザード情報を取得するウィザード取得ステップと、前記ウィザード情報に基づき、ウィザードの画面を生成する画面遷移管理ステップと、を有するものである。
【００２４】
本発明に係る他の画面表示方法は、クライアントが、サーバのメタ情報記憶部から、実行すべき機能に関連付けられたメタ情報を取得する機能呼出ステップと、前記サーバから独立したリポジトリのウィザード情報記憶部から、前記メタ情報に関連付けられたウィザード情報を取得するウィザード取得ステップと、前記ウィザード情報に基づき、ウィザードの画面を生成する画面遷移管理ステップと、を有するものである。
【００２５】
本発明に係るプログラムは、上記いずれかの画面表示方法を、クライアント・コンピュータに実行させるためのプログラムである。
【発明の効果】
【００２６】
本発明により、複数のサーバ・ソフトウェアとの通信を行うクライアント・ソフトウェアにおいて、サーバ・ソフトウェアをステートレスに保ち、かつ異なる複数のサーバ・ソフトウェアに対応できる画面表示システム、画面表示方法及びプログラムを提供することができる。
【図面の簡単な説明】
【００２７】
【図１】本発明の実施の形態１の画面表示システム１０００の構成を示す図である。
【図２】本発明の実施の形態１の画面表示システム１０００におけるメタ情報の例を示す図である。
【図３】本発明の実施の形態１の画面表示システム１０００の処理を示す図である。
【図４】本発明の実施の形態２の画面表示システム２０００の構成を示す図である。
【図５】本発明の実施の形態２の画面表示システム２０００の処理を示す図である。
【発明を実施するための形態】
【００２８】
以下、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
【００２９】
＜実施の形態１＞
まず、図１を用いて、本発明の実施の形態１にかかる画面表示システム１０００の構成について説明する。
【００３０】
画面表示システム１０００は、クライアント・システム１００、サーバ・システム１３０を含む。クライアント・システム１００とサーバ・システム１３０とは、ネットワーク１４０を介して通信可能に接続される。
【００３１】
クライアント・システム１００及びサーバ・システム１３０は、それぞれ図示しない記憶手段に格納されたクライアント・ソフトウェア及びサーバ・ソフトウェアに基づいて、各種制御を実行する機能を有する装置であり、典型的には中央演算処理装置（ＣＰＵ）、揮発性及び不揮性用メモリ、入出力ポート等を備えるコンピュータである。
【００３２】
クライアント・システム１００は、管理機能呼出モジュール１１１、ウィザード有無判別モジュール１１２、画面遷移管理モジュール１１３、ウィザード画面取得モジュール１１４、画面表示モジュール１２０を有する。クライアント・システム１００は、サーバ・システム１３０から、画面を表示するために必要な情報（以下、画面情報）と、画面の表示順序と、を取得して、複数の画面からなるウィザードを表示する。また、ユーザがウィザードに入力した情報を、サーバ・システム１３０に送信する。
【００３３】
サーバ・システム１３０は、管理機能実行モジュール１３１、管理機能メタ情報記憶部１３２、ウィザード情報記憶部１３３を含む。サーバ・システム１３０は、クライアント・システム１００からの管理機能の呼出し、管理機能のメタ情報の取得、及びウィザード情報の取得のリクエストを受け付け、必要な情報をクライアント・システム１００に送信する。
【００３４】
ネットワーク１４０は、クライアント・システム１００とサーバ・システム１３０とが通信するための通信路であり、例えばインターネットやイントラネットである。
【００３５】
つぎに、図３のフローチャートを用いて、実施の形態１にかかる画面表示システム１０００の動作について説明する。
【００３６】
Ｓ３００：クライアント・システム１００が動作を開始する。例えば、ユーザがマウスやキーボード等の入力装置により、管理機能の実行の指示を入力したことをトリガとして、動作を開始する。
【００３７】
Ｓ３０１：クライアント・システム１００は、ネットワーク１４０を介してサーバ・システム１３０に接続する。クライアント・システム１００の管理機能呼出モジュール１１１は、サーバ・システム１３０に対し、実行したい管理機能のメタ情報の取得を要求する。サーバ・システム１３０は、管理機能メタ情報記憶部１３２に格納されているメタ情報を、管理機能呼出モジュール１１１に送信する。
【００３８】
ここで、管理機能のメタ情報とは、画面表示システム１０００が管理機能を管理する際に利用可能な情報であって、管理機能に関連付けられた付加的な情報を言う。例えば、管理機能が機能Ａと機能Ｂとを有しているとき、機能Ａは「難易度」が「易しい」、機能Ｂは「難易度」が「難しい」といった情報を、メタ情報として保持することができる。これにより、画面表示システム１０００、例えばユーザが初心者であれば機能Ａのみを表示し、上級者であれば機能Ａと機能Ｂを表示する等の制御を行うことができるようになる。
【００３９】
Ｓ３０１の処理を具体例を用いて説明する。例えば、画面表示システム１０００が、Ｊａｖａ（登録商標）を基盤とするＪＭＸ（Ｊａｖａ  Ｍａｎａｇｅｍｅｎｔ  Ｅｘｔｅｎｓｉｏｎｓ）プラットフォームを使用してウィザードを実現するシステムであるものとする。なお、ＪＭＸは、ＪＳＲ（Ｊａｖａ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ）により規定されている標準技術である。
【００４０】
クライアント・システム１００としてのクライアント・システムは、ある管理機能すなわちＭＢｅａｎのオペレーションを呼び出したい場合、サーバ・システム１３０としてのサーバ・システムに対し、ＭＢｅａｎのオペレーションのメタ情報である、ＭＢｅａｎＯｐｅｒａｔｉｏｎＩｎｆｏオブジェクトの取得を要求する。サーバ・システムは、上記要求に応じ、クライアント・システムに、管理機能のメタ情報としての上記オブジェクトを送信する。ＭＢｅａｎＯｐｅｒａｔｉｏｎＩｎｆｏには、例えば以下のようなメタ情報が含まれる。
・オペレーション（機能）の名前等の基本情報
・オペレーションを利用者に見せるかどうか
・オペレーション呼出時の引数のデフォルト値
・オペレーションを呼出した時にシステムの状態を変更するかどうか
【００４１】
なお、ＭＢｅａｎＯｐｅｒａｔｉｏｎＩｎｆｏは、ＭＢｅａｎのメタ情報の保持単位であるＭＢｅａｎＩｎｆｏに内包される。
【００４２】
Ｓ３０２：クライアント・システム１００のウィザード有無判別モジュール１１２は、取得したメタ情報に基づき、実行したい管理機能に関連付けられているウィザードがあるか否かを判定する。
【００４３】
具体例を用いて説明する。クライアント・システムは、取得したＭＢｅａｎＯｐｅｒａｔｉｏｎＩｎｆｏに、フィールドｗｉｚａｒｄが存在するか否かを確認する。
【００４４】
なお、フィールドとは、ＭＢｅａｎのメタ情報であるＭＢｅａｎＩｎｆｏをさらに修飾するメタ情報であり、ＭＢｅａｎＩｎｆｏの任意の構成要素に付与することができる。ＭＢｅａｎＩｎｆｏとフィールドとの関係を、図２に示す。
【００４５】
Ｓ３０３：管理機能に関連付けられているウィザードが存在する場合、ウィザード情報取得モジュール１１４が、サーバ・システム１３０に対し、ウィザード情報を要求する。サーバ・システム１３０は、ウィザード情報記憶部１３３に格納されているウィザード情報を、ウィザード情報取得モジュール１１４に送信する。
【００４６】
具体例を用いて説明する。クライアント・システムは、フィールドｗｉｚａｒｄが存在する場合、ｗｉｚａｒｄの値が、ウィザード画面情報を取得するオペレーションであるとみなす。クライアント・システムは、ｗｉｚａｒｄの値にあたるオペレーションの呼出しを実施する。この呼出しにより取得できるのは、ウィザード情報としてのＯｂｊｅｃｔＮａｍｅの配列、すなわち管理対象を示すＩＤの配列である。ここで、各々のＯｂｊｅｃｔＮａｍｅは、ウィザードを構成する１画面に相当する。
【００４７】
Ｓ３０４：ウィザード情報の取得が完了した場合、又は管理機能に関連付けられているウィザードが存在しない場合、画面遷移管理モジュール１１３は、以下の手順により、表示すべき画面を決定する。
【００４８】
ウィザード情報の取得が行われている場合、画面遷移管理モジュール１１３は、取得したウィザード情報に基づいて表示すべき画面を決定する。
【００４９】
具体例を用いて説明する。ウィザード情報としてのＯｂｊｅｃｔＮａｍｅの配列の取得が行われている場合、クライアント・システムは、各々のＯｂｊｅｃｔＮａｍｅに対応するＭＢｅａｎＩｎｆｏを取得する。ここで、各々のＭｂｅａｎＩｎｆｏが持つ属性が、各々のウィザード画面における入力項目に相当する。よって、クライアント・システムは、これらの入力項目を有する入力画面を生成する。
【００５０】
一方、管理機能に関連付けられているウィザードが存在しない場合、画面遷移管理モジュール１１３は、管理機能のメタ情報を元に、管理機能に引き渡すべき引数を特定し、当該引数を入力するための入力項目を有する入力画面を生成する。
【００５１】
Ｓ３０５：画面遷移管理モジュール１１３は、表示すべき画面があるか否かを判定する。ウィザード情報の取得が行われているならば、画面遷移管理モジュール１１３は、ウィザードに含まれる画面を順次生成し、表示させる制御を行う。具体的には、ＯｂｊｅｃｔＮａｍｅの配列と同じ順序で、ウィザード画面を表示させる。ウィザードを構成する全ての画面の表示が終了したならば、Ｓ３０７に遷移する。一方、ウィザードが存在しないならば、生成した入力画面を表示させる制御を行う。
【００５２】
Ｓ３０６：画面表示モジュール１２０は、表示すべき画面を表示する。画面には、ユーザから入力項目に係る情報を収集するための入力欄が設けられる。画面表示モジュール１２０は、ユーザが入力した情報を保持する。
【００５３】
Ｓ３０７：表示すべき全ての画面の表示が終了したならば、管理機能呼出モジュール１１１が、Ｓ３０６において収集された情報を引数として、管理機能を呼び出す。すなわち、管理機能実行モジュール１３１に対し、管理機能の呼出しを要求する。
【００５４】
具体的には、クライアント・システムは、キー（入力項目名）と値（ユーザによる入力値）との組み合わせを引数として、実行したい管理機能にあたるＭＢｅａｎのオペレーションを呼び出す。つまり、呼出されるオペレーションの引数は、ｊａｖａ．ｕｔｉｌ．Ｐｒｏｐｅｒｔｉｅｓやｊａｖａ．ｕｔｉｌ．Ｍａｐを実装するクラスに限定される。
【００５５】
Ｓ３０８：管理機能実行モジュール１３１が、上記引数を用いて、要求された管理機能を実行する。
【００５６】
本実施の形態においては、クライアント・システム１００が、実行したい管理機能のウィザード情報をサーバ・システム１３０より取得し、そのウィザード情報に応じてウィザード画面を生成する。すなわち、ウィザード画面の生成をクライアント・システム１００が行うため、サーバ・システム１３０をステートレスに保つことができる。また、クライアント・システム１００は、ウィザード画面の入力項目が異なる複数のサーバ・システム１００に対応することができる。
【００５７】
＜実施の形態２＞
実施の形態１では、呼び出し先の管理機能にあたるＭＢｅａｎと、そのＭＢｅａｎにかかるウィザード画面情報の取得先と、が同一の場合における本発明の実施例を示した。一方、実施の形態２では、呼び出し先の管理機能にあたるＭＢｅａｎと、そのＭＢｅａｎにかかるウィザード画面情報の取得先と、が異なる場合における実施例を示す。なお、実施の形態２については、実施の形態１と異なる部分について主に説明する。特に説明しない部分については、実施の形態１と同様であるものとする。
【００５８】
図４を用いて、実施の形態２にかかる画面表示システム２０００の構成について説明する。
【００５９】
画面表示システム２０００は、クライアント・システム１００、サーバ・システム４３０、及びリポジトリ４５０を含む。クライアント・システム１００は、サーバ・システム４３０及びリポジトリ４５０と、それぞれネットワーク１４０を介して通信可能に接続される。
【００６０】
サーバ・システム４３０は、実施の形態１のサーバ・システム１３０と同様のハードウェア構成を備えるが、その制御は後述のようにサーバ・システム１３０とは異なる。リポジトリ４５０は、図示しない記憶手段に格納された制御プログラムに基づいて、各種制御を実行する機能を有する装置であり、典型的には中央演算処理装置（ＣＰＵ）、揮発性及び不揮性用メモリ、入出力ポート等を備えるコンピュータである。
【００６１】
実施の形態２において、サーバ・システム４３０は、管理機能呼出モジュール１３１、管理機能メタ情報記憶部１３２を有する。サーバ・システム４３０は、クライアント・システム１００からの管理機能の呼出し、管理機能のメタ情報の取得のリクエストを受け付け、必要な情報をクライアント・システム１００に送信する。
【００６２】
リポジトリ４５０は、ウィザード情報記憶部４５１を有する。リポジトリは、クライアント・システム１００からのウィザード情報の取得のリクエストを受け付け、必要な情報をクライアント・システム１００に送信する。
【００６３】
つづいて、図５を用いて、画面表示システム２０００の動作について説明する。
【００６４】
Ｓ６００：Ｓ３００と同様に、クライアント・システム１００が動作を開始する。
【００６５】
Ｓ６０１：Ｓ３０１と同様に、クライアント・システム１００は、ネットワーク１４０を介してサーバ・システム４３０に接続する。クライアント・システム１００の管理機能呼出モジュール１１１は、サーバ・システム４３０に対し、実行したい管理機能のメタ情報の取得を要求する。サーバ・システム４３０は、管理機能メタ情報記憶部４３２に格納されているメタ情報を、管理機能呼出モジュール１１１に送信する。
【００６６】
Ｓ６０２：Ｓ３０２と同様に、クライアント・システム１００のウィザード有無判別モジュール１１２は、取得したメタ情報に基づき、実行したい管理機能に関連付けられているウィザードがあるか否かを判定する。
【００６７】
Ｓ６０３：管理機能に関連付けられているウィザードが存在する場合、ウィザード情報取得モジュール１１４は、リポジトリ４５０に対し、ウィザード情報を要求する。リポジトリ４５０は、ウィザード情報記憶部４５１に格納されているウィザード情報を、ウィザード情報取得モジュール１１４に送信する。
【００６８】
具体例を用いて説明する。クライアント・システムは、Ｓ６０２で取得したメタ情報すなわちＭＢｅａｎＯｐｅｒａｔｉｏｎＩｎｆｏにフィールドｗｉｚａｒｄが存在する場合、ｗｉｚａｒｄの値を、ウィザード画面情報を取得するオペレーションとみなす。クライアント・システムは、ｗｉｚａｒｄの値にあたるオペレーションの呼出しを実施する。この際の呼び出し先は、リポジトリ４５０である。
【００６９】
Ｓ６０４：Ｓ３０４と同様に、ウィザード情報の取得が完了した場合、又は管理機能に関連付けられているウィザードが存在しない場合、画面遷移管理モジュール１１３は、以下の手順により、表示すべき画面を決定する。
【００７０】
ウィザード情報の取得が行われている場合、画面遷移管理モジュール１１３は、取得したウィザード情報に基づいて表示すべき画面を決定する。
【００７１】
一方、管理機能に関連付けられているウィザードが存在しない場合、画面遷移管理モジュール１１３は、管理機能のメタ情報を元に、管理機能に引き渡すべき引数を特定し、当該引数を入力するための入力項目を有する入力画面を生成する。
【００７２】
Ｓ６０５：Ｓ３０５と同様に、画面遷移管理モジュール１１３は、表示すべき画面があるか否かを判定する。ウィザード情報の取得が行われているならば、画面遷移管理モジュール１１３は、ウィザードに含まれる画面を順次生成し、表示させる制御を行う。ウィザードを構成する全ての画面の表示が終了したならば、Ｓ３０７に遷移する。一方、ウィザードが存在しないならば、生成した入力画面を表示させる制御を行う。
【００７３】
Ｓ６０６：Ｓ３０６と同様に、画面表示モジュール１２０は、表示すべき画面を表示する。画面には、ユーザから入力項目に係る情報を収集するための入力欄が設けられる。画面表示モジュール１２０は、ユーザが入力した情報を保持する。
【００７４】
Ｓ６０７：Ｓ３０７と同様に、表示すべき全ての画面の表示が終了したならば、管理機能呼出モジュール１１１が、Ｓ６０６において収集された情報を引数として、管理機能を呼び出す。すなわち、管理機能実行モジュール４３１に対し、管理機能の呼出しを要求する。
【００７５】
Ｓ６０８：Ｓ３０８と同様に、管理機能実行モジュール４３１が、上記引数を用いて、要求された管理機能を実行する。
【００７６】
本実施の形態においては、ウィザード情報記憶部４５１が、サーバ・システム４３０とは分離されたリポジトリ４５０に配される。これにより、管理対象のサーバ・システムと、そのメタ情報とを分離できる。そのため、サーバ・システムのソフトウェアを更新せずに、つまり機能には手を加えずに、管理方法や運用方法を変更する事ができる。
【００７７】
また、複数の異なるサーバ・システムのメタ情報、すなわちウィザード情報記憶部４５１を、１つのリポジトリ４５０で一元管理する事が可能である。これにより、複数のサーバ・システムの運用管理ポリシーの統一が容易になる。
【００７８】
＜その他の実施の形態＞
なお、本発明は上述した実施の形態のみに限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。
【００７９】
例えば、上述の実施の形態においては、クライアント・システム１００、サーバ・システム１３０及び４３０、リポジトリ４５０は、いずれも独立したハードウェアを有するものとして説明したが、必ずしもそうである必要はない。これらの要素のうち複数の要素が、同一のハードウェアを用いて、論理的に別個に実現されていても良い。また、少なくとも一つの要素が、複数のコンピュータ上で動作する１つの論理的な実行主体として実現されていても良い。
【００８０】
また、上述の実施の形態では、本発明を主にハードウェアの構成として説明したが、これに限定されるものではなく、任意の処理を、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）にコンピュータプログラムを実行させることにより実現することも可能である。この場合、コンピュータプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ  ｓｔｏｒａｇｅ  ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【符号の説明】
【００８１】
１０００  画面表示システム
１００  クライアント・システム
１１１  管理機能呼出モジュール
１１２  ウィザード有無判別モジュール
１１３  画面遷移管理モジュール
１１４  ウィザード画面取得モジュール
１２０  画面表示モジュール
１３０  サーバ・システム
１３１  管理機能実行モジュール
１３２  管理機能メタ情報記憶部
１３３  ウィザード情報記憶部
２０００  画面表示システム
４３０  サーバ・システム
４３１  管理機能実行モジュール
４３２  管理機能メタ情報記憶部
４５０  リポジトリ
４５１  ウィザード情報記憶部
【図１】
2014178856.tif 000003
【図２】
2014178856.tif 000004
【図３】
2014178856.tif 000005
【図４】
2014178856.tif 000006
【図５】
2014178856.tif 000007