JP2009290729A - 画像形成装置、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】複数のＷｅｂアプリケーションを適切に統合することのできる画像形成装置の提供を目的とする。
【解決手段】複数のプログラム実行手段を有する画像形成装置であって、プログラム実行手段ごとに、ＨＴＴＰリクエストに応じたＷｅｂページを生成する複数のＷｅｂページ生成手段と、複数のＷｅｂページ生成手段のそれぞれより、当該Ｗｅｂページ生成手段を利用させるためのメニュー項目の表示情報及び当該Ｗｅｂページ生成手段のＵＲＬを取得し、取得された情報を統合してプログラム実行手段ごとのファイルに保存すると共に、第一のファイルに他のプログラム実行手段に係るファイルより取得された情報をマージするメニュー情報統合手段と、ファイルに保存されている情報に基づいて、複数のＷｅｂページ生成手段を利用させるためのメニュー項目を含むＷｅｂページを生成するメニューページ生成手段とを有することにより上記課題を解決する。
【選択図】図７

Description

本発明は、画像形成装置、情報処理方法、及びプログラムに関し、特にＷｅｂサイトを提供する画像形成装置、情報処理方法、及びプログラムに関する。

従来、ネットワークを介してアプリケーションを利用するためのインフラとしてＷｅｂシステムが広く用いられている。Ｗｅｂシステムにおいて、アプリケーションは、Ｗｅｂサーバ又はアプリケーションサーバと呼ばれるサーバコンピュータ上にＷｅｂアプリケーションとして実装される。各Ｗｅｂアプリケーションには一意なＵＲＬ（Uniform Resource Locator）が割り当てられている。クライアント（Ｗｅｂブラウザ等）は、所望のＷｅｂアプリケーションに対するＵＲＬを指定してＨＴＴＰリクエストを送信することにより、当該Ｗｅｂアプリケーションのユーザインタフェース（Ｗｅｂページ）を表示させたり、当該Ｗｅｂアプリケーションに実装されたビジネスロジックを実行させたりすることができる。

ところで、近年ではコピー機、プリンタ、ファクシミリ、又は複合機等の画像形成装置においてもその機能をＷｅｂアプリケーションによって提供可能なものが存在する。このような画像形成装置によれば、利用者は、利用したい機能（Ｗｅｂアプリケーション）のＵＲＬをＷｅｂブラウザ等に入力することにより、当該機能を遠隔的に利用することができる。
特開２００４−３１８８４２号公報

しかしながら、利用者から見て画像形成装置は１台の機器である。したがって、複数のＷｅｂアプリケーションの集合としてではなく、一つのＷｅｂサイトとして利用者から認識されるような環境の構築が望ましい。

但し、他方において、近年のソフトウェア部品化技術の進歩により各Ｗｅｂアプリケーションの独立度は高くなっている。したがって、画像形成装置の機能強化に伴って、新たなＷｅｂアプリケーションを柔軟に追加可能な状態となっている。

したがって、単に複数のＷｅｂアプリケーションを一つのＷｅｂサイトとして統合的に見せるだけでなく、Ｗｅｂアプリケーションの構成の変化に柔軟に対応可能なＷｅｂサイトの構築が望まれる。

本発明は、上記の点に鑑みてなされたものであって、複数のＷｅｂアプリケーションを適切に統合することのできる画像形成装置、情報処理方法、及びプログラムの提供を目的とする。

そこで上記課題を解決するため、本発明は、複数のプログラム実行手段を有する画像形成装置であって、前記プログラム実行手段ごとに、ＨＴＴＰリクエストに応じた処理を実行し、処理結果を示す情報を表示させるＷｅｂページを生成する複数のＷｅｂページ生成手段と、複数の前記Ｗｅｂページ生成手段のそれぞれより、当該Ｗｅｂページ生成手段を利用させるためのメニュー項目の表示情報及び当該Ｗｅｂページ生成手段のＵＲＬを取得し、取得された情報を統合して前記プログラム実行手段ごとの第一のファイルに保存すると共に、前記第一のファイルに他の前記プログラム実行手段に係る前記第一のファイルより取得された情報をマージするメニュー情報統合手段と、前記第一のファイルに保存されている情報に基づいて、複数の前記Ｗｅｂページ生成手段を利用させるためのメニュー項目を含むＷｅｂページを生成するメニューページ生成手段とを有することを特徴とする。

このような画像形成装置では、複数のＷｅｂアプリケーションを適切に統合することができる。

本発明によれば、複数のＷｅｂアプリケーションを適切に統合することのできる画像形成装置、情報処理方法、及びプログラムを提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。本実施の形態では、複合機を画像形成装置の一例として説明する。複合機は、プリンタ、コピー、スキャナ、又は、ファクス等の複数の機能を一台の筐体において実現する画像形成装置である。

図１は、第一の実施の形態における複合機のプログラムの実行環境の構成例を説明するための図である。

図１では、複合機１が有するハードウェア資源の一部として、プロッタエンジン１１及びスキャナエンジン１２と、ソフトウェア資源の一部として、エンジン制御ボード１０１、ＯＳ１０２、ＪＶＭ（Java（登録商標） Virtual Machine）１０３、ＯＳＧｉ（Open Services Gateway Initiative）プラットフォーム１０４、バンドル１０５、及びネイティブコードサービス１０６等とが示されている。当該ソフトウェア資源は、複合機１が備える非図示の記憶装置に記録され、実装された処理手順を複合機１が備える非図示のＣＰＵに実行させることによりその機能を実現する。

エンジン制御ボード１０１は、プロッタエンジン１１及びスキャナエンジン１２等の複合機１の個別機能を制御し、エンジンＩ／Ｆ（インタフェース）を通して、エンジン制御ボード１０１の機能をＯＳ１０２等に提供する。

ＯＳ１０２は、いわゆるオペレーティング・システムであり、ＪＶＭ１０３や各ネイティブコードサービス１０６等をプロセスとして並列的に起動させる。ＪＶＭ１０３は、Ｊａｖａ（登録商標）言語に固有のバイトコードをＯＳ１０２上で動作可能なネイティブコードに変換して実行する。ＯＳＧｉプラットフォーム１０４は、ＯＳＧｉアライアンスによる標準化技術であり、Ｊａｖａ（登録商標）言語に基づいたオープンなソフトウェア部品化技術に基づいて作成されたソフトウェア部品の実行環境を提供するソフトウェアプラットフォームである。ＯＳＧｉプラットフォーム１０４上において、Ｊａｖａ（登録商標）言語のソフトウェアは「バンドル」と呼ばれるソフトウェア部品の形で実装される。一つのバンドルは、一つのＪＡＲ（Java（登録商標） ARchive）ファイルによって構成され、それぞれ独立して動的に（装置の再起動を要することなく）インストール可能である。バンドル１０５は、斯かるバンドルを示す。図示されるように、バンドル１０５は複数存在し得る。ネイティブコードサービス１０６は、例えば、Ｃ言語等によって作成された、ＯＳ１０１上において直接動作するネイティブコードによるプログラムであり、図示されるように複数存在しうる。各ネイティブコードサービス１０６は、例えば、複数のバンドル１０５より共通的に利用される各種の機能を実現する。ＪＶＭ１０３上でスレッドとして起動されるバンドル１０５によるネイティブコードサービス１０６の呼び出し（利用）は、例えば、ＪＮＩ（Java（登録商標） Native Interface）等を用いればよい。

以上のようなソフトウェア資源のうち、複合機１では、複数のバンドル１０５によって、Ｗｅｂサイトが実現される。図２は、第一の実施の形態において統合的なＷｅｂサイトを実現するための複数のバンドルの構成例を示す図である。

同図には、ＨＴＴＰサービスバンドル１０５−１と、ＷｅｂＵＩフレームワークバンドル１０５−２と、ＷｅｂＵＩコンテンツバンドル１０５−３ａ、３ｂ、及び３ｃ等の複数のＷｅｂＵＩコンテンツバンドル１０５−３とが示されている。これらはそれぞれ図１に示される一つのバンドル１０５に相当する。すなわち、図２では、図１のバンドル１０５のうち、Ｗｅｂサイトを実現するためのバンドル１０５の関係（階層関係）が示されている。

ＨＴＴＰサービスバンドル１０５−１は、いわゆるＨＴＴＰサーバ（ＨＴＴＰデーモン）として機能するバンドル１０５である。すなわち、ＨＴＴＰサービスバンドル１０５−１は、クライアント（Ｗｅｂブラウザ等）からのＨＴＴＰリクエストの受信、クライアントへのＨＴＴＰレスポンスの送信等、ＨＴＴＰ通信を制御する。

各ＷｅｂＵＩコンテンツバンドル１０５−３は、いわゆるＷｅｂアプリケーションとして機能するバンドル１０５である。すなわち、各ＷｅｂＵＩコンテンツバンドル１０５−３には一意なＵＲＬ（Uniform Resource Locator）が割り当てられている。各ＷｅｂＵＩコンテンツバンドル１０５−３は、自らに割り当てられたＵＲＬが指定されたＨＴＴＰリクエストに応じて固有のビジネスロジックを実行し、その処理結果を表示させるＷｅｂＵＩコンテンツ（ＨＴＭＬデータ等のＷｅｂページ）を生成する。

ＷｅｂＵＩフレームワークバンドル１０５−２は、それぞれ独立している複数のＷｅｂＵＩコンテンツバンドル１０５−３を統合し、一つのＷｅｂサイトを実現するための処理を実行するバンドル１０５である。複数のＷｅｂＵＩコンテンツバンドル１０５−３の統合の具体的な内容としては、複数のＷｅｂＵＩコンテンツバンドル１０５−３に対する共通の情報（セッション情報、認証情報、言語（表示言語）情報等）の管理や、ＨＴＴＰリクエストに指定されたＵＲＬに応じたＷｅｂＵＩコンテンツバンドル１０５−３の呼び分け（すなわち、ＨＴＴＰリクエストの分配）や、複数のＷｅｂＵＩコンテンツバンドル１０５−３のメニュー構成情報の管理等が挙げられる。

ＨＴＴＰリクエストの分配は、統合設定ファイル１１０に基づいて行われる。統合設定ファイルには、各ＵＲＬと各ＷｅｂＵＩコンテンツバンドル１０５−３との対応関係を示す情報（以下、「ＵＲＬ対応情報」という。）が含まれている。すなわち、ＷｅｂＵＩフレームワークバンドル１０５−２は、ＨＴＴＰリクエストに指定されたＵＲＬに対応するＷｅｂＵＩコンテンツバンドル１０５−３を統合設定ファイル１１０に基づいて判断し、当該ＷｅｂＵＩコンテンツバンドル１０５−３を呼び出してＨＴＴＰリクエストに応じた処理を実行させる。

また、メニュー構成情報は、メニューの階層構造や、メニューごとに表示情報（表示文字列等）及びＵＲＬ（ＷｅｂＵＩコンテンツバンドル１０５−３）との対応関係が定義された情報であり、統合メニューファイル１２０内に格納される。ここで、メニューとは、各ＷｅｂＵＩコンテンツバンドル１０５−３を利用させるためのメニューが表示されるＷｅｂページ（メニューページ）上におけるメニューをいう。

図３は、第一の実施の形態のメニューページの表示例を示す図である。同図のメニューページ５００において、メニュー５１０に含まれるメニュー項目（「ホーム」、「リモート操作」、「カスタマイズ」、「ジョブ／ログ」、及び「設定／管理」）は、ＷｅｂＵＩコンテンツバンドル１０５−３を呼び出すためのメニュー項目ではなく、メニューの階層構造を辿るためのメニュー項目である。一方、メニュー５１１、５１２、５１３、５１４、及び５１５は、ＷｅｂＵＩコンテンツバンドル１０５−３を呼び出すためのメニュー項目の集合（グループ）であり、その表示内容はメニュー５１０において選択されるメニュー項目に応じて変化する。すなわち、メニュー５１０のメニュー項目と、メニュー５１１、５１２、５１３、５１４、及び５１５との間には階層関係（親子関係）が存在する。また、メニュー５１１、５１２、５１３、５１４、及び５１５とそれぞれに含まれるメニュー項目との間にも階層関係（親子関係）が存在する。なお、同図では、メニュー５１０において「設定／管理」が選択されている状態が示されている。

したがって、図３の例に基づけば、メニュー構成情報には、メニュー５１０に含まれる各メニュー項目と他のメニューとの階層関係や、階層関係において末端のメニュー項目に対応するＵＲＬ等が定義されている。

メニューページ５００は、メニューページ５００のＵＲＬに対応したＷｅｂＵＩコンテンツバンドル１０５−３（例えば、ＷｅｂＵＩコンテンツバンドル１０５−３ａ）によって生成される。したがって、統合メニューファイル１２０は、当該ＷｅｂＵＩコンテンツバンドル１０５−３によってメニューページ５００を生成するために利用される。

なお、統合設定ファイル１１０及び統合メニューファイル１２０は、例えば、複合機１のＨＤＤ（Hard Disk Drive）に保存される。

ところで、統合設定ファイル１１０及び統合メニューファイル１２０は、ＷｅｂＵＩフレームワークバンドル１０５−２によって自動的に生成又は更新される。図４は、統合設定ファイル及び統合メニューファイルの生成処理を説明するための図である。前提として、各ＷｅｂＵＩコンテンツバンドル１０５−３は、設定ファイル及びメニューファイルを有する（関連付けられている）。設定ファイルは、当該ＷｅｂＵＩコンテンツバンドル１０５−３（の識別名）とＵＲＬとの対応関係を示す情報（ＵＲＬ対応情報）が記録されたファイルである。メニューファイルは、当該ＷｅｂＵＩコンテンツバンドル１０５−３のメニュー項目の表示内容及び配置位置を示す情報が記録されたファイルである。ここで、配置位置とは、メニューページ５００におけるメニューの階層構造上における配置位置をいう。

まず、各ＷｅｂＵＩコンテンツバンドル１０５−３は、それぞれが有しているメニューファイル及び設定ファイルを、ＷｅｂＵＩフレームワークバンドル１０５−２のファイル統合部１０５−２１に出力する（Ｓ１１、Ｓ１２、Ｓ１３）。但し、ファイル統合部１０５−２１が能動的に各ＷｅｂＵＩコンテンツバンドル１０５−３よりメニューファイル及び設定ファイルを取得してもよい。

続いて、ファイル統合部１０５−２１は、各ＷｅｂＵＩコンテンツバンドル１０５−３より収集されたメニューファイルを統合することにより統合メニューファイル１２０を生成する（Ｓ１４）。また、ファイル統合部１０５−２１は、各ＷｅｂＵＩコンテンツバンドル１０５−３より収集された設定ファイルを統合することにより統合設定ファイル１１０を生成又は更新する（Ｓ１５）。この際、ファイル統合部１０５−２１は、ＷｅｂＵＩコンテンツバンドル１０５−３間におけるＵＲＬの重複チェック等を行う。ＵＲＬが重複している場合、ファイル統合部１０５−２１は、統合設定ファイル１１０等の生成を中止する。なお、メニューファイルの統合及び設定ファイルの統合は、各メニューファイル又は設定ファイルの記述内容を直列的に並べることにより行えばよい。

続いて、ＷｅｂＵＩフレームワークバンドル１０５−２のリクエスト分配部１０５−２２は、生成又は更新された統合設定ファイル１１０よりＵＲＬ対応情報を取得し（Ｓ１６）、当該ＵＲＬ対応情報に含まれているＵＲＬの一覧（すなわち、ＷｅｂＵＩフレームワークバンドル１０５−２によって統合されるＷｅｂＵＩコンテンツバンドル１０５−３のＵＲＬの一覧）をＨＴＴＰサービスバンドル１０５−１に登録（通知）する（Ｓ１７）。

なお、ＨＴＴＰサービスバンドル１０５−１は、ＨＴＴＰリクエスト（例えば、メニューページ５００においてメニュー項目が選択されることにより送信されるＨＴＴＰリクエスト）の受信に応じ、当該ＨＴＴＰリクエストにおいて指定されているＵＲＬがＷｅｂＵＩフレームワークバンドル１０５−２より通知された一覧に含まれている場合は、当該ＨＴＴＰリクエストをＷｅｂＵＩフレームワークバンドル１０５−２のリクエスト分配部１０５−２２に通知する。リクエスト分配部１０５−２２は、当該ＨＴＴＰリクエストのＵＲＬに対応するＷｅｂＵＩコンテンツバンドル１０５−３を統合設定ファイル１１０に基づいて判定し、当該ＷｅｂＵＩコンテンツバンドル１０５−３を呼び出す。

続いて、複合機１の動作中に、新たなＷｅｂＵＩコンテンツバンドル１０５−３がインストール（追加）された場合の処理について説明する。図５は、第一の実施の形態においてＷｅｂＵＩコンテンツバンドルが追加された際の処理手順を説明するためのシーケンス図である。

例えば、新たにＷｅｂＵＩコンテンツバンドル１０５−３ｄがインストールされたとする。この場合、ＷｅｂＵＩコンテンツバンドル１０５−３ｄはインストールに応じて自らのメニューファイル及び設定ファイルの追加登録をＷｅｂＵＩフレームワークバンドル１０５−２のファイル統合部１０５−２１に要求する（Ｓ２１）。続いて、ファイル統合部１０５−２１は、新たに追加されたＷｅｂＵＩコンテンツバンドル１０５−３ｄの設定ファイルと統合設定ファイル１１０とに基づいてＵＲＬの重複の有無をチェックする（Ｓ２２）。ＵＲＬが重複している場合、ファイル統合部１０５は処理を中止し、ＵＲＬの変更等を促すメッセージ等を操作パネルに表示させる。

ＵＲＬが重複していない場合、ファイル統合部１０５−２１は、ＨＴＴＰサービスバンドル１０５−１に対してＵＲＬの一覧の登録の解除を要求する（Ｓ２３）。これにより、図４のステップＳ１７等において登録されているＵＲＬの一覧がＨＴＴＰサービスバンドル１０５−１において無効とされ、当該一覧に含まれるＵＲＬに係るＨＴＴＰリクエストの通知は中断される。

続いて、ファイル統合部１０５−２１は、ＷｅｂＵＩコンテンツバンドル１０５−３ｄのメニューファイル及び設定ファイルの内容を、統合メニューファイル１２０又は統合設定ファイル１１０に追加する（Ｓ２４）。続いて、ＷｅｂＵＩフレームワークバンドル１０５−２のリクエスト分配部１０５−２２は、更新された統合設定ファイル１１０に基づくＵＲＬの一覧をＨＴＴＰサービスバンドル１０５−１に登録する（Ｓ２５）。これにより、ＷｅｂＵＩフレームワークバンドル１０５−２上のＷｅｂＵＩコンテンツバンドル１０５−３に対するＨＴＴＰリクエストは有効なものとして扱われる。

上述したように、第一の実施の形態における複合機１によれば、それぞれ独立度の非常に高い各ＷｅｂＵＩコンテンツバンドル１０５−３を適切に統合し、一つのＷｅｂサイトを構築することができる。

次に、第二の実施の形態について説明する。第二の実施の形態では第一の実施の形態と異なる点について説明する。

図６は、第二の実施の形態における複合機のプログラムの実行環境の構成例を説明するための図である。図６中、図１と同一部分には同一符号を付し、その説明は適宜省略する。

同図に示されるように、複合機２は、コアＪＶＭ１０３ａ、アプリＪＶＭ１０３ｂ、及拡張ＪＶＭ１０３ｃ等の３つのＪＶＭ１０３を有し、ＪＶＭ１０３ごとに、図１において説明した構成（ＯＳＧｉプラットフォーム１０４、バンドル１０５）を有する。各ＪＶＭ１０３上におけるＯＳＧｉプラットフォーム１０４及びバンドル１０５は、それぞれの参照番号の末尾に「ａ」、「ｂ」、又は「ｃ」が付されることによって区別される。

基本的に、各ＪＶＭ１０３自体の機能（実装内容）は同じである。但し、ＪＶＭ１０３ごとに他のＪＶＭ環境又はネイティブ環境に対するアクセス権限が異なる。具体的には、コアＪＶＭ１０３ａは、例えば、複合機２のメーカー等によって作成されたバンドル１０５等、最も信頼度が高いバンドル１０５に対する実行環境を提供する。コアＪＶＭ１０３ａ上で動作するバンドル１０５を、便宜上「コアバンドル１０５ａ」という。コアバンドル１０５ａは、例えば、ネイティブコードサービス１０６及びエンジン制御ボード１０２によって提供される全ての機能を直接呼び出す（利用する）ことができる。但し、コアバンドル１０５ａによるネイティブコードサービス１０６又はエンジン制御ボード１０２の利用に関して制限を設けてもよい。

アプリＪＶＭ１０３ｂは、コアバンドル１０５ａより信頼度の低い、又は複合機２の資源に対するアクセス制限が厳しくされるべきバンドル１０５に対する実行環境を提供する。アプリＪＶＭ１０３ｂ上で動作するバンドル１０５を、便宜上「アプリバンドル１０５ｂ」という。アプリバンドル１０５ｂは、ネイティブコードサービス１０が提供する機能を直接利用することができる。但し、アプリバンドル１０５ｂによるネイティブコードサービス１０６の利用には、コアバンドル１０５ａに対して相対的に厳しい制限が設けられる。また、アプリバンドル１０５ｂは、コアバンドル１０５ａの全て又は一部の機能を直接利用することができる。なお、異なるＪＶＭ環境間の呼び出しは、ＲＭＩ（Remote Method Invocation）等を用いた公知の記述に従えばよい。

拡張ＪＶＭ１０３ｃは、アプリバンドル１０５ｂより信頼度の低い、又は複合機２の資源に対するアクセス制限が厳しくされるべきバンドル１０５に対する実行環境を提供する。拡張ＪＶＭ１０３ｃ上で動作するバンドル１０５を、便宜上「拡張バンドル１０５ｃ」という。拡張バンドル１０５ｃは、予め設定された制限の範囲内でコアバンドル１０５ａ及びアプリバンドル１０５ｂの機能を直接利用することができる。但し、拡張バンドル１０５ｃは、ネイティブコードサービス１０が提供する機能の直接的な利用は許可されない。

このように、複合機２では、ＪＶＭ環境単位でバンドル１０５のアクセス権限が制御される。図６では、３つのＪＶＭ１０３を備えた例が示されているため、各バンドル１０５のセキュリティレベルをどのＪＶＭ１０３で動作させるかによって３段階に分類することができる。したがって、バンドル１０５ごとにアクセス権限を制御する場合に比べて、より簡便に各アプリケーションのアクセス制御を行うことができる。なお、ＪＶＭ１０３は、２つであってもよいし、複合機２のハードウェア資源のスペックに応じて４つ以上であってもよい。２つの場合は、２段階のセキュリティレベルを形成することができ、４つ以上の場合は４つ以上のセキュリティレベルを形成することができる。

以上のような環境において、第二の実施の形態では次のようなバンドル構成によってＷｅｂサイトが実現される。図７は、第二の実施の形態において統合的なＷｅｂサイトを実現するためのバンドルの構成例を示す図である。

同図において、コアＪＶＭ１０３ａ上には、ＨＴＴＰサービスバンドル１０５ａ−１がコアバンドル１０５ａによって実装される。一方、アプリＪＶＭ１０３ｂ及び拡張ＪＶＭ１０３ｃ上のそれぞれの構成は、第一の実施の形態と同様である。すなわち、アプリＪＶＭ１０３ｂ上には、ＨＴＴＰサービスバンドル１０５ｂ−１、ＷｅｂＵＩフレームワークバンドル１０５ｂ−２、及び一つ以上のＷｅｂＵＩコンテンツバンドル１０５ｂ−３がアプリバンドル１０５によって実装される。また、拡張ＪＶＭ１０３ｃ上には、ＨＴＴＰサービスバンドル１０５ｃ−１、ＷｅｂＵＩフレームワークバンドル１０５ｃ−２、及び一つ以上のＷｅｂＵＩコンテンツバンドル１０５ｃ−３が拡張バンドル１０５によって実装される。

各バンドル１０５の機能は、第一の実施の形態において説明した通りである。なお、ＨＴＴＰサービスバンドル１０５ａ−１、１０５ｂ−１、及び１０５ｃ−１のそれぞれにおいて、ＨＴＴＰリクエストを受信するためのポート番号は異なっており、ＨＴＴＰサービスバンドル１０５ａ−１のポートのみが外部に（ネットワーク上に）公開される。

ところで、第二の実施の形態では、ＷｅｂＵＩフレームワークバンドル１０５ｂ−２及び１０５ｃ−２といった二つのＷｅｂＵＩフレームワークバンドル１０５−２が存在する。したがって、第二の実施の形態では、二つのＷｅｂＵＩフレームワーク１０５−２を統合するための仕組みが必要とされる。以下、斯かる仕組みの実現例について説明する。

まず、引き続き図６を用いて、統合設定ファイル１１０及び統合メニューファイル１２０の生成の際に実行される処理について説明する。

アプリＪＶＭ１０３ｂ上の各ＷｅｂＵＩコンテンツバンドル１０５ｂ−３は、それぞれが有しているメニューファイル及び設定ファイルを、ＷｅｂＵＩフレームワークバンドル１０５ｂ−２（のファイル統合部）に出力する（Ｓ３１）。同様に、拡張ＪＶＭ１０３ｃ上の各ＷｅｂＵＩコンテンツバンドル１０５ｃ−３は、それぞれが有しているメニューファイル及び設定ファイルを、ＷｅｂＵＩフレームワークバンドル１０５ｃ−２（のファイル統合部）に出力する（Ｓ４１）。

続いて、ＷｅｂＵＩフレームワークバンドル１０５ｂ−２は、収集されたメニューファイルを統合することにより統合メニューファイル１２０ｂを生成する（Ｓ３２）。また、フＷｅｂＵＩフレームワークバンドル１０５ｂ−２は、収集された設定ファイルを統合することにより統合設定ファイル１１０ｂを生成又は更新する（Ｓ３３）。同様に、ＷｅｂＵＩフレームワークバンドル１０５ｃ−２は、収集されたメニューファイルを統合することにより統合メニューファイル１２０ｃを生成する（Ｓ４２）。また、フＷｅｂＵＩフレームワークバンドル１０５ｃ−２は、収集された設定ファイルを統合することにより統合設定ファイル１１０ｃを生成又は更新する（Ｓ４３）。なお、設定ファイルの統合に際し、ＵＲＬの重複がチェックされるのは第一の実施の形態と同様である。

続いて、ＷｅｂＵＩフレームワークバンドル１０５ｂ−２は、統合設定ファイル１１０ｂに基づくＵＲＬの一覧をＨＴＴＰサービスバンドル１０５ｂ−１に登録する（Ｓ３４）。同様に、ＷｅｂＵＩフレームワークバンドル１０５ｃ−２は、統合設定ファイル１１０ｃに基づくＵＲＬの一覧をＨＴＴＰサービスバンドル１０５ｃ−１に登録する（Ｓ４４）。

続いて、ＨＴＴＰサービスバンドル１０５ｂ−１は、登録されたＵＲＬの一覧をコアＪＶＭ１０５ａ−１上のＨＴＴＰサービスバンドル１０５ａ−１に通知し、当該一覧（以下、「アプリＵＲＬ一覧」という。）に含まれるＵＲＬが指定されたＨＴＴＰリクエストの振り分けを要求する（Ｓ３５）。同様に、ＨＴＴＰサービスバンドル１０５ｃ−１は、登録されたＵＲＬの一覧をＨＴＴＰサービスバンドル１０５ａ−１に通知し、当該一覧（以下、「拡張ＵＲＬ一覧」という。）に含まれるＵＲＬが指定されたＨＴＴＰリクエストの振り分けを要求する（Ｓ４５）。

なお、上記では、アプリＪＶＭ１０３ｂ上の処理と拡張ＪＶＭ１０３ｃ上の処理とを並列的に記載したが、それぞれのＪＶＭ１０３上における処理は同期がとられていなくてもよい。但し、図８に示されるように、所定のタイミング（例えば、ＷｅｂＵＩフレームワークバンドル１０５ｂ−２又は１０５ｃ−２によって統合設定ファイル１１０又は統合メニューファイル１２０が生成又は更新されたとき）において、ＷｅｂＵＩフレームワークバンドル１０５ｂ−２とＷｅｂＵＩフレームワークバンドル１０５ｃ−２とは、それぞれの管理情報（統合設定ファイル１１０又は統合メニューファイル１２０に格納されている情報）をＲＭＩ（Remote Method Invocation）等によって交換し合う。

これにより、各ＷｅｂＵＩフレームワークバンドル１０５−２は、他方のＷｅｂＵＩフレームワークバンドル１０５−２によって管理される統合メニューファイル１２０の内容（メニュー構成情報）と、自らが管理する統合メニューファイル１２０の内容とをマージして新たな統合メニューファイル１２０を生成する。したがって、各ＷｅｂＵＩフレームワークバンドル１０５−２間で同じ内容の統合メニューファイル１２０が管理される（メニュー構成情報が共有される）。その結果、双方のＷｅｂＵＩフレームワークバンドル１０５−２上に、メニューページ５００を生成するＷｅｂＵＩコンテンツバンドル１０５−３が実装されている場合であっても、双方のＷｅｂＵＩコンテンツバンドル１０５−３によって生成されるメニューページ５００のメニューの構成は同じとなる。

また、各ＷｅｂＵＩフレームワークバンドル１０５−２は、他方のＷｅｂＵＩフレームワークバンドル１０５−２によって管理される統合設定ファイル１１０に登録されているＵＲＬと、自らが管理する統合設定ファイル１１０に登録されているＵＲＬとの重複チェックを行う。重複が検出された場合、重複しているＵＲＬを操作パネル等に表示させることにより操作者に対して修正を促す。これにより、ＷｅｂＵＩフレームワークバンドル１０５−２を跨いだ（ＪＶＭ１０３を跨いだ）ＵＲＬの重複が回避される。

続いて、ＨＴＴＰリクエスト受信時の処理について説明する。図９は、第二の実施の形態におけるＨＴＴＰリクエスト受信時の処理手順を説明するための図である。

Ｗｅｂブラウザ５１からのＨＴＴＰリクエストは、コアＪＶＭ１０３ａ上のＨＴＴＰサービスバンドル１０５ａ−１によって受信される（Ｓ５１）。上述したように、ＨＴＴＰサービスバンドル１０５ａ−１のみのポートが外部に公開されているため、各ＪＶＭ１０３のＷｅｂＵＩコンテンツバンドル１０５−３に対するＨＴＴＰリクエストは、ＨＴＴＰサービスバンドル１０５ａ−１によって統合的に受信される。ＨＴＴＰサービスバンドル１０５ａ−１は、受信されたＨＴＴＰリクエストにおいて指定されているＵＲＬと、アプリＵＲＬ一覧又は拡張ＵＲＬ一覧とに基づいて当該ＨＴＴＰリクエストの振り分け先を判定する。すなわち、受信されたＵＲＬがアプリＵＲＬ一覧に含まれている場合、ＨＴＴＰサービスバンドル１０５ａ−１は、当該ＨＴＴＰリクエストをＨＴＴＰサービスバンドル１０５ｂ−１に転送する（Ｓ５２）。一方、受信されたＵＲＬが拡張ＵＲＬ一覧に含まれている場合、ＨＴＴＰサービスバンドル１０５ａ−１は、当該ＨＴＴＰリクエストをＨＴＴＰサービスバンドル１０５ｃ−１に転送する（Ｓ５３）。その後に実行される処理手順については、第一の実施の形態において説明した通りであるため、ここでの説明は省略する。

続いて、複合機２の動作中に、新たなＷｅｂＵＩコンテンツバンドル１０５ｃ−３に係る拡張バンドル１０５ｃがインストール（追加）された場合の処理について説明する。図１０は、第二の実施の形態においてＷｅｂＵＩコンテンツバンドルが追加された際の処理手順を説明するためのシーケンス図である。

例えば、新たにＷｅｂＵＩコンテンツバンドル１０５ｃ−３ｃが拡張ＪＶＭ１０３ｃ上にインストールされたとする。この場合、ＷｅｂＵＩコンテンツバンドル１０５ｃ−３ｃはインストールに応じて自らのメニューファイル及び設定ファイルの追加登録をＷｅｂＵＩフレームワークバンドル１０５ｃ−２に要求する（Ｓ７１）。続いて、ＷｅｂＵＩフレームワークバンドル１０５ｃ−２は、新たに追加されたＷｅｂＵＩコンテンツバンドル１０５ｃ−３ｃの設定ファイルと統合設定ファイル１１０ｃとに基づいてＵＲＬの重複の有無をチェックする（Ｓ７２）。また、ＷｅｂＵＩフレームワークバンドル１０５ｃ−２は、ＷｅｂＵＩコンテンツバンドル１０５ｃ−３ｃの設定ファイルを、ＷｅｂＵＩフレームワークバンドル１０５ｂ−２に送信し、ＵＲＬの重複のチェックを要求する（Ｓ７３）。ＵＲＬが重複している場合、ＷｅｂＵＩフレームワークバンドル１０５ｃ−２は処理を中止し、ＵＲＬの変更等を促すメッセージ等を操作パネルに表示させる。

続いて、ＷｅｂＵＩフレームワークバンドル１０５ｃ−２は、ＷｅｂＵＩコンテンツバンドル１０５ｃ−３ｃの設定ファイル及びメニューファイルの内容を、統合設定ファイル１１０ｃ又は統合メニューファイル１２０ｃ又に追加する（Ｓ７４、Ｓ７５）。なお、統合設定ファイル１１０ｃ及び統合メニューファイル１２０ｃの更新の前後において、第一の実施の形態と同様に、ＨＴＴＰサービスバンドル１０５ｃ−１に対するＵＲＬの一覧の登録の解除及び再登録が行われる。

続いて、ＷｅｂＵＩフレームワークバンドル１０５ｃ−２は、メニュー構成情報が更新されたことをＷｅｂＵＩフレームワークバンドル１０５ｂ−２に通知する（Ｓ７６）。当該通知を受けて、ＷｅｂＵＩフレームワークバンドル１０５ｂ−２は、ＷｅｂＵＩフレームワークバンドル１０５ｃ−２よりメニュー構成情報（更新されたメニューファイル１２０ｃに格納されているメニュー構成情報）を取得し（Ｓ７７）、取得されたメニュー構成情報を、統合メニューファイル１２０ｂにマージする（Ｓ７８）。

上述したように、第二の実施の形態における複合機２によれば、複数のＪＶＭ１０３にＷｅｂＵＩフレームワークバンドル１０５−２が分散されて実装されている形態あっても、複合機２全体として統合されたＷｅｂサイトを構築することができる。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

第一の実施の形態における複合機のプログラムの実行環境の構成例を説明するための図である。 第一の実施の形態において統合的なＷｅｂサイトを実現するためのバンドルの構成例を示す図である。 第一の実施の形態のメニューページの表示例を示す図である。 統合設定ファイル及び統合メニューファイルの生成処理を説明するための図である。 第一の実施の形態においてＷｅｂＵＩコンテンツバンドルが追加された際の処理手順を説明するためのシーケンス図である。 第二の実施の形態における複合機のプログラムの実行環境の構成例を説明するための図である。 第二の実施の形態において統合的なＷｅｂサイトを実現するためのバンドルの構成例を示す図である。 ＷｅｂＵＩフレームワークバンドル間における情報交換を説明するための図である。 第二の実施の形態におけるＨＴＴＰリクエスト受信時の処理手順を説明するための図である。 第二の実施の形態においてＷｅｂＵＩコンテンツバンドルが追加された際の処理手順を説明するためのシーケンス図である。

符号の説明

１、２ 複合機
１１ プロッタエンジン
１２ スキャナエンジン
１０１ エンジン制御ボード
１０２ ＯＳ
１０３ ＪＶＭ
１０４ ＯＳＧｉプラットフォーム
１０５ バンドル
１０５−１、１０５ａ−１、１０５ｂ−１、１０５ｃ−１ ＨＴＴＰサービスバンドル
１０５−２、１０５ａ−２、１０５ｂ−２、１０５ｃ−２ ＷｅｂＵＩフレームワークバンドル
１０５−２１ ファイル統合部
１０５−２２ リクエスト分配部
１０５−３、３ａ、３ｂ、３ｃ ＷｅｂＵＩコンテンツバンドル
１０６ ネイティブコードサービス
１１０、１１０ａ、１１０ｂ 統合設定ファイル
１２０、１２０ａ、１２０ｂ 統合メニューファイル

Claims (15)

1. 複数のプログラム実行手段を有する画像形成装置であって、
   前記プログラム実行手段ごとに、
   ＨＴＴＰリクエストに応じた処理を実行し、処理結果を示す情報を表示させるＷｅｂページを生成する複数のＷｅｂページ生成手段と、
   複数の前記Ｗｅｂページ生成手段のそれぞれより、当該Ｗｅｂページ生成手段を利用させるためのメニュー項目の表示情報及び当該Ｗｅｂページ生成手段のＵＲＬを取得し、取得された情報を統合して前記プログラム実行手段ごとの第一のファイルに保存すると共に、前記第一のファイルに他の前記プログラム実行手段に係る前記第一のファイルより取得された情報をマージするメニュー情報統合手段と、
   前記第一のファイルに保存されている情報に基づいて、複数の前記Ｗｅｂページ手段を利用させるためのメニュー項目を含むＷｅｂページを生成するメニューページ生成手段とを有する画像形成装置。
2. 前記プログラム実行手段ごとに、
   複数の前記Ｗｅｂページ生成手段のそれぞれより、ＵＲＬとの対応情報を取得し、取得された前記対応情報を統合して前記プログラム実行手段ごとの第二のファイルに保存するＵＲＬ情報統合手段と、
   受信されるＨＴＴＰリクエストにおいて指定されたＵＲＬに対応する前記Ｗｅｂページ生成手段を前記第二のファイルに基づいて判定し、判定された前記Ｗｅｂページ生成手段に当該ＨＴＴＰリクエストに対応した処理を実行させるリクエスト分配手段とを有する請求項１記載の画像形成装置。
3. 前記ＵＲＬ情報統合手段は、取得された前記対応情報に基づいてＵＲＬの重複の有無を判定し、ＵＲＬが重複していない場合に前記対応情報を統合する請求項２記載の画像形成装置。
4. 前記ＵＲＬ情報統合手段は、前記第二のファイルに保存された前記対応情報に含まれるＵＲＬと他の前記プログラム実行手段の前記第二のファイルより取得された前記対応情報に含まれるＵＲＬとの重複の有無を判定し、重複が検出されたことを操作パネルに表示させる請求項３記載の画像形成装置。
5. 前記複数のプログラム実行手段の前記Ｗｅｂページ生成手段に対するＨＴＴＰリクエストを統合的に受信するリクエスト受信手段を有し、
   前記リクエスト受信手段は、前記第二のファイルに保存された情報を前記各プログラム実行手段より取得し、取得された情報に基づいて前記ＨＴＴＰリクエストに対応する前記Ｗｅｂページ生成手段が属する前記プログラム実行手段の前記リクエスト分配手段へ、該ＨＴＴＰリクエストを通知することを特徴とする請求項１乃至４いずれか一項記載の画像形成装置。
6. 複数のプログラム実行手段を有する画像形成装置が実行する情報処理方法であって、
   前記プログラム実行手段ごとに、
   ＨＴＴＰリクエストに応じた処理を実行し、処理結果を示す情報を表示させるＷｅｂページを生成する複数のＷｅｂページ生成手手段のそれぞれより、当該Ｗｅｂページ生成手段を利用させるためのメニュー項目の表示情報及び当該Ｗｅｂページ生成手段のＵＲＬを取得し、取得された情報を統合して前記プログラム実行手段ごとの第一のファイルに保存すると共に、前記第一のファイルに他の前記プログラム実行手段に係る前記第一のファイルより取得された情報をマージするメニュー情報統合手順と、
   前記第一のファイルに保存されている情報に基づいて、複数の前記Ｗｅｂページ生成手段を利用させるためのメニュー項目を含むＷｅｂページを生成するメニューページ生成手順とを有する情報処理方法。
7. 前記プログラム実行手段ごとに、
   複数の前記Ｗｅｂページ生成手段のそれぞれより、ＵＲＬとの対応情報を取得し、取得された前記対応情報を統合して前記プログラム実行手段ごとの第二のファイルに保存するＵＲＬ情報統合手順と、
   受信されるＨＴＴＰリクエストにおいて指定されたＵＲＬに対応する前記Ｗｅｂページ生成手段を前記第二のファイルに基づいて判定し、判定された前記Ｗｅｂページ生成手段に当該ＨＴＴＰリクエストに対応した処理を実行させるリクエスト分配手順とを有する請求項６記載の情報処理方法。
8. 前記ＵＲＬ情報統合手順は、取得された前記対応情報に基づいてＵＲＬの重複の有無を判定し、ＵＲＬが重複していない場合に前記対応情報を統合する請求項７記載の情報処理方法。
9. 前記ＵＲＬ情報統合手順は、前記第二のファイルに保存された前記対応情報に含まれるＵＲＬと他の前記プログラム実行手段の前記第二のファイルより取得された前記対応情報に含まれるＵＲＬとの重複の有無を判定し、重複が検出されたことを操作パネルに表示させる請求項８記載の情報処理方法。
10. 前記複数のプログラム実行手段の前記Ｗｅｂページ生成手段に対するＨＴＴＰリクエストを統合的に受信するリクエスト受信手順を有し、
    前記リクエスト受信手順は、前記第二のファイルに保存された情報を前記各プログラム実行手段より取得し、取得された情報に基づいて前記ＨＴＴＰリクエストに対応する前記Ｗｅｂページ生成手段が属する前記プログラム実行手段の前記リクエスト分配手順へ、該ＨＴＴＰリクエストを通知することを特徴とする請求項６乃至９いずれか一項記載の情報処理方法。
11. 複数のプログラム実行手段を有する画像形成装置に、
    ＨＴＴＰリクエストに応じた処理を実行し、処理結果を示す情報を表示させるＷｅｂページを生成する複数のＷｅｂページ生成手段のそれぞれより、当該Ｗｅｂページ生成手段を利用させるためのメニュー項目の表示情報及び当該Ｗｅｂページ生成手段のＵＲＬを取得し、取得された情報を統合して前記プログラム実行手段ごとの第一のファイルに保存すると共に、前記第一のファイルに他の前記プログラム実行手段に係る前記第一のファイルより取得された情報をマージするメニュー情報統合手順と、
    前記第一のファイルに保存されている情報に基づいて、複数の前記Ｗｅｂページ生成手段を利用させるためのメニュー項目を含むＷｅｂページを生成するメニューページ生成手順とを前記プログラム実行手段ごとに実行させるプログラム。
12. 複数の前記Ｗｅｂページ生成手段のそれぞれより、ＵＲＬとの対応情報を取得し、取得された前記対応情報を統合して前記プログラム実行手段ごとの第二のファイルに保存するＵＲＬ情報統合手順と、
    受信されるＨＴＴＰリクエストにおいて指定されたＵＲＬに対応する前記Ｗｅｂページ生成手段を前記第二のファイルに基づいて判定し、判定された前記Ｗｅｂページ生成手段に当該ＨＴＴＰリクエストに対応した処理を実行させるリクエスト分配手順とを前記プログラム実行手段ごとに実行させる請求項１１記載のプログラム。
13. 前記ＵＲＬ情報統合手順は、取得された前記対応情報に基づいてＵＲＬの重複の有無を判定し、ＵＲＬが重複していない場合に前記対応情報を統合する請求項１２記載のプログラム。
14. 前記ＵＲＬ情報統合手順は、前記第二のファイルに保存された前記対応情報に含まれるＵＲＬと他の前記プログラム実行手段の前記第二のファイルより取得された前記対応情報に含まれるＵＲＬとの重複の有無を判定し、重複が検出されたことを操作パネルに表示させる請求項１３記載のプログラム。
15. 前記複数のプログラム実行手段の前記Ｗｅｂページ生成手段に対するＨＴＴＰリクエストを統合的に受信するリクエスト受信手順を実行させ、
    前記リクエスト受信手順は、前記第二のファイルに保存された情報を前記各プログラム実行手段より取得し、取得された情報に基づいて前記ＨＴＴＰリクエストに対応する前記Ｗｅｂページ生成手段が属する前記プログラム実行手段の前記リクエスト分配手順へ、該ＨＴＴＰリクエストを通知することを特徴とする請求項１１乃至１４いずれか一項記載のプログラム。

Images