ＷｅｂＡＰＩサーバプログラム、ＷｅｂＡＰＩ公開方法
【課題】ＯＳＧｉバンドルが備える機能をＷｅｂＡＰＩ経由で容易に公開することのできる技術を提供する。
【解決手段】本発明に係るＷｅｂＡＰＩサーバプログラムは、ＯＳＧｉフレームワーク上に登録されているＯＳＧｉバンドル（ＯＳＧｉサービス）のクラス名とメソッド名をＨＴＴＰリクエストとして受け取り、これらに合致するＯＳＧｉバンドル（ＯＳＧｉサービス）を呼び出して実行し、その結果をＨＴＴＰレスポンスとして返信する。
【解決手段】本発明に係るＷｅｂＡＰＩサーバプログラムは、ＯＳＧｉフレームワーク上に登録されているＯＳＧｉバンドル（ＯＳＧｉサービス）のクラス名とメソッド名をＨＴＴＰリクエストとして受け取り、これらに合致するＯＳＧｉバンドル（ＯＳＧｉサービス）を呼び出して実行し、その結果をＨＴＴＰレスポンスとして返信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＯＳＧｉフレームワーク仕様に対応したＯＳＧｉバンドルをＷｅｂＡＰＩ経由で公開する技術に関するものである。
【背景技術】
【０００２】
図１は、ＯＳＧｉフレームワークの構成を示す図である。ＯＳＧｉフレームワークとは、Ｊａｖａ（登録商標）Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ上で動作し、ＪａｖａプログラムをＰｌｕｇｉｎモジュールとして取り扱い、動的にアプリケーションへ追加できるようにする、サービスプラットフォームである。ＯＳＧｉフレームワークは、ＯＳＧｉ Ａｌｌｉａｎｃｅによって開発・定義されている（非特許文献１）。
【０００３】
図１において、ＯＳＧｉフレームワーク１３は、ホスト１０上で動作するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）１１およびその配下で動作するＪａｖａＶＭ１２上のＪａｖａアプリケーションとして実装されている。ＯＳＧｉフレームワーク１３は、Ｊａｖａモジュールの提供するサービスをＯＳＧｉプラットフォーム１３上に登録するためのインターフェースである、サービスレジストリ１３１を公開している。ＯＳＧｉフレームワーク仕様に準拠し、ＯＳＧｉフレームワーク１３に登録することができるよう（ＯＳＧｉフレームワーク上で動作するよう）に構成されているＪａｖａモジュールのことを、ＯＳＧｉバンドルと呼ぶ。ＯＳＧｉバンドルの実体は、Ｊａｖａクラス（Ｊａｖａクラス群 or Ｊａｖａパッケージ or 複数のＪａｖａクラスから成るＪａｖａパッケージ）および関連する設定ファイル等である。また、ＯＳＧｉバンドルの提供するサービスのことをＯＳＧｉサービスと呼ぶ。ＯＳＧｉサービスの実体は、Ｊａｖａクラスである。
【０００４】
例えば、ＯＳＧｉフレームワーク１３上でＯＳＧｉバンドルＡ１４が既に動作していると仮定する。ＪａｖａＶＭ１２は、ＯＳＧｉフレームワーク１３を利用することにより、ＯＳＧｉバンドルＡ１４と連携して動作するＯＳＧｉバンドルＢ１５を、ＯＳＧｉバンドルＡ１４を再起動することなくアプリケーション上に追加することができる。
【０００５】
ここでいう連携とは、ＯＳＧｉバンドルＡ１４からＯＳＧｉバンドルＢ１５が有するメソッドを呼び出す、ＯＳＧｉバンドルＢ１５からＯＳＧｉバンドルＡ１４が有するメソッドを呼び出す、両バンドル間でデータを共有する、などの動作のことをいう。
【０００６】
ＯＳＧｉバンドル同士の連携は、ＯＳＧｉフレームワーク１３が提供するサービスレジストリ１３１を介して行なわれる。例えば、ＯＳＧｉバンドルＢ１５が備える機能Ｂ１５１（メソッド（クラス））をＯＳＧｉバンドルＡ１４から使用したい場合、所定のコマンドを発行することにより、ＯＳＧｉバンドルＢ１５をサービスレジストリ１３１に登録する。
【０００７】
サービスレジストリ１３１に登録されたＯＳＧｉバンドルＢ１５の機能Ｂは、ＯＳＧｉサービスＢ１３２として、サービスレジストリ１３１上で公開される。ＯＳＧｉバンドルＡ１４は、サービスレジストリ１３１からＯＳＧｉサービスＢ１３２を取得し、機能Ｂ１５１に対応する（機能Ｂの有する）メソッドを実行することができる。
【０００８】
一方、ＯＳＧｉバンドルＢ１５が備える機能１５１を、ホスト１０の外部から使用するためには、そのための通信インターフェースをＯＳＧｉバンドルＢ１５内に設けておく必要がある。例えばＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いて機能１５１をクライアント端末２０から使用するためには、ＷｅｂＡＰＩサーバとしての機能を備えたＷｅｂＡＰＩサーバ部１５２をＯＳＧｉバンドルＢ１５内に設ける必要がある。
【０００９】
ここでいうＷｅｂＡＰＩサーバとは、例えばＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）のように、ＨＴＴＰを用いてネットワーク経由でアプリケーションを実行してその結果を取得するためのインターフェース、およびそのためのＷｅｂサーバ機能のことを総称的に指したものである。具体的な実装手段はＣＧＩに限られるものではなく、ＨＴＴＰを介してリクエストを受け付け、その実行結果をＨＴＴＰレスポンスとして返すものであれば、任意の実装手法を用いることができる。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】ＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ Ｒｅｌｅａｓｅ ４、ＵＲＬ：http://www.osgi.org/Release4/HomePage（２０１０年８月９日取得）
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ＯＳＧｉバンドルが備える機能をネットワーク上で公開し、ネットワーク経由で使用できるようにするためには、図１に示したＷｅｂＡＰＩサーバ部１５２のようなサーバ機能および機能を公開するためのインターフェースが必要となる。しかし、機能を公開するＯＳＧｉバンドル毎に上述のような機能を実装することは、開発工数などの面から負担が大きい。
【００１２】
本発明は、上記のような課題を解決するためになされたものであり、ＯＳＧｉバンドルが備える機能をＷｅｂＡＰＩ経由で容易に公開することのできる技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明に係るＷｅｂＡＰＩサーバプログラムは、ＯＳＧｉフレームワーク上に登録されているＯＳＧｉバンドルのクラス名とメソッド名をＨＴＴＰリクエストとして受け取り、これらに合致するＯＳＧｉバンドルを呼び出して実行し、その結果をＨＴＴＰレスポンスとして返信する。
【発明の効果】
【００１４】
本発明に係るＷｅｂＡＰＩサーバプログラムによれば、ネットワーク上で機能を公開したいＯＳＧｉバンドル（ＯＳＧｉサービス）をＯＳＧｉフレームワークに登録するのみで、自動的にＷｅｂＡＰＩ経由でネットワーク上に公開することができる。したがって、個々のＯＳＧｉバンドルにはＷｅｂＡＰＩサーバ機能を実装する必要がなくなり、開発負担をかけずに、ＯＳＧｉバンドルをＷｅｂサービスとして提供することができる。
【図面の簡単な説明】
【００１５】
【図１】ＯＳＧｉフレームワークの構成を示す図である。
【図２】実施形態１に係るＷｅｂシステム１００の構成図である。
【図３】ＷｅｂＡＰＩバンドル１７の機能ブロック図を示す。
【図４】ＯＳＧｉサービスの実体を模式的に示す図である。
【図５】ＯＳＧｉバンドルＢ１５をサービスレジストリ１３１に登録し、ＯＳＧｉサービスとして実行するまでの様子を示す概念図である。
【図６】クラス名とメソッド名を指定して実行結果を返信するよう要求するＨＴＴＰリクエストとそのレスポンスの対応関係を示す図である。
【図７】サービスレジストリ１３１に登録されているＯＳＧｉサービスの一覧を返信するよう要求するＨＴＴＰリクエストとそのレスポンスを例示する図である。
【図８】ＷｅｂＡＰＩバンドル１７の動作フローである。
【図９】実施形態２において、ＷｅｂＡＰＩバンドル１７がＯＳＧｉサービスをＷｅｂＡＰＩとして公開する様子を示す図である。
【図１０】ＷｅｂＡＰＩバンドル１７を介してＯＳＧｉサービスを呼び出す際に指定することのできるＨＴＴＰリクエストパラメータとレスポンス例を示す図である。
【図１１】レスポンスの記述形式としてＸＭＬを用いる例を示す図である。
【発明を実施するための形態】
【００１６】
＜実施の形態１＞
図２は、本発明の実施形態１に係るＷｅｂシステム１００の構成図である。Ｗｅｂシステム１００は、ホスト１０上で動作するアプリケーションを、ネットワークを介してクライアント２０から利用する形態のシステムである。クライアント２０は、ＨＴＴＰを用いてホスト１０にアクセスし、利用したい機能をリクエストし、その実行結果をＨＴＴＰレスポンスとして受信する。
【００１７】
ホスト１０は、図１で説明したＯＳＧｉバンドルＡ１４に代えて、ＷｅｂＡＰＩバンドル１７を備える。その他の構成は、図１と同様である（バンドルＢはＷｅｂＡＰＩサーバ部を持たない）。なお、以下の説明の便宜上、ＯＳＧｉバンドルＢ１５が持つＪａｖａオブジェクトである機能ＢをＯＳＧｉフレームワーク１３に登録したときの名称を、ＳｅｒｖｉｃｅＢ１３２として表記することにする。
【００１８】
ホスト１０は、ＯＳ１１、ＪａｖａＶＭ１２などを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの演算装置、これらプログラムおよび各ＯＳＧｉバンドルを格納するＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶装置、必要なメモリおよびネットワークインターフェースなどの、ホストコンピュータとして必要な構成を適宜備えるものとする。
【００１９】
以下では説明の便宜上、ＯＳＧｉフレームワーク１３や各ＯＳＧｉバンドルなどのプログラムを動作主体として説明するが、実際にこれらプログラムを実行するのは、ホスト１０が備えるＣＰＵ、さらにはＣＰＵが実行するＪａｖａＶＭ１２であることを付言しておく。
【００２０】
ＷｅｂＡＰＩバンドル１７は、ＯＳＧｉバンドルとして実装されている。ＷｅｂＡＰＩバンドル１７は、サービスレジストリ１３１に（ＯＳＧｉサービスを）登録するためのものではなく、クライアント２０からリクエストを受け付けてサービスレジストリ１３１に登録されているサービスを呼び出して実行し、その結果を返信するモジュールである。ＷｅｂＡＰＩバンドル１７は、ＪａｖａＶＭ１２の配下で動作し、クライアント２０からのＨＴＴＰリクエストを待ち受けるＷｅｂサーバ機能を提供する。ＷｅｂＡＰＩバンドル１７は、本発明における「ＷｅｂＡＰＩサーバプログラム」に相当する。
【００２１】
クライアント２０は、ＨＴＴＰを用いてＷｅｂＡＰＩバンドル１７が公開するＷｅｂＡＰＩにアクセスし、ＷｅｂＡＰＩバンドル１７が提供するサービス（ここではＳｅｒｖｉｃｅＢ１３２）を実行するようリクエストする。ＷｅｂＡＰＩバンドル１７はそのリクエストを処理し、実行結果をＨＴＴＰレスポンスとしてクライアント２０に返信する。
【００２２】
図３は、ＷｅｂＡＰＩバンドル１７の機能ブロック図を示す。ＷｅｂＡＰＩバンドル１７は、ＨＴＴＰサーバ部１７１、ＯＳＧｉサービス実行部１７２、ＯＳＧｉサービス一覧取得部１７３を備える。これら機能部は、ＷｅｂＡＰＩバンドル１７が備えるＪａｖａメソッドとして実装することができる。
【００２３】
ＨＴＴＰサーバ部１７１は、クライアント２０からＨＴＴＰリクエストを受け付け、ＨＴＴＰレスポンスを返信する、Ｗｅｂサーバとしての機能を備える。ＯＳＧｉサービス実行部１７２は、サービスレジストリ１３１に登録されているＯＳＧｉサービスを取得し、実行する。ＯＳＧｉサービス一覧取得部１７３は、サービスレジストリ１３１に登録されているＯＳＧｉサービスの一覧を取得する。
【００２４】
図４は、ＯＳＧｉサービスの実体を模式的に示す図である。ここでは、ＯＳＧｉバンドルＢ１５の持つ機能ＢをＯＳＧｉサービスであるＳｅｒｖｉｃｅＢ１３２として登録する場合の例を示した。
【００２５】
ＯＳＧｉサービスの実体は、サービスレジストリ１３１に登録されたＯＳＧｉバンドルを構成する（ＯＳＧｉバンドルが持つ）Ｊａｖａクラスのインスタンスである。ＯＳＧｉサービスをサービスレジストリ１３１に登録するとは、ＯＳＧｉバンドルを構成する（ＯＳＧｉバンドルが持つ）Ｊａｖａクラスのインスタンスを生成し、その参照をサービスレジストリ１３１に引き渡すことである。
【００２６】
ＯＳＧｉサービスを利用する側では、サービスレジストリ１３１が保持しているこのＪａｖａインスタンスを、クラス名をキーとして取得し、そのクラスが有するメソッドを実行することにより、ＯＳＧｉサービスを利用する。
【００２７】
図４に示す例では、ＯＳＧｉサービスを利用する側のＪａｖａクラス（例えばＷｅｂＡＰＩバンドル１７）は、クラス名「ＳｅｒｖｉｃｅＢ」をキーにしてサービスレジストリ１３１からＳｅｒｖｉｃｅＢ１３２を取得し、メソッド「ｆｕｎｃ１」「ｆｕｎｃ２」などを実行する。これらのメソッドは、ＯＳＧｉバンドルＢ１５が提供する機能１５１に相当する。
【００２８】
図５は、ＯＳＧｉバンドルＢ１５をサービスレジストリ１３１に登録し、ＯＳＧｉサービスとして実行するまでの様子を示す概念図である。ＯＳＧｉサービスとＪａｖａインスタンスの関連イメージを示すため、ごく簡略化したサンプルソースコードを併記した。同ソースコードは説明のためのものであり、必ずしも実際のソースコードを示すものではないことを付言しておく。
【００２９】
ＯＳＧｉサービスの提供元であるＯＳＧｉバンドルＢ１５は、ＳｅｒｖｉｃｅＢオブジェクトを生成し、サービスレジストリ１３１に登録する。サービスレジストリ１３１は、ＳｅｒｖｉｃｅＢクラスのインスタンスへの参照を保持する。
【００３０】
ＯＳＧｉサービスを利用する側であるＷｅｂＡＰＩバンドル１７のＯＳＧｉサービス実行部１７２は、利用しようとしているＯＳＧｉサービスのバンドルに対応するクラス名「ＳｅｒｖｉｃｅＢ」をキーにして、サービスレジストリ１３１からＳｅｒｖｉｃｅＢオブジェクトへの参照を取得する。ＯＳＧｉサービス実行部１７２（実際にはＪａｖａＶＭ１２）は、取得したＳｅｒｖｉｃｅＢオブジェクトを、ホスト１０が備えるメモリ上に確保する（参照なのでオブジェクト用のメモリは不要。参照を入れる変数用のメモリのみ要）。
【００３１】
ＷｅｂＡＰＩバンドル１７のＯＳＧｉサービス実行部１７２は、ＳｅｒｖｉｃｅＢオブジェクトが有するメソッド、例えば「ｆｕｎｃ１」メソッドを実行する。ＨＴＴＰサーバ部１７１は、その結果をクライアント２０にＨＴＴＰレスポンス形式で返信する。
【００３２】
図５で説明した例では、ＯＳＧｉサービスを提供するＯＳＧｉバンドルのクラス名およびメソッド名が、ＷｅｂＡＰＩバンドル１７にとって既知であることを前提とした。ただし、一般にはＯＳＧｉバンドルのクラス名およびメソッド名は必ずしも既知ではなく、Ｗｅｂシステム１００の設計仕様などによって個別に異なる。また、図５のように実装すると、ＷｅｂＡＰＩバンドル１７とＯＳＧｉバンドルＢ１５の結びつきが強くなり、ＯＳＧｉフレームワーク１３がＰｌｕｇｉｎ機構を提供することの利点が減じられてしまう。
【００３３】
そこで以下では、ＯＳＧｉサービスを提供するＯＳＧｉバンドルのクラス名およびメソッド名をＷｅｂＡＰＩバンドル１７の外部から与え、任意のクラス名およびメソッド名をサービスレジストリ１３１から呼び出すことができるように構成することを考える。
【００３４】
図６は、クライアント２０からＷｅｂＡＰＩバンドル１７に対して、クラス名とメソッド名を指定して実行結果を返信するよう要求するＨＴＴＰリクエストとそのレスポンスの対応関係を示す図である。１行目はＳｅｒｖｉｃｅＢ１３２の「ｆｕｎｃ１」メソッドを呼び出す場合の例、２行目はＳｅｒｖｉｃｅＢ１３２の「ｆｕｎｃ２」メソッドを呼び出す場合の例を示す。
【００３５】
クライアント２０は、ＷｅｂＡＰＩバンドル１７にＨＴＴＰリクエストを発行する際に、リクエストパラメータとして、ＯＳＧｉサービスを提供するクラス名、そのメソッド名、メソッドの引数を、リクエスト内に含めておく。引数が複数ある場合は、その分だけリクエストパラメータを設ける。
【００３６】
ＷｅｂＡＰＩバンドル１７のＨＴＴＰサーバ部１７１は、上記ＨＴＴＰリクエストを受け取ると、リクエストパラメータ部分を切り出してＯＳＧｉサービス実行部１７２に引き渡す。
【００３７】
ＯＳＧｉサービス実行部１７２は、リクエストパラメータに記述されているクラス名をキーにして、サービスレジストリ１３１から同クラス名に該当するＯＳＧｉサービスを呼び出す。ＯＳＧｉサービス実行部１７２は、リクエストパラメータに記述されているメソッド名に対応するメソッドを実行し、ＨＴＴＰサーバ部１７１を介して、その結果をクライアント２０に返信する。ＨＴＴＰレスポンスはテキスト形式であるため、記述形式は任意でよい。図６では、リクエストパラメータと同様の形式を用いた例を示した。メソッドの戻り値が複数ある場合は、その旨をＨＴＴＰレスポンス内に併せて記述する。
【００３８】
クライアント２０が、サービスレジストリ１３１上に存在しないクラス名またはメソッド名をリクエストパラメータ内で指定した場合、またはクラスとメソッドは存在するが引数の型が合致しない場合、ＯＳＧｉサービス実行部１７２およびＨＴＴＰサーバ部１７１は、例外を発行してその旨をクライアント２０に返信する。
【００３９】
ＯＳＧｉサービス実行部１７２が、リクエストパラメータに記述されているクラス名を用いてＯＳＧｉサービスのクラスを取得するとき、図５の左上ソースコード例に示すように、サービスレジストリ１３１は、汎用クラス型であるＯｂｊｅｃｔ型としてＯＳＧｉクラスを引き渡す。これは、任意のクラス型をサービスレジストリ１３１に登録できるようにするために必要な仕様であると思われる。
【００４０】
ただし、Ｏｂｊｅｃｔ型は汎用クラス型であるため、ごく基本的なメソッドしか備えておらず、ＳｅｒｖｉｃｅＢクラスが有する「ｆｕｎｃ１」「ｆｕｎｃ２」のようなメソッドは備えていない。そこでＷｅｂＡＰＩバンドル１７は、文字列変数が保持している文字列を用いて任意のメソッドを起動することのできる、ｊａｖａ．ｌａｎｇ．ｒｅｆｌｅｃｔパッケージの機能を利用する。
【００４１】
同パッケージの機能を用いると、Ｏｂｊｅｃｔクラス型をＳｅｒｖｉｃｅＢクラス型に変換することなく、Ｏｂｊｅｃｔ型のままで任意のメソッドを起動することができる。このことは、任意クラスの任意メソッドを実行することができるメリットの他に、特定クラスへの依存性をなくすことができる点でも有利である。
【００４２】
すなわち、通常であれば、ＷｅｂＡＰＩバンドル１７は、ＳｅｒｖｉｃｅＢ１３２のクラス名をクライアント２０からリクエストパラメータとして与えられたとき、サービスレジストリ１３１から取得したＯｂｊｅｃｔ型をいったんＳｅｒｖｉｃｅＢ型に変換した上で、「ｆｕｎｃ１」などのメソッドを実行する。Ｏｂｊｅｃｔ型は同メソッドを有さないからである。しかしそのためには、ＷｅｂＡＰＩバンドル１７内でＳｅｒｖｉｃｅＢクラスをあらかじめ取り込んでおかなければならず、その時点でＷｅｂＡＰＩバンドル１７の汎用性が減じられてしまう。
【００４３】
これに対し上記手法によれば、リクエストパラメータで与えられたクラス型に変換する処理は発生しないので、同クラスを取り込む必要はなくなり、クラス型に対する中立性・汎用性を保つことができる。
【００４４】
図７は、クライアント２０からＷｅｂＡＰＩバンドル１７に対して、サービスレジストリ１３１に登録されているＯＳＧｉサービスの一覧を返信するよう要求するＨＴＴＰリクエストとそのレスポンスを例示する図である。クライアント２０は、ＷｅｂＡＰＩバンドル１７にＨＴＴＰリクエストを発行する際に、ＯＳＧｉサービスの一覧を返信するよう要求する旨を、リクエストパラメータとしてリクエスト内に含めておく。図７に示す例ではパラメータ「ｇｅｔｓｅｒｖｉｃｅｌｉｓｔ＝ｔｒｕｅ」がこれに相当する。
【００４５】
ＷｅｂＡＰＩバンドル１７のＨＴＴＰサーバ部１７１は、上記ＨＴＴＰリクエストを受け取ると、リクエストパラメータ部分を切り出してＯＳＧｉサービス実行部１７２に引き渡す。
【００４６】
ＯＳＧｉサービス一覧取得部１７３は、サービスレジストリ１３１に登録されているＯＳＧｉサービスのクラス名一覧を取得する。さらに、ｊａｖａ．ｌａｎｇ．ｒｅｆｌｅｃｔパッケージの機能を利用して、各ＯＳＧｉサービスのクラスが有するメソッド名、メソッド引数、メソッド戻り型などの情報を取得する。ＯＳＧｉサービス一覧取得部１７３は、ＨＴＴＰサーバ部１７１を介して、取得結果をクライアント２０に返信する。
【００４７】
ＯＳＧｉサービス一覧取得部１７３の機能は、例えばクライアント２０が利用したいサービスに対応するクラス名やメソッド名がサービスレジストリ１３１内に存在するか否かを確認するためなどに用いられる。
【００４８】
図８は、ＷｅｂＡＰＩバンドル１７の動作フローである。以下、図８の各ステップについて説明する。
【００４９】
（図８：ステップＳ８０１）
ＷｅｂＡＰＩバンドル１７が起動すると、ＨＴＴＰサーバ部１７１はクライアント２０からのＨＴＴＰリクエストを待機する。クライアント２０からＨＴＴＰリクエストが到着すると、ＨＴＴＰサーバ部１７１は、そのリクエストがＯＳＧｉサービスの一覧を取得するリクエストであるか、ＯＳＧｉサービスを呼び出すリクエストであるかを判定する。前者であればステップＳ８０２へ進み、後者であればステップＳ８０３へ進む。
【００５０】
（図８：ステップＳ８０２）
ＯＳＧｉサービス一覧取得部１７３は、サービスレジストリ１３１に登録されているＯＳＧｉサービスのクラス名、メソッド名、メソッド引数、メソッド戻り型などの一覧を取得する。ＨＴＴＰサーバ部１７１は、その取得結果をＨＴＴＰレスポンスとしてクライアント２０に返信し、本動作フローを終了する。ＨＴＴＰサーバ部１７１は、再びＨＴＴＰリクエストを待機する。
【００５１】
（図８：ステップＳ８０３）
ＯＳＧｉサービス実行部１７２は、クライアント２０からのＨＴＴＰリクエストで指定されたクラス名、メソッド名などを用いて、サービスレジストリ１３１から該当するＯＳＧｉサービスを呼び出す。呼び出しに成功した場合はステップＳ８０４へ進み、失敗した場合はステップＳ８０５へ進む。
【００５２】
（図８：ステップＳ８０４）
ＯＳＧｉサービス実行部１７２は、ステップＳ８０３で呼び出したＯＳＧｉサービス（呼び出したクラス）のメソッドを実行する。実行に成功した場合はステップＳ８０６へ進み、失敗した場合はステップＳ８０５へ進む。
【００５３】
（図８：ステップＳ８０５）
ＨＴＴＰサーバ部１７１は、エラーが発生した旨のＨＴＴＰレスポンスを、クライアント２０に返信する。ＨＴＴＰサーバ部１７１は、再びＨＴＴＰリクエストを待機する。本ステップにおいて、ＨＴＴＰレスポンスの内容部分にエラーが発生した旨を記述してもよいし、単純にＨＴＴＰが規定するエラーコードを返信してもよい。どのようなエラーが発生したのか明示する観点では、前者のほうが望ましい。
【００５４】
（図８：ステップＳ８０６）
ＨＴＴＰサーバ部１７１は、ＯＳＧｉサービス実行部１７２がＯＳＧｉサービスを実行した結果をＨＴＴＰレスポンス内に記述し、クライアント２０に返信する。ＨＴＴＰサーバ部１７１は、再びＨＴＴＰリクエストを待機する。
【００５５】
＜実施の形態１：まとめ＞
以上のように、本実施形態１に係るＷｅｂＡＰＩバンドル１７は、実行したいＯＳＧｉサービスのクラス名、メソッド名などを指定するＨＴＴＰリクエストを受け取り、当該メソッドを実行してその結果をＨＴＴＰレスポンスとして返信する。これにより、ネットワーク上で公開したいＯＳＧｉバンドルの持つＯＳＧｉサービスをサービスレジストリ１３１に登録しておけば、自動的にＷｅｂＡＰＩとしてネットワークに公開することができるので、個別にＨＴＴＰサーバ機能などを実装する必要がなくなり、開発負担を低減することができる。
【００５６】
また、本実施形態１に係るＷｅｂＡＰＩバンドル１７は、サービスレジストリ１３１からＯＳＧｉサービスを取得した後、汎用クラス型であるＯｂｊｅｃｔ型をＯＳＧｉバンドルのクラス型に変換することなく、クライアント２０が指定したメソッドをそのまま実行する。これにより、ＷｅｂＡＰＩバンドル１７をＯＳＧｉバンドルのクラス型から切り離し、クラス間の依存関係をなくして汎用性を高めることができる。すなわち、ＷｅｂＡＰＩバンドル１７は、サービスレジストリ１３１にどのようなＯＳＧｉサービスが登録されていても、そのクラス型をあらかじめ読み込んでおくことなく、指定されたクラスおよびメソッドを呼び出して実行することができる。
【００５７】
また、本実施形態１に係るＷｅｂＡＰＩバンドル１７は、サービスレジストリ１３１に登録されているクラス名、メソッド名などの一覧をクライアント２０に提供することができる。これにより、クライアント２０はリクエストを発行する前にエラーが発生する可能性を事前に知ることができるので、メソッドを実行してエラーが返ってくるか否かにより当該メソッドの存否を調べるような非効率な処理をしなくてすむ。
【００５８】
＜実施の形態２＞
実施形態１では、サービスレジストリ１３１に登録されているＯＳＧｉバンドルは無条件にネットワーク上へ公開される。しかし、ＯＳＧｉフレームワーク１３の機能を利用するためサービスレジストリ１３１に登録されているＯＳＧｉバンドルのなかには、ネットワークに公開したくないものも含まれている可能性がある。そこで本発明の実施形態２では、ネットワーク上に公開するＯＳＧｉバンドルとそうでないＯＳＧｉバンドルを区別するための手法を説明する。その他の構成は実施形態１と同様であるため、以下では差異点を中心に説明する。
【００５９】
図９は、本実施形態２において、ＷｅｂＡＰＩバンドル１７がＯＳＧｉサービスをＷｅｂＡＰＩとして公開する様子を示す図である。本実施形態２では、ＯＳＧｉバンドルのうちネットワーク上にＷｅｂＡＰＩとして公開するものについては、メンバ変数１５３（フィールド）「ｏｐｅｎａｐｉ」を設けることとする。
【００６０】
ＷｅｂＡＰＩバンドル１７は、ＯＳＧｉサービスを実行するようリクエストを受けたとき、またはサービスレジストリ１３１に登録されているＯＳＧｉサービスの一覧を取得するようリクエストを受けたとき、サービスレジストリ１３１から取得したＯＳＧｉバンドルクラスのメンバ変数「ｏｐｅｎａｐｉ」を取得する。同メンバ変数の値が「ｔｒｕｅ」である場合は、当該クラスが有するメソッドをＷｅｂＡＰＩとして公開してよいものと判断する。同メンバ変数の値が「ｔｒｕｅ」でない場合、または同メンバ変数が存在しない場合は、当該クラスが有するメソッドをＷｅｂＡＰＩとして公開しない。
【００６１】
ＷｅｂＡＰＩバンドル１７は、ＷｅｂＡＰＩとして公開しないクラスについてサービス実行リクエストを受けた場合は、エラーを返信する。また、ＷｅｂＡＰＩとして公開しないクラスについては、サービスレジストリ１３１に登録されているＯＳＧｉサービスの一覧をクライアント２０に返信するとき、その一覧に当該クラスを記述しないこととする。
【００６２】
ＷｅｂＡＰＩバンドル１７がサービスレジストリ１３１からＯＳＧｉバンドルクラス（ＯＳＧｉサービスクラス）を取得したとき、図５で説明したように、クラス型はＯｂｊｅｃｔ型となっている。そこでＷｅｂＡＰＩバンドル１７は、ｊａｖａ．ｌａｎｇ．ｒｅｆｌｅｃｔパッケージの機能を利用して、メンバ変数「ｏｐｅｎａｐｉ」にアクセスする。この手法によれば、同メンバ変数がｐｒｉｖａｔｅ指定されている（当該クラスの外部からアクセスすることを禁止する旨の宣言）場合でも、同メンバ変数にアクセスすることができる。
【００６３】
なお、メンバ変数「ｏｐｅｎａｐｉ」をｐｒｉｖａｔｅ宣言する場合、他のＯＳＧｉバンドルから同変数を参照することはできないので、他のＯＳＧｉバンドルにとっては同変数が存在しないに等しい。すなわち、本実施形態２に固有のメンバ変数を設けているか否かによらず、ＯＳＧｉフレームワーク１３にとっては全てのＯＳＧｉバンドルを同等に取り扱うことができるので、本実施形態２固有の格別の配慮を要さない点で便宜である。
【００６４】
＜実施の形態２：まとめ＞
以上のように、本実施形態２に係るＷｅｂＡＰＩバンドル１７は、サービスレジストリ１３１に登録されているＯＳＧｉバンドルのメンバ変数「ｏｐｅｎａｐｉ」の値をチェックし、当該クラスをＷｅｂＡＰＩとして公開してよいか否かを判定する。これにより、ネットワークに公開したいＯＳＧｉバンドルのみを選択的に公開することができるので、公開すべきでないＯＳＧｉバンドルを不用意にネットワークへ公開する可能性を低減することができる。
【００６５】
＜実施の形態３＞
本発明の実施形態３では、クライアント２０とＷｅｂＡＰＩバンドル１７の間のＨＴＴＰリクエストおよびＨＴＴＰレスポンスの形式について補足する。Ｗｅｂシステム１００の構成は、実施形態１〜２と同様である。
【００６６】
図１０は、ＷｅｂＡＰＩバンドル１７を介してＯＳＧｉサービスを呼び出す際に指定することのできるＨＴＴＰリクエストパラメータとレスポンス例を示す図である。
【００６７】
ＨＴＴＰはテキストベースのプロトコルであるため、Ｊａｖａオブジェクトをそのままリクエストおよびレスポンス内で用いることは難しい。したがって、クライアント２０からのリクエスト上およびクライアント２０へのレスポンス上で用いることができるのは、テキストベースで表現することのできる、Ｊａｖａ基本型およびＳｔｒｉｎｇ（文字列）型に限られる。すなわち、独自のクラス型や、任意のクラス型を含む配列（例えばＡｒｒａｙＬｉｓｔ）などは用いることができない。
【００６８】
また、Ｄｉｃｔｉｏｎａｒｙ型（内部的に複数の値を格納している、配列に似たクラス型）はレスポンス内で用いることはできるが、リクエストパラメータとして用いることは好ましくない。これは、ＨＴＴＰリクエストパラメータの記述形式に起因する。
【００６９】
ＨＴＴＰレスポンスは改行コードを含む任意のテキスト形式で記述することができるため、Ｊａｖａメソッドの実行結果がＤｉｃｔｉｏｎａｒｙ型であり、そのなかに複数の値が含まれている場合でも、全ての値をレスポンス内に記述することができる。
【００７０】
しかし、ＨＴＴＰリクエストパラメータは「ａｒｇ１＝１」のように、パラメータ名とその値を１つずつペアにして記述するため、パラメータ値がＤｉｃｔｉｏｎａｒｙ型になっていて内部的に複数の値を含む場合、「ａｒｇ１＝（ａｇｅ＝３０＆ｈｅｉｇｈｔ＝１７０）」のように多重的に記載せざるを得ず、煩雑になってしまう。また実際上、引数としてＤｉｃｔｉｏｎａｒｙ型を用いる必要性はあまりない。そこで図１０では、リクエストパラメータとしてＤｉｃｔｉｏｎａｒｙ型を用いないこととした。
【００７１】
図１１は、レスポンスの記述形式としてＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いる例を示す図である。レスポンスの内容は、図６と同様である。このようなＸＭＬ形式のレスポンスを、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）形式とも呼ぶ。レスポンスをＸＭＬ形式に変換する処理は、ＯＳＧｉサービスとの関連が少ない処理であるため、例えばＨＴＴＰサーバ部１７１が実施すればよい。
【００７２】
レスポンスのほか、ＨＴＴＰリクエストもＸＭＬ形式で記述することもできる。例えばＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）形式のＸＭＬメッセージをクライアント２０からＷｅｂＡＰＩバンドル１７に発行し、ＨＴＴＰサーバ部１７１がそのメッセージを解析して必要なパラメータのみをＯＳＧｉサービス実行部１７２に引き渡すようにすればよい。
【００７３】
＜実施の形態４＞
以上の実施形態１〜３では、ＷｅｂＡＰＩバンドル１７はＨＴＴＰリクエストとしてＯＳＧｉサービスのクラス名などを直接受け取ることとしたが、必ずしもクラス名などそのものを記述したリクエストパラメータを用いなくともよい。
【００７４】
例えば、ＷｅｂＡＰＩバンドル１７は、クラス名やメソッド名を所定規則で変換した文字列をリクエストパラメータとして受け取り、ＷｅｂＡＰＩバンドル１７の内部、または適当な変換モジュールなどを介して、ＯＳＧｉサービスのクラス名、メソッド名などに変換してもよい。すなわち、ＷｅｂＡＰＩバンドル１７は、少なくともＯＳＧｉサービスのクラス名、メソッド名などを特定することのできるリクエストパラメータを受け取れば足りる。
【符号の説明】
【００７５】
１０：ホスト、１１：ＯＳ、１２：ＪａｖａＶＭ、１３：ＯＳＧｉフレームワーク、１３１：サービスレジストリ、１３２：ＳｅｒｖｉｃｅＢ、１４：ＯＳＧｉバンドルＡ、１５：ＯＳＧｉバンドルＢ、１５１：機能Ｂ、１５２：ＷｅｂＡＰＩサーバ部、１５３：メンバ変数、１７：ＷｅｂＡＰＩバンドル、１７１：ＨＴＴＰサーバ部、１７２：ＯＳＧｉサービス実行部、１７３：ＯＳＧｉサービス一覧取得部、２０：クライアント、１００：Ｗｅｂシステム。
【技術分野】
【０００１】
本発明は、ＯＳＧｉフレームワーク仕様に対応したＯＳＧｉバンドルをＷｅｂＡＰＩ経由で公開する技術に関するものである。
【背景技術】
【０００２】
図１は、ＯＳＧｉフレームワークの構成を示す図である。ＯＳＧｉフレームワークとは、Ｊａｖａ（登録商標）Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ上で動作し、ＪａｖａプログラムをＰｌｕｇｉｎモジュールとして取り扱い、動的にアプリケーションへ追加できるようにする、サービスプラットフォームである。ＯＳＧｉフレームワークは、ＯＳＧｉ Ａｌｌｉａｎｃｅによって開発・定義されている（非特許文献１）。
【０００３】
図１において、ＯＳＧｉフレームワーク１３は、ホスト１０上で動作するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）１１およびその配下で動作するＪａｖａＶＭ１２上のＪａｖａアプリケーションとして実装されている。ＯＳＧｉフレームワーク１３は、Ｊａｖａモジュールの提供するサービスをＯＳＧｉプラットフォーム１３上に登録するためのインターフェースである、サービスレジストリ１３１を公開している。ＯＳＧｉフレームワーク仕様に準拠し、ＯＳＧｉフレームワーク１３に登録することができるよう（ＯＳＧｉフレームワーク上で動作するよう）に構成されているＪａｖａモジュールのことを、ＯＳＧｉバンドルと呼ぶ。ＯＳＧｉバンドルの実体は、Ｊａｖａクラス（Ｊａｖａクラス群 or Ｊａｖａパッケージ or 複数のＪａｖａクラスから成るＪａｖａパッケージ）および関連する設定ファイル等である。また、ＯＳＧｉバンドルの提供するサービスのことをＯＳＧｉサービスと呼ぶ。ＯＳＧｉサービスの実体は、Ｊａｖａクラスである。
【０００４】
例えば、ＯＳＧｉフレームワーク１３上でＯＳＧｉバンドルＡ１４が既に動作していると仮定する。ＪａｖａＶＭ１２は、ＯＳＧｉフレームワーク１３を利用することにより、ＯＳＧｉバンドルＡ１４と連携して動作するＯＳＧｉバンドルＢ１５を、ＯＳＧｉバンドルＡ１４を再起動することなくアプリケーション上に追加することができる。
【０００５】
ここでいう連携とは、ＯＳＧｉバンドルＡ１４からＯＳＧｉバンドルＢ１５が有するメソッドを呼び出す、ＯＳＧｉバンドルＢ１５からＯＳＧｉバンドルＡ１４が有するメソッドを呼び出す、両バンドル間でデータを共有する、などの動作のことをいう。
【０００６】
ＯＳＧｉバンドル同士の連携は、ＯＳＧｉフレームワーク１３が提供するサービスレジストリ１３１を介して行なわれる。例えば、ＯＳＧｉバンドルＢ１５が備える機能Ｂ１５１（メソッド（クラス））をＯＳＧｉバンドルＡ１４から使用したい場合、所定のコマンドを発行することにより、ＯＳＧｉバンドルＢ１５をサービスレジストリ１３１に登録する。
【０００７】
サービスレジストリ１３１に登録されたＯＳＧｉバンドルＢ１５の機能Ｂは、ＯＳＧｉサービスＢ１３２として、サービスレジストリ１３１上で公開される。ＯＳＧｉバンドルＡ１４は、サービスレジストリ１３１からＯＳＧｉサービスＢ１３２を取得し、機能Ｂ１５１に対応する（機能Ｂの有する）メソッドを実行することができる。
【０００８】
一方、ＯＳＧｉバンドルＢ１５が備える機能１５１を、ホスト１０の外部から使用するためには、そのための通信インターフェースをＯＳＧｉバンドルＢ１５内に設けておく必要がある。例えばＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いて機能１５１をクライアント端末２０から使用するためには、ＷｅｂＡＰＩサーバとしての機能を備えたＷｅｂＡＰＩサーバ部１５２をＯＳＧｉバンドルＢ１５内に設ける必要がある。
【０００９】
ここでいうＷｅｂＡＰＩサーバとは、例えばＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）のように、ＨＴＴＰを用いてネットワーク経由でアプリケーションを実行してその結果を取得するためのインターフェース、およびそのためのＷｅｂサーバ機能のことを総称的に指したものである。具体的な実装手段はＣＧＩに限られるものではなく、ＨＴＴＰを介してリクエストを受け付け、その実行結果をＨＴＴＰレスポンスとして返すものであれば、任意の実装手法を用いることができる。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】ＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ Ｒｅｌｅａｓｅ ４、ＵＲＬ：http://www.osgi.org/Release4/HomePage（２０１０年８月９日取得）
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ＯＳＧｉバンドルが備える機能をネットワーク上で公開し、ネットワーク経由で使用できるようにするためには、図１に示したＷｅｂＡＰＩサーバ部１５２のようなサーバ機能および機能を公開するためのインターフェースが必要となる。しかし、機能を公開するＯＳＧｉバンドル毎に上述のような機能を実装することは、開発工数などの面から負担が大きい。
【００１２】
本発明は、上記のような課題を解決するためになされたものであり、ＯＳＧｉバンドルが備える機能をＷｅｂＡＰＩ経由で容易に公開することのできる技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明に係るＷｅｂＡＰＩサーバプログラムは、ＯＳＧｉフレームワーク上に登録されているＯＳＧｉバンドルのクラス名とメソッド名をＨＴＴＰリクエストとして受け取り、これらに合致するＯＳＧｉバンドルを呼び出して実行し、その結果をＨＴＴＰレスポンスとして返信する。
【発明の効果】
【００１４】
本発明に係るＷｅｂＡＰＩサーバプログラムによれば、ネットワーク上で機能を公開したいＯＳＧｉバンドル（ＯＳＧｉサービス）をＯＳＧｉフレームワークに登録するのみで、自動的にＷｅｂＡＰＩ経由でネットワーク上に公開することができる。したがって、個々のＯＳＧｉバンドルにはＷｅｂＡＰＩサーバ機能を実装する必要がなくなり、開発負担をかけずに、ＯＳＧｉバンドルをＷｅｂサービスとして提供することができる。
【図面の簡単な説明】
【００１５】
【図１】ＯＳＧｉフレームワークの構成を示す図である。
【図２】実施形態１に係るＷｅｂシステム１００の構成図である。
【図３】ＷｅｂＡＰＩバンドル１７の機能ブロック図を示す。
【図４】ＯＳＧｉサービスの実体を模式的に示す図である。
【図５】ＯＳＧｉバンドルＢ１５をサービスレジストリ１３１に登録し、ＯＳＧｉサービスとして実行するまでの様子を示す概念図である。
【図６】クラス名とメソッド名を指定して実行結果を返信するよう要求するＨＴＴＰリクエストとそのレスポンスの対応関係を示す図である。
【図７】サービスレジストリ１３１に登録されているＯＳＧｉサービスの一覧を返信するよう要求するＨＴＴＰリクエストとそのレスポンスを例示する図である。
【図８】ＷｅｂＡＰＩバンドル１７の動作フローである。
【図９】実施形態２において、ＷｅｂＡＰＩバンドル１７がＯＳＧｉサービスをＷｅｂＡＰＩとして公開する様子を示す図である。
【図１０】ＷｅｂＡＰＩバンドル１７を介してＯＳＧｉサービスを呼び出す際に指定することのできるＨＴＴＰリクエストパラメータとレスポンス例を示す図である。
【図１１】レスポンスの記述形式としてＸＭＬを用いる例を示す図である。
【発明を実施するための形態】
【００１６】
＜実施の形態１＞
図２は、本発明の実施形態１に係るＷｅｂシステム１００の構成図である。Ｗｅｂシステム１００は、ホスト１０上で動作するアプリケーションを、ネットワークを介してクライアント２０から利用する形態のシステムである。クライアント２０は、ＨＴＴＰを用いてホスト１０にアクセスし、利用したい機能をリクエストし、その実行結果をＨＴＴＰレスポンスとして受信する。
【００１７】
ホスト１０は、図１で説明したＯＳＧｉバンドルＡ１４に代えて、ＷｅｂＡＰＩバンドル１７を備える。その他の構成は、図１と同様である（バンドルＢはＷｅｂＡＰＩサーバ部を持たない）。なお、以下の説明の便宜上、ＯＳＧｉバンドルＢ１５が持つＪａｖａオブジェクトである機能ＢをＯＳＧｉフレームワーク１３に登録したときの名称を、ＳｅｒｖｉｃｅＢ１３２として表記することにする。
【００１８】
ホスト１０は、ＯＳ１１、ＪａｖａＶＭ１２などを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの演算装置、これらプログラムおよび各ＯＳＧｉバンドルを格納するＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶装置、必要なメモリおよびネットワークインターフェースなどの、ホストコンピュータとして必要な構成を適宜備えるものとする。
【００１９】
以下では説明の便宜上、ＯＳＧｉフレームワーク１３や各ＯＳＧｉバンドルなどのプログラムを動作主体として説明するが、実際にこれらプログラムを実行するのは、ホスト１０が備えるＣＰＵ、さらにはＣＰＵが実行するＪａｖａＶＭ１２であることを付言しておく。
【００２０】
ＷｅｂＡＰＩバンドル１７は、ＯＳＧｉバンドルとして実装されている。ＷｅｂＡＰＩバンドル１７は、サービスレジストリ１３１に（ＯＳＧｉサービスを）登録するためのものではなく、クライアント２０からリクエストを受け付けてサービスレジストリ１３１に登録されているサービスを呼び出して実行し、その結果を返信するモジュールである。ＷｅｂＡＰＩバンドル１７は、ＪａｖａＶＭ１２の配下で動作し、クライアント２０からのＨＴＴＰリクエストを待ち受けるＷｅｂサーバ機能を提供する。ＷｅｂＡＰＩバンドル１７は、本発明における「ＷｅｂＡＰＩサーバプログラム」に相当する。
【００２１】
クライアント２０は、ＨＴＴＰを用いてＷｅｂＡＰＩバンドル１７が公開するＷｅｂＡＰＩにアクセスし、ＷｅｂＡＰＩバンドル１７が提供するサービス（ここではＳｅｒｖｉｃｅＢ１３２）を実行するようリクエストする。ＷｅｂＡＰＩバンドル１７はそのリクエストを処理し、実行結果をＨＴＴＰレスポンスとしてクライアント２０に返信する。
【００２２】
図３は、ＷｅｂＡＰＩバンドル１７の機能ブロック図を示す。ＷｅｂＡＰＩバンドル１７は、ＨＴＴＰサーバ部１７１、ＯＳＧｉサービス実行部１７２、ＯＳＧｉサービス一覧取得部１７３を備える。これら機能部は、ＷｅｂＡＰＩバンドル１７が備えるＪａｖａメソッドとして実装することができる。
【００２３】
ＨＴＴＰサーバ部１７１は、クライアント２０からＨＴＴＰリクエストを受け付け、ＨＴＴＰレスポンスを返信する、Ｗｅｂサーバとしての機能を備える。ＯＳＧｉサービス実行部１７２は、サービスレジストリ１３１に登録されているＯＳＧｉサービスを取得し、実行する。ＯＳＧｉサービス一覧取得部１７３は、サービスレジストリ１３１に登録されているＯＳＧｉサービスの一覧を取得する。
【００２４】
図４は、ＯＳＧｉサービスの実体を模式的に示す図である。ここでは、ＯＳＧｉバンドルＢ１５の持つ機能ＢをＯＳＧｉサービスであるＳｅｒｖｉｃｅＢ１３２として登録する場合の例を示した。
【００２５】
ＯＳＧｉサービスの実体は、サービスレジストリ１３１に登録されたＯＳＧｉバンドルを構成する（ＯＳＧｉバンドルが持つ）Ｊａｖａクラスのインスタンスである。ＯＳＧｉサービスをサービスレジストリ１３１に登録するとは、ＯＳＧｉバンドルを構成する（ＯＳＧｉバンドルが持つ）Ｊａｖａクラスのインスタンスを生成し、その参照をサービスレジストリ１３１に引き渡すことである。
【００２６】
ＯＳＧｉサービスを利用する側では、サービスレジストリ１３１が保持しているこのＪａｖａインスタンスを、クラス名をキーとして取得し、そのクラスが有するメソッドを実行することにより、ＯＳＧｉサービスを利用する。
【００２７】
図４に示す例では、ＯＳＧｉサービスを利用する側のＪａｖａクラス（例えばＷｅｂＡＰＩバンドル１７）は、クラス名「ＳｅｒｖｉｃｅＢ」をキーにしてサービスレジストリ１３１からＳｅｒｖｉｃｅＢ１３２を取得し、メソッド「ｆｕｎｃ１」「ｆｕｎｃ２」などを実行する。これらのメソッドは、ＯＳＧｉバンドルＢ１５が提供する機能１５１に相当する。
【００２８】
図５は、ＯＳＧｉバンドルＢ１５をサービスレジストリ１３１に登録し、ＯＳＧｉサービスとして実行するまでの様子を示す概念図である。ＯＳＧｉサービスとＪａｖａインスタンスの関連イメージを示すため、ごく簡略化したサンプルソースコードを併記した。同ソースコードは説明のためのものであり、必ずしも実際のソースコードを示すものではないことを付言しておく。
【００２９】
ＯＳＧｉサービスの提供元であるＯＳＧｉバンドルＢ１５は、ＳｅｒｖｉｃｅＢオブジェクトを生成し、サービスレジストリ１３１に登録する。サービスレジストリ１３１は、ＳｅｒｖｉｃｅＢクラスのインスタンスへの参照を保持する。
【００３０】
ＯＳＧｉサービスを利用する側であるＷｅｂＡＰＩバンドル１７のＯＳＧｉサービス実行部１７２は、利用しようとしているＯＳＧｉサービスのバンドルに対応するクラス名「ＳｅｒｖｉｃｅＢ」をキーにして、サービスレジストリ１３１からＳｅｒｖｉｃｅＢオブジェクトへの参照を取得する。ＯＳＧｉサービス実行部１７２（実際にはＪａｖａＶＭ１２）は、取得したＳｅｒｖｉｃｅＢオブジェクトを、ホスト１０が備えるメモリ上に確保する（参照なのでオブジェクト用のメモリは不要。参照を入れる変数用のメモリのみ要）。
【００３１】
ＷｅｂＡＰＩバンドル１７のＯＳＧｉサービス実行部１７２は、ＳｅｒｖｉｃｅＢオブジェクトが有するメソッド、例えば「ｆｕｎｃ１」メソッドを実行する。ＨＴＴＰサーバ部１７１は、その結果をクライアント２０にＨＴＴＰレスポンス形式で返信する。
【００３２】
図５で説明した例では、ＯＳＧｉサービスを提供するＯＳＧｉバンドルのクラス名およびメソッド名が、ＷｅｂＡＰＩバンドル１７にとって既知であることを前提とした。ただし、一般にはＯＳＧｉバンドルのクラス名およびメソッド名は必ずしも既知ではなく、Ｗｅｂシステム１００の設計仕様などによって個別に異なる。また、図５のように実装すると、ＷｅｂＡＰＩバンドル１７とＯＳＧｉバンドルＢ１５の結びつきが強くなり、ＯＳＧｉフレームワーク１３がＰｌｕｇｉｎ機構を提供することの利点が減じられてしまう。
【００３３】
そこで以下では、ＯＳＧｉサービスを提供するＯＳＧｉバンドルのクラス名およびメソッド名をＷｅｂＡＰＩバンドル１７の外部から与え、任意のクラス名およびメソッド名をサービスレジストリ１３１から呼び出すことができるように構成することを考える。
【００３４】
図６は、クライアント２０からＷｅｂＡＰＩバンドル１７に対して、クラス名とメソッド名を指定して実行結果を返信するよう要求するＨＴＴＰリクエストとそのレスポンスの対応関係を示す図である。１行目はＳｅｒｖｉｃｅＢ１３２の「ｆｕｎｃ１」メソッドを呼び出す場合の例、２行目はＳｅｒｖｉｃｅＢ１３２の「ｆｕｎｃ２」メソッドを呼び出す場合の例を示す。
【００３５】
クライアント２０は、ＷｅｂＡＰＩバンドル１７にＨＴＴＰリクエストを発行する際に、リクエストパラメータとして、ＯＳＧｉサービスを提供するクラス名、そのメソッド名、メソッドの引数を、リクエスト内に含めておく。引数が複数ある場合は、その分だけリクエストパラメータを設ける。
【００３６】
ＷｅｂＡＰＩバンドル１７のＨＴＴＰサーバ部１７１は、上記ＨＴＴＰリクエストを受け取ると、リクエストパラメータ部分を切り出してＯＳＧｉサービス実行部１７２に引き渡す。
【００３７】
ＯＳＧｉサービス実行部１７２は、リクエストパラメータに記述されているクラス名をキーにして、サービスレジストリ１３１から同クラス名に該当するＯＳＧｉサービスを呼び出す。ＯＳＧｉサービス実行部１７２は、リクエストパラメータに記述されているメソッド名に対応するメソッドを実行し、ＨＴＴＰサーバ部１７１を介して、その結果をクライアント２０に返信する。ＨＴＴＰレスポンスはテキスト形式であるため、記述形式は任意でよい。図６では、リクエストパラメータと同様の形式を用いた例を示した。メソッドの戻り値が複数ある場合は、その旨をＨＴＴＰレスポンス内に併せて記述する。
【００３８】
クライアント２０が、サービスレジストリ１３１上に存在しないクラス名またはメソッド名をリクエストパラメータ内で指定した場合、またはクラスとメソッドは存在するが引数の型が合致しない場合、ＯＳＧｉサービス実行部１７２およびＨＴＴＰサーバ部１７１は、例外を発行してその旨をクライアント２０に返信する。
【００３９】
ＯＳＧｉサービス実行部１７２が、リクエストパラメータに記述されているクラス名を用いてＯＳＧｉサービスのクラスを取得するとき、図５の左上ソースコード例に示すように、サービスレジストリ１３１は、汎用クラス型であるＯｂｊｅｃｔ型としてＯＳＧｉクラスを引き渡す。これは、任意のクラス型をサービスレジストリ１３１に登録できるようにするために必要な仕様であると思われる。
【００４０】
ただし、Ｏｂｊｅｃｔ型は汎用クラス型であるため、ごく基本的なメソッドしか備えておらず、ＳｅｒｖｉｃｅＢクラスが有する「ｆｕｎｃ１」「ｆｕｎｃ２」のようなメソッドは備えていない。そこでＷｅｂＡＰＩバンドル１７は、文字列変数が保持している文字列を用いて任意のメソッドを起動することのできる、ｊａｖａ．ｌａｎｇ．ｒｅｆｌｅｃｔパッケージの機能を利用する。
【００４１】
同パッケージの機能を用いると、Ｏｂｊｅｃｔクラス型をＳｅｒｖｉｃｅＢクラス型に変換することなく、Ｏｂｊｅｃｔ型のままで任意のメソッドを起動することができる。このことは、任意クラスの任意メソッドを実行することができるメリットの他に、特定クラスへの依存性をなくすことができる点でも有利である。
【００４２】
すなわち、通常であれば、ＷｅｂＡＰＩバンドル１７は、ＳｅｒｖｉｃｅＢ１３２のクラス名をクライアント２０からリクエストパラメータとして与えられたとき、サービスレジストリ１３１から取得したＯｂｊｅｃｔ型をいったんＳｅｒｖｉｃｅＢ型に変換した上で、「ｆｕｎｃ１」などのメソッドを実行する。Ｏｂｊｅｃｔ型は同メソッドを有さないからである。しかしそのためには、ＷｅｂＡＰＩバンドル１７内でＳｅｒｖｉｃｅＢクラスをあらかじめ取り込んでおかなければならず、その時点でＷｅｂＡＰＩバンドル１７の汎用性が減じられてしまう。
【００４３】
これに対し上記手法によれば、リクエストパラメータで与えられたクラス型に変換する処理は発生しないので、同クラスを取り込む必要はなくなり、クラス型に対する中立性・汎用性を保つことができる。
【００４４】
図７は、クライアント２０からＷｅｂＡＰＩバンドル１７に対して、サービスレジストリ１３１に登録されているＯＳＧｉサービスの一覧を返信するよう要求するＨＴＴＰリクエストとそのレスポンスを例示する図である。クライアント２０は、ＷｅｂＡＰＩバンドル１７にＨＴＴＰリクエストを発行する際に、ＯＳＧｉサービスの一覧を返信するよう要求する旨を、リクエストパラメータとしてリクエスト内に含めておく。図７に示す例ではパラメータ「ｇｅｔｓｅｒｖｉｃｅｌｉｓｔ＝ｔｒｕｅ」がこれに相当する。
【００４５】
ＷｅｂＡＰＩバンドル１７のＨＴＴＰサーバ部１７１は、上記ＨＴＴＰリクエストを受け取ると、リクエストパラメータ部分を切り出してＯＳＧｉサービス実行部１７２に引き渡す。
【００４６】
ＯＳＧｉサービス一覧取得部１７３は、サービスレジストリ１３１に登録されているＯＳＧｉサービスのクラス名一覧を取得する。さらに、ｊａｖａ．ｌａｎｇ．ｒｅｆｌｅｃｔパッケージの機能を利用して、各ＯＳＧｉサービスのクラスが有するメソッド名、メソッド引数、メソッド戻り型などの情報を取得する。ＯＳＧｉサービス一覧取得部１７３は、ＨＴＴＰサーバ部１７１を介して、取得結果をクライアント２０に返信する。
【００４７】
ＯＳＧｉサービス一覧取得部１７３の機能は、例えばクライアント２０が利用したいサービスに対応するクラス名やメソッド名がサービスレジストリ１３１内に存在するか否かを確認するためなどに用いられる。
【００４８】
図８は、ＷｅｂＡＰＩバンドル１７の動作フローである。以下、図８の各ステップについて説明する。
【００４９】
（図８：ステップＳ８０１）
ＷｅｂＡＰＩバンドル１７が起動すると、ＨＴＴＰサーバ部１７１はクライアント２０からのＨＴＴＰリクエストを待機する。クライアント２０からＨＴＴＰリクエストが到着すると、ＨＴＴＰサーバ部１７１は、そのリクエストがＯＳＧｉサービスの一覧を取得するリクエストであるか、ＯＳＧｉサービスを呼び出すリクエストであるかを判定する。前者であればステップＳ８０２へ進み、後者であればステップＳ８０３へ進む。
【００５０】
（図８：ステップＳ８０２）
ＯＳＧｉサービス一覧取得部１７３は、サービスレジストリ１３１に登録されているＯＳＧｉサービスのクラス名、メソッド名、メソッド引数、メソッド戻り型などの一覧を取得する。ＨＴＴＰサーバ部１７１は、その取得結果をＨＴＴＰレスポンスとしてクライアント２０に返信し、本動作フローを終了する。ＨＴＴＰサーバ部１７１は、再びＨＴＴＰリクエストを待機する。
【００５１】
（図８：ステップＳ８０３）
ＯＳＧｉサービス実行部１７２は、クライアント２０からのＨＴＴＰリクエストで指定されたクラス名、メソッド名などを用いて、サービスレジストリ１３１から該当するＯＳＧｉサービスを呼び出す。呼び出しに成功した場合はステップＳ８０４へ進み、失敗した場合はステップＳ８０５へ進む。
【００５２】
（図８：ステップＳ８０４）
ＯＳＧｉサービス実行部１７２は、ステップＳ８０３で呼び出したＯＳＧｉサービス（呼び出したクラス）のメソッドを実行する。実行に成功した場合はステップＳ８０６へ進み、失敗した場合はステップＳ８０５へ進む。
【００５３】
（図８：ステップＳ８０５）
ＨＴＴＰサーバ部１７１は、エラーが発生した旨のＨＴＴＰレスポンスを、クライアント２０に返信する。ＨＴＴＰサーバ部１７１は、再びＨＴＴＰリクエストを待機する。本ステップにおいて、ＨＴＴＰレスポンスの内容部分にエラーが発生した旨を記述してもよいし、単純にＨＴＴＰが規定するエラーコードを返信してもよい。どのようなエラーが発生したのか明示する観点では、前者のほうが望ましい。
【００５４】
（図８：ステップＳ８０６）
ＨＴＴＰサーバ部１７１は、ＯＳＧｉサービス実行部１７２がＯＳＧｉサービスを実行した結果をＨＴＴＰレスポンス内に記述し、クライアント２０に返信する。ＨＴＴＰサーバ部１７１は、再びＨＴＴＰリクエストを待機する。
【００５５】
＜実施の形態１：まとめ＞
以上のように、本実施形態１に係るＷｅｂＡＰＩバンドル１７は、実行したいＯＳＧｉサービスのクラス名、メソッド名などを指定するＨＴＴＰリクエストを受け取り、当該メソッドを実行してその結果をＨＴＴＰレスポンスとして返信する。これにより、ネットワーク上で公開したいＯＳＧｉバンドルの持つＯＳＧｉサービスをサービスレジストリ１３１に登録しておけば、自動的にＷｅｂＡＰＩとしてネットワークに公開することができるので、個別にＨＴＴＰサーバ機能などを実装する必要がなくなり、開発負担を低減することができる。
【００５６】
また、本実施形態１に係るＷｅｂＡＰＩバンドル１７は、サービスレジストリ１３１からＯＳＧｉサービスを取得した後、汎用クラス型であるＯｂｊｅｃｔ型をＯＳＧｉバンドルのクラス型に変換することなく、クライアント２０が指定したメソッドをそのまま実行する。これにより、ＷｅｂＡＰＩバンドル１７をＯＳＧｉバンドルのクラス型から切り離し、クラス間の依存関係をなくして汎用性を高めることができる。すなわち、ＷｅｂＡＰＩバンドル１７は、サービスレジストリ１３１にどのようなＯＳＧｉサービスが登録されていても、そのクラス型をあらかじめ読み込んでおくことなく、指定されたクラスおよびメソッドを呼び出して実行することができる。
【００５７】
また、本実施形態１に係るＷｅｂＡＰＩバンドル１７は、サービスレジストリ１３１に登録されているクラス名、メソッド名などの一覧をクライアント２０に提供することができる。これにより、クライアント２０はリクエストを発行する前にエラーが発生する可能性を事前に知ることができるので、メソッドを実行してエラーが返ってくるか否かにより当該メソッドの存否を調べるような非効率な処理をしなくてすむ。
【００５８】
＜実施の形態２＞
実施形態１では、サービスレジストリ１３１に登録されているＯＳＧｉバンドルは無条件にネットワーク上へ公開される。しかし、ＯＳＧｉフレームワーク１３の機能を利用するためサービスレジストリ１３１に登録されているＯＳＧｉバンドルのなかには、ネットワークに公開したくないものも含まれている可能性がある。そこで本発明の実施形態２では、ネットワーク上に公開するＯＳＧｉバンドルとそうでないＯＳＧｉバンドルを区別するための手法を説明する。その他の構成は実施形態１と同様であるため、以下では差異点を中心に説明する。
【００５９】
図９は、本実施形態２において、ＷｅｂＡＰＩバンドル１７がＯＳＧｉサービスをＷｅｂＡＰＩとして公開する様子を示す図である。本実施形態２では、ＯＳＧｉバンドルのうちネットワーク上にＷｅｂＡＰＩとして公開するものについては、メンバ変数１５３（フィールド）「ｏｐｅｎａｐｉ」を設けることとする。
【００６０】
ＷｅｂＡＰＩバンドル１７は、ＯＳＧｉサービスを実行するようリクエストを受けたとき、またはサービスレジストリ１３１に登録されているＯＳＧｉサービスの一覧を取得するようリクエストを受けたとき、サービスレジストリ１３１から取得したＯＳＧｉバンドルクラスのメンバ変数「ｏｐｅｎａｐｉ」を取得する。同メンバ変数の値が「ｔｒｕｅ」である場合は、当該クラスが有するメソッドをＷｅｂＡＰＩとして公開してよいものと判断する。同メンバ変数の値が「ｔｒｕｅ」でない場合、または同メンバ変数が存在しない場合は、当該クラスが有するメソッドをＷｅｂＡＰＩとして公開しない。
【００６１】
ＷｅｂＡＰＩバンドル１７は、ＷｅｂＡＰＩとして公開しないクラスについてサービス実行リクエストを受けた場合は、エラーを返信する。また、ＷｅｂＡＰＩとして公開しないクラスについては、サービスレジストリ１３１に登録されているＯＳＧｉサービスの一覧をクライアント２０に返信するとき、その一覧に当該クラスを記述しないこととする。
【００６２】
ＷｅｂＡＰＩバンドル１７がサービスレジストリ１３１からＯＳＧｉバンドルクラス（ＯＳＧｉサービスクラス）を取得したとき、図５で説明したように、クラス型はＯｂｊｅｃｔ型となっている。そこでＷｅｂＡＰＩバンドル１７は、ｊａｖａ．ｌａｎｇ．ｒｅｆｌｅｃｔパッケージの機能を利用して、メンバ変数「ｏｐｅｎａｐｉ」にアクセスする。この手法によれば、同メンバ変数がｐｒｉｖａｔｅ指定されている（当該クラスの外部からアクセスすることを禁止する旨の宣言）場合でも、同メンバ変数にアクセスすることができる。
【００６３】
なお、メンバ変数「ｏｐｅｎａｐｉ」をｐｒｉｖａｔｅ宣言する場合、他のＯＳＧｉバンドルから同変数を参照することはできないので、他のＯＳＧｉバンドルにとっては同変数が存在しないに等しい。すなわち、本実施形態２に固有のメンバ変数を設けているか否かによらず、ＯＳＧｉフレームワーク１３にとっては全てのＯＳＧｉバンドルを同等に取り扱うことができるので、本実施形態２固有の格別の配慮を要さない点で便宜である。
【００６４】
＜実施の形態２：まとめ＞
以上のように、本実施形態２に係るＷｅｂＡＰＩバンドル１７は、サービスレジストリ１３１に登録されているＯＳＧｉバンドルのメンバ変数「ｏｐｅｎａｐｉ」の値をチェックし、当該クラスをＷｅｂＡＰＩとして公開してよいか否かを判定する。これにより、ネットワークに公開したいＯＳＧｉバンドルのみを選択的に公開することができるので、公開すべきでないＯＳＧｉバンドルを不用意にネットワークへ公開する可能性を低減することができる。
【００６５】
＜実施の形態３＞
本発明の実施形態３では、クライアント２０とＷｅｂＡＰＩバンドル１７の間のＨＴＴＰリクエストおよびＨＴＴＰレスポンスの形式について補足する。Ｗｅｂシステム１００の構成は、実施形態１〜２と同様である。
【００６６】
図１０は、ＷｅｂＡＰＩバンドル１７を介してＯＳＧｉサービスを呼び出す際に指定することのできるＨＴＴＰリクエストパラメータとレスポンス例を示す図である。
【００６７】
ＨＴＴＰはテキストベースのプロトコルであるため、Ｊａｖａオブジェクトをそのままリクエストおよびレスポンス内で用いることは難しい。したがって、クライアント２０からのリクエスト上およびクライアント２０へのレスポンス上で用いることができるのは、テキストベースで表現することのできる、Ｊａｖａ基本型およびＳｔｒｉｎｇ（文字列）型に限られる。すなわち、独自のクラス型や、任意のクラス型を含む配列（例えばＡｒｒａｙＬｉｓｔ）などは用いることができない。
【００６８】
また、Ｄｉｃｔｉｏｎａｒｙ型（内部的に複数の値を格納している、配列に似たクラス型）はレスポンス内で用いることはできるが、リクエストパラメータとして用いることは好ましくない。これは、ＨＴＴＰリクエストパラメータの記述形式に起因する。
【００６９】
ＨＴＴＰレスポンスは改行コードを含む任意のテキスト形式で記述することができるため、Ｊａｖａメソッドの実行結果がＤｉｃｔｉｏｎａｒｙ型であり、そのなかに複数の値が含まれている場合でも、全ての値をレスポンス内に記述することができる。
【００７０】
しかし、ＨＴＴＰリクエストパラメータは「ａｒｇ１＝１」のように、パラメータ名とその値を１つずつペアにして記述するため、パラメータ値がＤｉｃｔｉｏｎａｒｙ型になっていて内部的に複数の値を含む場合、「ａｒｇ１＝（ａｇｅ＝３０＆ｈｅｉｇｈｔ＝１７０）」のように多重的に記載せざるを得ず、煩雑になってしまう。また実際上、引数としてＤｉｃｔｉｏｎａｒｙ型を用いる必要性はあまりない。そこで図１０では、リクエストパラメータとしてＤｉｃｔｉｏｎａｒｙ型を用いないこととした。
【００７１】
図１１は、レスポンスの記述形式としてＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いる例を示す図である。レスポンスの内容は、図６と同様である。このようなＸＭＬ形式のレスポンスを、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）形式とも呼ぶ。レスポンスをＸＭＬ形式に変換する処理は、ＯＳＧｉサービスとの関連が少ない処理であるため、例えばＨＴＴＰサーバ部１７１が実施すればよい。
【００７２】
レスポンスのほか、ＨＴＴＰリクエストもＸＭＬ形式で記述することもできる。例えばＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）形式のＸＭＬメッセージをクライアント２０からＷｅｂＡＰＩバンドル１７に発行し、ＨＴＴＰサーバ部１７１がそのメッセージを解析して必要なパラメータのみをＯＳＧｉサービス実行部１７２に引き渡すようにすればよい。
【００７３】
＜実施の形態４＞
以上の実施形態１〜３では、ＷｅｂＡＰＩバンドル１７はＨＴＴＰリクエストとしてＯＳＧｉサービスのクラス名などを直接受け取ることとしたが、必ずしもクラス名などそのものを記述したリクエストパラメータを用いなくともよい。
【００７４】
例えば、ＷｅｂＡＰＩバンドル１７は、クラス名やメソッド名を所定規則で変換した文字列をリクエストパラメータとして受け取り、ＷｅｂＡＰＩバンドル１７の内部、または適当な変換モジュールなどを介して、ＯＳＧｉサービスのクラス名、メソッド名などに変換してもよい。すなわち、ＷｅｂＡＰＩバンドル１７は、少なくともＯＳＧｉサービスのクラス名、メソッド名などを特定することのできるリクエストパラメータを受け取れば足りる。
【符号の説明】
【００７５】
１０：ホスト、１１：ＯＳ、１２：ＪａｖａＶＭ、１３：ＯＳＧｉフレームワーク、１３１：サービスレジストリ、１３２：ＳｅｒｖｉｃｅＢ、１４：ＯＳＧｉバンドルＡ、１５：ＯＳＧｉバンドルＢ、１５１：機能Ｂ、１５２：ＷｅｂＡＰＩサーバ部、１５３：メンバ変数、１７：ＷｅｂＡＰＩバンドル、１７１：ＨＴＴＰサーバ部、１７２：ＯＳＧｉサービス実行部、１７３：ＯＳＧｉサービス一覧取得部、２０：クライアント、１００：Ｗｅｂシステム。
【特許請求の範囲】
【請求項１】
ＯＳＧｉフレームワーク仕様に対応したＯＳＧｉバンドルをＷｅｂＡＰＩ経由で公開する処理をコンピュータに実行させるプログラムであって、前記コンピュータに、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドルまたはＯＳＧｉサービスとして登録されているクラスのクラス名と当該クラスが有するメソッド名を特定することができるパラメータを含むＨＴＴＰリクエストを受け付ける受信ステップと、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドルまたはＯＳＧｉサービスとして登録されているクラスのうち前記クラス名に合致するものを、前記ＯＳＧｉフレームワークが公開しているインターフェースを介して呼び出すサービス呼出ステップと、
前記サービス呼出ステップで呼び出したクラスが有するメソッドのうち前記メソッド名に合致するものを実行するサービス実行ステップと、
前記サービス実行ステップの結果を、前記ＨＴＴＰリクエストの送信元にＨＴＴＰレスポンスの形式で返信する返信ステップと、
を実行させることを特徴とするＷｅｂＡＰＩサーバプログラム。
【請求項２】
前記サービス呼出ステップでは、前記コンピュータに、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドル（ＯＳＧｉサービス）として登録されているクラスのうち前記クラス名に合致するものを、汎用クラス型として呼び出させ、
前記サービス実行ステップでは、前記コンピュータに、
前記サービス呼出ステップで呼び出したクラスが有するメソッドのうち前記メソッド名に合致するものを、前記汎用クラス型から前記クラス名に対応するクラス型に変換する処理を介さずに実行させる
ことを特徴とする請求項１記載のＷｅｂＡＰＩサーバプログラム。
【請求項３】
前記ＯＳＧｉバンドルは、
当該ＯＳＧｉバンドルを構成しているクラスが有するメソッドをＷｅｂＡＰＩ経由で公開してよいか否かを示すメンバ変数を有しており、
前記ＷｅｂＡＰＩサーバプログラムは、前記コンピュータに、
前記サービス呼出ステップで呼び出したクラスが有する前記メンバ変数の値をチェックすることにより、当該クラスが有するメソッドをＷｅｂＡＰＩ経由で公開してよいか否かを判定する公開判定ステップを実行させ、
前記公開判定ステップにおいてＷｅｂＡＰＩ経由で公開してよいと判定したクラスが有するメソッドについてのみ前記サービス実行ステップおよび前記返信ステップを実行させる
ことを特徴とする請求項１または２記載のＷｅｂＡＰＩサーバプログラム。
【請求項４】
前記コンピュータに、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドルまたはＯＳＧｉサービスとして登録されているクラスのクラス名、当該クラスが有するメソッド名、当該メソッドの引数、および当該メソッドの戻り型の一覧を取得するサービス一覧取得ステップと、
前記サービス一覧取得ステップの結果を、前記ＨＴＴＰリクエストの送信元にＨＴＴＰレスポンスの形式で返信するステップと、
を実行させることを特徴とする請求項１から３のいずれか１項記載のＷｅｂＡＰＩサーバプログラム。
【請求項５】
前記ＷｅｂＡＰＩサーバプログラムは、ＯＳＧｉフレームワーク仕様に対応したＯＳＧｉバンドルとして実装されている
ことを特徴とする請求項１から４のいずれか１項記載のＷｅｂＡＰＩサーバプログラム。
【請求項６】
前記受信ステップおよび前記返信ステップにおいて、前記コンピュータに、
ＳＯＡＰ形式またはＲＥＳＴ形式の通信データを用いて、前記ＨＴＴＰリクエストの送信元との間で通信させる
ことを特徴とする請求項１から５のいずれか１項記載のＷｅｂＡＰＩサーバプログラム。
【請求項７】
ＯＳＧｉフレームワーク仕様に対応したＯＳＧｉバンドルの提供するＯＳＧｉサービスをＷｅｂＡＰＩ経由で公開する方法であって、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドルまたはＯＳＧｉサービスとして登録されているクラスのクラス名と当該クラスが有するメソッド名を特定することができるパラメータを含むＨＴＴＰリクエストを受け付けるステップと、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドルとして登録されているクラスのうち前記クラス名に合致するものを、前記ＯＳＧｉフレームワークが公開しているインターフェースを介して呼び出すサービス呼出ステップと、
前記サービス呼出ステップで呼び出したクラスが有するメソッドのうち前記メソッド名に合致するものを実行するサービス実行ステップと、
前記サービス実行ステップの結果を、前記ＨＴＴＰリクエストの送信元にＨＴＴＰレスポンスの形式で返信するステップと、
を有することを特徴とするＷｅｂＡＰＩ公開方法。
【請求項１】
ＯＳＧｉフレームワーク仕様に対応したＯＳＧｉバンドルをＷｅｂＡＰＩ経由で公開する処理をコンピュータに実行させるプログラムであって、前記コンピュータに、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドルまたはＯＳＧｉサービスとして登録されているクラスのクラス名と当該クラスが有するメソッド名を特定することができるパラメータを含むＨＴＴＰリクエストを受け付ける受信ステップと、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドルまたはＯＳＧｉサービスとして登録されているクラスのうち前記クラス名に合致するものを、前記ＯＳＧｉフレームワークが公開しているインターフェースを介して呼び出すサービス呼出ステップと、
前記サービス呼出ステップで呼び出したクラスが有するメソッドのうち前記メソッド名に合致するものを実行するサービス実行ステップと、
前記サービス実行ステップの結果を、前記ＨＴＴＰリクエストの送信元にＨＴＴＰレスポンスの形式で返信する返信ステップと、
を実行させることを特徴とするＷｅｂＡＰＩサーバプログラム。
【請求項２】
前記サービス呼出ステップでは、前記コンピュータに、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドル（ＯＳＧｉサービス）として登録されているクラスのうち前記クラス名に合致するものを、汎用クラス型として呼び出させ、
前記サービス実行ステップでは、前記コンピュータに、
前記サービス呼出ステップで呼び出したクラスが有するメソッドのうち前記メソッド名に合致するものを、前記汎用クラス型から前記クラス名に対応するクラス型に変換する処理を介さずに実行させる
ことを特徴とする請求項１記載のＷｅｂＡＰＩサーバプログラム。
【請求項３】
前記ＯＳＧｉバンドルは、
当該ＯＳＧｉバンドルを構成しているクラスが有するメソッドをＷｅｂＡＰＩ経由で公開してよいか否かを示すメンバ変数を有しており、
前記ＷｅｂＡＰＩサーバプログラムは、前記コンピュータに、
前記サービス呼出ステップで呼び出したクラスが有する前記メンバ変数の値をチェックすることにより、当該クラスが有するメソッドをＷｅｂＡＰＩ経由で公開してよいか否かを判定する公開判定ステップを実行させ、
前記公開判定ステップにおいてＷｅｂＡＰＩ経由で公開してよいと判定したクラスが有するメソッドについてのみ前記サービス実行ステップおよび前記返信ステップを実行させる
ことを特徴とする請求項１または２記載のＷｅｂＡＰＩサーバプログラム。
【請求項４】
前記コンピュータに、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドルまたはＯＳＧｉサービスとして登録されているクラスのクラス名、当該クラスが有するメソッド名、当該メソッドの引数、および当該メソッドの戻り型の一覧を取得するサービス一覧取得ステップと、
前記サービス一覧取得ステップの結果を、前記ＨＴＴＰリクエストの送信元にＨＴＴＰレスポンスの形式で返信するステップと、
を実行させることを特徴とする請求項１から３のいずれか１項記載のＷｅｂＡＰＩサーバプログラム。
【請求項５】
前記ＷｅｂＡＰＩサーバプログラムは、ＯＳＧｉフレームワーク仕様に対応したＯＳＧｉバンドルとして実装されている
ことを特徴とする請求項１から４のいずれか１項記載のＷｅｂＡＰＩサーバプログラム。
【請求項６】
前記受信ステップおよび前記返信ステップにおいて、前記コンピュータに、
ＳＯＡＰ形式またはＲＥＳＴ形式の通信データを用いて、前記ＨＴＴＰリクエストの送信元との間で通信させる
ことを特徴とする請求項１から５のいずれか１項記載のＷｅｂＡＰＩサーバプログラム。
【請求項７】
ＯＳＧｉフレームワーク仕様に対応したＯＳＧｉバンドルの提供するＯＳＧｉサービスをＷｅｂＡＰＩ経由で公開する方法であって、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドルまたはＯＳＧｉサービスとして登録されているクラスのクラス名と当該クラスが有するメソッド名を特定することができるパラメータを含むＨＴＴＰリクエストを受け付けるステップと、
前記ＯＳＧｉフレームワーク上でＯＳＧｉバンドルとして登録されているクラスのうち前記クラス名に合致するものを、前記ＯＳＧｉフレームワークが公開しているインターフェースを介して呼び出すサービス呼出ステップと、
前記サービス呼出ステップで呼び出したクラスが有するメソッドのうち前記メソッド名に合致するものを実行するサービス実行ステップと、
前記サービス実行ステップの結果を、前記ＨＴＴＰリクエストの送信元にＨＴＴＰレスポンスの形式で返信するステップと、
を有することを特徴とするＷｅｂＡＰＩ公開方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１２−４８３９１（Ｐ２０１２−４８３９１Ａ）
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願番号】特願２０１０−１８８６４２（Ｐ２０１０−１８８６４２）
【出願日】平成２２年８月２５日（２０１０．８．２５）
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
【Ｆターム（参考）】
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願日】平成２２年８月２５日（２０１０．８．２５）
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
【Ｆターム（参考）】
[ Back to top ]