IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社ラキールの特許一覧

特許7017660情報処理装置、情報処理システム、情報処理方法及びプログラム
<>
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図1
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図2
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図3
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図4
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図5
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図6
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図7
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図8
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図9
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図10
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図11
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図12
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図13
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図14
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図15
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図16
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図17
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図18
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図19
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図20
  • 特許-情報処理装置、情報処理システム、情報処理方法及びプログラム 図21
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2022-01-31
(45)【発行日】2022-02-08
(54)【発明の名称】情報処理装置、情報処理システム、情報処理方法及びプログラム
(51)【国際特許分類】
   G06F 9/48 20060101AFI20220201BHJP
【FI】
G06F9/48 370
【請求項の数】 10
(21)【出願番号】P 2021084216
(22)【出願日】2021-05-18
【審査請求日】2021-07-12
【早期審査対象出願】
(73)【特許権者】
【識別番号】507070445
【氏名又は名称】株式会社ラキール
(74)【代理人】
【識別番号】100127384
【弁理士】
【氏名又は名称】坊野 康博
(74)【代理人】
【識別番号】100152054
【弁理士】
【氏名又は名称】仲野 孝雅
(72)【発明者】
【氏名】川上 嘉章
(72)【発明者】
【氏名】加曽利 航平
【審査官】三坂 敏夫
(56)【参考文献】
【文献】特開2012-100113(JP,A)
【文献】特開2002-108683(JP,A)
【文献】特開2020-181565(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/455-9/54
G06F 15/00
(57)【特許請求の範囲】
【請求項1】
複数のユーザそれぞれによるクライアント端末を用いたリクエストに応じて、リクエスト元のクライアント端末にレスポンスを返却する情報処理装置であって、
前記リクエストに含まれるユーザ識別情報に基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する特定手段と、
記リクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記リクエスト元のクライアント端末に返却する第1処理制御手段と、
前記特定手段により前記追加サービスが存在すると特定された場合に、前記第1処理制御手段による前記サービスの実行を契機として、追加サービスを実行し、該実行結果を追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第2処理制御手段と、
を備えることを特徴とする情報処理装置。
【請求項2】
前記リクエストに対応するサービスが同一の場合であっても、前記追加サービスが存在するか否かと、前記追加サービスが存在する場合のその追加サービスの処理内容とが、前記複数のユーザによって異なる、
ことを特徴とする請求項1に記載の情報処理装置。
【請求項3】
前記第1処理制御手段は、前記リクエストに対応している複数のサービスを連続した一連のサービスとして実行すると共に、該一連のサービスに対応する定義に基づいて、前記一連のサービスに含まれる前記複数のサービスの内の何れのサービスの実行結果を前記レスポンスに含ませるか特定し、該特定されたサービスの実行結果のみを前記レスポンスとして前記クライアント端末に返却する、
ことを特徴とする請求項1又は2に記載の情報処理装置。
【請求項4】
前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスと、前記ユーザ識別情報とが、前記クライアント端末を用いてリクエストをする複数のユーザ以外の他のユーザの設定指示に基づいて対応付けて設定されており、
前記特定手段は、前記設定における設定内容と、前記リクエストに含まれるユーザ識別情報とに基づいて、リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する、
ことを特徴とする請求項1乃至3の何れか1項に記載の情報処理装置。
【請求項5】
前記第2処理制御手段は、前記特定手段により前記追加サービスが存在すると特定された場合に、前記第1処理制御手段による前記サービスの実行を契機として、前記リクエスト元のクライアント端末を用いたユーザに対応する所定の条件が満たされか否かを判定し、前記所定の条件が満たされないと判定した場合には、追加サービスを実行しない、
ことを特徴とする請求項1乃至の何れか1項に記載の情報処理装置。
【請求項6】
複数のユーザそれぞれによるクライアント端末を用いたリクエストに応じて、リクエスト元のクライアント端末にレスポンスを返却する情報処理システムであって、
サービスを示すアイコン及び追加サービスを示すアイコンを含んだグラフィカルユーザインターフェースを表示する表示制御手段と、
前記グラフィカルユーザインターフェースを参照したユーザによる、前記サービスを示すアイコンの選択と、前記追加サービスを示すアイコンの選択とを伴う設定指示に基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスと、ユーザ識別情報とを対応付けて設定する設定手段と、
前記設定における設定内容と、前記リクエストに含まれるユーザ識別情報とに基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する特定手段と、
記リクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記リクエスト元のクライアント端末に返却する第1処理制御手段と、
前記特定手段により前記追加サービスが存在すると特定された場合に、前記第1処理制御手段による前記サービスの実行を契機として、追加サービスを実行し、該実行結果を追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第2処理制御手段と、
を備えることを特徴とする情報処理システム。
【請求項7】
前記設定手段は、前記サービスを提供するソフトウェア及び前記追加サービスを提供するソフトウェアの改変を行うことなく前記設定を行う、
ことを特徴とする請求項6に記載の情報処理システム。
【請求項8】
複数のユーザそれぞれによるクライアント端末を用いたリクエストに応じて、リクエスト元のクライアント端末にレスポンスを返却する情報処理装置により行われる情報処理方法であって、
前記リクエストに含まれるユーザ識別情報に基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する特定ステップと、
記リクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記リクエスト元のクライアント端末に返却する第1処理制御ステップと、
前記特定ステップにて前記追加サービスが存在すると特定された場合に、前記第1処理制御ステップにおる前記サービスの実行を契機として、追加サービスを実行し、該実行結果を追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第2処理制御ステップと、
を含むことを特徴とする情報処理方法。
【請求項9】
複数のユーザそれぞれによるクライアント端末を用いたリクエストに応じて、リクエスト元のクライアント端末にレスポンスを返却する情報処理システムにより行われる情報処理方法であって、
サービスを示すアイコン及び追加サービスを示すアイコンを含んだグラフィカルユーザインターフェースを表示する表示制御ステップと、
前記グラフィカルユーザインターフェースを参照したユーザによる、前記サービスを示すアイコンの選択と、前記追加サービスを示すアイコンの選択とを伴う設定指示に基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスと、ユーザ識別情報とを対応付けて設定する設定ステップと、
前記設定における設定内容と、前記リクエストに含まれるユーザ識別情報とに基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する特定ステップと、
記リクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記リクエスト元のクライアント端末に返却する第1処理制御ステップと、
前記特定ステップにて前記追加サービスが存在すると特定された場合に、前記第1処理制御ステップにおる前記サービスの実行を契機として、追加サービスを実行し、該実行結果を追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第2処理制御ステップと、
含むことを特徴とする情報処理方法。
【請求項10】
複数のユーザそれぞれによるクライアント端末を用いたリクエストに応じて、リクエスト元のクライアント端末にレスポンスを返却するコンピュータに、
前記リクエストに含まれるユーザ識別情報に基づいて、前記リクエスト元のクライアント端末を用いたユーザに対応する追加サービスが存在するか否かを特定する特定機能と、
記リクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記リクエスト元のクライアント端末に返却する第1処理制御機能と、
前記特定機能により前記追加サービスが存在すると特定された場合に、前記第1処理制御機能による前記サービスの実行を契機として、追加サービスを実行し、該実行結果を追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第2処理制御機能と、
を実現させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、情報処理システム、情報処理方法及びプログラムに関する。
【背景技術】
【0002】
近年、情報処理の分野において、企業や個人を対象に様々なサービスが提供されている。これらのサービスは、例えば、いわゆるクラウドサービスや、API(Application Programming Interface)による連携を利用したサービスといった態様で提供される。
このようなサービスの提供に関する技術の一例が、特許文献1に開示されている。特許文献1に開示の技術では、サービスを提供するシステムを監視することにより、サービスを提供するシステムを円滑に運用する。
【先行技術文献】
【特許文献】
【0003】
【文献】特開2021-043855号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、一般的な技術は、特定のサービスを提供することを前提としているものが殆どであり、多様なサービスを簡便に提供するという観点において、未だ改善の余地があると考えられる。
【0005】
本発明の課題は、情報処理に関する多様なサービスを、より簡便に提供することである。
【課題を解決するための手段】
【0006】
上記課題を解決するため、本発明の一実施形態に係る情報処理装置は、
クライアントからのリクエストに応じて、前記クライアントにレスポンスを返却する情報処理装置であって、
前記クライアントからのリクエストに対応するサービスを実行し、該実行結果を前記レスポンスとして前記クライアントに返却する第1処理制御手段と、
前記第1処理制御手段による前記サービスの実行を契機として、前記クライアントからのリクエストに対応する追加サービスを実行し、該実行結果を前記追加サービスに対応する送信先に対して、前記レスポンスの返却とは関わりなく送信する第2処理制御手段と、
を備えることを特徴とする。
【発明の効果】
【0007】
本発明によれば、情報処理に関する多様なサービスを、より簡便に提供することができる。
【図面の簡単な説明】
【0008】
図1】本発明に係る情報処理システムS全体のシステム構成を示す模式図である。
図2】情報処理システムSにより実現される連続サービス機能と追加サービス機能の概略について示す概念図である。
図3】各装置を構成する情報処理装置800のハードウェア構成を示す図である。
図4】運用者端末10の機能的構成を示すブロック図である。
図5】データベースサーバ20の機能的構成を示すブロック図である。
図6】連続サービスデータベース221のデータベース構造(テーブル)を示す模式図である。
図7】追加サービスデータベース222のデータベース構造(テーブル)を示す模式図である。
図8】管理サーバ30の機能的構成を示すブロック図である。
図9】クライアント端末40の機能的構成を示すブロック図である。
図10】サービス提供サーバ50の機能的構成を示すブロック図である。
図11】運用者端末10が実行するデータベース設定処理の流れを示すフローチャートである。
図12】データベースサーバ20が実行する設定記憶処理の流れを示すフローチャートである。
図13】管理サーバ30が実行するサービス特定処理の流れを示すフローチャートである。
図14】管理サーバ30が実行する連続サービス制御処理の流れを示すフローチャートである。
図15】管理サーバ30が実行するフロー実行処理の流れを示すフローチャートである。
図16】管理サーバ30が実行する追加サービス制御処理の流れを示すフローチャートである。
図17】クライアント端末40が実行するクライアント側処理の流れを示すフローチャートである。
図18】サービス提供サーバ50が実行するサーバ側処理の流れを示すフローチャートである。
図19】何れのサービスを連続サービスに設定するかを選択するための設定用画面例を示す模式図である。
図20】追加サービスに関する設定用画面例であって、追加サービスを実行する契機となるAPIを選択するための設定用画面例を示す模式図である。
図21】追加サービスに関する設定用画面例であって、何れのサービスを追加サービスに設定するかを選択するための設定用画面の他の例を示す模式図である。
【発明を実施するための形態】
【0009】
以下、本発明の実施形態について、図面を参照して説明する。
[構成]
[システム構成]
図1は、本発明に係る情報処理システムS全体のシステム構成を示す模式図である。
図1に示すように、情報処理システムSは、運用者端末10と、データベースサーバ20と、管理サーバ30と、クライアント端末40-1~40-n(nは自然数)と、を含んで構成される。また、情報処理システムSは、サービス提供サーバ50-1~50-m(mは自然数)と連携可能に構成されている。
【0010】
さらに、運用者端末10は、データベースサーバ20と通信可能に接続されている。同様に、管理サーバ30は、データベースサーバ20、クライアント端末40-1~40-n、及びサービス提供サーバ50-1~50-mのそれぞれと通信可能に接続されている。これらの通信接続は、有線通信であっても無線通信であってもよく、さらに図示を省略したインターネットやLAN(Local Area Network)といったネットワークを介したものであってもよい。
【0011】
なお、以下の説明において、n台のクライアント端末40(ここでは、クライアント端末40-1~40-n)や、m台のサービス提供サーバ50(ここでは、サービス提供サーバ50-1~50-m)を区別することなく説明する場合には、符号の末尾を省略して、単に「クライアント端末40」や「サービス提供サーバ50」と呼ぶ。
【0012】
情報処理システムSは、クライアント端末40を利用するクライアントに対して、様々なサービスを提供するシステムである。例えば、情報処理システムSでは、APIによる連携を利用した様々なサービスが、HTTP(Hyper Text Transfer Protocol)に準拠して提供される。
【0013】
運用者端末10は、情報処理システムSを運用する運用者によって用いられる。運用者端末10では、管理サーバ30が様々な機能を提供するための設定が行われる。例えば、管理サーバ30が後述の連続サービス機能や、追加サービス機能を提供するための設定が行われる。
【0014】
データベースサーバ20は、運用者端末10による設定をデータベースとして記憶する。この設定は、上述の運用者端末10により行われる。また、この設定は、管理サーバ30により検索され、利用される。
【0015】
管理サーバ30は、データベースサーバ20が記憶する設定に基づいて、情報処理システムSにおいて様々な機能(例えば、連続サービス機能や、追加サービス機能)を実現する。
【0016】
クライアント端末40は、サービスの提供を受けるユーザ(すなわち、クライアント)によって用いられる。このユーザは、企業であってもよいし、個人であってもよい。クライアント端末40は、サービスの提供を受けるために、リクエストを送信する。
【0017】
サービス提供サーバ50は、リクエストに応じてレスポンスを返却することによりサービスの提供を実現する。サービス提供サーバ50は、情報処理システムSを運用する運用者により構築されたサーバであってもよいし、この運用者とは異なる他の事業者により構築された外部サーバであってもよい。
【0018】
[機能の概略]
このような構成を有する情報処理システムSは、上述したように、特徴的な機能として「(1)連続サービス機能」と、「(2)追加サービス機能」という2つの機能を実現する。これら2つの機能について図2を参照して説明をする。図2は、情報処理システムSにより実現される連続サービス機能と追加サービス機能の概略について示す概念図である。
【0019】
ここで、これら機能の前提として、クライアント端末40は、サービスの提供を受けるために、リクエストを送信する。一方で、サービス提供サーバ50は、このリクエストに応じてレスポンスを返却することによりサービスの提供を実現する。すなわち、クライアント端末40及びサービス提供サーバ50は、いわゆるクライアントサーバシステムとして機能する。
しかしながら、情報処理システムSでは、これらクライアント端末40とサービス提供サーバ50間の通信は直接行われるのではなく、管理サーバ30を介して行われる。すなわち、サービス提供サーバ50は、クライアントサーバシステムにおけるプロキシ(代理)として機能する。この場合に、管理サーバ30は、いわゆるプロキシ(代理)サーバとして単に通信を中継するのではなく、予めなされている設定に基づいて、上述した連続サービス機能と、追加サービス機能といった機能を実現する。
【0020】
これらの機能について、具体例を用いて説明をする。例えば、図2に示すように、各サービス提供サーバ50が提供する各種サービスとして「アカウント作成サービス」、「ユーザ作成サービス」、「商品販売サービス」、「メール送信サービス」、「在庫発注サービス」が存在するとする。このような状況で、仮にクライアント端末40のユーザが複数のサービスの提供を希望する場合、通常は、これら複数のサービスそれぞれに対応した、複数のリクエストを、所定の順序で行う必要がある。しかしながら、これではクライアント端末40の処理として煩雑である。そこで、管理サーバ30は、これら複数のサービスを部品として組み合わせることにより、連続サービス機能や追加サービス機能を実現する。
【0021】
連続サービス機能を実現する場合、管理サーバ30は、クライアント端末40からのリクエストに対応する複数のサービスを、連続した一連のサービス(以下、「連続サービス」と称する。)として実行すると共に、その実行結果をレスポンスとしてクライアント端末40に返却する。クライアント端末40からのリクエストに対応するこのレスポンスには、全てのサービスの実行結果が含まれていてもよく、一部のサービス実行結果が含まれていてもよく、何れのサービスの実行結果も含まれていなくてもよい。どのようなレスポンスとするのかについては、サービスの内容やサービスの特性等に基づいて、任意に定義することができる。
【0022】
例えば、クライアント端末40のユーザがEC(Electronic Commerce)サイトを運営する事業者であるとする。この場合、購入者のアカウントを作成するアカウント作成サービス、購入者の情報を登録するユーザ作成サービス、購入対象となる商品を販売する商品販売サービス、購入者に対して販売契約が完了した旨をメールで通知するメール送信サービスといった複数のサービスを、1つの連続サービス(ここでは、「ECサイト運営サービス」)として予め設定しておく。この設定は、例えば、このクライアントを識別するクライアント識別コードを含んだECサイト運営サービスのリクエストに対応付けて、これらの複数のサービスを1つの連続サービスとして設定しておくことにより実現する。
【0023】
そして、管理サーバ30は、このクライアント端末40から、クライアント識別コードを含んだECサイト運営サービスのリクエストを受信した場合に、この設定に基づいて、各サービスに対応する各サービス提供サーバ50それぞれに対して、順番にリクエストを送信する。そして、管理サーバ30は、これらのリクエストに応じて、各サービス提供サーバ50から返却されたレスポンスを、リクエスト元のクライアント端末40に対して返却する。これにより、情報処理システムSは、連続サービス機能を実現することができる。この場合に、どのようなレスポンスとするのかについては、上述したように、サービスの内容やサービスの特性等に基づいて、任意に定義することができる。
【0024】
一方で、追加サービス機能を実現する場合、管理サーバ30は、クライアント端末40からのリクエストに対応する或るサービスの実行を契機として、この或るサービスに対応する別途のサービス(以下、「追加サービス」と称する。)を実行し、この実行結果を追加サービスに対応する送信先に対して、レスポンスの返却とは関わりなく送信する。
【0025】
例えば、上述の例と同様に、クライアント端末40のユーザがECサイトを運営する事業者であるとする。そして、この事業者は、商品販売サービスにより商品を販売した場合に、商品の在庫をメーカに発注するための「在庫発注サービス」を追加するという希望を持っているとする。この場合、商品販売サービスを実行後に、追加サービスとして在庫発注サービスが提供されるように予め設定しておく。この設定は、例えば、このクライアントを識別するクライアント識別コードを含んだ商品販売サービスのリクエストに対応付けて、在庫発注サービスを追加サービスとして設定しておくことにより実現する。
【0026】
そして、管理サーバ30は、このクライアント端末40から、クライアント識別コードを含んだ商品販売サービスのリクエストを受信した場合に、この設定に基づいて、商品販売サービスに対応するサービス提供サーバ50に対してリクエストを送信すると共に、このリクエストに応じて、サービス提供サーバ50から返却されたレスポンスを、リクエスト元のクライアント端末40に対して返却する。一方で、管理サーバ30は、追加サービスである在庫発注サービスに対応するサービス提供サーバ50に対してリクエストを送信すると共に、このリクエストに応じて、サービス提供サーバ50から返却されたレスポンスを、追加サービスに対応する送信先(リクエスト元のクライアント端末40の場合もある。)に対して送信する。これにより、情報処理システムSは、追加サービス機能を実現することができる。
【0027】
なお、連続サービス機能と追加サービス機能は、これらを組み合わせて利用することもできる。例えば、連続サービス機能によりECサイト運営サービスを実行すると共に、このECサイト運営サービスに含まれる商品販売サービスが行われたことを契機として、追加サービスとして在庫発注サービスを実行することもできる。また、例えば、追加サービスにおいて、商品販売サービスが行われ、且つ、所定の条件(例えば、商品の現時点での在庫数が所定個数未満となったこと)が満たされた場合にのみ、追加サービスである在庫発注サービスを行うようにすることもできる。
【0028】
以上説明したように、管理サーバ30は、連続サービス機能として、リクエスト毎に異なる複数のサービスを連続サービスとして実行する。また、管理サーバ30は、追加サービス機能として、さらに、この連続サービスとは別途に、リクエスト毎に異なる追加サービスを実行する。そして、これら実行される連続サービスや追加サービスは、リクエストを行ったクライアントに対応して設定されているものである。
【0029】
そのため、管理サーバ30は、予め設定されている対応関係に基づくのみで、そのクライアント端末40を利用するクライアントにとって最適なサービスを提供することができる。この場合に、クライアント端末40は、通常通りリクエストを送信するだけでよい。また、サービス提供サーバ50も、通常通りリクエストに応じて、レスポンスを返却するだけでよい。そのため、連続サービスや追加サービスを提供する既存のソフトウェアの改変(例えば、ソースコードの編集)等の作業を行う必要や、新たにサービス提供サーバ50を構築する必要なく、複数のサービスを部品として組み合わせて提供することができる。
従って、管理サーバ30によれば、情報処理に関する多様なサービスを、より簡便に提供する、という課題を解決することが可能となる。
【0030】
特に、連続サービスや追加サービスを提供する既存のソフトウェアの改変(例えば、ソースコードの編集)等の作業を行う必要がないので、情報処理システムSの運用者やソフトウェアの開発者の労力を軽減できる。これに伴い、仮にソフトウェアを改変すると、これに波及して他のサービスのソフトウェア等の修正も必要となってしまうという問題を防止することができる。また、他の事業者が提供するサービスといった、そもそもソースコードを改変することが現実的ではないものも部品として組み合わせることができる。つまり、より一層サービスを活用することができる。
また、対応関係に関する設定を変更するだけで、各クライアント端末40を利用するクライアントごとに、個別にサービスを組み合わせたり、個別にサービスを追加したりすること(すなわち、個別にカスタマイズすること)が容易に実現できる。したがって、情報処理システムSの運用者やソフトウェアの開発者に加えて、各クライアント端末40のユーザに対してもメリットを与えることができる。
【0031】
[ハードウェア構成]
次に、情報処理システムSにおける各装置のハードウェア構成を説明する。
情報処理システムSに含まれる各装置、及びこの情報処理システムSと連携するサービス提供サーバ50のそれぞれは、スマートフォンや、タブレット型の端末や、パーソナルコンピュータや、サーバ装置といった情報処理装置800によって構成され、その基本的構成は同様である。
【0032】
図3は、各装置を構成する情報処理装置800のハードウェア構成を示す図である。
図3に示すように、各装置を構成する情報処理装置800は、CPU(Central Processing Unit)811と、ROM(Read Only Memory)812と、RAM(Random Access Memory)813と、バス814と、入力部815と、出力部816と、記憶部817と、通信部818と、ドライブ819と、撮像部820と、を備えている。
【0033】
CPU811は、ROM812に記録されているプログラム、または、記憶部817からRAM813にロードされたプログラムに従って各種の処理を実行する。
RAM813には、CPU811が各種の処理を実行する上において必要なデータ等も適宜記憶される。
【0034】
CPU811、ROM812及びRAM813は、バス814を介して相互に接続されている。バス814には、入力部815、出力部816、記憶部817、通信部818、ドライブ819及び撮像部820が接続されている。
【0035】
入力部815は、各種ボタン等で構成され、指示操作に応じて各種情報を入力する。
出力部816は、ディスプレイやスピーカ等で構成され、画像や音声を出力する。
【0036】
記憶部817は、ハードディスクあるいはDRAM(Dynamic Random Access Memory)等で構成され、各サーバで管理される各種データを記憶する。
通信部818は、ネットワークを介して他の装置との間で行う通信を制御する。
【0037】
ドライブ819には、磁気ディスク、光ディスク、光磁気ディスク、あるいは半導体メモリ等よりなる、リムーバブルメディア831が適宜装着される。ドライブ819によってリムーバブルメディア831から読み出されたプログラムは、必要に応じて記憶部817にインストールされる。
撮像部820は、レンズ及び撮像素子等を備えた撮像装置によって構成され、被写体のデジタル画像を撮像する。
なお、情報処理装置800がデータベースサーバ20、管理サーバ30、あるいはサービス提供サーバ50として構成される場合には、撮像部820を省略した構成とすることも可能である。また、情報処理装置800がタブレット端末として構成される場合には、入力部815をタッチセンサによって構成し、出力部816のディスプレイに重ねて配置することにより、タッチパネルを備える構成とすることも可能である。
【0038】
[機能的構成]
次に、情報処理システムSにおける各装置の機能的構成について説明する。
[運用者端末10の構成]
図4は、運用者端末10の機能的構成を示すブロック図である。
図4に示すように、運用者端末10のCPU811においては、UI制御部111と、フロー変換部112と、設定指示部113と、が機能する。また、運用者端末10の記憶部817においては、サービス情報記憶部121が形成される。
以下で特に言及しない場合も含め、これら機能ブロック間では、処理を実現するために必要なデータを、適切なタイミングで適宜送受信する。
【0039】
UI制御部111は、運用者による操作を実現するためのユーザインターフェースの表示を制御する。例えば、UI制御部111は、運用者が、通常のサービスや、連続サービスや、追加サービスに関する設定を行うための、設定用画面の表示を制御する。この設定用画面は、任意のレイアウトとすることができるが、例えば、何れのクライアントの何れのリクエストに、何れの通常のサービスや、何れの連続サービスや、何れの追加サービスが対応するのかを選択するためのグラフィカルユーザインターフェースとすることができる。これにより、UI制御部111は、運用者に、サービスを選択するという簡便な操作を行わせるのみで、通常のサービスや、連続サービスや、追加サービスに関する設定を行うことができる。このようなグラフィカルユーザインターフェースの具体例については、情報処理システムS全体の機能及び動作を説明した後に説明する。
【0040】
フロー変換部112は、グラフィカルユーザインターフェースを参照した運用者の、連続サービスや、追加サービスの選択結果を、コンピュータが実行可能なデータ形式に変換する。コンピュータが実行可能なデータ形式とは、例えば、連続サービス及び追加サービスの実行に必要な情報や、所定の機能を実現するためのソースコード等が、ブロック単位のフローとしてJSON(JavaScript Object Notation)形式で記述されたデータである。
また、フロー変換部112は、連続サービスや追加サービス以外の、通常のサービスに関する運用者の設定(例えば、新たな通常のサービスの追加)があった場合にも、この設定を、コンピュータが実行可能なデータ形式に変換する。この場合、コンピュータが実行可能なデータ形式とは、例えば、サービスを提供するサービス提供サーバ50に対応するURLや、サービスのIDや、APIのID等を記述したデータである。
【0041】
なお、UI制御部111による表示の制御やフロー変換部112による変換を行うために必要となる、サービスに関する情報(例えば、サービスの名称や機能の情報や、サービスに対応するサービス提供サーバ50の情報や、リクエストを作成するためのサービスのIDや、APIのIDや、各クライアント端末40のユーザの情報や、その他サービスの実行に必要な情報)は、サービス情報記憶部121に記憶されている。すなわち、サービス情報記憶部121は、サービスに関する情報を記憶する記憶部(リポジトリ)として機能する。
【0042】
設定指示部113は、フロー変換部112が変換後のデータを、データベースサーバ20に記憶させることにより、通常のサービスや、連続サービスや、追加サービスに関する設定を行う。そのために、設定指示部113は、フロー変換部112が変換後のデータを、設定指示と共に、データベースサーバ20に対して送信する。
【0043】
[データベースサーバ20の構成]
図5は、データベースサーバ20の機能的構成を示すブロック図である。
図5に示すように、データベースサーバ20のCPU811においては、データベース管理部211が機能する。また、データベースサーバ20の記憶部817においては、連続サービスデータベース221と、追加サービスデータベース222と、が形成される。
以下で特に言及しない場合も含め、これら機能ブロック間では、処理を実現するために必要なデータを、適切なタイミングで適宜送受信する。
【0044】
データベース管理部211は、連続サービスデータベース221や追加サービスデータベース222に構築されているデータベースを管理する。具体的に、データベース管理部211は、運用者端末10の設定指示部113から送信されてきた設定指示に基づいて、通常のサービスや、連続サービスの設定に対応する変換後のデータを連続サービスデータベース221に構築されているデータベースに格納することにより、データベースを更新する。同様に、データベース管理部211は、運用者端末10の設定指示部113から送信されてきた設定指示に基づいて、追加サービスの設定に対応する変換後のデータを追加サービスデータベース222に構築されているデータベースに格納することにより、データベースを更新する。すなわち、連続サービスデータベース221は、通常のサービスに関する設定や、連続サービス機能に関する設定を格納するデータベース(リポジトリ)として機能する。また、追加サービスデータベース222は、追加サービス機能に関する設定を格納するデータベース(リポジトリ)として機能する。
【0045】
また、連続サービスデータベース221は、管理サーバ30からの検索要求があった場合には、この検索要求に基づいて、連続サービスデータベース221や追加サービスデータベース222を検索して情報を抽出すると共に、その抽出した情報を管理サーバ30に対して返却する。
【0046】
次に、連続サービスデータベース221及び追加サービスデータベース222のデータベース構造(テーブル)について、図6及び図7を参照して説明する。
【0047】
図6は、連続サービスデータベース221のデータベース構造(テーブル)を示す模式図である。図6に示すように、連続サービスデータベース221のデータベース構造(テーブル)は、列(カラム)として、「サービスID」、「APIID」、「クライアント識別コード」、「URL」、「連続サービスフローデータ」、及び「パラメータメタデータ」を含んでいる。また、連続サービスデータベース221のデータベース構造(テーブル)は、通常のサービスや連続サービスそれぞれについて、行(レコード)を設けている。そして各入力項目(フィールド)には、データベース管理部211により対応するデータが格納される。
【0048】
ここで、サービスIDは、通常のサービスや、連続サービスや、追加のサービスを特定するための識別子である。
また、APIIDは、APIを特定するための識別子である。一般的に1つのサービスは、複数のAPIと連携して、複数のリクエストを行うことにより実現される。そこで、この1つのサービスに対応する複数のリクエストを実現するために、1つのサービスに対応するサービスIDと複数のリクエストに対応する複数のAPIIDが組み合わされて利用される。これにより、1つのサービスに対応する複数のリクエストを実現することができる。
【0049】
クライアント識別コードは、クライアント端末40のユーザであるクライアントを識別するための識別子である。例えば、クライアント端末40のユーザが企業である場合には、その企業名等がクライアント識別コードとして利用される。
URLは、サービスを提供するサービス提供サーバ50に対応するURLである。通常のサービスについては、このURLが格納されている。一方で、連続サービスについては、URLは格納されていない。
【0050】
連続サービスフローデータは、運用者端末10のフロー変換部112が変換後の、ブロック単位のフローとしてJSON形式で記述されたデータである。連続サービスについては、この連続サービスフローデータが格納されている。一方で、通常のサービスについては、連続サービスフローデータは格納されていない。
【0051】
パラメータメタデータは、APIによる連携を利用したサービスの提供を受ける場合に、そのAPIが要求するパラメータの情報である。例えば、ユーザ情報を提供するAPIの場合、どのユーザの情報を提供するかを特定する「userId」というパラメータを必ず送信する必要があるが、このようなAPIが要求する情報をまとめたものが、パラメータメタデータである。このパラメータメタデータに基づいて、リクエストは生成される。
【0052】
図7は、追加サービスデータベース222のデータベース構造(テーブル)を示す模式図である。図7に示すように、追加サービスデータベース222のデータベース構造(テーブル)は、列(カラム)として、「サービスID」、「APIID」、「クライアント識別コード」、及び、「追加サービスフローデータ」を含んでいる。また、追加サービスデータベース222のデータベース構造(テーブル)は、追加サービスそれぞれについて、行(レコード)を設けている。そして各入力項目(フィールド)には、データベース管理部211により対応するデータが格納される。
【0053】
ここで、サービスIDは、追加サービスを特定するための識別子である。
また、APIIDは、APIを特定するための識別子である。
【0054】
クライアント識別コードは、クライアント端末40のユーザを識別するための識別子である。
追加サービスフローデータは、運用者端末10のフロー変換部112が変換後の、ブロック単位のフローとしてJSON形式で記述されたデータである。追加サービスデータベース222では、これら4つの情報が紐付いている。
【0055】
[管理サーバ30の構成]
図8は、管理サーバ30の機能的構成を示すブロック図である。
図8に示すように、管理サーバ30のCPU811においては、依頼応答送受信部311と、サービス特定部312と、連続サービス制御部313と、フロー実行部314と、追加サービス制御部315と、が機能する。また、管理サーバ30の記憶部817においては、処理データ記憶部321が形成される。
以下で特に言及しない場合も含め、これら機能ブロック間では、処理を実現するために必要なデータを、適切なタイミングで適宜送受信する。
【0056】
依頼応答送受信部311は、リクエスト及びレスポンスを送受信する。具体的に、依頼応答送受信部311は、クライアント端末40からのリクエストを受信する。また、依頼応答送受信部311は、このリクエストに対応して管理サーバ30において作成されたリクエストを、リクエストに対応するサービス提供サーバ50に対して送信する。さらに、依頼応答送受信部311は、サービス提供サーバ50から返却されたレスポンスを受信すると共に、このレスポンスを対応するクライアント端末40に送信(すなわち、返却)したり、追加サービスに対応する送信先に対して送信したりする。
【0057】
ここで、サービス特定部312、連続サービス制御部313、フロー実行部314、及び追加サービス制御部315は、連続サービス機能や追加サービス機能を実現するために、それぞれが所定の関数を実行する。これら関数を実行する場合にこれら各機能ブロック間で発生する引数や返却値は、処理データ記憶部321に一時的に記憶される。また、依頼応答送受信部311が、送受信するリクエスト及びレスポンスについても、処理データ記憶部321に一時的に記憶される。すなわち、処理データ記憶部321は、管理サーバ30において実行される様々な処理に関連する情報の記憶部(リポジトリ)として機能する。
【0058】
サービス特定部312は、クライアント端末40から受信したリクエストと、データベースサーバ20の連続サービスデータベース221が記憶する情報とに基づいて、このリクエストに対応する、通常のサービスや連続サービスを特定する関数を実行する。
【0059】
連続サービス制御部313は、リクエストに対応する通常のサービス実行する制御や、対応する連続サービスをフロー実行部314に実行させる制御を行う。また、連続サービス制御部313は、この通常のサービスや連続サービスの実行結果を、依頼応答送受信部311を介してレスポンスとしてクライアント端末40に返却する。この場合に、どのようなレスポンスとするのかについては、上述したように、サービスの内容やサービスの特性等に基づいて、任意に定義することができる。
【0060】
フロー実行部314は、連続サービス制御部313や追加サービス制御部315の制御に基づいて、連続サービスや、追加サービスを実行する。これらのサービスは、データベースサーバ20の連続サービスデータベース221が記憶する連続サービスフローや、データベースサーバ20の追加サービスデータベース222が記憶する追加サービスフローに基づいて、実行される。
【0061】
追加サービス制御部315は、連続サービス制御部313による追加サービスや連続サービスの実行を契機として、リクエストに対応する追加サービスをフロー実行部314に実行させる制御を行う。また、追加サービス制御部315は、この追加サービスの実行結果を追加サービスに対応する送信先に対して、通常のサービスや連続サービスのレスポンスの返却とは関わりなく送信する。
【0062】
[クライアント端末40の構成]
図9は、クライアント端末40の機能的構成を示すブロック図である。
図9に示すように、クライアント端末40のCPU811においては、UI制御部411と、依頼部412と、クライアント側処理部413と、が機能する。また、クライアント端末40の記憶部817においては、クライアント側ソフトウェア記憶部421が形成される。
以下で特に言及しない場合も含め、これら機能ブロック間では、処理を実現するために必要なデータを、適切なタイミングで適宜送受信する。
【0063】
UI制御部411は、クライアント端末40のユーザによる操作を実現するためのユーザインターフェースの表示を制御する。例えば、UI制御部411は、ユーザが、通常のサービスや、連続サービスや、追加サービスの実行指示を行うための指示用画面の表示や、これらサービスにより提供される情報(例えば、文字、静止画、及び動画等)を閲覧するための閲覧用画面の表示を制御する。
【0064】
依頼部412は、ユーザの実行指示がなされた場合や、所定の条件(例えば、所定の周期の到来)が満たされた場合に、通常のサービスや、連続サービスや、追加サービスを実行するためのリクエストを生成する。そして、依頼部412は、生成したリクエストを管理サーバ30に対して送信する。このリクエストには、実行するサービスのサービスID及びAPIID、並びに、クライアント端末40のユーザに対応するクライアント識別コード(以下、これらを「識別情報群」と称する。)が含まれる。
【0065】
また、リクエストには、さらに、リクエストパラメータが含まれる。リクエストパラメータとは、APIによる連携を利用したサービスの提供を受ける場合に、そのAPIに対応するサービス提供サーバ50に対して実際に送信すべきパラメータである。例えば、データベースサーバ20の連続サービスデータベース221の説明の際に例示したように、パラメータメタデータが、ユーザ情報を提供するAPIである場合には、リクエストパラメータは、「userId:Xxxxxx-Yyyyyy」というように、実際の値に対応するパラメータを当てはめたものとなる。なお、この「Xxxxxx-Yyyyyy」は、ユーザの名字及び名前をアルファベット表記したものであるとする。
【0066】
クライアント側処理部413は、サービスの提供を受けるためのクライアント側のソフトウェア(例えば、サービスに対応するクライアント側のプログラム)を、提供されるサービスそれぞれに対応して動作させる。このクライアント側処理部413によるクライアント側のソフトウェアの動作により、UI制御部411が作成する各種画面への表示や、依頼部412によるリクエストの生成が実現される。クライアント側処理部413が動作させる、クライアント側のソフトウェアは、クライアント側ソフトウェア記憶部421に記憶されている。すなわち、クライアント側ソフトウェア記憶部421は、クライアント側のソフトウェアを記憶するする記憶部(リポジトリ)として機能する。
【0067】
[サービス提供サーバ50の構成]
図10は、サービス提供サーバ50の機能的構成を示すブロック図である。
図10に示すように、サービス提供サーバ50のCPU811においては、依頼応答送受信部511と、サーバ側処理部512と、が機能する。また、サービス提供サーバ50の記憶部817においては、サーバ側ソフトウェア記憶部521が形成される。
以下で特に言及しない場合も含め、これら機能ブロック間では、処理を実現するために必要なデータを、適切なタイミングで適宜送受信する。
【0068】
依頼応答送受信部511は、リクエスト及びレスポンスを送受信する。具体的に、依頼応答送受信部511は、管理サーバ30からのリクエストを受信する。また、依頼応答送受信部511は、このリクエストに対応してサーバ側処理部512において作成されたレスポンスを、管理サーバ30に返却する。
【0069】
サーバ側処理部512は、サービスの提供を提供するためのサーバ側のソフトウェア(例えば、サービスに対応するサーバ側のプログラム)を、提供するサービスそれぞれに対応して動作させる。このサーバ側処理部512によるサーバ側のソフトウェアの動作により、レスポンスが生成される。そして、サーバ側処理部512は、生成したレスポンスを、依頼応答送受信部511を介して管理サーバ30に対して送信(すなわち、返却)する。サーバ側のソフトウェアは、サーバ側ソフトウェア記憶部521に記憶されている。すなわち、サーバ側ソフトウェア記憶部521は、サーバ側のソフトウェアを記憶する記憶部(リポジトリ)として機能する。
【0070】
[動作]
次に、情報処理システムSの動作を説明する。
[データベース設定処理]
図11は、運用者端末10が実行するデータベース設定処理の流れを示すフローチャートである。
データベース設定処理は、運用者端末10の起動と共に開始され、繰り返し実行される。
【0071】
データベース設定処理が開始されると、ステップS11において、UI制御部111は、ユーザインターフェース(ここでは、グラフィカルユーザインターフェース)を表示する。
【0072】
ステップS12において、フロー変換部112は、グラフィカルユーザインターフェースを参照した運用者の、通常のサービスまたは連続サービスの設定操作を受け付けたか否かを判定する。設定操作を受け付けた場合は、ステップS12においてYesと判定され、処理はステップS13に進む。一方で、設定操作を受け付けていない場合は、ステップS13においてNoと判定され、処理はステップS15に進む。
【0073】
ステップS13において、フロー変換部112は、グラフィカルユーザインターフェースを参照した運用者の、通常のサービスや、連続サービスの選択結果を、コンピュータが実行可能なデータ形式に変換する。
【0074】
ステップS14において、設定指示部113は、フロー変換部112が変換後のデータを、データベースサーバ20の追加サービスデータベース222に記憶させるために、変換後のデータと設定指示とを、データベースサーバ20に対して送信する。
【0075】
ステップS15において、フロー変換部112は、グラフィカルユーザインターフェースを参照した運用者の、追加サービスの設定操作を受け付けたか否かを判定する。設定操作を受け付けた場合は、ステップS15においてYesと判定され、処理はステップS16に進む。一方で、設定操作を受け付けていない場合は、ステップS15においてNoと判定され、本処理は終了する。そして、ステップS11から処理は繰り返される。
【0076】
ステップS16において、フロー変換部112は、グラフィカルユーザインターフェースを参照した運用者の、追加サービスの選択結果を、コンピュータが実行可能なデータ形式に変換する。
【0077】
ステップS17において、設定指示部113は、フロー変換部112が変換後のデータを、データベースサーバ20の追加サービスデータベース222に記憶させるために、変換後のデータと設定指示とを、データベースサーバ20に対して送信する。これにより、本処理は終了する。そして、ステップS11から処理は繰り返される。
【0078】
[設定記憶処理処理]
図12は、データベースサーバ20が実行する設定記憶処理の流れを示すフローチャートである。
設定記憶処理は、データベースサーバ20の起動と共に開始され、繰り返し実行される。
【0079】
設定記憶処理が開始されると、ステップS21において、データベース管理部211は、連続サービスデータベース221についての設定指示を、運用者端末10から受信したか否かを判定する。設定指示を受信した場合は、ステップS21においてYesと判定され、処理はステップS22に進む。一方で、場合は、ステップS21においてNoと判定され、処理はステップS23に進む。
【0080】
ステップS22において、データベース管理部211は、運用者端末10の設定指示部113から送信されてきた設定指示に基づいて、通常のサービスや、連続サービスの設定に対応する変換後のデータを連続サービスデータベース221に構築されている連続データベースに格納することにより、連続データベースを更新する。
【0081】
ステップS23において、データベース管理部211は、追加サービスデータベース222についての設定指示を、運用者端末10から受信したか否かを判定する。設定指示を受信した場合は、ステップS23においてYesと判定され、処理はステップS24に進む。一方で、場合は、ステップS21においてNoと判定され、処理はステップS25に進む。
【0082】
ステップS24において、データベース管理部211は、運用者端末10の設定指示部113から送信されてきた設定指示に基づいて、追加サービスの設定に対応する変換後のデータを追加サービスデータベース222に構築されている追加データベースに格納することにより、追加データベースを更新する。
【0083】
ステップS25において、データベース管理部211は、管理サーバ30から検索要求を受信したか否かを判定する。検索要求を受信した場合は、ステップS25においてYesと判定され、処理はステップS26に進む。一方で、検索要求を受信していない場合は、ステップS25においてNoと判定され、本処理は終了する。そして、ステップS21から処理は繰り返される。
【0084】
ステップS26において、データベース管理部211は、検索要求に基づいて、連続サービスデータベース221や追加サービスデータベース222を検索して情報を抽出する。
【0085】
ステップS27において、データベース管理部211は、抽出した情報を管理サーバ30に対して送信(すなわち、返却)する。これにより、本処理は終了する。そして、ステップS11から処理は繰り返される。
【0086】
[サービス特定処理]
図13は、管理サーバ30が実行するサービス特定処理の流れを示すフローチャートである。
サービス特定処理は、管理サーバ30が、クライアント端末40からのリクエストを受信した場合に実行される。
【0087】
サービス特定処理が開始されると、ステップS31において、サービス特定部312は、受信したリクエストから識別情報群(すなわち、実行するサービスのサービスID及びAPIID、並びに、クライアント端末40のユーザに対応するクライアント識別コード)を抽出する。これが本処理の引数である。
【0088】
ステップS32において、サービス特定部312は、識別情報群を検索条件とした検索要求を、データベースサーバ20に対して送信することにより、連続サービスデータベース221に構築されている連続サービスデータベースを検索する。
【0089】
ステップS33において、サービス特定部312は、連続サービスデータベースに、検索条件に対応する検索結果が存在していたか否かを判定する。検索結果が存在していた場合は、ステップS33においてYesと判定され、処理はステップS34に進む。一方で、検索結果が存在していない場合は、ステップS33においてNoと判定され、処理はステップS35に進む。
【0090】
ステップS34において、サービス特定部312は、連続サービスデータベースの検索結果(すなわち、検索条件に基づいて抽出された情報)を、本処理の返却値に設定し、処理データ記憶部321に一時的に記憶させる。これにより、本処理は終了する。
【0091】
ステップS35において、サービス特定部312は、エラー処理を行う。エラー処理としては、例えば、クライアント端末40に対し、実行不可能なサービスがリクエストされたことを示すメッセージ等のエラーメッセージを送信する。これにより、本処理は終了する。
【0092】
[連続サービス制御処理]
図14は、管理サーバ30が実行する連続サービス制御処理の流れを示すフローチャートである。
連続サービス制御処理は、上述したサービス特定処理が正常に終了した場合に、続けて実行される。
【0093】
サービス特定処理が開始されると、ステップS41において、連続サービス制御部313は、サービス特定処理の返却値である連続サービスデータベースの検索結果から、連続サービスフローを抽出する。この連続サービスデータベースの検索結果と、クライアント端末40から受信したリクエストに含まれているリクエストパラメータが本処理の引数である。
【0094】
ステップS42において、連続サービス制御部313は、連続サービスフローが存在したか(すなわち、実行するサービスが連続サービスであるか)否かを判定する。連続サービスフローが存在した場合は、ステップS42においてYesと判定され、処理はステップS46に進む。一方で、連続サービスフローが存在しない場合は、ステップS42においてNoと判定され、処理はステップS43に進む。
【0095】
ステップS43において、連続サービス制御部313は、連続サービスデータベースの検索結果から、URLとパラメータメタデータ抽出する。
【0096】
ステップS44において、連続サービス制御部313は、URLとパラメータメタデータに基づいて、リクエストを生成する。具体的に、連続サービス制御部313は、パラメータメタデータに対応する情報を、引数であるリクエストパラメータから抽出し、URLに対応するサービス提供サーバ50に対するリクエストを生成する。
【0097】
ステップS45において、連続サービス制御部313は、生成したリクエストを、URLに対応するサービス提供サーバ50に対して送信する。これにより、通常サービスのリクエストが行われたこととなる。
【0098】
ステップS46において、連続サービス制御部313は、連続サービスフローを処理対象として、後述するフロー実行処理をフロー実行部314に実行させる。
【0099】
ステップS47において、連続サービス制御部313は、フロー実行部314が実行したフロー実行処理の結果を取得して、これをレスポンスとする。
【0100】
ステップS48において、連続サービス制御部313は、レスポンス(ステップS45のリクエストに応じてサービス提供サーバ50から返却されたレスポンス、または、ステップS47において取得したフロー実行処理の結果に基づくレスポンス)を本処理の返却値に設定し、処理データ記憶部321に一時的に記憶させる。これにより、本処理は終了する。
【0101】
[フロー実行処理]
図15は、管理サーバ30が実行するフロー実行処理の流れを示すフローチャートである。
フロー実行処理は、上述したサービス特定処理や、後述の追加サービス制御処理におけるサブルーチンとして実行される。
【0102】
フロー実行処理が開始されると、ステップS51において、フロー実行部314は、実行対象の連続サービスフローまたは実行対象の追加サービスフローの開始ブロックのデータを処理対象として特定する。この実行対象の連続サービスフローまたは実行対象の追加サービスフローが、本処理の引数である。
【0103】
ステップS52において、フロー実行部314は、処理対象のブロックに対応する処理を開始する。
【0104】
ステップS53において、フロー実行部314は、受け取ったブロックのタイプを判定する。ブロックのタイプとしては、例えば、「開始ブロック」、「サービスブロック」、「分岐ブロック」、「ソースコードブロック」、「終了ブロック」が定義されている。
【0105】
ステップS53において受け取ったブロックが開始ブロックである場合、処理はステップS54に進む。
ステップS53において受け取ったブロックがサービスブロックである場合、処理はステップS58に進む。
ステップS53において受け取ったブロックが分岐ブロックである場合、処理はステップS63に進む。
ステップS53において受け取ったブロックがソースコードブロックである場合、処理はステップS68に進む。
ステップS53において受け取ったブロックが終了ブロックである場合、処理はステップS69に進む。
【0106】
ステップS54において、フロー実行部314は、クライアント端末40から受信したリクエストに関するリクエストプロパティの変数を定義する。
【0107】
ステップS55において、フロー実行部314は、リクエストプロパティのバリデーション(検証)を実行する。
【0108】
ステップS56において、フロー実行部314は、バリデーションに問題があるか否かの判定を行う。バリデーションに問題がある場合、ステップS56においてYesと判定されて、処理はステップS57に進む。一方、バリデーションに問題がない場合、ステップS56においてNoと判定されて、処理はステップS66に進む。
【0109】
ステップS57において、フロー実行部314は、エラー処理を行う。エラー処理として、例えば、クライアント端末40に対し、実行不可能なサービスがリクエストされたことを示すメッセージ等のエラーメッセージを送信することができる。これにより、本処理は終了する。
【0110】
ステップS58において、フロー実行部314は、受け取ったブロックのデータに基づいて、実行対象の連続サービスまたは実行対象の追加サービスを特定すると共に、この連続サービスまたは追加サービスのURLとパラメータメタデータ抽出する。
【0111】
ステップS59において、フロー実行部314は、URLとパラメータメタデータに基づいて、リクエストを生成する。具体的に、フロー実行部314は、パラメータメタデータに対応する情報を、引数であるリクエストパラメータから抽出し、URLに対応するサービス提供サーバ50に対するリクエストを生成する。
【0112】
ステップS60において、フロー実行部314は、生成したリクエストを、URLに対応するサービス提供サーバ50に対して送信する。これにより、連続サービスまたは追加サービスのリクエストが行われたこととなる。なお、ステップS59~ステップS60の処理は、上述した連続サービス制御処理におけるステップS43~ステップS45と同等の処理であるので、フロー実行部314が行うのではなく、連続サービス制御部313を呼び出して連続サービス制御部313が行うようにしてもよい。
【0113】
ステップS61において、フロー実行部314は、リクエストに応じてサービス提供サーバ50から返却されたレスポンスを変数に定義する。
ステップS62において、フロー実行部314は、レスポンスに応じて次に実行するブロックを決定する。ステップS62の後、フロー実行部314は、ステップS66に進む。
【0114】
ステップS63において、フロー実行部314は、分岐ブロックから分岐の条件を取得する。
ステップS64において、フロー実行部314は、現在のステータスが取得した分岐の条件に適合するか否かの判定を行う。
現在のステータスが取得した分岐の条件に適合しない場合、ステップS64においてNoと判定されて、処理はステップS63に進む。
一方、現在のステータスが取得した分岐の条件に適合する場合、ステップS64においてYesと判定されて、処理はステップS65に進む。
【0115】
ステップS65において、フロー実行部314は、適合した条件に応じて次に実行するブロックを決定する。
ステップS66において、フロー実行部314は、次に実行するブロックを処理対処として特定する。ステップS66の後、処理はステップS52に進む。
【0116】
ステップS67において、フロー実行部314は、ブロックに定義されているソースコードを実行する。ステップS67の後、処理はステップS66に進む。
ステップS68において、フロー実行部314は、リクエストに関するレスポンスプロパティの変数を定義する。
【0117】
ステップS69において、フロー実行部314は、レスポンスのステータスコード(ここでは、HTTPレスポンスステータスコード)を定義する。
【0118】
ステップS70において、フロー実行部314は、本フロー実行処理の実行結果であるレスポンスを、本フロー実行処理の呼び出し元(すなわち、連続サービス制御部313又は追加サービス制御部315)に返却する。そして、このレスポンスは、返却された連続サービス制御部313又は追加サービス制御部315により、レスポンスに対応する送信先に対して送信される。これにより、本処理は終了する。
【0119】
[追加サービス制御処理]
図16は、管理サーバ30が実行する追加サービス制御処理の流れを示すフローチャートである。
追加サービス制御処理は、上述した連続サービス制御処理が終了した場合に、続けて実行される。
【0120】
追加サービス制御処理が開始されると、ステップS81において、追加サービス制御部315は、サービス特定処理の返却値である連続サービスデータベースの検索結果から、識別情報群(すなわち、実行するサービスのサービスID及びAPIID、並びに、クライアント端末40のユーザに対応するクライアント識別コード)を抽出する。この識別情報群と、連続サービス制御処理の返却値であるレスポンスが本処理の引数である。
【0121】
ステップS82において、追加サービス制御部315は、識別情報群を検索条件とした検索要求を、データベースサーバ20に対して送信することにより、追加サービスデータベース222に構築されている追加サービスデータベースを検索する。
【0122】
ステップS83において、追加サービス制御部315は、追加サービスデータベースに、検索条件に対応する検索結果が存在していたか否かを判定する。検索結果が存在していた場合は、ステップS83においてYesと判定され、処理はステップS84に進む。一方で、検索結果が存在していない場合は、ステップS83においてNoと判定され、処理はステップS86に進む。
【0123】
ステップS84において、追加サービス制御部315は、追加サービスデータベースの検索結果(すなわち、検索条件に基づいて抽出された情報)から、追加サービスフローを抽出する。
【0124】
ステップS85において、追加サービス制御部315は、追加サービスフローを処理対象として、上述したフロー実行処理をフロー実行部314に実行させる。
【0125】
ステップS86において、追加サービス制御部315は、引数であるレスポンスを、本処理の返却値に設定する。
【0126】
ステップS87において、追加サービス制御部315は、依頼応答送受信部311を介して返却値に設定したレスポンスを、リクエスト元のクライアント端末40に対して送信(すなわち、返却)する。これにより、本処理は終了する。
【0127】
[クライアント側処理]
図17は、クライアント端末40が実行するクライアント側処理の流れを示すフローチャートである。
クライアント側処理は、クライアント端末40の起動と共に開始され、繰り返し実行される。
【0128】
クライアント側処理が開始されると、ステップS91において、UI制御部411は、ユーザインターフェースを表示する。
【0129】
ステップS92において、依頼部412は、リクエストの送信条件が満たされたか否かを判定する。例えば、ユーザの実行指示がなされた場合や、所定の条件(例えば、所定の周期の到来)が満たされた場合に、リクエストの送信条件が満たされたと判定される。リクエストの送信条件が満たされた場合は、ステップS92においてYesと判定され、処理はステップS93に進む。一方で、リクエストの送信条件が満たされていない場合は、ステップS92においてNoと判定され、処理はステップS94に進む。
【0130】
ステップS94において、依頼部412は、リクエストを生成する。このリクエストには、上述したように、識別情報群(すなわち、実行するサービスのサービスID及びAPIID、並びに、クライアント端末40のユーザに対応するクライアント識別コード)とリクエストパラメータが含まれる。
【0131】
ステップS95において、依頼部412は、生成したリクエストを管理サーバ30に対して送信する。
【0132】
ステップS96において、クライアント側処理部413は、管理サーバ30からリクエストを受信したか否かを判定する。リクエストを受信した場合は、ステップS95においてYesと判定され、処理はステップS96に進む。一方で、リクエストを受信していない場合は、ステップS95においてNoと判定され、本処理は終了する。そして、ステップS91から処理は繰り返される。
【0133】
ステップS96において、クライアント側処理部413は、レスポンスに対応する処理(例えば、取得した情報の表示)を実行する。これにより、本処理は終了する。そして、ステップS91から処理は繰り返される。
【0134】
[サーバ側処理]
図18は、サービス提供サーバ50が実行するサーバ側処理の流れを示すフローチャートである。
サーバ側処理は、サービス提供サーバ50の起動と共に開始され、繰り返し実行される。
サーバ側処理が開始されると、ステップS101において、依頼応答送受信部511は、リクエストを受信したか否かを判定する。リクエストを受信した場合は、ステップS101においてYesと判定され、処理はステップS102に進む。一方で、場合は、ステップS101においてNoと判定され、本処理は終了する。そして、ステップS101から処理は繰り返される。
ステップS102において、サーバ側処理部512は、リクエストに対応する処理を実行してレスポンスを生成する。
ステップS103において、サーバ側処理部512は、レスポンスを、依頼応答送受信部511を介して管理サーバ30に対して送信(すなわち、返却)する。
【0135】
以上説明した各処理によれば、管理サーバ30は、予め設定されている対応関係に基づくのみで、そのクライアント端末40を利用するクライアントにとって最適なサービスを提供することができる。この場合に、クライアント端末40は、通常通りリクエストを送信するだけでよい。また、サービス提供サーバ50も、通常通りリクエストに応じて、レスポンスを返却するだけでよい。そのため、連続サービスや追加サービスを提供する既存のソフトウェアの改変(例えば、ソースコードの編集)等の作業を行う必要や、新たにサービス提供サーバ50を構築する必要なく、複数のサービスを部品として組み合わせて提供することができる。

従って、以上説明した各処理によれば、情報処理に関する多様なサービスを、より簡便に提供する、という課題を解決することが可能となる。
【0136】
[画面表示例]
運用者端末10において、運用者が、通常のサービスや、連続サービスや、追加サービスに関する設定を行うための、設定用画面の表示例について、図19図21を参照して説明する。
これらの設定用画面例は、UI制御部111がサービス情報記憶部121に記憶されている情報等に基づいて表示の制御を行うことにより、運用者端末10の出力部816に含まれるディスプレイ上に表示される。具体的に、これらの設定画面例では、リクエストに、何れの通常のサービスや、何れの連続サービスや、何れの追加サービスが対応するのかを選択するためのグラフィカルユーザインターフェースが表示される。
【0137】
図19は、何れのサービスを連続サービスに設定するかを選択するための設定用画面例を示す模式図である。表示領域AR11に連続サービスを構成する部品を選択するアイコンが表示される。例えば、このアイコンからサービスを選択したり、ソースコードを選択したり、分岐や並行処理に関する設定を選択したりすることができる。表示領域AR11において選択されたサービス等は、連続サービスを構成する要素として、表示領域AR12に配置可能となる。運用者は、これら選択したサービス等をマウス等で移動させる操作を行うことにより、簡便に連続サービスに対応する連続サービスフローを作成することができる。この例であれば、トークンの検証、会員情報の検索、健康情報の取得、ソースコードに基づいた処理の実行、といった一連のサービスを実行する「会員健康情報取得」という連続サービスフローが作成されている。
【0138】
図20及び図21は、追加サービスに関する設定用画面例であって、追加サービスを実行する契機となるAPIを選択すると共に、何れのサービスを追加サービスとして設定するかを選択するための設定用画面例を示す模式図である。表示領域AR21には、様々なサービス等が一覧表示されている。また、表示領域AR22には、設定の進捗状況を示すバーが表示される。運用者は、まず追加サービスを実行する契機となる、通常のサービスまたは連続サービスを表示領域AR21における一覧表示から選択する。次に、運用者は、選択した通常のサービスまたは連続サービスを提供するためのAPIの何れかを表示領域AR21における一覧表示から選択する。
【0139】
すると、画面は、図21に示す設定用画面例に遷移する。この場合、表示領域AR11と同様にして、表示領域AR31には追加サービスを構成する部品を選択するアイコンが表示される。例えば、このアイコンからサービスを選択したり、ソースコードを選択したり、分岐や並行処理に関する設定を選択したりすることができる。また、これも表示領域AR12と同様にして、表示領域AR31において選択されたサービス等は、追加サービスを構成する要素として、表示領域AR32に配置可能となる。運用者は、これら選択したサービス等をマウス等で移動させる操作を行うことにより、簡便に追加サービスに対応する追加サービスフローを作成することができる。この例であれば、「ワークフローの申請があった場合に、メッセンジャーに通知する」という追加サービスフローが作成されている。
これにより、図21において選択した通常のサービスまたは連続サービスを提供するAPIが実行されたことを契機として、図22において作成した追加サービスフローが実行されることとなる。
【0140】
このようにして作成された連続サービスフローや追加サービスフローは、上述したようにフロー変換部112により変換された後にデータベースサーバ20に設定され、管理サーバ30において利用することが可能となる。
【0141】
以上説明したように、図示したようなグラフィカルユーザインターフェースを用いることにより、運用者は、マウス等での選択や移動等の簡便な操作を行うのみで、連続サービスや追加サービスに関する設定を容易に実現することができる。
【0142】
以上のように、本実施形態に係る管理サーバ30は、クライアント端末40からのリクエストに応じて、クライアント端末40にレスポンスを返却する管理サーバ30であって、連続サービス制御部313と、追加サービス制御部315と、を備える。
連続サービス制御部313は、リクエストに対応するサービスを実行し、該実行結果をレスポンスとしてクライアント端末40に返却する。
追加サービス制御部315は、連続サービス制御部313によるサービスの実行を契機として、リクエストに対応する追加サービスを実行し、該実行結果を追加サービスに対応する送信先に対して、レスポンスの返却とは関わりなく送信する。
【0143】
このように、管理サーバ30は、リクエスト毎に異なるサービスを実行する。また、管理サーバ30は、さらに、このサービスとは別途に、リクエスト毎に異なる追加サービスを実行する。すなわち、実行されるサービスや追加サービスは、そのクライアント端末40とそのリクエストの組み合わせに対応するものである。
そのため、管理サーバ30は、予め設定されている対応関係に基づくのみで、そのクライアント端末40のユーザにとって最適なサービスや追加サービスを実行することができる。この場合に、クライアント端末40は、通常通りリクエストを送信するだけでよい。また、サービス提供サーバ50も、通常通りリクエストに応じて、レスポンスを返却するだけでよい。そのため、サービスや追加サービスを提供する既存のソフトウェアの改変(例えば、ソースコードの編集)等の作業を行う必要や、新たにサービス提供サーバ50を構築する必要なく、複数のサービスを部品として組み合わせて提供することができる。
従って、管理サーバ30によれば、情報処理に関する多様なサービスを、より簡便に提供する、という課題を解決することが可能となる。
【0144】
連続サービス制御部313は、リクエストに対応している複数のサービスを連続した一連のサービスとして実行すると共に、該一連のサービスに対応して定義されたレスポンスをクライアント端末40に返却する。
これにより、管理サーバ30は、管理サーバ30は、予め設定されている対応関係に基づくのみで、そのクライアント端末40のユーザにとって最適な複数のサービスを一連の連続サービスとして実行することができる。
【0145】
追加サービス制御部315は、連続した一連のサービスとして実行される複数のサービスの内の、所定のサービスの実行を契機として、リクエストに対応する追加サービスを実行し、該実行結果をレスポンスとは関わりなく出力する。
これにより、サービスの進捗状況に合わせて、適切なタイミングで追加サービスを実行することができる。
【0146】
追加サービス制御部315は、連続サービス制御部313によるサービスの実行を契機として、リクエストに対応する所定の条件が満たされか否かを判定し、所定の条件が満たされないと判定した場合には、追加サービスを実行しない。
これにより、必要な場合にのみサービスと共に追加サービスを実行し、不必要な場合にはサービスのみを実行することができる。
【0147】
サービス及び追加サービスは、管理サーバ30にアプリケーションプログラムインターフェースを介して接続された外部サーバに依頼することにより実行するサービスを含む。
これにより、APIを介して連携可能な外部サーバ(例えば、管理サーバ30の運用者が管理する外部サーバ、あるいはこの運用者とは異なる事業者が管理する外部サーバ)が提供するサービスを、管理サーバ30のサービスや追加サービスに組み込むことができる。
【0148】
以上のように、本実施形態に係る情報処理システムSは、クライアント端末40からのリクエストに応じて、クライアント端末40にレスポンスを返却する情報処理システムSであって、UI制御部111と、フロー変換部112と、設定指示部113と、連続サービス制御部313と、追加サービス制御部315と、を備える。
UI制御部111は、リクエストに、何れのサービスと何れの追加サービスとが対応するのかを選択するためのグラフィカルユーザインターフェースを表示する。
フロー変換部112及び設定指示部113は、グラフィカルユーザインターフェースを参照したユーザの選択結果を、コンピュータが実行可能なデータ形式に変換して設定する。
連続サービス制御部313は、フロー変換部112及び設定指示部113の設定に基づいて、リクエストに対応するサービスを実行し、該実行結果をレスポンスとしてクライアント端末40に返却する。
追加サービス制御部315は、フロー変換部112及び設定指示部113の設定に基づいて、連続サービス制御部313によるサービスの実行を契機として、リクエストに対応する追加サービスを実行し、該実行結果を追加サービスに対応する送信先に対して、レスポンスの返却とは関わりなく送信する。
これにより、情報処理システムSは、ユーザに、グラフィカルユーザインターフェースを用いた簡便な操作を行わせるのみで、リクエストと、サービス及び追加サービスとの対応付けを実現することができる。加えて、情報処理システムSは、管理サーバ30と同様の処理を行うこともできる。
従って、情報処理システムSによれば、情報処理に関する多様なサービスを、より一層簡便に提供することが可能となる。
【0149】
フロー変換部112及び設定指示部113は、サービスを提供するソフトウェア及び追加サービスを提供するソフトウェアの改変を行うことなく設定を行う。
これにより、対応関係を設定するために、サービスを提供するソフトウェア及び追加サービスを提供するソフトウェアの改変(例えば、ソースコードの編集)等の作業を行う必要はない。
【0150】
なお、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。
例えば、上述の実施形態における情報処理システムSのシステム構成は一例であり、情報処理システムSの機能が全体として実現されていれば、別体として実現した複数のサーバを1つのサーバとして実現したり、より多くのサーバに機能を分散して実装したりすることが可能である。
また、上述の実施形態におけるサービスとして、APIによる連携を利用したマイクロサービスを主として想定することができるが、その他、これらに類するサービスを含めることも可能である。
【0151】
上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
換言すると、上述の実施形態における機能的構成は例示に過ぎず、特に限定されない。すなわち、上述した一連の処理を全体として実行できる機能が情報処理システムSを構成するいずれかのコンピュータに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に示した例に限定されない。
また、1つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。
【0152】
また、上述した一連の処理を実行するためのプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布されるリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。
【0153】
以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。
【符号の説明】
【0154】
10 運用者端末、20 データベースサーバ、30 管理サーバ、40 クライアント端末、50 サービス提供サーバ、800 情報処理装置、811 CPU、812 ROM、813 RAM、814 バス、815 入力部、816 出力部、817 記憶部、818 通信部、819 ドライブ、820 撮像部、831 リムーバブルメディア、111,411 UI(ユーザインターフェース)制御部、112 フロー変換部、113 設定指示部、121 サービス情報記憶部、211 データベース管理部、221 連続サービスデータベース、222 追加サービスデータベース、311、511 依頼応答送受信部、312 サービス特定部、313 連続サービス制御部、314 フロー実行部、315 追加サービス制御部、321 処理データ記憶部、412 依頼部、413 クライアント側処理部、421 クライアント側ソフトウェア記憶部、512 サーバ側処理部、521 サーバ側ソフトウェア記憶部、S 情報処理システム
【要約】
【課題】情報処理に関する多様なサービスを、より簡便に提供すること。
【解決手段】管理サーバ30は、クライアント端末40からのリクエストに応じて、クライアント端末40にレスポンスを返却する管理サーバ30であって、連続サービス制御部313と、追加サービス制御部315と、を備える。連続サービス制御部313は、リクエストに対応するサービスを実行し、該実行結果をレスポンスとしてクライアント端末40に返却する。追加サービス制御部315は、連続サービス制御部313によるサービスの実行を契機として、リクエストに対応する追加サービスを実行し、該実行結果を追加サービスに対応する送信先に対して、レスポンスの返却とは関わりなく送信する。
【選択図】図8
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21