JP7017660B1 - 情報処理装置、情報処理システム、情報処理方法及びプログラム - Google Patents

Abstract

【課題】情報処理に関する多様なサービスを、より簡便に提供すること。【解決手段】管理サーバ３０は、クライアント端末４０からのリクエストに応じて、クライアント端末４０にレスポンスを返却する管理サーバ３０であって、連続サービス制御部３１３と、追加サービス制御部３１５と、を備える。連続サービス制御部３１３は、リクエストに対応するサービスを実行し、該実行結果をレスポンスとしてクライアント端末４０に返却する。追加サービス制御部３１５は、連続サービス制御部３１３によるサービスの実行を契機として、リクエストに対応する追加サービスを実行し、該実行結果を追加サービスに対応する送信先に対して、レスポンスの返却とは関わりなく送信する。【選択図】図８

Description

本発明は、情報処理装置、情報処理システム、情報処理方法及びプログラムに関する。

近年、情報処理の分野において、企業や個人を対象に様々なサービスが提供されている。これらのサービスは、例えば、いわゆるクラウドサービスや、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）による連携を利用したサービスといった態様で提供される。
このようなサービスの提供に関する技術の一例が、特許文献１に開示されている。特許文献１に開示の技術では、サービスを提供するシステムを監視することにより、サービスを提供するシステムを円滑に運用する。

特開２０２１－０４３８５５号公報

しかしながら、一般的な技術は、特定のサービスを提供することを前提としているものが殆どであり、多様なサービスを簡便に提供するという観点において、未だ改善の余地があると考えられる。

本発明の課題は、情報処理に関する多様なサービスを、より簡便に提供することである。

上記課題を解決するため、本発明の一実施形態に係る情報処理装置は、
クライアントからのリクエストに応じて、前記クライアントにレスポンスを返却する情報処理装置であって、
前記クライアントからのリクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記クライアントに返却する第１処理制御手段と、
前記第１処理制御手段による前記サービスの実行を契機として、前記クライアントからのリクエストに対応する追加サービスを実行し、該実行結果を前記追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第２処理制御手段と、
を備えることを特徴とする。

本発明によれば、情報処理に関する多様なサービスを、より簡便に提供することができる。

本発明に係る情報処理システムＳ全体のシステム構成を示す模式図である。 情報処理システムＳにより実現される連続サービス機能と追加サービス機能の概略について示す概念図である。 各装置を構成する情報処理装置８００のハードウェア構成を示す図である。 運用者端末１０の機能的構成を示すブロック図である。 データベースサーバ２０の機能的構成を示すブロック図である。 連続サービスデータベース２２１のデータベース構造（テーブル）を示す模式図である。 追加サービスデータベース２２２のデータベース構造（テーブル）を示す模式図である。 管理サーバ３０の機能的構成を示すブロック図である。 クライアント端末４０の機能的構成を示すブロック図である。 サービス提供サーバ５０の機能的構成を示すブロック図である。 運用者端末１０が実行するデータベース設定処理の流れを示すフローチャートである。 データベースサーバ２０が実行する設定記憶処理の流れを示すフローチャートである。 管理サーバ３０が実行するサービス特定処理の流れを示すフローチャートである。 管理サーバ３０が実行する連続サービス制御処理の流れを示すフローチャートである。 管理サーバ３０が実行するフロー実行処理の流れを示すフローチャートである。 管理サーバ３０が実行する追加サービス制御処理の流れを示すフローチャートである。 クライアント端末４０が実行するクライアント側処理の流れを示すフローチャートである。 サービス提供サーバ５０が実行するサーバ側処理の流れを示すフローチャートである。 何れのサービスを連続サービスに設定するかを選択するための設定用画面例を示す模式図である。 追加サービスに関する設定用画面例であって、追加サービスを実行する契機となるＡＰＩを選択するための設定用画面例を示す模式図である。 追加サービスに関する設定用画面例であって、何れのサービスを追加サービスに設定するかを選択するための設定用画面の他の例を示す模式図である。

以下、本発明の実施形態について、図面を参照して説明する。
［構成］
［システム構成］
図１は、本発明に係る情報処理システムＳ全体のシステム構成を示す模式図である。
図１に示すように、情報処理システムＳは、運用者端末１０と、データベースサーバ２０と、管理サーバ３０と、クライアント端末４０－１～４０－ｎ（ｎは自然数）と、を含んで構成される。また、情報処理システムＳは、サービス提供サーバ５０－１～５０－ｍ（ｍは自然数）と連携可能に構成されている。

さらに、運用者端末１０は、データベースサーバ２０と通信可能に接続されている。同様に、管理サーバ３０は、データベースサーバ２０、クライアント端末４０－１～４０－ｎ、及びサービス提供サーバ５０－１～５０－ｍのそれぞれと通信可能に接続されている。これらの通信接続は、有線通信であっても無線通信であってもよく、さらに図示を省略したインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）といったネットワークを介したものであってもよい。

なお、以下の説明において、ｎ台のクライアント端末４０（ここでは、クライアント端末４０－１～４０－ｎ）や、ｍ台のサービス提供サーバ５０（ここでは、サービス提供サーバ５０－１～５０－ｍ）を区別することなく説明する場合には、符号の末尾を省略して、単に「クライアント端末４０」や「サービス提供サーバ５０」と呼ぶ。

情報処理システムＳは、クライアント端末４０を利用するクライアントに対して、様々なサービスを提供するシステムである。例えば、情報処理システムＳでは、ＡＰＩによる連携を利用した様々なサービスが、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に準拠して提供される。

運用者端末１０は、情報処理システムＳを運用する運用者によって用いられる。運用者端末１０では、管理サーバ３０が様々な機能を提供するための設定が行われる。例えば、管理サーバ３０が後述の連続サービス機能や、追加サービス機能を提供するための設定が行われる。

データベースサーバ２０は、運用者端末１０による設定をデータベースとして記憶する。この設定は、上述の運用者端末１０により行われる。また、この設定は、管理サーバ３０により検索され、利用される。

管理サーバ３０は、データベースサーバ２０が記憶する設定に基づいて、情報処理システムＳにおいて様々な機能（例えば、連続サービス機能や、追加サービス機能）を実現する。

クライアント端末４０は、サービスの提供を受けるユーザ（すなわち、クライアント）によって用いられる。このユーザは、企業であってもよいし、個人であってもよい。クライアント端末４０は、サービスの提供を受けるために、リクエストを送信する。

サービス提供サーバ５０は、リクエストに応じてレスポンスを返却することによりサービスの提供を実現する。サービス提供サーバ５０は、情報処理システムＳを運用する運用者により構築されたサーバであってもよいし、この運用者とは異なる他の事業者により構築された外部サーバであってもよい。

［機能の概略］
このような構成を有する情報処理システムＳは、上述したように、特徴的な機能として「（１）連続サービス機能」と、「（２）追加サービス機能」という２つの機能を実現する。これら２つの機能について図２を参照して説明をする。図２は、情報処理システムＳにより実現される連続サービス機能と追加サービス機能の概略について示す概念図である。

ここで、これら機能の前提として、クライアント端末４０は、サービスの提供を受けるために、リクエストを送信する。一方で、サービス提供サーバ５０は、このリクエストに応じてレスポンスを返却することによりサービスの提供を実現する。すなわち、クライアント端末４０及びサービス提供サーバ５０は、いわゆるクライアントサーバシステムとして機能する。
しかしながら、情報処理システムＳでは、これらクライアント端末４０とサービス提供サーバ５０間の通信は直接行われるのではなく、管理サーバ３０を介して行われる。すなわち、サービス提供サーバ５０は、クライアントサーバシステムにおけるプロキシ（代理）として機能する。この場合に、管理サーバ３０は、いわゆるプロキシ（代理）サーバとして単に通信を中継するのではなく、予めなされている設定に基づいて、上述した連続サービス機能と、追加サービス機能といった機能を実現する。

これらの機能について、具体例を用いて説明をする。例えば、図２に示すように、各サービス提供サーバ５０が提供する各種サービスとして「アカウント作成サービス」、「ユーザ作成サービス」、「商品販売サービス」、「メール送信サービス」、「在庫発注サービス」が存在するとする。このような状況で、仮にクライアント端末４０のユーザが複数のサービスの提供を希望する場合、通常は、これら複数のサービスそれぞれに対応した、複数のリクエストを、所定の順序で行う必要がある。しかしながら、これではクライアント端末４０の処理として煩雑である。そこで、管理サーバ３０は、これら複数のサービスを部品として組み合わせることにより、連続サービス機能や追加サービス機能を実現する。

連続サービス機能を実現する場合、管理サーバ３０は、クライアント端末４０からのリクエストに対応する複数のサービスを、連続した一連のサービス（以下、「連続サービス」と称する。）として実行すると共に、その実行結果をレスポンスとしてクライアント端末４０に返却する。クライアント端末４０からのリクエストに対応するこのレスポンスには、全てのサービスの実行結果が含まれていてもよく、一部のサービス実行結果が含まれていてもよく、何れのサービスの実行結果も含まれていなくてもよい。どのようなレスポンスとするのかについては、サービスの内容やサービスの特性等に基づいて、任意に定義することができる。

例えば、クライアント端末４０のユーザがＥＣ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ）サイトを運営する事業者であるとする。この場合、購入者のアカウントを作成するアカウント作成サービス、購入者の情報を登録するユーザ作成サービス、購入対象となる商品を販売する商品販売サービス、購入者に対して販売契約が完了した旨をメールで通知するメール送信サービスといった複数のサービスを、１つの連続サービス（ここでは、「ＥＣサイト運営サービス」）として予め設定しておく。この設定は、例えば、このクライアントを識別するクライアント識別コードを含んだＥＣサイト運営サービスのリクエストに対応付けて、これらの複数のサービスを１つの連続サービスとして設定しておくことにより実現する。

そして、管理サーバ３０は、このクライアント端末４０から、クライアント識別コードを含んだＥＣサイト運営サービスのリクエストを受信した場合に、この設定に基づいて、各サービスに対応する各サービス提供サーバ５０それぞれに対して、順番にリクエストを送信する。そして、管理サーバ３０は、これらのリクエストに応じて、各サービス提供サーバ５０から返却されたレスポンスを、リクエスト元のクライアント端末４０に対して返却する。これにより、情報処理システムＳは、連続サービス機能を実現することができる。この場合に、どのようなレスポンスとするのかについては、上述したように、サービスの内容やサービスの特性等に基づいて、任意に定義することができる。

一方で、追加サービス機能を実現する場合、管理サーバ３０は、クライアント端末４０からのリクエストに対応する或るサービスの実行を契機として、この或るサービスに対応する別途のサービス（以下、「追加サービス」と称する。）を実行し、この実行結果を追加サービスに対応する送信先に対して、レスポンスの返却とは関わりなく送信する。

例えば、上述の例と同様に、クライアント端末４０のユーザがＥＣサイトを運営する事業者であるとする。そして、この事業者は、商品販売サービスにより商品を販売した場合に、商品の在庫をメーカに発注するための「在庫発注サービス」を追加するという希望を持っているとする。この場合、商品販売サービスを実行後に、追加サービスとして在庫発注サービスが提供されるように予め設定しておく。この設定は、例えば、このクライアントを識別するクライアント識別コードを含んだ商品販売サービスのリクエストに対応付けて、在庫発注サービスを追加サービスとして設定しておくことにより実現する。

そして、管理サーバ３０は、このクライアント端末４０から、クライアント識別コードを含んだ商品販売サービスのリクエストを受信した場合に、この設定に基づいて、商品販売サービスに対応するサービス提供サーバ５０に対してリクエストを送信すると共に、このリクエストに応じて、サービス提供サーバ５０から返却されたレスポンスを、リクエスト元のクライアント端末４０に対して返却する。一方で、管理サーバ３０は、追加サービスである在庫発注サービスに対応するサービス提供サーバ５０に対してリクエストを送信すると共に、このリクエストに応じて、サービス提供サーバ５０から返却されたレスポンスを、追加サービスに対応する送信先（リクエスト元のクライアント端末４０の場合もある。）に対して送信する。これにより、情報処理システムＳは、追加サービス機能を実現することができる。

なお、連続サービス機能と追加サービス機能は、これらを組み合わせて利用することもできる。例えば、連続サービス機能によりＥＣサイト運営サービスを実行すると共に、このＥＣサイト運営サービスに含まれる商品販売サービスが行われたことを契機として、追加サービスとして在庫発注サービスを実行することもできる。また、例えば、追加サービスにおいて、商品販売サービスが行われ、且つ、所定の条件（例えば、商品の現時点での在庫数が所定個数未満となったこと）が満たされた場合にのみ、追加サービスである在庫発注サービスを行うようにすることもできる。

以上説明したように、管理サーバ３０は、連続サービス機能として、リクエスト毎に異なる複数のサービスを連続サービスとして実行する。また、管理サーバ３０は、追加サービス機能として、さらに、この連続サービスとは別途に、リクエスト毎に異なる追加サービスを実行する。そして、これら実行される連続サービスや追加サービスは、リクエストを行ったクライアントに対応して設定されているものである。

そのため、管理サーバ３０は、予め設定されている対応関係に基づくのみで、そのクライアント端末４０を利用するクライアントにとって最適なサービスを提供することができる。この場合に、クライアント端末４０は、通常通りリクエストを送信するだけでよい。また、サービス提供サーバ５０も、通常通りリクエストに応じて、レスポンスを返却するだけでよい。そのため、連続サービスや追加サービスを提供する既存のソフトウェアの改変（例えば、ソースコードの編集）等の作業を行う必要や、新たにサービス提供サーバ５０を構築する必要なく、複数のサービスを部品として組み合わせて提供することができる。
従って、管理サーバ３０によれば、情報処理に関する多様なサービスを、より簡便に提供する、という課題を解決することが可能となる。

特に、連続サービスや追加サービスを提供する既存のソフトウェアの改変（例えば、ソースコードの編集）等の作業を行う必要がないので、情報処理システムＳの運用者やソフトウェアの開発者の労力を軽減できる。これに伴い、仮にソフトウェアを改変すると、これに波及して他のサービスのソフトウェア等の修正も必要となってしまうという問題を防止することができる。また、他の事業者が提供するサービスといった、そもそもソースコードを改変することが現実的ではないものも部品として組み合わせることができる。つまり、より一層サービスを活用することができる。
また、対応関係に関する設定を変更するだけで、各クライアント端末４０を利用するクライアントごとに、個別にサービスを組み合わせたり、個別にサービスを追加したりすること（すなわち、個別にカスタマイズすること）が容易に実現できる。したがって、情報処理システムＳの運用者やソフトウェアの開発者に加えて、各クライアント端末４０のユーザに対してもメリットを与えることができる。

［ハードウェア構成］
次に、情報処理システムＳにおける各装置のハードウェア構成を説明する。
情報処理システムＳに含まれる各装置、及びこの情報処理システムＳと連携するサービス提供サーバ５０のそれぞれは、スマートフォンや、タブレット型の端末や、パーソナルコンピュータや、サーバ装置といった情報処理装置８００によって構成され、その基本的構成は同様である。

図３は、各装置を構成する情報処理装置８００のハードウェア構成を示す図である。
図３に示すように、各装置を構成する情報処理装置８００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）８１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）８１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８１３と、バス８１４と、入力部８１５と、出力部８１６と、記憶部８１７と、通信部８１８と、ドライブ８１９と、撮像部８２０と、を備えている。

ＣＰＵ８１１は、ＲＯＭ８１２に記録されているプログラム、または、記憶部８１７からＲＡＭ８１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ８１３には、ＣＰＵ８１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ８１１、ＲＯＭ８１２及びＲＡＭ８１３は、バス８１４を介して相互に接続されている。バス８１４には、入力部８１５、出力部８１６、記憶部８１７、通信部８１８、ドライブ８１９及び撮像部８２０が接続されている。

入力部８１５は、各種ボタン等で構成され、指示操作に応じて各種情報を入力する。
出力部８１６は、ディスプレイやスピーカ等で構成され、画像や音声を出力する。

記憶部８１７は、ハードディスクあるいはＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各サーバで管理される各種データを記憶する。
通信部８１８は、ネットワークを介して他の装置との間で行う通信を制御する。

ドライブ８１９には、磁気ディスク、光ディスク、光磁気ディスク、あるいは半導体メモリ等よりなる、リムーバブルメディア８３１が適宜装着される。ドライブ８１９によってリムーバブルメディア８３１から読み出されたプログラムは、必要に応じて記憶部８１７にインストールされる。
撮像部８２０は、レンズ及び撮像素子等を備えた撮像装置によって構成され、被写体のデジタル画像を撮像する。
なお、情報処理装置８００がデータベースサーバ２０、管理サーバ３０、あるいはサービス提供サーバ５０として構成される場合には、撮像部８２０を省略した構成とすることも可能である。また、情報処理装置８００がタブレット端末として構成される場合には、入力部８１５をタッチセンサによって構成し、出力部８１６のディスプレイに重ねて配置することにより、タッチパネルを備える構成とすることも可能である。

［機能的構成］
次に、情報処理システムＳにおける各装置の機能的構成について説明する。
［運用者端末１０の構成］
図４は、運用者端末１０の機能的構成を示すブロック図である。
図４に示すように、運用者端末１０のＣＰＵ８１１においては、ＵＩ制御部１１１と、フロー変換部１１２と、設定指示部１１３と、が機能する。また、運用者端末１０の記憶部８１７においては、サービス情報記憶部１２１が形成される。
以下で特に言及しない場合も含め、これら機能ブロック間では、処理を実現するために必要なデータを、適切なタイミングで適宜送受信する。

ＵＩ制御部１１１は、運用者による操作を実現するためのユーザインターフェースの表示を制御する。例えば、ＵＩ制御部１１１は、運用者が、通常のサービスや、連続サービスや、追加サービスに関する設定を行うための、設定用画面の表示を制御する。この設定用画面は、任意のレイアウトとすることができるが、例えば、何れのクライアントの何れのリクエストに、何れの通常のサービスや、何れの連続サービスや、何れの追加サービスが対応するのかを選択するためのグラフィカルユーザインターフェースとすることができる。これにより、ＵＩ制御部１１１は、運用者に、サービスを選択するという簡便な操作を行わせるのみで、通常のサービスや、連続サービスや、追加サービスに関する設定を行うことができる。このようなグラフィカルユーザインターフェースの具体例については、情報処理システムＳ全体の機能及び動作を説明した後に説明する。

フロー変換部１１２は、グラフィカルユーザインターフェースを参照した運用者の、連続サービスや、追加サービスの選択結果を、コンピュータが実行可能なデータ形式に変換する。コンピュータが実行可能なデータ形式とは、例えば、連続サービス及び追加サービスの実行に必要な情報や、所定の機能を実現するためのソースコード等が、ブロック単位のフローとしてＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式で記述されたデータである。
また、フロー変換部１１２は、連続サービスや追加サービス以外の、通常のサービスに関する運用者の設定（例えば、新たな通常のサービスの追加）があった場合にも、この設定を、コンピュータが実行可能なデータ形式に変換する。この場合、コンピュータが実行可能なデータ形式とは、例えば、サービスを提供するサービス提供サーバ５０に対応するＵＲＬや、サービスのＩＤや、ＡＰＩのＩＤ等を記述したデータである。

なお、ＵＩ制御部１１１による表示の制御やフロー変換部１１２による変換を行うために必要となる、サービスに関する情報（例えば、サービスの名称や機能の情報や、サービスに対応するサービス提供サーバ５０の情報や、リクエストを作成するためのサービスのＩＤや、ＡＰＩのＩＤや、各クライアント端末４０のユーザの情報や、その他サービスの実行に必要な情報）は、サービス情報記憶部１２１に記憶されている。すなわち、サービス情報記憶部１２１は、サービスに関する情報を記憶する記憶部（リポジトリ）として機能する。

設定指示部１１３は、フロー変換部１１２が変換後のデータを、データベースサーバ２０に記憶させることにより、通常のサービスや、連続サービスや、追加サービスに関する設定を行う。そのために、設定指示部１１３は、フロー変換部１１２が変換後のデータを、設定指示と共に、データベースサーバ２０に対して送信する。

［データベースサーバ２０の構成］
図５は、データベースサーバ２０の機能的構成を示すブロック図である。
図５に示すように、データベースサーバ２０のＣＰＵ８１１においては、データベース管理部２１１が機能する。また、データベースサーバ２０の記憶部８１７においては、連続サービスデータベース２２１と、追加サービスデータベース２２２と、が形成される。
以下で特に言及しない場合も含め、これら機能ブロック間では、処理を実現するために必要なデータを、適切なタイミングで適宜送受信する。

データベース管理部２１１は、連続サービスデータベース２２１や追加サービスデータベース２２２に構築されているデータベースを管理する。具体的に、データベース管理部２１１は、運用者端末１０の設定指示部１１３から送信されてきた設定指示に基づいて、通常のサービスや、連続サービスの設定に対応する変換後のデータを連続サービスデータベース２２１に構築されているデータベースに格納することにより、データベースを更新する。同様に、データベース管理部２１１は、運用者端末１０の設定指示部１１３から送信されてきた設定指示に基づいて、追加サービスの設定に対応する変換後のデータを追加サービスデータベース２２２に構築されているデータベースに格納することにより、データベースを更新する。すなわち、連続サービスデータベース２２１は、通常のサービスに関する設定や、連続サービス機能に関する設定を格納するデータベース（リポジトリ）として機能する。また、追加サービスデータベース２２２は、追加サービス機能に関する設定を格納するデータベース（リポジトリ）として機能する。

また、連続サービスデータベース２２１は、管理サーバ３０からの検索要求があった場合には、この検索要求に基づいて、連続サービスデータベース２２１や追加サービスデータベース２２２を検索して情報を抽出すると共に、その抽出した情報を管理サーバ３０に対して返却する。

次に、連続サービスデータベース２２１及び追加サービスデータベース２２２のデータベース構造（テーブル）について、図６及び図７を参照して説明する。

図６は、連続サービスデータベース２２１のデータベース構造（テーブル）を示す模式図である。図６に示すように、連続サービスデータベース２２１のデータベース構造（テーブル）は、列（カラム）として、「サービスＩＤ」、「ＡＰＩＩＤ」、「クライアント識別コード」、「ＵＲＬ」、「連続サービスフローデータ」、及び「パラメータメタデータ」を含んでいる。また、連続サービスデータベース２２１のデータベース構造（テーブル）は、通常のサービスや連続サービスそれぞれについて、行（レコード）を設けている。そして各入力項目（フィールド）には、データベース管理部２１１により対応するデータが格納される。

ここで、サービスＩＤは、通常のサービスや、連続サービスや、追加のサービスを特定するための識別子である。
また、ＡＰＩＩＤは、ＡＰＩを特定するための識別子である。一般的に１つのサービスは、複数のＡＰＩと連携して、複数のリクエストを行うことにより実現される。そこで、この１つのサービスに対応する複数のリクエストを実現するために、１つのサービスに対応するサービスＩＤと複数のリクエストに対応する複数のＡＰＩＩＤが組み合わされて利用される。これにより、１つのサービスに対応する複数のリクエストを実現することができる。

クライアント識別コードは、クライアント端末４０のユーザであるクライアントを識別するための識別子である。例えば、クライアント端末４０のユーザが企業である場合には、その企業名等がクライアント識別コードとして利用される。
ＵＲＬは、サービスを提供するサービス提供サーバ５０に対応するＵＲＬである。通常のサービスについては、このＵＲＬが格納されている。一方で、連続サービスについては、ＵＲＬは格納されていない。

連続サービスフローデータは、運用者端末１０のフロー変換部１１２が変換後の、ブロック単位のフローとしてＪＳＯＮ形式で記述されたデータである。連続サービスについては、この連続サービスフローデータが格納されている。一方で、通常のサービスについては、連続サービスフローデータは格納されていない。

パラメータメタデータは、ＡＰＩによる連携を利用したサービスの提供を受ける場合に、そのＡＰＩが要求するパラメータの情報である。例えば、ユーザ情報を提供するＡＰＩの場合、どのユーザの情報を提供するかを特定する「ｕｓｅｒＩｄ」というパラメータを必ず送信する必要があるが、このようなＡＰＩが要求する情報をまとめたものが、パラメータメタデータである。このパラメータメタデータに基づいて、リクエストは生成される。

図７は、追加サービスデータベース２２２のデータベース構造（テーブル）を示す模式図である。図７に示すように、追加サービスデータベース２２２のデータベース構造（テーブル）は、列（カラム）として、「サービスＩＤ」、「ＡＰＩＩＤ」、「クライアント識別コード」、及び、「追加サービスフローデータ」を含んでいる。また、追加サービスデータベース２２２のデータベース構造（テーブル）は、追加サービスそれぞれについて、行（レコード）を設けている。そして各入力項目（フィールド）には、データベース管理部２１１により対応するデータが格納される。

ここで、サービスＩＤは、追加サービスを特定するための識別子である。
また、ＡＰＩＩＤは、ＡＰＩを特定するための識別子である。

クライアント識別コードは、クライアント端末４０のユーザを識別するための識別子である。
追加サービスフローデータは、運用者端末１０のフロー変換部１１２が変換後の、ブロック単位のフローとしてＪＳＯＮ形式で記述されたデータである。追加サービスデータベース２２２では、これら４つの情報が紐付いている。

［管理サーバ３０の構成］
図８は、管理サーバ３０の機能的構成を示すブロック図である。
図８に示すように、管理サーバ３０のＣＰＵ８１１においては、依頼応答送受信部３１１と、サービス特定部３１２と、連続サービス制御部３１３と、フロー実行部３１４と、追加サービス制御部３１５と、が機能する。また、管理サーバ３０の記憶部８１７においては、処理データ記憶部３２１が形成される。
以下で特に言及しない場合も含め、これら機能ブロック間では、処理を実現するために必要なデータを、適切なタイミングで適宜送受信する。

依頼応答送受信部３１１は、リクエスト及びレスポンスを送受信する。具体的に、依頼応答送受信部３１１は、クライアント端末４０からのリクエストを受信する。また、依頼応答送受信部３１１は、このリクエストに対応して管理サーバ３０において作成されたリクエストを、リクエストに対応するサービス提供サーバ５０に対して送信する。さらに、依頼応答送受信部３１１は、サービス提供サーバ５０から返却されたレスポンスを受信すると共に、このレスポンスを対応するクライアント端末４０に送信（すなわち、返却）したり、追加サービスに対応する送信先に対して送信したりする。

ここで、サービス特定部３１２、連続サービス制御部３１３、フロー実行部３１４、及び追加サービス制御部３１５は、連続サービス機能や追加サービス機能を実現するために、それぞれが所定の関数を実行する。これら関数を実行する場合にこれら各機能ブロック間で発生する引数や返却値は、処理データ記憶部３２１に一時的に記憶される。また、依頼応答送受信部３１１が、送受信するリクエスト及びレスポンスについても、処理データ記憶部３２１に一時的に記憶される。すなわち、処理データ記憶部３２１は、管理サーバ３０において実行される様々な処理に関連する情報の記憶部（リポジトリ）として機能する。

サービス特定部３１２は、クライアント端末４０から受信したリクエストと、データベースサーバ２０の連続サービスデータベース２２１が記憶する情報とに基づいて、このリクエストに対応する、通常のサービスや連続サービスを特定する関数を実行する。

連続サービス制御部３１３は、リクエストに対応する通常のサービス実行する制御や、対応する連続サービスをフロー実行部３１４に実行させる制御を行う。また、連続サービス制御部３１３は、この通常のサービスや連続サービスの実行結果を、依頼応答送受信部３１１を介してレスポンスとしてクライアント端末４０に返却する。この場合に、どのようなレスポンスとするのかについては、上述したように、サービスの内容やサービスの特性等に基づいて、任意に定義することができる。

フロー実行部３１４は、連続サービス制御部３１３や追加サービス制御部３１５の制御に基づいて、連続サービスや、追加サービスを実行する。これらのサービスは、データベースサーバ２０の連続サービスデータベース２２１が記憶する連続サービスフローや、データベースサーバ２０の追加サービスデータベース２２２が記憶する追加サービスフローに基づいて、実行される。

追加サービス制御部３１５は、連続サービス制御部３１３による追加サービスや連続サービスの実行を契機として、リクエストに対応する追加サービスをフロー実行部３１４に実行させる制御を行う。また、追加サービス制御部３１５は、この追加サービスの実行結果を追加サービスに対応する送信先に対して、通常のサービスや連続サービスのレスポンスの返却とは関わりなく送信する。

［クライアント端末４０の構成］
図９は、クライアント端末４０の機能的構成を示すブロック図である。
図９に示すように、クライアント端末４０のＣＰＵ８１１においては、ＵＩ制御部４１１と、依頼部４１２と、クライアント側処理部４１３と、が機能する。また、クライアント端末４０の記憶部８１７においては、クライアント側ソフトウェア記憶部４２１が形成される。
以下で特に言及しない場合も含め、これら機能ブロック間では、処理を実現するために必要なデータを、適切なタイミングで適宜送受信する。

ＵＩ制御部４１１は、クライアント端末４０のユーザによる操作を実現するためのユーザインターフェースの表示を制御する。例えば、ＵＩ制御部４１１は、ユーザが、通常のサービスや、連続サービスや、追加サービスの実行指示を行うための指示用画面の表示や、これらサービスにより提供される情報（例えば、文字、静止画、及び動画等）を閲覧するための閲覧用画面の表示を制御する。

依頼部４１２は、ユーザの実行指示がなされた場合や、所定の条件（例えば、所定の周期の到来）が満たされた場合に、通常のサービスや、連続サービスや、追加サービスを実行するためのリクエストを生成する。そして、依頼部４１２は、生成したリクエストを管理サーバ３０に対して送信する。このリクエストには、実行するサービスのサービスＩＤ及びＡＰＩＩＤ、並びに、クライアント端末４０のユーザに対応するクライアント識別コード（以下、これらを「識別情報群」と称する。）が含まれる。

また、リクエストには、さらに、リクエストパラメータが含まれる。リクエストパラメータとは、ＡＰＩによる連携を利用したサービスの提供を受ける場合に、そのＡＰＩに対応するサービス提供サーバ５０に対して実際に送信すべきパラメータである。例えば、データベースサーバ２０の連続サービスデータベース２２１の説明の際に例示したように、パラメータメタデータが、ユーザ情報を提供するＡＰＩである場合には、リクエストパラメータは、「ｕｓｅｒＩｄ：Ｘｘｘｘｘｘ－Ｙｙｙｙｙｙ」というように、実際の値に対応するパラメータを当てはめたものとなる。なお、この「Ｘｘｘｘｘｘ－Ｙｙｙｙｙｙ」は、ユーザの名字及び名前をアルファベット表記したものであるとする。

クライアント側処理部４１３は、サービスの提供を受けるためのクライアント側のソフトウェア（例えば、サービスに対応するクライアント側のプログラム）を、提供されるサービスそれぞれに対応して動作させる。このクライアント側処理部４１３によるクライアント側のソフトウェアの動作により、ＵＩ制御部４１１が作成する各種画面への表示や、依頼部４１２によるリクエストの生成が実現される。クライアント側処理部４１３が動作させる、クライアント側のソフトウェアは、クライアント側ソフトウェア記憶部４２１に記憶されている。すなわち、クライアント側ソフトウェア記憶部４２１は、クライアント側のソフトウェアを記憶するする記憶部（リポジトリ）として機能する。

［サービス提供サーバ５０の構成］
図１０は、サービス提供サーバ５０の機能的構成を示すブロック図である。
図１０に示すように、サービス提供サーバ５０のＣＰＵ８１１においては、依頼応答送受信部５１１と、サーバ側処理部５１２と、が機能する。また、サービス提供サーバ５０の記憶部８１７においては、サーバ側ソフトウェア記憶部５２１が形成される。
以下で特に言及しない場合も含め、これら機能ブロック間では、処理を実現するために必要なデータを、適切なタイミングで適宜送受信する。

依頼応答送受信部５１１は、リクエスト及びレスポンスを送受信する。具体的に、依頼応答送受信部５１１は、管理サーバ３０からのリクエストを受信する。また、依頼応答送受信部５１１は、このリクエストに対応してサーバ側処理部５１２において作成されたレスポンスを、管理サーバ３０に返却する。

サーバ側処理部５１２は、サービスの提供を提供するためのサーバ側のソフトウェア（例えば、サービスに対応するサーバ側のプログラム）を、提供するサービスそれぞれに対応して動作させる。このサーバ側処理部５１２によるサーバ側のソフトウェアの動作により、レスポンスが生成される。そして、サーバ側処理部５１２は、生成したレスポンスを、依頼応答送受信部５１１を介して管理サーバ３０に対して送信（すなわち、返却）する。サーバ側のソフトウェアは、サーバ側ソフトウェア記憶部５２１に記憶されている。すなわち、サーバ側ソフトウェア記憶部５２１は、サーバ側のソフトウェアを記憶する記憶部（リポジトリ）として機能する。

［動作］
次に、情報処理システムＳの動作を説明する。
［データベース設定処理］
図１１は、運用者端末１０が実行するデータベース設定処理の流れを示すフローチャートである。
データベース設定処理は、運用者端末１０の起動と共に開始され、繰り返し実行される。

データベース設定処理が開始されると、ステップＳ１１において、ＵＩ制御部１１１は、ユーザインターフェース（ここでは、グラフィカルユーザインターフェース）を表示する。

ステップＳ１２において、フロー変換部１１２は、グラフィカルユーザインターフェースを参照した運用者の、通常のサービスまたは連続サービスの設定操作を受け付けたか否かを判定する。設定操作を受け付けた場合は、ステップＳ１２においてＹｅｓと判定され、処理はステップＳ１３に進む。一方で、設定操作を受け付けていない場合は、ステップＳ１３においてＮｏと判定され、処理はステップＳ１５に進む。

ステップＳ１３において、フロー変換部１１２は、グラフィカルユーザインターフェースを参照した運用者の、通常のサービスや、連続サービスの選択結果を、コンピュータが実行可能なデータ形式に変換する。

ステップＳ１４において、設定指示部１１３は、フロー変換部１１２が変換後のデータを、データベースサーバ２０の追加サービスデータベース２２２に記憶させるために、変換後のデータと設定指示とを、データベースサーバ２０に対して送信する。

ステップＳ１５において、フロー変換部１１２は、グラフィカルユーザインターフェースを参照した運用者の、追加サービスの設定操作を受け付けたか否かを判定する。設定操作を受け付けた場合は、ステップＳ１５においてＹｅｓと判定され、処理はステップＳ１６に進む。一方で、設定操作を受け付けていない場合は、ステップＳ１５においてＮｏと判定され、本処理は終了する。そして、ステップＳ１１から処理は繰り返される。

ステップＳ１６において、フロー変換部１１２は、グラフィカルユーザインターフェースを参照した運用者の、追加サービスの選択結果を、コンピュータが実行可能なデータ形式に変換する。

ステップＳ１７において、設定指示部１１３は、フロー変換部１１２が変換後のデータを、データベースサーバ２０の追加サービスデータベース２２２に記憶させるために、変換後のデータと設定指示とを、データベースサーバ２０に対して送信する。これにより、本処理は終了する。そして、ステップＳ１１から処理は繰り返される。

［設定記憶処理処理］
図１２は、データベースサーバ２０が実行する設定記憶処理の流れを示すフローチャートである。
設定記憶処理は、データベースサーバ２０の起動と共に開始され、繰り返し実行される。

設定記憶処理が開始されると、ステップＳ２１において、データベース管理部２１１は、連続サービスデータベース２２１についての設定指示を、運用者端末１０から受信したか否かを判定する。設定指示を受信した場合は、ステップＳ２１においてＹｅｓと判定され、処理はステップＳ２２に進む。一方で、場合は、ステップＳ２１においてＮｏと判定され、処理はステップＳ２３に進む。

ステップＳ２２において、データベース管理部２１１は、運用者端末１０の設定指示部１１３から送信されてきた設定指示に基づいて、通常のサービスや、連続サービスの設定に対応する変換後のデータを連続サービスデータベース２２１に構築されている連続データベースに格納することにより、連続データベースを更新する。

ステップＳ２３において、データベース管理部２１１は、追加サービスデータベース２２２についての設定指示を、運用者端末１０から受信したか否かを判定する。設定指示を受信した場合は、ステップＳ２３においてＹｅｓと判定され、処理はステップＳ２４に進む。一方で、場合は、ステップＳ２１においてＮｏと判定され、処理はステップＳ２５に進む。

ステップＳ２４において、データベース管理部２１１は、運用者端末１０の設定指示部１１３から送信されてきた設定指示に基づいて、追加サービスの設定に対応する変換後のデータを追加サービスデータベース２２２に構築されている追加データベースに格納することにより、追加データベースを更新する。

ステップＳ２５において、データベース管理部２１１は、管理サーバ３０から検索要求を受信したか否かを判定する。検索要求を受信した場合は、ステップＳ２５においてＹｅｓと判定され、処理はステップＳ２６に進む。一方で、検索要求を受信していない場合は、ステップＳ２５においてＮｏと判定され、本処理は終了する。そして、ステップＳ２１から処理は繰り返される。

ステップＳ２６において、データベース管理部２１１は、検索要求に基づいて、連続サービスデータベース２２１や追加サービスデータベース２２２を検索して情報を抽出する。

ステップＳ２７において、データベース管理部２１１は、抽出した情報を管理サーバ３０に対して送信（すなわち、返却）する。これにより、本処理は終了する。そして、ステップＳ１１から処理は繰り返される。

［サービス特定処理］
図１３は、管理サーバ３０が実行するサービス特定処理の流れを示すフローチャートである。
サービス特定処理は、管理サーバ３０が、クライアント端末４０からのリクエストを受信した場合に実行される。

サービス特定処理が開始されると、ステップＳ３１において、サービス特定部３１２は、受信したリクエストから識別情報群（すなわち、実行するサービスのサービスＩＤ及びＡＰＩＩＤ、並びに、クライアント端末４０のユーザに対応するクライアント識別コード）を抽出する。これが本処理の引数である。

ステップＳ３２において、サービス特定部３１２は、識別情報群を検索条件とした検索要求を、データベースサーバ２０に対して送信することにより、連続サービスデータベース２２１に構築されている連続サービスデータベースを検索する。

ステップＳ３３において、サービス特定部３１２は、連続サービスデータベースに、検索条件に対応する検索結果が存在していたか否かを判定する。検索結果が存在していた場合は、ステップＳ３３においてＹｅｓと判定され、処理はステップＳ３４に進む。一方で、検索結果が存在していない場合は、ステップＳ３３においてＮｏと判定され、処理はステップＳ３５に進む。

ステップＳ３４において、サービス特定部３１２は、連続サービスデータベースの検索結果（すなわち、検索条件に基づいて抽出された情報）を、本処理の返却値に設定し、処理データ記憶部３２１に一時的に記憶させる。これにより、本処理は終了する。

ステップＳ３５において、サービス特定部３１２は、エラー処理を行う。エラー処理としては、例えば、クライアント端末４０に対し、実行不可能なサービスがリクエストされたことを示すメッセージ等のエラーメッセージを送信する。これにより、本処理は終了する。

［連続サービス制御処理］
図１４は、管理サーバ３０が実行する連続サービス制御処理の流れを示すフローチャートである。
連続サービス制御処理は、上述したサービス特定処理が正常に終了した場合に、続けて実行される。

サービス特定処理が開始されると、ステップＳ４１において、連続サービス制御部３１３は、サービス特定処理の返却値である連続サービスデータベースの検索結果から、連続サービスフローを抽出する。この連続サービスデータベースの検索結果と、クライアント端末４０から受信したリクエストに含まれているリクエストパラメータが本処理の引数である。

ステップＳ４２において、連続サービス制御部３１３は、連続サービスフローが存在したか（すなわち、実行するサービスが連続サービスであるか）否かを判定する。連続サービスフローが存在した場合は、ステップＳ４２においてＹｅｓと判定され、処理はステップＳ４６に進む。一方で、連続サービスフローが存在しない場合は、ステップＳ４２においてＮｏと判定され、処理はステップＳ４３に進む。

ステップＳ４３において、連続サービス制御部３１３は、連続サービスデータベースの検索結果から、ＵＲＬとパラメータメタデータ抽出する。

ステップＳ４４において、連続サービス制御部３１３は、ＵＲＬとパラメータメタデータに基づいて、リクエストを生成する。具体的に、連続サービス制御部３１３は、パラメータメタデータに対応する情報を、引数であるリクエストパラメータから抽出し、ＵＲＬに対応するサービス提供サーバ５０に対するリクエストを生成する。

ステップＳ４５において、連続サービス制御部３１３は、生成したリクエストを、ＵＲＬに対応するサービス提供サーバ５０に対して送信する。これにより、通常サービスのリクエストが行われたこととなる。

ステップＳ４６において、連続サービス制御部３１３は、連続サービスフローを処理対象として、後述するフロー実行処理をフロー実行部３１４に実行させる。

ステップＳ４７において、連続サービス制御部３１３は、フロー実行部３１４が実行したフロー実行処理の結果を取得して、これをレスポンスとする。

ステップＳ４８において、連続サービス制御部３１３は、レスポンス（ステップＳ４５のリクエストに応じてサービス提供サーバ５０から返却されたレスポンス、または、ステップＳ４７において取得したフロー実行処理の結果に基づくレスポンス）を本処理の返却値に設定し、処理データ記憶部３２１に一時的に記憶させる。これにより、本処理は終了する。

［フロー実行処理］
図１５は、管理サーバ３０が実行するフロー実行処理の流れを示すフローチャートである。
フロー実行処理は、上述したサービス特定処理や、後述の追加サービス制御処理におけるサブルーチンとして実行される。

フロー実行処理が開始されると、ステップＳ５１において、フロー実行部３１４は、実行対象の連続サービスフローまたは実行対象の追加サービスフローの開始ブロックのデータを処理対象として特定する。この実行対象の連続サービスフローまたは実行対象の追加サービスフローが、本処理の引数である。

ステップＳ５２において、フロー実行部３１４は、処理対象のブロックに対応する処理を開始する。

ステップＳ５３において、フロー実行部３１４は、受け取ったブロックのタイプを判定する。ブロックのタイプとしては、例えば、「開始ブロック」、「サービスブロック」、「分岐ブロック」、「ソースコードブロック」、「終了ブロック」が定義されている。

ステップＳ５３において受け取ったブロックが開始ブロックである場合、処理はステップＳ５４に進む。
ステップＳ５３において受け取ったブロックがサービスブロックである場合、処理はステップＳ５８に進む。
ステップＳ５３において受け取ったブロックが分岐ブロックである場合、処理はステップＳ６３に進む。
ステップＳ５３において受け取ったブロックがソースコードブロックである場合、処理はステップＳ６８に進む。
ステップＳ５３において受け取ったブロックが終了ブロックである場合、処理はステップＳ６９に進む。

ステップＳ５４において、フロー実行部３１４は、クライアント端末４０から受信したリクエストに関するリクエストプロパティの変数を定義する。

ステップＳ５５において、フロー実行部３１４は、リクエストプロパティのバリデーション（検証）を実行する。

ステップＳ５６において、フロー実行部３１４は、バリデーションに問題があるか否かの判定を行う。バリデーションに問題がある場合、ステップＳ５６においてＹｅｓと判定されて、処理はステップＳ５７に進む。一方、バリデーションに問題がない場合、ステップＳ５６においてＮｏと判定されて、処理はステップＳ６６に進む。

ステップＳ５７において、フロー実行部３１４は、エラー処理を行う。エラー処理として、例えば、クライアント端末４０に対し、実行不可能なサービスがリクエストされたことを示すメッセージ等のエラーメッセージを送信することができる。これにより、本処理は終了する。

ステップＳ５８において、フロー実行部３１４は、受け取ったブロックのデータに基づいて、実行対象の連続サービスまたは実行対象の追加サービスを特定すると共に、この連続サービスまたは追加サービスのＵＲＬとパラメータメタデータ抽出する。

ステップＳ５９において、フロー実行部３１４は、ＵＲＬとパラメータメタデータに基づいて、リクエストを生成する。具体的に、フロー実行部３１４は、パラメータメタデータに対応する情報を、引数であるリクエストパラメータから抽出し、ＵＲＬに対応するサービス提供サーバ５０に対するリクエストを生成する。

ステップＳ６０において、フロー実行部３１４は、生成したリクエストを、ＵＲＬに対応するサービス提供サーバ５０に対して送信する。これにより、連続サービスまたは追加サービスのリクエストが行われたこととなる。なお、ステップＳ５９～ステップＳ６０の処理は、上述した連続サービス制御処理におけるステップＳ４３～ステップＳ４５と同等の処理であるので、フロー実行部３１４が行うのではなく、連続サービス制御部３１３を呼び出して連続サービス制御部３１３が行うようにしてもよい。

ステップＳ６１において、フロー実行部３１４は、リクエストに応じてサービス提供サーバ５０から返却されたレスポンスを変数に定義する。
ステップＳ６２において、フロー実行部３１４は、レスポンスに応じて次に実行するブロックを決定する。ステップＳ６２の後、フロー実行部３１４は、ステップＳ６６に進む。

ステップＳ６３において、フロー実行部３１４は、分岐ブロックから分岐の条件を取得する。
ステップＳ６４において、フロー実行部３１４は、現在のステータスが取得した分岐の条件に適合するか否かの判定を行う。
現在のステータスが取得した分岐の条件に適合しない場合、ステップＳ６４においてＮｏと判定されて、処理はステップＳ６３に進む。
一方、現在のステータスが取得した分岐の条件に適合する場合、ステップＳ６４においてＹｅｓと判定されて、処理はステップＳ６５に進む。

ステップＳ６５において、フロー実行部３１４は、適合した条件に応じて次に実行するブロックを決定する。
ステップＳ６６において、フロー実行部３１４は、次に実行するブロックを処理対処として特定する。ステップＳ６６の後、処理はステップＳ５２に進む。

ステップＳ６７において、フロー実行部３１４は、ブロックに定義されているソースコードを実行する。ステップＳ６７の後、処理はステップＳ６６に進む。
ステップＳ６８において、フロー実行部３１４は、リクエストに関するレスポンスプロパティの変数を定義する。

ステップＳ６９において、フロー実行部３１４は、レスポンスのステータスコード（ここでは、ＨＴＴＰレスポンスステータスコード）を定義する。

ステップＳ７０において、フロー実行部３１４は、本フロー実行処理の実行結果であるレスポンスを、本フロー実行処理の呼び出し元（すなわち、連続サービス制御部３１３又は追加サービス制御部３１５）に返却する。そして、このレスポンスは、返却された連続サービス制御部３１３又は追加サービス制御部３１５により、レスポンスに対応する送信先に対して送信される。これにより、本処理は終了する。

［追加サービス制御処理］
図１６は、管理サーバ３０が実行する追加サービス制御処理の流れを示すフローチャートである。
追加サービス制御処理は、上述した連続サービス制御処理が終了した場合に、続けて実行される。

追加サービス制御処理が開始されると、ステップＳ８１において、追加サービス制御部３１５は、サービス特定処理の返却値である連続サービスデータベースの検索結果から、識別情報群（すなわち、実行するサービスのサービスＩＤ及びＡＰＩＩＤ、並びに、クライアント端末４０のユーザに対応するクライアント識別コード）を抽出する。この識別情報群と、連続サービス制御処理の返却値であるレスポンスが本処理の引数である。

ステップＳ８２において、追加サービス制御部３１５は、識別情報群を検索条件とした検索要求を、データベースサーバ２０に対して送信することにより、追加サービスデータベース２２２に構築されている追加サービスデータベースを検索する。

ステップＳ８３において、追加サービス制御部３１５は、追加サービスデータベースに、検索条件に対応する検索結果が存在していたか否かを判定する。検索結果が存在していた場合は、ステップＳ８３においてＹｅｓと判定され、処理はステップＳ８４に進む。一方で、検索結果が存在していない場合は、ステップＳ８３においてＮｏと判定され、処理はステップＳ８６に進む。

ステップＳ８４において、追加サービス制御部３１５は、追加サービスデータベースの検索結果（すなわち、検索条件に基づいて抽出された情報）から、追加サービスフローを抽出する。

ステップＳ８５において、追加サービス制御部３１５は、追加サービスフローを処理対象として、上述したフロー実行処理をフロー実行部３１４に実行させる。

ステップＳ８６において、追加サービス制御部３１５は、引数であるレスポンスを、本処理の返却値に設定する。

ステップＳ８７において、追加サービス制御部３１５は、依頼応答送受信部３１１を介して返却値に設定したレスポンスを、リクエスト元のクライアント端末４０に対して送信（すなわち、返却）する。これにより、本処理は終了する。

［クライアント側処理］
図１７は、クライアント端末４０が実行するクライアント側処理の流れを示すフローチャートである。
クライアント側処理は、クライアント端末４０の起動と共に開始され、繰り返し実行される。

クライアント側処理が開始されると、ステップＳ９１において、ＵＩ制御部４１１は、ユーザインターフェースを表示する。

ステップＳ９２において、依頼部４１２は、リクエストの送信条件が満たされたか否かを判定する。例えば、ユーザの実行指示がなされた場合や、所定の条件（例えば、所定の周期の到来）が満たされた場合に、リクエストの送信条件が満たされたと判定される。リクエストの送信条件が満たされた場合は、ステップＳ９２においてＹｅｓと判定され、処理はステップＳ９３に進む。一方で、リクエストの送信条件が満たされていない場合は、ステップＳ９２においてＮｏと判定され、処理はステップＳ９４に進む。

ステップＳ９４において、依頼部４１２は、リクエストを生成する。このリクエストには、上述したように、識別情報群（すなわち、実行するサービスのサービスＩＤ及びＡＰＩＩＤ、並びに、クライアント端末４０のユーザに対応するクライアント識別コード）とリクエストパラメータが含まれる。

ステップＳ９５において、依頼部４１２は、生成したリクエストを管理サーバ３０に対して送信する。

ステップＳ９６において、クライアント側処理部４１３は、管理サーバ３０からリクエストを受信したか否かを判定する。リクエストを受信した場合は、ステップＳ９５においてＹｅｓと判定され、処理はステップＳ９６に進む。一方で、リクエストを受信していない場合は、ステップＳ９５においてＮｏと判定され、本処理は終了する。そして、ステップＳ９１から処理は繰り返される。

ステップＳ９６において、クライアント側処理部４１３は、レスポンスに対応する処理（例えば、取得した情報の表示）を実行する。これにより、本処理は終了する。そして、ステップＳ９１から処理は繰り返される。

［サーバ側処理］
図１８は、サービス提供サーバ５０が実行するサーバ側処理の流れを示すフローチャートである。
サーバ側処理は、サービス提供サーバ５０の起動と共に開始され、繰り返し実行される。
サーバ側処理が開始されると、ステップＳ１０１において、依頼応答送受信部５１１は、リクエストを受信したか否かを判定する。リクエストを受信した場合は、ステップＳ１０１においてＹｅｓと判定され、処理はステップＳ１０２に進む。一方で、場合は、ステップＳ１０１においてＮｏと判定され、本処理は終了する。そして、ステップＳ１０１から処理は繰り返される。
ステップＳ１０２において、サーバ側処理部５１２は、リクエストに対応する処理を実行してレスポンスを生成する。
ステップＳ１０３において、サーバ側処理部５１２は、レスポンスを、依頼応答送受信部５１１を介して管理サーバ３０に対して送信（すなわち、返却）する。

以上説明した各処理によれば、管理サーバ３０は、予め設定されている対応関係に基づくのみで、そのクライアント端末４０を利用するクライアントにとって最適なサービスを提供することができる。この場合に、クライアント端末４０は、通常通りリクエストを送信するだけでよい。また、サービス提供サーバ５０も、通常通りリクエストに応じて、レスポンスを返却するだけでよい。そのため、連続サービスや追加サービスを提供する既存のソフトウェアの改変（例えば、ソースコードの編集）等の作業を行う必要や、新たにサービス提供サーバ５０を構築する必要なく、複数のサービスを部品として組み合わせて提供することができる。
。
従って、以上説明した各処理によれば、情報処理に関する多様なサービスを、より簡便に提供する、という課題を解決することが可能となる。

［画面表示例］
運用者端末１０において、運用者が、通常のサービスや、連続サービスや、追加サービスに関する設定を行うための、設定用画面の表示例について、図１９～図２１を参照して説明する。
これらの設定用画面例は、ＵＩ制御部１１１がサービス情報記憶部１２１に記憶されている情報等に基づいて表示の制御を行うことにより、運用者端末１０の出力部８１６に含まれるディスプレイ上に表示される。具体的に、これらの設定画面例では、リクエストに、何れの通常のサービスや、何れの連続サービスや、何れの追加サービスが対応するのかを選択するためのグラフィカルユーザインターフェースが表示される。

図１９は、何れのサービスを連続サービスに設定するかを選択するための設定用画面例を示す模式図である。表示領域ＡＲ１１に連続サービスを構成する部品を選択するアイコンが表示される。例えば、このアイコンからサービスを選択したり、ソースコードを選択したり、分岐や並行処理に関する設定を選択したりすることができる。表示領域ＡＲ１１において選択されたサービス等は、連続サービスを構成する要素として、表示領域ＡＲ１２に配置可能となる。運用者は、これら選択したサービス等をマウス等で移動させる操作を行うことにより、簡便に連続サービスに対応する連続サービスフローを作成することができる。この例であれば、トークンの検証、会員情報の検索、健康情報の取得、ソースコードに基づいた処理の実行、といった一連のサービスを実行する「会員健康情報取得」という連続サービスフローが作成されている。

図２０及び図２１は、追加サービスに関する設定用画面例であって、追加サービスを実行する契機となるＡＰＩを選択すると共に、何れのサービスを追加サービスとして設定するかを選択するための設定用画面例を示す模式図である。表示領域ＡＲ２１には、様々なサービス等が一覧表示されている。また、表示領域ＡＲ２２には、設定の進捗状況を示すバーが表示される。運用者は、まず追加サービスを実行する契機となる、通常のサービスまたは連続サービスを表示領域ＡＲ２１における一覧表示から選択する。次に、運用者は、選択した通常のサービスまたは連続サービスを提供するためのＡＰＩの何れかを表示領域ＡＲ２１における一覧表示から選択する。

すると、画面は、図２１に示す設定用画面例に遷移する。この場合、表示領域ＡＲ１１と同様にして、表示領域ＡＲ３１には追加サービスを構成する部品を選択するアイコンが表示される。例えば、このアイコンからサービスを選択したり、ソースコードを選択したり、分岐や並行処理に関する設定を選択したりすることができる。また、これも表示領域ＡＲ１２と同様にして、表示領域ＡＲ３１において選択されたサービス等は、追加サービスを構成する要素として、表示領域ＡＲ３２に配置可能となる。運用者は、これら選択したサービス等をマウス等で移動させる操作を行うことにより、簡便に追加サービスに対応する追加サービスフローを作成することができる。この例であれば、「ワークフローの申請があった場合に、メッセンジャーに通知する」という追加サービスフローが作成されている。
これにより、図２１において選択した通常のサービスまたは連続サービスを提供するＡＰＩが実行されたことを契機として、図２２において作成した追加サービスフローが実行されることとなる。

このようにして作成された連続サービスフローや追加サービスフローは、上述したようにフロー変換部１１２により変換された後にデータベースサーバ２０に設定され、管理サーバ３０において利用することが可能となる。

以上説明したように、図示したようなグラフィカルユーザインターフェースを用いることにより、運用者は、マウス等での選択や移動等の簡便な操作を行うのみで、連続サービスや追加サービスに関する設定を容易に実現することができる。

以上のように、本実施形態に係る管理サーバ３０は、クライアント端末４０からのリクエストに応じて、クライアント端末４０にレスポンスを返却する管理サーバ３０であって、連続サービス制御部３１３と、追加サービス制御部３１５と、を備える。
連続サービス制御部３１３は、リクエストに対応するサービスを実行し、該実行結果をレスポンスとしてクライアント端末４０に返却する。
追加サービス制御部３１５は、連続サービス制御部３１３によるサービスの実行を契機として、リクエストに対応する追加サービスを実行し、該実行結果を追加サービスに対応する送信先に対して、レスポンスの返却とは関わりなく送信する。

このように、管理サーバ３０は、リクエスト毎に異なるサービスを実行する。また、管理サーバ３０は、さらに、このサービスとは別途に、リクエスト毎に異なる追加サービスを実行する。すなわち、実行されるサービスや追加サービスは、そのクライアント端末４０とそのリクエストの組み合わせに対応するものである。
そのため、管理サーバ３０は、予め設定されている対応関係に基づくのみで、そのクライアント端末４０のユーザにとって最適なサービスや追加サービスを実行することができる。この場合に、クライアント端末４０は、通常通りリクエストを送信するだけでよい。また、サービス提供サーバ５０も、通常通りリクエストに応じて、レスポンスを返却するだけでよい。そのため、サービスや追加サービスを提供する既存のソフトウェアの改変（例えば、ソースコードの編集）等の作業を行う必要や、新たにサービス提供サーバ５０を構築する必要なく、複数のサービスを部品として組み合わせて提供することができる。
従って、管理サーバ３０によれば、情報処理に関する多様なサービスを、より簡便に提供する、という課題を解決することが可能となる。

連続サービス制御部３１３は、リクエストに対応している複数のサービスを連続した一連のサービスとして実行すると共に、該一連のサービスに対応して定義されたレスポンスをクライアント端末４０に返却する。
これにより、管理サーバ３０は、管理サーバ３０は、予め設定されている対応関係に基づくのみで、そのクライアント端末４０のユーザにとって最適な複数のサービスを一連の連続サービスとして実行することができる。

追加サービス制御部３１５は、連続した一連のサービスとして実行される複数のサービスの内の、所定のサービスの実行を契機として、リクエストに対応する追加サービスを実行し、該実行結果をレスポンスとは関わりなく出力する。
これにより、サービスの進捗状況に合わせて、適切なタイミングで追加サービスを実行することができる。

追加サービス制御部３１５は、連続サービス制御部３１３によるサービスの実行を契機として、リクエストに対応する所定の条件が満たされか否かを判定し、所定の条件が満たされないと判定した場合には、追加サービスを実行しない。
これにより、必要な場合にのみサービスと共に追加サービスを実行し、不必要な場合にはサービスのみを実行することができる。

サービス及び追加サービスは、管理サーバ３０にアプリケーションプログラムインターフェースを介して接続された外部サーバに依頼することにより実行するサービスを含む。
これにより、ＡＰＩを介して連携可能な外部サーバ（例えば、管理サーバ３０の運用者が管理する外部サーバ、あるいはこの運用者とは異なる事業者が管理する外部サーバ）が提供するサービスを、管理サーバ３０のサービスや追加サービスに組み込むことができる。

以上のように、本実施形態に係る情報処理システムＳは、クライアント端末４０からのリクエストに応じて、クライアント端末４０にレスポンスを返却する情報処理システムＳであって、ＵＩ制御部１１１と、フロー変換部１１２と、設定指示部１１３と、連続サービス制御部３１３と、追加サービス制御部３１５と、を備える。
ＵＩ制御部１１１は、リクエストに、何れのサービスと何れの追加サービスとが対応するのかを選択するためのグラフィカルユーザインターフェースを表示する。
フロー変換部１１２及び設定指示部１１３は、グラフィカルユーザインターフェースを参照したユーザの選択結果を、コンピュータが実行可能なデータ形式に変換して設定する。
連続サービス制御部３１３は、フロー変換部１１２及び設定指示部１１３の設定に基づいて、リクエストに対応するサービスを実行し、該実行結果をレスポンスとしてクライアント端末４０に返却する。
追加サービス制御部３１５は、フロー変換部１１２及び設定指示部１１３の設定に基づいて、連続サービス制御部３１３によるサービスの実行を契機として、リクエストに対応する追加サービスを実行し、該実行結果を追加サービスに対応する送信先に対して、レスポンスの返却とは関わりなく送信する。
これにより、情報処理システムＳは、ユーザに、グラフィカルユーザインターフェースを用いた簡便な操作を行わせるのみで、リクエストと、サービス及び追加サービスとの対応付けを実現することができる。加えて、情報処理システムＳは、管理サーバ３０と同様の処理を行うこともできる。
従って、情報処理システムＳによれば、情報処理に関する多様なサービスを、より一層簡便に提供することが可能となる。

フロー変換部１１２及び設定指示部１１３は、サービスを提供するソフトウェア及び追加サービスを提供するソフトウェアの改変を行うことなく設定を行う。
これにより、対応関係を設定するために、サービスを提供するソフトウェア及び追加サービスを提供するソフトウェアの改変（例えば、ソースコードの編集）等の作業を行う必要はない。

なお、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。
例えば、上述の実施形態における情報処理システムＳのシステム構成は一例であり、情報処理システムＳの機能が全体として実現されていれば、別体として実現した複数のサーバを１つのサーバとして実現したり、より多くのサーバに機能を分散して実装したりすることが可能である。
また、上述の実施形態におけるサービスとして、ＡＰＩによる連携を利用したマイクロサービスを主として想定することができるが、その他、これらに類するサービスを含めることも可能である。

上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
換言すると、上述の実施形態における機能的構成は例示に過ぎず、特に限定されない。すなわち、上述した一連の処理を全体として実行できる機能が情報処理システムＳを構成するいずれかのコンピュータに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に示した例に限定されない。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

また、上述した一連の処理を実行するためのプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布されるリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。

以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。

１０ 運用者端末、２０ データベースサーバ、３０ 管理サーバ、４０ クライアント端末、５０ サービス提供サーバ、８００ 情報処理装置、８１１ ＣＰＵ、８１２ ＲＯＭ、８１３ ＲＡＭ、８１４ バス、８１５ 入力部、８１６ 出力部、８１７ 記憶部、８１８ 通信部、８１９ ドライブ、８２０ 撮像部、８３１ リムーバブルメディア、１１１，４１１ ＵＩ（ユーザインターフェース）制御部、１１２ フロー変換部、１１３ 設定指示部、１２１ サービス情報記憶部、２１１ データベース管理部、２２１ 連続サービスデータベース、２２２ 追加サービスデータベース、３１１、５１１ 依頼応答送受信部、３１２ サービス特定部、３１３ 連続サービス制御部、３１４ フロー実行部、３１５ 追加サービス制御部、３２１ 処理データ記憶部、４１２ 依頼部、４１３ クライアント側処理部、４２１ クライアント側ソフトウェア記憶部、５１２ サーバ側処理部、５２１ サーバ側ソフトウェア記憶部、Ｓ 情報処理システム

Claims (10)

1. 複数のユーザそれぞれによるクライアント端末を用いたリクエストに応じて、リクエスト元のクライアント端末にレスポンスを返却する情報処理装置であって、
   前記リクエストに含まれるユーザ識別情報に基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する特定手段と、
   前記リクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記リクエスト元のクライアント端末に返却する第１処理制御手段と、
   前記特定手段により前記追加サービスが存在すると特定された場合に、前記第１処理制御手段による前記サービスの実行を契機として、該追加サービスを実行し、該実行結果を該追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第２処理制御手段と、
   を備えることを特徴とする情報処理装置。
2. 前記リクエストに対応するサービスが同一の場合であっても、前記追加サービスが存在するか否かと、前記追加サービスが存在する場合のその追加サービスの処理内容とが、前記複数のユーザによって異なる、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記第１処理制御手段は、前記リクエストに対応している複数のサービスを連続した一連のサービスとして実行すると共に、該一連のサービスに対応する定義に基づいて、前記一連のサービスに含まれる前記複数のサービスの内の何れのサービスの実行結果を前記レスポンスに含ませるか特定し、該特定されたサービスの実行結果のみを前記レスポンスとして前記クライアント端末に返却する、
   ことを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスと、前記ユーザ識別情報とが、前記クライアント端末を用いてリクエストをする複数のユーザ以外の他のユーザの設定指示に基づいて対応付けて設定されており、
   前記特定手段は、前記設定における設定内容と、前記リクエストに含まれるユーザ識別情報とに基づいて、リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する、
   ことを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
5. 前記第２処理制御手段は、前記特定手段により前記追加サービスが存在すると特定された場合に、前記第１処理制御手段による前記サービスの実行を契機として、前記リクエスト元のクライアント端末を用いたユーザに対応する所定の条件が満たされたか否かを判定し、前記所定の条件が満たされないと判定した場合には、該追加サービスを実行しない、
   ことを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
6. 複数のユーザそれぞれによるクライアント端末を用いたリクエストに応じて、リクエスト元のクライアント端末にレスポンスを返却する情報処理システムであって、
   サービスを示すアイコン及び追加サービスを示すアイコンを含んだグラフィカルユーザインターフェースを表示する表示制御手段と、
   前記グラフィカルユーザインターフェースを参照したユーザによる、前記サービスを示すアイコンの選択と、前記追加サービスを示すアイコンの選択とを伴う設定指示に基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスと、ユーザ識別情報とを対応付けて設定する設定手段と、
   前記設定における設定内容と、前記リクエストに含まれるユーザ識別情報とに基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する特定手段と、
   前記リクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記リクエスト元のクライアント端末に返却する第１処理制御手段と、
   前記特定手段により前記追加サービスが存在すると特定された場合に、前記第１処理制御手段による前記サービスの実行を契機として、該追加サービスを実行し、該実行結果を該追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第２処理制御手段と、
   を備えることを特徴とする情報処理システム。
7. 前記設定手段は、前記サービスを提供するソフトウェア及び前記追加サービスを提供するソフトウェアの改変を行うことなく前記設定を行う、
   ことを特徴とする請求項６に記載の情報処理システム。
8. 複数のユーザそれぞれによるクライアント端末を用いたリクエストに応じて、リクエスト元のクライアント端末にレスポンスを返却する情報処理装置により行われる情報処理方法であって、
   前記リクエストに含まれるユーザ識別情報に基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する特定ステップと、
   前記リクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記リクエスト元のクライアント端末に返却する第１処理制御ステップと、
   前記特定ステップにて前記追加サービスが存在すると特定された場合に、前記第１処理制御ステップにおける前記サービスの実行を契機として、該追加サービスを実行し、該実行結果を該追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第２処理制御ステップと、
   を含むことを特徴とする情報処理方法。
9. 複数のユーザそれぞれによるクライアント端末を用いたリクエストに応じて、リクエスト元のクライアント端末にレスポンスを返却する情報処理システムにより行われる情報処理方法であって、
   サービスを示すアイコン及び追加サービスを示すアイコンを含んだグラフィカルユーザインターフェースを表示する表示制御ステップと、
   前記グラフィカルユーザインターフェースを参照したユーザによる、前記サービスを示すアイコンの選択と、前記追加サービスを示すアイコンの選択とを伴う設定指示に基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスと、ユーザ識別情報とを対応付けて設定する設定ステップと、
   前記設定における設定内容と、前記リクエストに含まれるユーザ識別情報とに基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する特定ステップと、
   前記リクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記リクエスト元のクライアント端末に返却する第１処理制御ステップと、
   前記特定ステップにて前記追加サービスが存在すると特定された場合に、前記第１処理制御ステップにおける前記サービスの実行を契機として、該追加サービスを実行し、該実行結果を該追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第２処理制御ステップと、
   を含むことを特徴とする情報処理方法。
10. 複数のユーザそれぞれによるクライアント端末を用いたリクエストに応じて、リクエスト元のクライアント端末にレスポンスを返却するコンピュータに、
    前記リクエストに含まれるユーザ識別情報に基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する特定機能と、
    前記リクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記リクエスト元のクライアント端末に返却する第１処理制御機能と、
    前記特定機能により前記追加サービスが存在すると特定された場合に、前記第１処理制御機能による前記サービスの実行を契機として、該追加サービスを実行し、該実行結果を該追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第２処理制御機能と、
    を実現させることを特徴とするプログラム。

Images