以下、本発明の実施形態について図面を参照しながら詳細に説明する。
[第一の実施形態]
<システム構成>
まず、本実施形態に係る情報処理システム1のシステム構成について、図1を参照しながら説明する。図1は、第一の実施形態に係る情報処理システムの一例のシステム構成を示す図である。
図1に示す情報処理システム1は、サービス提供環境E1、ユーザ環境E2、及び外部ストレージシステム40を含み、インターネット等の広域的なネットワークN1を介して通信可能に接続されている。
サービス提供環境E1は、ネットワークN1を介してクラウドサービス等の外部サービスを提供するシステム環境である。なお、本実施形態では、外部サービスの具体例としてクラウドサービスを採用して説明するが、ASP(Application Service Provider)によって提供されるサービスやWebサービス等、ネットワークを介して提供されるサービスに関して本実施形態が適用されても良い。
サービス提供環境E1は、一台以上の情報処理装置で実現されるサービス提供システム10を有する。サービス提供システム10は、ネットワークN1を介して所定のサービスを提供する。例えば、サービス提供システム10は、ユーザ環境E2の画像形成装置20において原稿をスキャンして生成された電子ファイルを、OCR(Optical Character Reader)処理して、外部ストレージシステム40に保存するサービス(スキャン配信サービス)を提供する。本実施形態に係るサービス提供システム10は、このようなスキャン配信サービスを提供する。
ただし、サービス提供システム10により提供されるサービスは、これに限られない。サービス提供システム10は、例えば、外部ストレージシステム40に保存されている電子ファイルを、ユーザ環境E2の画像形成装置20で印刷するサービス(クラウドプリントサービス)を提供しても良い。
また、サービス提供システム10は、例えば、外部ストレージシステム40に保存されている電子ファイルを、ユーザ環境E2のプロジェクタで投影するサービスを提供しても良い。さらに、サービス提供システム10は、画像形成装置20において原稿をスキャンして生成された電子ファイルを、OCR処理した後、所定の言語に翻訳(例えば、英語から日本語に翻訳)して、外部ストレージシステム40に保存するサービスを提供しても良い。このように、本実施形態に係るサービス提供システム10は、外部ストレージシステム40と連携した一連の処理により実現される各種のサービスを提供する。
なお、サービス提供システム10の全部又は一部は、ユーザ環境E2に設置されていても良い。すなわち、サービス提供システム10を構成する情報処理装置の全部又は一部は、ユーザ環境E2に包含されていても良い。
ユーザ環境E2は、例えば、画像形成装置20を使用するユーザである企業等におけるシステム環境である。ユーザ環境E2は、一台以上の画像形成装置20、及び一台以上のPC端末30を含み、例えばLAN(Local Area Network)等のネットワークを介して接続されている。
本実施形態に係る画像形成装置20は、スキャン機能を有するMFP(Multifunction Peripheral)等の複合機である。なお、画像形成装置20は、スキャン機能以外に、プリント機能やコピー機能、ファクス(FAX)通信機能等を有していても良い。
また、本実施形態に係るPC端末30は、サービス提供システム10が各種のサービスを提供するためのプログラムの開発等に用いられる情報処理装置である。ユーザは、PC端末30を用いて、所定の処理を実行するプログラムやモジュール等をサービス提供システム10に追加等することができる。
外部ストレージシステム40は、ネットワークN1を介してストレージサービス(又はオンラインストレージ)と呼ばれるクラウドサービスを提供するコンピュータシステムである。
ストレージサービスとは、外部ストレージシステム40のストレージの記憶領域を貸し出すサービスである。本実施形態では、スキャン配信サービスにおいて、外部ストレージシステム40によって貸し出される記憶領域に、OCR処理された電子ファイルを保存(アップロード)する。
なお、以降では、複数の外部ストレージシステム40について、各々を区別するときは、「外部ストレージシステム401」、「外部ストレージシステム402」等と添え字を用いて記載する。また、外部ストレージシステム401によって提供されるサービスの名称を「ストレージサービスA」、外部ストレージシステム402によって提供されるサービスの名称を「ストレージサービスB」等とする。
外部ストレージシステム40は、複数台の情報処理装置によって実現されるシステムであっても良い。また、図1に示す情報処理システム1の構成は一例であって、他の構成であっても良い。例えば、ユーザ環境E2は、画像形成装置20に加えて又は画像形成装置20に代えて、プロジェクタ、電子黒板等の各種機器を有していても良い。
<ハードウェア構成>
≪サービス提供システム、PC端末≫
サービス提供システム10及びPC端末30のハードウェア構成について、図2を参照しながら説明する。図2は、第一の実施形態に係るサービス提供システム及びPC端末の一例のハードウェア構成を示す図である。なお、サービス提供システム10及びPC端末30は、同様のハードウェア構成を有しているため、以降では、主に、サービス提供システム10のハードウェア構成について説明する。
サービス提供システム10は、入力装置11、表示装置12、外部I/F13、及びRAM(Random Access Memory)14を有する。また、サービス提供システム10は、ROM(Read Only Memory)15、CPU(Central Processing Unit)16、通信I/F17、及びHDD(Hard Disk Drive)18を有する。これらの各ハードウェアは、それぞれがバスBで接続されている。
入力装置11は、キーボードやマウス、タッチパネル等を含み、ユーザが各操作信号を入力するのに用いられる。表示装置12は、ディスプレイ等を含み、サービス提供システム10による処理結果を表示する。なお、入力装置11及び表示装置12は、必要なときにバスBに接続して利用する形態であっても良い。
通信I/F17は、サービス提供システム10をネットワークN1に接続するインタフェースである。これにより、サービス提供システム10は、通信I/F17を介してデータ通信を行うことができる。
HDD18は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、サービス提供システム10全体を制御する基本ソフトウェアであるOS(Operating System)、及びOS上において各種機能を提供するアプリケーションソフトウェア等がある。
なお、サービス提供システム10は、HDD18に代えて又はHDD18に加えて、フラッシュメモリを用いるドライブ装置(例えばソリッドステートドライブ:SSD)を利用しても良い。また、HDD18は、格納しているプログラムやデータを所定のファイルシステム及び/又はDBにより管理している。
外部I/F13は、外部装置とのインタフェースである。外部装置には、記録媒体13a等がある。これにより、サービス提供システム10は、外部I/F13を介して記録媒体13aの読み取り及び/又は書き込みを行うことができる。記録媒体13aには、フレキシブルディスク、CD、DVD、SDメモリカード、USBメモリ等がある。
ROM15は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリである。ROM15には、サービス提供システム10の起動時に実行されるBIOS(Basic Input/Output System)、OS設定、及びネットワーク設定等のプログラムやデータが格納されている。RAM14は、プログラムやデータを一時保持する揮発性の半導体メモリである。
CPU16は、ROM15やHDD18等からプログラムやデータをRAM14上に読み出し、処理を実行することで、サービス提供システム10全体の制御や機能を実現する演算装置である。
本実施形態に係るサービス提供システム10及びPC端末30は、上記のハードウェア構成を有することにより、後述するような各種処理を実現できる。
≪画像形成装置≫
画像形成装置20のハードウェア構成について、図3を参照しながら説明する。図3は、第一の実施形態に係る画像形成装置の一例のハードウェア構成を示す図である。
画像形成装置20は、コントローラ21、操作パネル22、外部I/F23、通信I/F24、プリンタ25、及びスキャナ26を有する。また、コントローラ21は、CPU211、RAM212、ROM213、NVRAM214、及びHDD215を有する。
ROM213は、各種プログラムやデータを格納する。RAM212は、プログラムやデータを一時保持する。NVRAM214は、例えば設定情報等が格納されている。また、HDD215は、各種プログラムやデータを格納する。
CPU211は、ROM213やNVRAM214、HDD215等からプログラムやデータ、設定情報等をRAM212上に読み出し、処理を実行することで、画像形成装置20全体の制御や機能を実現する。
操作パネル22は、ユーザからの入力を受け付ける入力部と、表示を行う表示部とを備えている。外部I/F23は、外部装置とのインタフェースである。外部装置には、記録媒体23a等がある。これにより、画像形成装置20は、外部I/F23を介して記録媒体23aの読み取り及び/又は書き込みを行うことができる。記録媒体23aにはICカード、フレキシブルディスク、CD、DVD、SDメモリカード、USBメモリ等がある。
通信I/F24は、画像形成装置20をネットワークN1に接続するインタフェースである。これにより、画像形成装置20は通信I/F24を介してデータ通信を行うことができる。プリンタ25は、印刷データを印刷するための印刷装置である。スキャナ26は原稿を読み取り画像ファイル(電子ファイル)を生成するための読取装置である。
本実施形態に係る画像形成装置20は、上記のハードウェア構成を有することにより、後述するような各種処理を実現できる。
<ソフトウェア構成>
次に、本実施形態に係る情報処理システム1の処理ブロックについて、図4を参照しながら説明する。図4は、第一の実施形態に係る情報処理システムの一例の処理ブロックを示す図である。
図4に示す画像形成装置20は、例えばCPU211等により実行されるブラウザ210を有する。画像形成装置20のユーザは、ブラウザ210を介して、サービス提供システム10により提供されるサービスを利用することができる。このように、本実施形態に係る画像形成装置20では、ブラウザ210が搭載(インストール)されていれば良く、サービスを利用するための専用のアプリケーションが搭載されている必要がない。
図4に示すPC端末30は、例えばCPU16等により実行されるブラウザ310を有する。PC端末30のユーザは、ブラウザ310を介して、所定の処理を実行するプログラムやモジュール等(すなわち、後述する「コンポーネント」)をサービス提供システム10に追加することができる。これにより、本実施形態に係るサービス提供システム10では、PC端末30から追加されたコンポーネントにより実現されるサービスを追加することができる。
ここで、コンポーネントとは、サービス提供システム10により提供されるサービスを実現するための一連の処理に含まれる一の処理を実行するためのモジュール等である。
図4に示すサービス提供システム10は、サービス処理部110、ドキュメントサービス部150、及びストレージサービス連携部160を有する。これら各部は、サービス提供システム10に搭載された1以上のプログラムが、CPU16に実行させる処理により実現される。
また、サービス提供システム10は、アプリ情報記憶部190を有する。アプリ情報記憶部190は、HDD18により実現可能である。なお、アプリ情報記憶部190は、サービス提供システム10とネットワークN1を介して接続される記憶装置等により実現されても良い。
サービス処理部110は、画像形成装置20のブラウザ210からの要求に応じて、各種のサービスに関する処理を実行する。サービス処理部110は、アプリ管理部120、ロジック処理部130、及びデータI/F部140を有する。
アプリ管理部120は、アプリ情報記憶部190に記憶されているアプリ情報1000を管理する。アプリ管理部120は、画像形成装置20のブラウザ210からの要求に応じて、アプリ情報1000に含まれる画面定義に基づくアプリ画面を返信する。これにより、画像形成装置20の操作パネル22には、ブラウザ210により、サービス提供システム10により提供されるサービスを利用するためのアプリ画面が表示される。
ここで、アプリ情報1000には、アプリ画面を画像形成装置20に表示させるための画面定義と、アプリ画面から利用されるサービスを実現するための処理内容とが含まれる。なお、アプリ情報1000には、複数の画面定義と、複数の処理内容とが含まれていても良い。
また、アプリ管理部120は、ロジック処理部130からの要求に応じて、アプリ情報1000に含まれる処理内容を返信する。処理内容は、サービス提供システム10により提供されるサービスを実現するための一連の処理(一連の処理は「処理フロー」とも称される。)の内容が記述されている。
ロジック処理部130は、画像形成装置20のブラウザ210からの要求に応じて、アプリ管理部120を介して処理内容を取得する。そして、ロジック処理部130は、取得した処理内容に基づく一連の処理を実行する。
すなわち、ロジック処理部130は、ドキュメントサービス部150又は/及びストレージサービス連携部160のファイル処理部170に対して、処理内容に従った処理の実行を要求することで、当該処理内容に基づく一連の処理を実行する。これにより、本実施形態に係るサービス提供システム10は、画像形成装置20に対して各種のサービスを提供することができる。なお、ロジック処理部130の詳細な処理ブロックについては、後述する。
データI/F部140は、画像形成装置20のブラウザ210からの要求に応じて、ストレージサービス連携部160のデータ処理部180に対して、所定の要求(例えば、フォルダ一覧の取得要求等)を行う。
ドキュメントサービス部150は、サービス提供システム10により提供されるサービスを実現するためのプログラム(モジュール)群である。ドキュメントサービス部150には、電子ファイルに対してOCR処理を行うOCR処理151が含まれる。なお、ドキュメントサービス部150には、例えば、所定の言語で記載されている文書ファイル(電子ファイル)を他の所定の言語に翻訳する翻訳処理プログラム等の各種プログラムが含まれても良い。
ストレージサービス連携部160は、ロジック処理部130やデータI/F部140からの要求に応じて、外部ストレージシステム40に対して、各種処理の実行を要求する。
ここで、本実施形態に係るサービス提供システム10は、外部ストレージシステム40毎に、ストレージサービス連携部160を有する。すなわち、サービス提供システム10は、外部ストレージシステム401に対して処理の実行を要求するためのストレージサービスA連携部1601、外部ストレージシステム402に対して処理の実行を要求するためのストレージサービスB連携部1602等を有する。このように、サービス提供システム10は、当該サービス提供システム10と連携して処理を行う外部ストレージシステム40毎に、それぞれの外部ストレージシステム40に対応するストレージサービス連携部160を有する。
なお、以降では、複数のストレージサービス連携部160について、各々を区別するときは、「ストレージサービスA連携部1601」、「ストレージサービスB連携部1602」等と記載する。
ストレージサービス連携部160は、上述したように、ロジック処理部130からの要求を受け取るファイル処理部170、及びデータI/F部140からの要求を受け取るデータ処理部180を有する。
ファイル処理部170は、外部ストレージシステム40に保存されている電子ファイルに対する操作(例えば、取得、保存、編集等)を行うためのAPI(Application Programming Interface)が定義された共通I/F171及び固有I/F172を有する。
共通I/F171は、複数の外部ストレージシステム40間で共通に利用できるAPIであり、例えば図5(a)に示すAPIが挙げられる。換言すれば、ファイル処理部170の共通I/F171は、すべての外部ストレージシステム40が利用できるファイル操作に関する機能(例えば、ファイルの取得、保存等)を利用するためのAPI群である。
一方、固有I/F172は、特定の外部ストレージシステム40において利用できるAPIであり、例えば図5(b)に示すAPIが挙げられる。換言すれば、ファイル処理部170の固有I/F172は、特定の外部ストレージシステム40において利用できるファイル操作に関する機能(例えば、ファイルの編集等)を利用するためのAPI群である。
したがって、共通I/F171は、すべてのストレージサービス連携部160に対して同様に定義される。一方で、固有I/F172は、当該固有I/F172で定義されるAPIが利用可能な特定の外部ストレージシステム40に対応するストレージサービス連携部160に対して個別に定義される。
また、データ処理部180は、外部ストレージシステム40に保存されている電子ファイルの書誌情報等のメタデータ(例えば、ファイル一覧、フォルダ一覧等)を取得等するためのAPIが定義された共通I/F181及び固有I/F182を有する。
共通I/F181は、複数の外部ストレージシステム40間で共通に利用できるAPIであり、例えば図5(c)に示すAPIが挙げられる。換言すれば、データ処理部180の共通I/F181は、すべての外部ストレージシステム40で利用できるメタデータ取得等の機能を利用するためのAPI群である。
一方、固有I/F182は、特定の外部ストレージシステム40において利用できるAPIであり、例えば図5(d)に示すAPIが挙げられる。換言すれば、データ処理部180の固有I/F182は、特定の外部ストレージシステム40において利用できるメタデータ取得等の機能(例えば、画像ファイル一覧の取得等)を利用するためのAPI群である。
したがって、共通I/F181は、すべてのストレージサービス連携部160に対して同様に定義される。一方で、固有I/F182は、当該固有I/F182で定義されるAPIが利用可能な特定の外部ストレージシステム40に対応するストレージサービス連携部160に対して個別に定義される。
以上のように、本実施形態に係るサービス提供システム10は、連携して処理を行う外部ストレージシステム40毎に、それぞれの外部ストレージシステム40に対応するストレージサービス連携部160を有する。このため、本実施形態に係る情報処理システム1では、連携先となる外部ストレージシステム40を追加等する場合には、当該外部ストレージシステム40に対応するストレージサービス連携部160をサービス提供システム10に追加等すれば良い。
したがって、本実施形態に係るサービス提供システム10は、連携先となる外部ストレージシステム40の追加等に伴う影響を局所化することができる。換言すれば、他の処理ブロック(サービス処理部110やドキュメントサービス部150等)に影響を与えることなく(すなわち、他の処理ブロックを修正等する必要なく)、連携先となる外部ストレージシステム40の追加等を行うことができる。
これにより、本実施形態に係るサービス提供システム10では、連携先の外部ストレージシステム40の追加等の開発に要する工数を削減することができる。なお、ストレージサービス連携部160の追加等は、SDK(Software Development Kit)を用いて行うことができる。
また、ストレージサービス連携部160では、共通I/F171及び固有I/F172がそれぞれ異なるモジュール等で実現される。さらに、共通I/F171及び固有I/F172で定義されるAPIは、「ストレージサービス名」(外部サービス名)を指定することで利用することができる(すなわち、「ストレージサービス名」(外部サービス名)が可変部分となっている)。
したがって、連携先の外部ストレージシステム40を追加する場合には、他のストレージサービス連携部160に定義されている共通I/F171を再利用することができる。換言すれば、連携先の外部ストレージシステム40を追加する場合には、当該追加する外部ストレージシステム40の固有I/F172のみを開発すれば良い。これにより、本実施形態に係るサービス提供システム10では、連携先の外部ストレージシステム40の追加等の開発に要する工数をさらに削減することができる。なお、このことは、データ処理部180の共通I/F181及び固有I/F182に関しても同様である。
アプリ情報記憶部190は、各種のサービスを提供するためのアプリ情報1000を記憶する。アプリ情報1000は、アプリ画面を画像形成装置20に表示させるための画面定義と、アプリ画面から利用されるサービスを実現するための一連の処理の内容が記述された処理内容とを含む。また、アプリ情報1000には、当該アプリ情報1000を一意に識別するためのアプリIDが付与されている。なお、以降では、ストレージサービスAと連携したスキャン配信サービスを提供するためのアプリ情報1000のアプリIDを「app001」とする。
ここで、ストレージサービスAと連携したスキャン配信サービスを提供するためのアプリ情報1000の画面定義に含まれるデータ定義について、図6を参照しながら説明する。図6は、データ定義の一例を示す図である。
図6に示すデータ定義1100は、画像形成装置20のブラウザ210により操作パネル22等に表示されるアプリ画面の入力欄(入力ボックス)や選択欄(選択ボックス)等を構成するための情報が記述されている。
具体的には、図6に示すデータ定義1100に含まれるデータ定義部1101には、スキャンにより生成される電子ファイルのファイル名を入力するための入力欄を構成するための情報が記述されている。また、図6に示すデータ定義に含まれるデータ定義部1102には、ストレージサービスAにおける保存先フォルダを選択するための選択欄を構成するための情報が記述されている。
なお、データ定義部1102の「data_source」には、選択欄の各選択要素(ここでは、保存先候補のフォルダ名及びフォルダID)の取得先のURL(Uniform Resource Locator)が記述されている。
次に、ストレージサービスAと連携したスキャン配信サービスを提供するためのアプリ情報1000の画面定義に含まれるレイアウト情報について、図7を参照しながら説明する。図7は、レイアウト情報の一例を示す図である。
図7に示すレイアウト情報1200は、画像形成装置20のブラウザ210により操作パネル22等に表示されるアプリ画面における文字(入力欄の表示名称等)や入力欄、選択欄等の表示位置や表示名称等の情報が記述されている。
具体的には、図7に示すレイアウト情報1200に含まれるレイアウト定義部1201には、データ定義1100における「"data_id":1」(すなわち、データ定義部1101)の表示位置及び表示名称の情報が記述されている。これにより、アプリ画面には、表示名称が「ファイル名」である入力欄が、1番目の位置に表示される。また、レイアウト情報1200に含まれるレイアウト定義部1202では、データ定義1100における「"data_id":2」(すなわち、データ定義部1102)の表示位置及び表示名称の情報が記述されている。これにより、アプリ画面には、表示名称が「保存先フォルダ選択」である選択欄が、2番目の位置に表示される。
次に、ストレージサービスAと連携したスキャン配信サービスを提供するためのアプリ情報1000の処理内容について、図8を参照しながら説明する。図8は、処理内容の一例を示す図である。
図8に示す処理内容1300は、ストレージサービスAと連携したスキャン配信サービスを実現するための一連の処理の内容が記述されている。
具体的には、図8に示す処理内容1300に含まれるフローID定義部1301には、当該処理内容1300を一意に識別するための識別情報であるフローID「flow001」が記述されている。また、図8に示す処理定義部1302及び処理定義部1303には、ストレージサービスAと連携したスキャン配信サービスを実現するための一連の処理の内容が定義されている。
すなわち、処理定義部1302には、スキャンして生成された電子ファイルをOCR処理するための処理の内容が記述されている。また、処理定義部1303には、OCR処理後の電子ファイルをストレージサービスAに配信するための処理の内容が記述されている。このように、アプリ情報1000に含まれる処理内容には、外部ストレージシステム40と連携した一連の処理を構成する一以上の処理の内容が記述されている。
以上のように、本実施形態に係るサービス提供システム10は、画像形成装置20にアプリ画面を表示させるための画面定義と、サービスを実現するための一連の処理(処理フロー)の内容が記述された処理内容とが含まれるアプリ情報1000を有する。そして、本実施形態に係るサービス提供システム10は、画像形成装置20に対して、アプリ情報1000を利用して各種のサービスを提供する。このため、サービス提供システム10により提供されるサービスを追加等する場合には、アプリ情報記憶部190にアプリ情報1000を追加等すれば良い。
また、本実施形態に係るサービス提供システム10にアプリ情報1000を追加するには、画面定義及び処理内容を記述すれば良いため、簡易に開発することができる。したがって、本実施形態に係るサービス提供システム10では、サービスの追加・変更等に伴う開発工数を削減させることができるとともに、例えばサードベンダー等によるサービスの追加・変更等を容易に行うことができる。
<処理の詳細>
次に、本実施形態に係る情報処理システム1の処理の詳細について説明する。
≪スキャン配信サービスの全体処理≫
本実施形態に係るスキャン配信サービスを画像形成装置20のユーザが利用する場合の全体的な処理について、図9を参照しながら説明する。図9は、第一の実施形態に係るスキャン配信サービスの全体処理の一例を示すシーケンス図である。
まず、画像形成装置20のユーザは、ブラウザ210を用いて、サービス提供システム10により提供されるサービスの一覧を取得するための操作を行う。すると、画像形成装置20は、サービスの一覧の取得要求をサービス提供システム10のサービス処理部110に送信する(ステップS901)。サービス処理部110のアプリ管理部120は、当該取得要求を受け取ると、サービス提供システム10により提供されるサービスの一覧を画像形成装置20に送信する。これにより、画像形成装置20の操作パネル22には、ブラウザ210により、サービス提供システム10により提供されるサービスの一覧が表示される。
なお、サービスの一覧には、例えば、サービス提供システム10により提供されるサービスのサービス名と、当該サービスを提供するためのアプリ情報1000のアプリIDと、当該サービスを実現するための処理内容のフローIDとが含まれる。
ユーザは、画像形成装置20の操作パネル22に表示されたサービスの一覧から、自身が利用を所望するサービスを選択する。すると、ブラウザ210は、ユーザにより選択されたサービスに対応するアプリ情報1000のアプリIDと、処理内容のフローIDとをアプリ管理部120に送信する(ステップS902)。
ここで、本実施形態では、ユーザにより「ストレージサービスAと連携したスキャン配信サービス」の利用が選択されたものとする。したがって、ブラウザ210は、アプリID「app001」と、フローID「flow001」とをアプリ管理部120に送信する。
そして、アプリ管理部120は、ブラウザ210から受け取ったアプリID「app001」のアプリ情報1000に含まれる画面定義に基づいてHTML(HyperText Markup Language)形式のアプリ画面を生成し、ブラウザ210に返信する。
画像形成装置20のブラウザ210は、アプリ管理部120からアプリ画面を受け取ると、表示用情報の取得をデータI/F部140に要求する(ステップS903)。
ここで、表示用情報とは、例えばアプリ画面の選択欄の各選択要素のことである。すなわち、本実施形態では、ブラウザ210は、スキャン配信サービスの配信先(保存先)となるストレージサービスAのフォルダの一覧の取得を、データI/F部140に要求する。
表示用情報の取得要求は、図6のデータ定義部1102に記述されている「"data_source"」に定義されているURL「http://sample.xxx.co.jp/service-a/data/folders」にHTTPリクエストを送信することで行うことができる。
なお、当該URLのうち、「http://sample.xxx.co.jp」の部分がサービス提供システム10のホスト名、「/service-a/data/folders」の部分がストレージサービス連携部160におけるAPI(すなわち、図5に示すAPI)の指定となる。
次に、データI/F部140は、ブラウザ210から表示用情報の取得要求を受け取ると、当該要求を、対応するストレージサービス連携部160のデータ処理部180に送信する(ステップS904)。すなわち、データI/F部140は、上記のURLに含まれる「service-a」(ストレージサービス名)に基づき、当該要求を、ストレージサービスA連携部1601のデータ処理部1801に送信する。
データ処理部180は、データI/F部140から表示用情報の取得要求を受け取ると、当該取得要求に含まれるURLに基づく処理要求を外部ストレージシステム40に送信する(ステップS905)。すなわち、データ処理部180は、データI/F部140から受け取った取得要求に含まれるURLに基づき、共通I/F181又は固有I/F182に定義されているAPIを利用して、該当の外部ストレージシステム40に処理を要求する。
より具体的には、上記のURLに含まれる「/service-a/data/folders」に基づき、データ処理部1801は、共通I/F1811に定義されているAPIを用いて、外部ストレージシステム401にフォルダ一覧の取得を要求する。すると、画像形成装置20のブラウザ210は、ストレージサービスA連携部1601を介して、フォルダ一覧を取得する。フォルダ一覧は、本実施形態に係るスキャン配信サービスにおいて、電子ファイルの保存先の候補となるストレージサービスAのフォルダ名及びフォルダID等の情報である。
次に、ブラウザ210は、アプリ管理部120から受け取ったアプリ画面と、外部ストレージシステム40から受け取ったフォルダ一覧とに基づき、例えば図10(a)に示すようなアプリ画面2000を、操作パネル22に表示させる(ステップS906)。
ここで、図10(a)で示すスキャン配信サービスを利用するためのアプリ画面2000は、ファイル名入力欄2001、保存先フォルダ選択欄2002、及びスキャン実行ボタン2003を含む。このうち、ファイル名入力欄2001及び保存先フォルダ選択欄2002は、図10(b)に示すように、それぞれHTMLソースコード2101及び2102で記述されている。このようなHTMLソースコード2101及び2102は、アプリ管理部120により、図6に示すデータ定義部1101及び1102と、図7に示すレイアウト定義部1201及び1202とに基づいて生成される。
ただし、HTMLソースコード2102に指定されている「option」の設定値は、外部ストレージシステム40から取得したフォルダ一覧に基づき、ブラウザ210で設定される。このように、アプリ画面2000は、アプリ情報1000に含まれる画面定義に基づきアプリ管理部120で生成されたHTMLに対して、外部ストレージシステム40から取得したフォルダ一覧の情報を設定することで生成される。
次に、ユーザは、図10(a)のアプリ画面2000において、ファイル名入力欄2001に所望のファイル名を入力して、保存先フォルダ選択欄2002から所望の保存先フォルダを選択する。そして、画像形成装置20のスキャナ26に原稿をセットして、スキャン実行ボタン2003を押下する。すると、画像形成装置20のブラウザ210は、これらの操作を受け付ける(ステップS907)。
ここで、ユーザは、ファイル名入力欄2001にファイル名「test」を入力し、保存先フォルダ選択欄2002から「FolderB」を選択して、スキャン実行ボタン2003を押下したものとする。すると、画像形成装置20のスキャナ26により原稿が読み取られ、ファイル名「test」の電子ファイルが生成される(ステップS908)。
続いて、画像形成装置20のブラウザ210は、スキャン配信サービスの処理実行要求をロジック処理部130に送信する(ステップS909)。ここで、当該実行要求には、アプリID「app001」と、当該アプリIDのアプリ情報1000に含まれる処理内容1300のフローID「flow001」と、生成された電子ファイルと、選択された保存先フォルダ「FolderB」のフォルダID「folder_id_b」とが含まれる。
ロジック処理部130は、ブラウザ210から処理実行要求を受け取ると、当該処理実行要求に含まれるアプリID及びフローIDに対応する処理内容に基づく一連の処理を実行するフロー実行処理を行う(ステップS910)。これにより、ストレージサービスAと連携したスキャン配信サービスが実現される。なお、フロー実行処理の詳細については後述する。
そして、ロジック処理部130は、フロー実行処理の処理結果を、画像形成装置20のブラウザ210に送信する(ステップS911)。これにより、本実施形態に係るスキャン配信サービスが完了する。
≪フロー実行処理≫
次に、図9のステップS910のフロー実行処理の詳細について説明する。フロー実行処理は、主に、ロジック処理部130により実行される。したがって、フロー実行処理の詳細について説明する前に、ロジック処理部130の詳細な処理ブロックについて、図11を参照しながら説明する。図11は、第一の実施形態に係るロジック処理部の一例の処理ブロックを示す図である。
ロジック処理部130は、フロー実行部131、コンポーネント管理部132、コンポーネント群133、型変換管理部134、及び型変換群135を有する。また、ロジック処理部130は、コンポーネント情報テーブル3000、及び型変換テーブル4000を利用する。
フロー実行部131は、画像形成装置20のブラウザ210から処理実行要求を受け取ると、アプリ管理部120を介して、アプリ情報1000から処理内容を取得する。そして、フロー実行部131は、取得した処理内容に記述された一連の処理の内容に従って、当該一連の処理に含まれる一の処理を実行するコンポーネントの取得を要求する。また、フロー実行部131は、取得したコンポーネントに対して処理の実行を要求する。
コンポーネント管理部132は、フロー実行部131からのコンポーネントの取得要求に応じて、コンポーネントの生成を行う。なお、コンポーネントの生成とは、例えばクラスで定義されたコンポーネントを、メモリ(例えばRAM14)上に展開することを意味する。
コンポーネント管理部132は、コンポーネント判別部1321、既存コンポーネント生成部1322、追加コンポーネント生成部1323、及びコンポーネント登録部1324を有する。
コンポーネント判別部1321は、フロー実行部131からのコンポーネントの取得要求に応じて、コンポーネント情報テーブル3000を参照し、当該取得要求に係るコンポーネントが、既存コンポーネント又は追加コンポーネントのいずれであるかを判別する。
ここで、既存コンポーネントとは、サービス提供システム10に予め組み込まれているコンポーネントのことを言う。一方、追加コンポーネントとは、ユーザがPC端末30を介して、コンポーネント情報テーブル3000に登録されたコンポーネントのことを言う。換言すれば、追加コンポーネントとは、ユーザにより開発等され、サービス提供システム10に追加されたコンポーネントのことである。
このように、本実施形態に係るサービス提供システム10では、ユーザにより開発等されたコンポーネントを追加することができる。このため、ユーザは、追加コンポーネントを用いて実現される一連の処理を処理内容として記述することができるため、様々なサービスを提供するアプリ情報1000を開発することができるようになる。
既存コンポーネント生成部1322は、コンポーネント判別部1321によりコンポーネントの取得要求に係るコンポーネントが既存コンポーネントであると判別された場合、当該取得要求に係る既存コンポーネントを生成する。
追加コンポーネント生成部1323は、コンポーネント判別部1321によりコンポーネントの取得要求に係るコンポーネントが追加コンポーネントであると判別された場合、当該取得要求に係る追加コンポーネントを生成する。
コンポーネント登録部1324は、PC端末30のブラウザ310からの要求に応じて、追加コンポーネントをコンポーネント情報テーブル3000に登録する。また、コンポーネント登録部1324は、PC端末30のブラウザ310からの要求に応じて、コンポーネント情報テーブル3000に登録されている追加コンポーネントの更新や削除を行う。
ここで、コンポーネント情報テーブル3000について、図12を参照しながら説明する。図12は、第一の実施形態に係るコンポーネント情報の一例を示す図である。
図12に示すコンポーネント情報テーブル3000は、コンポーネント毎に、コンポーネントに関する情報(コンポーネント情報)を管理する。コンポーネント情報は、データ項目として、コンポーネント名、バージョン、パラメータ、及びファイルを有する。
コンポーネント名は、コンポーネントの情報である。バージョンは、コンポーネントのバージョンである。各コンポーネントは、コンポーネント名及びバージョンにより一意に識別される。
パラメータは、コンポーネントに対する入力パラメータである。例えば、外部ストレージシステム40に電子ファイルを配信するためのコンポーネント(後述する配信コンポーネント)のパラメータは、当該外部ストレージシステム40における保存先のフォルダのフォルダID等である。
ファイルは、コンポーネントを生成するための電子ファイル(以降では、この電子ファイルを「生成ファイル」と表す。)が、例えばJAR(Java Archive)等のデータ形式で格納される。したがって、本実施形態では、追加コンポーネントのコンポーネント情報のデータ項目「ファイル」には、当該追加コンポーネントの生成ファイルが格納される。一方で、既存コンポーネントのコンポーネント情報のデータ項目「ファイル」には、生成ファイルが格納されない。
より具体的には、図12に示すコンポーネント情報テーブル3000において、コンポーネント名「ocrA」、バージョン「v1」のコンポーネント情報のデータ項目「ファイル」には、生成ファイルが格納されていない。一方で、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報のデータ項目「ファイル」には、コンポーネントの生成ファイルが格納されている。
したがって、図12に示すコンポーネント情報テーブル3000において、コンポーネント名「ocrA」、バージョン「v1」のコンポーネント情報は、既存コンポーネントのコンポーネント情報である。一方で、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報は、追加コンポーネントのコンポーネント情報である。
コンポーネント群133は、既存コンポーネントや追加コンポーネントの集合である。コンポーネント群133には、コンポーネント名「ocrA」、バージョン「v1」のコンポーネント情報に対応するOCRAコンポーネント1331が含まれる。また、コンポーネント群133には、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報に対応するOCRBコンポーネント1332が含まれる。
同様に、コンポーネント群133には、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報に対応する配信Aコンポーネント1333が含まれる。また、コンポーネント群133には、コンポーネント名「uploadB」、バージョン「v1」のコンポーネント情報に対応する配信Bコンポーネント1334が含まれる。
このように、コンポーネント群133は、コンポーネント情報テーブル3000で管理されているコンポーネント情報に対応するコンポーネントの集合である。
さらに、コンポーネント群133に含まれる各コンポーネントは、コンポーネント共通I/F1330を有する。コンポーネント共通I/F1330は、各コンポーネントに対して共通に定義されたAPIであり、コンポーネントを生成するためのAPIと、コンポーネントに対して処理の実行を要求するためのAPIとが含まれる。
このように、各コンポーネントがコンポーネント共通I/F1330を有することで、コンポーネントの追加等に伴う影響を局所化することができる。換言すれば、フロー実行部131やコンポーネント管理部132、他のコンポーネント等に影響を与えることなく、コンポーネントの追加等を行うことができる。このため、コンポーネントの追加等の開発に要する工数を削減することができる。
型変換管理部134は、データ型の型変換を管理する。ここで、各コンポーネントは、自身が扱えるデータ型が予め定められている。したがって、型変換管理部134は、コンポーネントからの要求に応じて、型変換テーブル4000を参照して、当該要求に応じた型変換を生成する。
ここで、型変換テーブル4000について、図13を参照しながら説明する。図13は、型変換テーブルの一例を示す図である。
図13に示す型変換テーブル4000は、型変換に関する情報(型変換情報)を管理する。型変換情報は、データ項目として、変換前のデータ型、変換後のデータ型、及び生成する型変換を有する。これにより、例えば、コンポーネントから「InputStream」のデータ型を「LocalFilePath」のデータ型に変換する要求を受け取った場合、型変換管理部134は、後述する第1の型変換1351を生成する。
そして、型変換管理部134は、生成された型変換に対して型変換処理の実行を要求する。ここで、型変換とは、データ型の型変換処理を実行するためのモジュール等であり、例えばクラスや関数等で定義される。
なお、型変換の生成とは、例えばクラスで定義された型変換を、メモリ(例えばRAM14)上に展開することを意味する。また、データ型には、例えば、ストリームデータを示すデータ型「InputStream」、記憶装置等に格納されている電子ファイルのパス(アドレス)を示す「LocalFilePath」、電子ファイルの実体を示す「File」等が挙げられる。
型変換群135は、型変換の集合である。型変換群135には、データ型「InputStream」を「LocalFilePath」に変換する第1の型変換1351が含まれる。型変換群135には、第1の型変換1351以外にも、例えば、「LocalFilePath」を「File」に変換する第2の型変換等が含まれる。
さらに、これらの各型変換は、型変換共通I/F1350を有する。型変換共通I/F1350は、各型変換に対して共通に定義されたAPIであり、型変換を生成するためのAPIと、型変換に対して処理の実行を要求するためのAPIとが含まれる。このように、各型変換が型変換共通I/F1350を有するようにすることで、型変換の追加等に伴う影響を局所化することができる。換言すれば、型変換管理部134に影響を与えることなく、コンポーネントの追加等を行うことができる。これにより、型変換の追加等の開発に要する工数を削減することができる。
続いて、図9のステップS910のフロー実行処理の詳細について、図14を参照しながら説明する。図14は、第一の実施形態に係るフロー実行処理の一例を示すシーケンス図である。
まず、フロー実行部131は、ブラウザ210からスキャン配信サービスの処理実行要求を受け付けると、アプリ管理部120に処理内容の取得を要求する(ステップS1401)。ここで、当該処理内容の取得要求には、アプリID「app001」と、フローID「flow001」とが含まれる。
そして、フロー実行部131は、アプリ管理部120からアプリID「app001」に対応するアプリ情報1000に含まれるフローID「flow001」処理内容を取得する。すなわち、フロー実行部131は、図8に示す処理内容1300を取得する。
フロー実行部131は、取得した処理内容1300に従ってコンポーネントの取得を、コンポーネント管理部132に要求する(ステップS1402)。より具体的には、フロー実行部131は、図8に示す処理内容1300の処理定義部1302に記述に基づいて、コンポーネント名「ocrB」、バージョン「v2」のコンポーネントの取得を、コンポーネント管理部132に要求する。
コンポーネント管理部132は、コンポーネントの取得要求を受け取ると、コンポーネント判別部1321により、当該取得要求に係るコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを判別する(ステップS1403)。すなわち、コンポーネント判別部1321は、コンポーネント情報テーブル3000を参照し、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されているか否かを判別する。
コンポーネント判別部1321は、コンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されている場合、取得要求に係るコンポーネントは追加コンポーネントであると判別する。一方、コンポーネント判別部1321は、コンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されていない場合、取得要求に係るコンポーネントは既存コンポーネントであると判別する。
本実施形態では、コンポーネント情報テーブル3000において、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報には、データ項目「ファイル」に、コンポーネントの生成ファイルが格納されている。したがって、コンポーネント判別部1321は、取得要求に係るコンポーネントが追加コンポーネントであると判別する。
コンポーネント判別部1321は、取得要求に係るコンポーネントが追加コンポーネントであると判別した場合、当該取得要求を追加コンポーネント生成部1323に送信する(ステップS1404)。
次に、追加コンポーネント生成部1323は、当該取得要求を受け取ると、コンポーネント名「ocrB」、バージョン「v2」に基づき、コンポーネント情報テーブル3000からコンポーネントの生成ファイルを取得する(ステップS1405)。すなわち、追加コンポーネント生成部1323は、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報のデータ項目「ファイル」に格納されている生成ファイルを取得する。
続いて、追加コンポーネント生成部1323は、取得した生成ファイルに基づいて追加コンポーネントを生成する(ステップS1406)。すなわち、追加コンポーネント生成部1323は、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報から取得した生成ファイルに基づいて、OCRBコンポーネント1332を生成する。なお、OCRBコンポーネント1332の生成は、例えば、JAR形式の生成ファイルを実行して、コンポーネント共通I/F1330に定義されたコンポーネントを生成するためのAPIを用いて行うことができる。
そして、追加コンポーネント生成部1323は、OCRBコンポーネント1332が生成されると、OCRBコンポーネント1332をフロー実行部131に返信する。これは、例えば、追加コンポーネント生成部1323は、OCRBコンポーネント1332が展開されたメモリ(例えばRAM14)上のアドレスを、フロー実行部131に返信すれば良い。
次に、フロー実行部131は、データを指定して、生成されたOCRBコンポーネント1332に処理の実行を要求する(ステップS1407)。なお、ここで指定されるデータは、データ型が「InputStream」としてブラウザ210から渡される電子ファイルである。
すなわち、フロー実行部131は、ブラウザ210からデータ型「InputStream」として渡される電子ファイルを、単に「データ」として(データ型を意識することなく)、OCRBコンポーネント1332に渡して処理の実行を要求する。図14では、このようにデータ型を意識することなく渡される電子ファイル等を、単に「データ」と表す。
次に、OCRBコンポーネント1332は、データが指定された処理の実行要求を受け取ると、データ型の型変換を型変換管理部134に要求する(ステップS1408)。ここで、当該型変換要求には、データと、OCRBコンポーネント1332が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。
型変換管理部134は、型変換要求を受け取ると、当該型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS1409)。ここでは、受け取った型変換要求に含まれるデータのデータ型は「InputStream」である一方、指定されたデータ型は「LocalFilePath」であるから、一致しないものと判断される。
すると、型変換管理部134は、型変換テーブル4000を参照し、「InputStream」を「LocalFilePath」に変換するための型変換を特定して(ここでは、第1の型変換1351が特定される)、当該特定された型変換を生成する(ステップS1410)。
次に、型変換管理部134は、生成された第1の型変換1351に対して、データを指定して型変換処理の実行を要求する(ステップS1411)。すると、第1の型変換1351は、指定されたデータのデータ型を「InputStream」から「LocalFilePath」に変換して(ステップS1412)、当該変換後のデータを型変換管理部134に返信する。そして、型変換管理部134は、型変換後のデータをOCRBコンポーネント1332に返信する(ステップS1413)。
OCRBコンポーネント1332は、型変換後のデータを受け取ると、処理を実行する(ステップS1414)。すなわち、データ型「LocalFilePath」のデータ(つまり、パス又はアドレス)により示される電子ファイルに対して、OCR処理を実行する。より具体的には、OCRBコンポーネント1332は、ドキュメントサービス部150のOCR処理151に処理を要求し、OCR処理151が当該電子ファイルに対して処理を実行する。
そして、OCRBコンポーネント1332は、処理の実行が完了すると、データをフロー実行部131に返信する。なお、ここで返信されるデータは、OCR処理後の電子ファイルを示すパス又はアドレスである(すなわち、返信されるデータのデータ型は「LocalFilePath」である。)。
次に、フロー実行部131は、取得した処理内容1300に従ってコンポーネントの取得を、コンポーネント管理部132に要求する(ステップS1415)。より具体的には、フロー実行部131は、図8に示す処理内容1300の処理定義部1302の次の処理定義部1303の記述に基づいて、コンポーネント名「uploadA」、バージョン「v1」のコンポーネントの取得を、コンポーネント管理部132に要求する。
コンポーネント管理部132は、コンポーネントの取得要求を受け取ると、コンポーネント判別部1321により、当該取得要求に係るコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを判別する(ステップS1416)。すなわち、コンポーネント判別部1321は、コンポーネント情報テーブル3000を参照し、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されているか否かを判別する。
コンポーネント判別部1321は、コンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されている場合、取得要求に係るコンポーネントは追加コンポーネントであると判別する。一方、コンポーネント判別部1321は、コンポーネント情報のデータ項目「ファイル」に、コンポーネントの生成ファイルが格納されていない場合、取得要求に係るコンポーネントは既存コンポーネントであると判別する。
本実施形態では、コンポーネント情報テーブル3000において、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報には、データ項目「ファイル」に、コンポーネントの生成ファイルが格納されていない。したがって、コンポーネント判別部1321は、取得要求に係るコンポーネントが既存コンポーネントであると判別する。
コンポーネント判別部1321は、取得要求に係るコンポーネントが既存コンポーネントであると判別した場合、当該取得要求を既存コンポーネント生成部1322に送信する(ステップS1417)。
次に、既存コンポーネント生成部1322は、コンポーネントの取得要求を受け取ると、当該取得要求に係る既存コンポーネントを生成する(ステップS1418)。すなわち、既存コンポーネント生成部1322は、コンポーネント名「uploadA」、バージョン「v1」に基づいて、配信Aコンポーネント1333を生成する。なお、配信Aコンポーネント1333の生成は、コンポーネント共通I/F1330に定義されたコンポーネントを生成するためのAPIを用いて行うことができる。
そして、既存コンポーネント生成部1322は、配信Aコンポーネント1333が生成されると、配信Aコンポーネント1333をフロー実行部131に返信する。これは、例えば、既存コンポーネント生成部1322は、配信Aコンポーネント1333が展開されたメモリ(例えばRAM14)上のアドレスを、フロー実行部131に返信すれば良い。
次に、フロー実行部131は、データを指定して、生成された配信Aコンポーネント1333に処理の実行を要求する(ステップS1419)。なお、ここで指定されるデータは、データ型が「LocalFilePath」としてOCRBコンポーネント1332から返信されたOCR処理後の電子ファイルである。
次に、配信Aコンポーネント1333は、データが指定された処理の実行要求を受け取ると、データ型の型変換を型変換管理部134に要求する(ステップS1420)。ここで、当該型変換要求には、データと、配信Aコンポーネント1333が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。
型変換管理部134は、型変換要求を受け取ると、当該型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS1421)。ここでは、受け取った型変換要求に含まれるデータのデータ型は「LocalFilePath」であり、指定されたデータ型も「LocalFilePath」であるから、一致するものと判断される。
そして、型変換管理部134は、型変換要求に含まれていたデータを、そのまま配信Aコンポーネント1333に送信する(ステップS1422)。このように、データ型チェック(ステップS1421の処理)で両者のデータ型が一致する場合には、型変換管理部134は型変換の生成を行わない。
配信Aコンポーネント1333は、型変換管理部134からデータを受け取ると、処理を実行する(ステップS1423)。
すなわち、配信Aコンポーネント1333は、ストレージサービスA連携部1601のファイル処理部1701に対して、共通I/F1711として定義されているファイル保存のAPIを用いて、データの配信実行を要求する。より具体的には、配信Aコンポーネント1333は、ストレージサービスA連携部1601のファイル処理部1701に対して、図5(a)に示すAPIとして「service-a/process/folder」を用いてデータの配信実行を要求する。これにより、ストレージサービスAのフォルダ「FolderB」に、ファイル名「test」の電子ファイル(スキャンにより生成された電子ファイルに対してOCR処理した電子ファイル)が保存される。
そして、配信Aコンポーネント1333は、処理の実行が完了すると、データをフロー実行部131に返信する。なお、ここで返信されるデータは、例えば、ストレージサービスAに対して電子ファイルの配信が正常に行われたことを示す処理結果である。これにより、本実施形態に係るサービス提供システム10において、処理内容1300に基づく、ストレージサービスAと連携した一連の処理の実行が完了する。
以上のように、本実施形態に係るサービス提供システム10では、サービスを実現するための一連の処理に含まれる一の処理を実行するコンポーネントが、既存コンポーネント又は追加コンポーネントのいずれであるかを判別する。そして、本実施形態に係るサービス提供システム10では、判別結果に応じて、既存コンポーネント又は追加コンポーネントを生成する。
このように、本実施形態に係るサービス提供システム10では、例えばJAR形式等で開発や配布等される様々なコンポーネントを利用することができる。このため、例えば、アプリ情報1000の開発者等は、追加コンポーネントも含めた様々なコンポーネントにより実行される処理で構成される一連の処理の内容を処理内容として記述することができる。したがって、本実施形態に係るサービス提供システム10では、追加コンポーネントにより実行される処理を含む一連の処理で実現される多様なサービスを提供することができるようになる。
≪コンポーネントの追加、更新、及び削除処理≫
次に、本実施形態に係るサービス提供システム10に対して追加コンポーネントを追加する場合や追加コンポーネントを更新する場合、追加コンポーネントを削除する場合の処理について、図15を参照しながら説明する。図15は、第一の実施形態に係るコンポーネントの追加、更新、及び削除処理の一例を示すシーケンス図である。
まず、コンポーネントの開発者等のユーザは、PC端末30のブラウザ310により、コンポーネント編集画面の表示操作を行う。すると、ブラウザ310は、当該表示操作を受け付けて、例えば図16(a)に示すコンポーネント編集画面5000を、表示装置12に表示させる(ステップS1501)。
図16(a)に示すコンポーネント編集画面5000は、追加コンポーネントの追加(登録)、更新、及び削除を行うための画面である。コンポーネント編集画面5000には、新たなコンポーネントをコンポーネント情報テーブル3000に登録するための追加ボタン5010、登録されている追加コンポーネントを更新するための更新ボタン5020、削除するための削除ボタン5030が含まれる。
コンポーネント編集画面5000において、ユーザにより追加ボタン5010が選択された場合、ブラウザ310は、当該操作を受け付けて、例えば図16(b)に示すコンポーネント追加画面5100を表示させる(ステップS1502)。
図16(b)に示すコンポーネント追加画面5100は、コンポーネントを追加(登録)するための画面であり、コンポーネント名欄5110、ファイル欄5120、参照ボタン5130、及び登録ボタン5140が含まれる。
ユーザは、コンポーネント名欄5110に登録する追加コンポーネントのコンポーネント名を入力し、ファイル欄5120に追加コンポーネントの生成ファイルを指定した上で、登録ボタン5140を押下して、追加コンポーネントの登録操作を行う。すると、ブラウザ310は、当該登録操作を受け付ける(ステップS1503)。なお、ユーザは、参照ボタン5130を押下して生成ファイルの格納先の一覧を表示した上で、当該一覧から所望の生成ファイルを選択することで、ファイル欄5120に生成ファイルを指定しても良い。
ブラウザ310は、追加コンポーネントの登録操作を受け付けると、コンポーネントの登録を、コンポーネント管理部132に要求する(ステップS1504)。なお、コンポーネントの登録要求には、コンポーネント名欄5110に指定されたコンポーネント名と、ファイル欄5120に指定された生成ファイルとが含まれる。
コンポーネント管理部132は、コンポーネントの登録要求を受け取ると、コンポーネント登録部1324により、当該登録要求に含まれるコンポーネント名及び生成ファイルに基づきコンポーネント情報を作成する。そして、コンポーネント登録部1324は、作成したコンポーネント情報をコンポーネント情報テーブル3000に登録する(ステップS1504)。これにより、本実施形態に係るサービス提供システム10に追加コンポーネントが登録される。
なお、コンポーネント登録部1324は、当該登録要求に含まれるコンポーネント名と同一のコンポーネント名がコンポーネント情報テーブル3000に存在しない場合、データ項目「バージョン」に「v1」を設定してコンポーネント情報を作成する。一方、コンポーネント登録部1324は、当該登録要求に含まれるコンポーネント名と同一のコンポーネント名がコンポーネント情報テーブル3000に存在する場合、データ項目「バージョン」に最新のバージョンを付与してコンポーネント情報を作成する。
また、コンポーネント登録部1324は、当該登録要求に含まれる生成ファイルから追加コンポーネントの入力パラメータに関する情報を取得して、当該入力パラメータに関する情報を、データ項目「パラメータ」に設定してコンポーネント情報を作成する。なお、コンポーネント登録部1324は、例えばデータ形式が異なる等により、生成ファイルから入力パラメータに関する情報を取得することができない場合は、ユーザに入力パラメータに関する情報を指定させるための画面をPC端末30に表示させても良い。
コンポーネント編集画面5000において、ユーザにより、更新を所望する追加コンポーネントのコンポーネント名及びバージョンが対応付けられた更新ボタン5020が選択された場合、ブラウザ310は、当該操作を受け付ける。そして、ブラウザ310は、例えば図16(c)に示すコンポーネント更新画面5200を表示させる(ステップS1506)。
図16(c)に示すコンポーネント更新画面5200は、追加コンポーネントを更新するための画面であり、ファイル欄5210、参照ボタン5220、及び更新ボタン5230が含まれる。
ユーザは、ファイル欄5210に生成ファイルを指定した上で、更新ボタン5230を押下して、追加コンポーネントの更新操作を行う。すると、ブラウザ310は、当該更新操作を受け付ける(ステップS1507)。なお、ユーザは、参照ボタン5220を押下して、生成ファイルの格納先の一覧を表示した上で、当該一覧から所望の生成ファイルを選択することで、ファイル欄5210に生成ファイルを指定しても良い。
ブラウザ310は、追加コンポーネントの更新操作を受け付けると、コンポーネントの更新を、コンポーネント管理部132に要求する(ステップS1508)。なお、コンポーネントの更新要求には、ユーザにより選択された更新ボタン5020に対応付けられたコンポーネント名及びバージョンと、ファイル欄5210に指定された生成ファイルとが含まれる。
コンポーネント管理部132は、コンポーネントの更新要求を受け取ると、コンポーネント登録部1324により、コンポーネント情報テーブル3000に登録されているコンポーネント情報を更新する(ステップS1509)。すなわち、コンポーネント登録部1324は、当該登録要求に含まれるコンポーネント名及びバージョンに対応するコンポーネント情報のデータ項目「ファイル」を、当該登録要求に含まれる生成ファイルで上書きして更新する。これにより、本実施形態に係るサービス提供システム10に登録されている追加コンポーネントが更新される。
なお、本実施形態に係るサービス提供システム10は、追加コンポーネントの更新により、アプリ情報1000に含まれる処理内容に基づく一連の処理が正常に実行することができなくなる場合、当該更新を行わないようにしても良い。又は、この場合、更新前のコンポーネント情報を残しつつ、更新後のコンポーネント情報をコンポーネント情報テーブル3000に登録するようにしても良い。
また、本実施形態に係るサービス提供システム10は、更新対象の追加コンポーネントを利用した一連の処理が実行中である場合、当該一連の処理の実行が完了した後、更新対象の追加コンポーネントを更新すれば良い。
コンポーネント編集画面5000において、ユーザにより、削除を所望する追加コンポーネントのコンポーネント名及びバージョンに対応付けられた削除ボタン5030が選択された場合、ブラウザ310は、当該操作を受け付ける(ステップS1510)。
ブラウザ310は、追加コンポーネントの削除操作を受け付けると、コンポーネントの削除を、コンポーネント管理部132に要求する(ステップS1511)。なお、コンポーネントの削除要求には、ユーザにより選択された削除ボタン5030に対応付けられたコンポーネント名及びバージョンが含まれる。
コンポーネント管理部132は、コンポーネントの削除要求を受け取ると、コンポーネント登録部1324により、コンポーネント情報テーブル3000に登録されているコンポーネント情報を削除する(ステップS1512)。すなわち、コンポーネント登録部1324は、当該削除要求に含まれるコンポーネント名及びバージョンに対応するコンポーネント情報を、コンポーネント情報テーブル3000から削除する。これにより、本実施形態に係るサービス提供システム10に登録されている追加コンポーネントが削除される。
以上のように、本実施形態に係るサービス提供システム10では、PC端末30等から追加コンポーネントの登録を行うことができる。このため、アプリ情報1000の開発者等のユーザは、自身が開発するアプリ情報1000が利用する追加コンポーネントをサービス提供システム10に登録することができる。したがって、本実施形態に係るサービス提供システム10では、様々なサービスを提供することができるようになる。
また、本実施形態に係るサービス提供システム10では、登録されている追加コンポーネントを、PC端末30等から更新や削除を行うことができる。このため、アプリ情報1000の開発者等のユーザは、例えば、アプリ情報1000が利用する追加コンポーネントの更新を行うことができ、柔軟にアプリ情報1000を開発することができるようになる。
さらに、本実施形態に係るサービス提供システム10では、例えばJAR形式等で開発や配布等される生成ファイルを登録することで、追加コンポーネントを利用することができるようになる。このため、本実施形態に係るサービス提供システム10では、既存コンポーネントに影響を与えることなく、追加コンポーネントの登録、更新、削除を行うことができる。すなわち、本実施形態に係るサービス提供システム10では、当該サービス提供システム10を停止等させる必要なく、動的に追加コンポーネントの登録、更新、削除を行うことができる。
[第二の実施形態]
次に、第二の実施形態に係る情報処理システム1について説明する。第二の実施形態では、フロー実行処理において、実行されるコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを、第一の実施形態と異なる方法で判別する。なお、以降では、第一の実施形態と実質的に同一の機能を有する箇所及び同一の処理を行う箇所については、第一の実施形態と同一の符号を用いて、その説明を省略する。
<ソフトウェア構成>
本実施形態に係る情報処理システム1に含まれるサービス提供システム10のロジック処理部130の処理ブロックについて、図17を参照しながら説明する。図17は、第二の実施形態に係るロジック処理部の一例の処理ブロックを示す図である。
本実施形態に係るロジック処理部130のコンポーネント管理部132は、コンポーネント判別部1321Aを有する。また、本実施形態に係るロジック処理部130は、コンポーネント情報テーブル3000Aを利用する。
コンポーネント判別部1321Aは、コンポーネントの取得要求に応じて、コンポーネント情報テーブル3000Aを参照し、当該取得要求に係るコンポーネントが、既存コンポーネント又は追加コンポーネントのいずれであるかを判別する。
ここで、コンポーネント情報テーブル3000Aについて、図18を参照しながら説明する。図18は、第二の実施形態に係るコンポーネント情報テーブルの一例を示す図である。
図18に示すコンポーネント情報テーブル3000Aは、データ項目として、さらに、コンポーネント区分を有する。コンポーネント区分は、コンポーネント情報が、既存コンポーネントのコンポーネント情報又は追加コンポーネントのコンポーネント情報のいずれであるかを示す区分である。したがって、本実施形態に係るコンポーネント判別部1321Aは、コンポーネント情報のコンポーネント区分を参照することで、コンポーネントの取得要求に係るコンポーネントが、既存コンポーネント又は追加コンポーネントのいずれであるかを判別することができる。
<処理の詳細>
次に、本実施形態に係る情報処理システム1の処理の詳細について説明する。
≪フロー実行処理≫
以降では、本実施形態に係るフロー実行処理について、図19を参照しながら説明する。図19は、第二の実施形態に係るフロー実行処理の一例を示すシーケンス図である。なお、第一の実施形態に係るフロー実行処理と同様の処理を行う箇所については、その説明を省略する。
コンポーネント管理部132は、コンポーネントの取得要求を受け取ると、コンポーネント判別部1321Aにより、当該取得要求に係るコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを判別する(ステップS1901)。すなわち、コンポーネント判別部1321Aは、コンポーネント情報テーブル3000Aを参照し、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報のデータ項目「コンポーネント区分」が、「既存」又は「追加」のいずれであるかを判別する。
コンポーネント判別部1321Aは、コンポーネント情報のデータ項目「コンポーネント区分」が「追加」である場合、取得要求に係るコンポーネントは追加コンポーネントであると判別する。一方、コンポーネント判別部1321Aは、コンポーネント情報のデータ項目「コンポーネント区分」が「既存」である場合、取得要求に係るコンポーネントは既存コンポーネントであると判別する。
本実施形態では、コンポーネント情報テーブル3000Aにおいて、コンポーネント名「ocrB」、バージョン「v2」のコンポーネント情報は、データ項目「コンポーネント区分」が「追加」である。したがって、コンポーネント判別部1321Aは、取得要求に係るコンポーネントが追加コンポーネントであると判別する。
コンポーネント管理部132は、コンポーネントの取得要求を受け取ると、コンポーネント判別部1321Aにより、当該取得要求に係るコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを判別する(ステップS1902)。すなわち、コンポーネント判別部1321Aは、コンポーネント情報テーブル3000Aを参照し、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報のデータ項目「コンポーネント区分」が、「既存」又は「追加」のいずれであるかを判別する。
本実施形態では、コンポーネント情報テーブル3000Aにおいて、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報は、データ項目「コンポーネント区分」が「既存」である。したがって、コンポーネント判別部1321Aは、取得要求に係るコンポーネントが既存コンポーネントであると判別する。
以上のように、本実施形態に係るサービス提供システム10では、コンポーネント情報のデータ項目「コンポーネント区分」を参照することで、取得要求に係るコンポーネントが既存コンポーネント又は追加コンポーネントのいずれであるかを判別する。これにより、本実施形態に係るサービス提供システム10では、既存コンポーネント又は追加コンポーネントのいずれであるかの判別を、より簡易に行うことができる。
[第三の実施形態]
次に、第三の実施形態に係る情報処理システム1について説明する。第三の実施形態では、フロー実行処理において、既存コンポーネントも生成ファイルに基づいて生成する。なお、以降では、第二の実施形態と実質的に同一の機能を有する箇所及び同一の処理を行う箇所については、第二の実施形態と同一の符号を用いて、その説明を省略する。
<ソフトウェア構成>
本実施形態に係る情報処理システム1に含まれるサービス提供システム10のロジック処理部130の処理ブロックについて、図20を参照しながら説明する。図20は、第三の実施形態に係るロジック処理部の一例の処理ブロックを示す図である。
本実施形態に係るロジック処理部130のコンポーネント管理部132は、既存コンポーネント生成部1322Aを有する。また、本実施形態に係るロジック処理部130は、コンポーネント情報テーブル3000Bを利用する。
既存コンポーネント生成部1322Aは、コンポーネント判別部1321Aによりコンポーネントの取得要求に係るコンポーネントが既存コンポーネントであると判別された場合、当該取得要求に係る既存コンポーネントを生成する。このとき、既存コンポーネント生成部1322Aは、コンポーネント情報テーブル3000Bから既存コンポーネントの生成ファイルを取得し、当該取得した生成ファイルに基づいて既存コンポーネントを生成する。
ここで、コンポーネント情報テーブル3000Bについて、図21を参照しながら説明する。図21は、第三の実施形態に係るコンポーネント情報テーブルの一例を示す図である。
図21に示すコンポーネント情報テーブル3000Bは、既存コンポーネントのコンポーネント情報のデータ項目「ファイル」に、生成ファイルが格納されている。このように、本実施形態に係るコンポーネント情報テーブル3000Bは、既存コンポーネントの生成ファイルも管理している。
<処理の詳細>
次に、本実施形態に係る情報処理システム1の処理の詳細について説明する。
≪フロー実行処理≫
以降では、本実施形態に係るフロー実行処理について、図22を参照しながら説明する。図22は、第三の実施形態に係るフロー実行処理の一例を示すシーケンス図である。なお、第二の実施形態に係るフロー実行処理と同様の処理を行う箇所については、その説明を省略する。
既存コンポーネント生成部1322Aは、コンポーネントの取得要求を受け取ると、コンポーネント名「uploadA」、バージョン「v1」に基づき、コンポーネント情報テーブル3000Bからコンポーネントの生成ファイルを取得する(ステップS2201)。すなわち、既存コンポーネント生成部1322Aは、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報のデータ項目「ファイル」に格納されている生成ファイルを取得する。
次に、既存コンポーネント生成部1322Aは、取得した生成ファイルに基づいて既存コンポーネントを生成する(ステップS2202)。すなわち、既存コンポーネント生成部1322Aは、コンポーネント名「uploadA」、バージョン「v1」のコンポーネント情報から取得した生成ファイルに基づいて、配信Aコンポーネント1333を生成する。なお、配信Aコンポーネント1333の生成は、例えば、JAR形式の生成ファイルを実行して、コンポーネント共通I/F1330に定義されたコンポーネントを生成するためのAPIを用いて行うことができる。
そして、既存コンポーネント生成部1322Aは、配信Aコンポーネント1333が生成されると、配信Aコンポーネント1333をフロー実行部131に返信する。これは、例えば、既存コンポーネント生成部1322Aは、配信Aコンポーネント1333が展開されたメモリ(例えばRAM14)上のアドレスを、フロー実行部131に返信すれば良い。
以上のように、本実施形態に係るサービス提供システム10では、コンポーネント情報テーブル3000Bに格納された生成ファイルに基づいて、既存コンポーネントの生成を行う。これにより、本実施形態に係るサービス提供システム10では、既存コンポーネントと追加コンポーネントを同様に管理することができる。
本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。