情報処理装置
【課題】ユーザの介在が必要なWebサイトのWebAPI化を容易に行なう。
【解決手段】駅名入力画面で所望の乗車駅名と下車駅名が入力されると、旅費精算アプリは、乗車駅から下車駅までの経路探索をスクレイピングサーバ1に要求する。スクレイピングサーバ1のWebAPI提供処理部13は、乗車駅および下車駅の候補が示される駅名選択HTMLページデータを経路探索Webサイトから取得して、Webブラウザにより駅名選択画面を表示させる。駅名選択画面から意図する駅名が選択されると、UI提供処理部14は、乗車駅から下車駅までの経路が示される経路一覧HTMLページを経路探索Webサイトから取得してWebブラウザにより表示させる。また、スクレイピング実行部16は、経路一覧HTMLページをもとに、XML形式の経路一覧XMLデータを生成して、旅費精算アプリに返す。
【解決手段】駅名入力画面で所望の乗車駅名と下車駅名が入力されると、旅費精算アプリは、乗車駅から下車駅までの経路探索をスクレイピングサーバ1に要求する。スクレイピングサーバ1のWebAPI提供処理部13は、乗車駅および下車駅の候補が示される駅名選択HTMLページデータを経路探索Webサイトから取得して、Webブラウザにより駅名選択画面を表示させる。駅名選択画面から意図する駅名が選択されると、UI提供処理部14は、乗車駅から下車駅までの経路が示される経路一覧HTMLページを経路探索Webサイトから取得してWebブラウザにより表示させる。また、スクレイピング実行部16は、経路一覧HTMLページをもとに、XML形式の経路一覧XMLデータを生成して、旅費精算アプリに返す。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ユーザ端末装置からのリクエストにしたがってWebアプリケーションのサービスを提供する情報処理装置に関する。
【背景技術】
【0002】
従来、Webサイトの機能をシステム向けにAPI(アプリケーションプログラミングインタフェース:Application Programming Interface)として提供する技術(以下、WebAPIと称する)や、複数のWebサイトの機能やWebAPIを組み合わせて新たなサービスを提供する技術(マッシュアップなどと呼ばれる)が成熟してきた。
【0003】
前述した、Webサイトの機能を提供する技術としては、例えば特許文献1に開示されるように、複数のWebアプリケーションを実行する場合に、汎用Webブラウザを用いて、前段の処理結果を後段のWebアプリケーションに引き継ぐものがある。
【0004】
また、Webサイトの機能を提供する他の技術としては、例えば、Webサイト提供者自らシステム向けにAPIを提供する技術が挙げられ、また、Webサイト画面からデータを抜き出してシステム向けのAPI化を行なうスクレイピング(scraping)ライブラリや環境が挙げられ、また、システム向けAPIを組み合わせて新たなサービスを構築するマッシュアップ環境が挙げられる。
【0005】
ところで、Webサイトが提供するサービスには、利用時にユーザの介在を必要とするものもある。例として、WebAPIが、オンライン書店での検索を行なってユーザの好む本の情報を取得する事や、経路探索用のWebサイトがユーザからの選択にしたがって適切な乗車駅/下車駅を特定して経路を探索する事が挙げられる。
【0006】
このように、WebサイトをスクレイピングしてWebAPI化を行なう際には、WebAPIの実行時にユーザが介在する仕組みを考慮する必要がある。以下、この仕組みについて経路探索Webサイトを例として説明を行なう。
【0007】
図10は、従来の経路探索Webサイトの画面表示例を示す図である。
図10に示した経路探索Webサイトでは、駅名入力画面にてユーザがユーザ端末装置を用いて乗車駅名と下車駅名を入力して画面上の検索ボタンを押すと、経路一覧画面にて乗車駅から下車駅までの乗り換え経路が提示される。
【0008】
ただし駅名入力画面で入力した駅名に曖昧性があると、この駅名入力画面が駅名選択画面に遷移し、ユーザが意図する駅名を選択するよう促す。
【0009】
図10に示した例では、駅名入力画面で入力された「府中」という駅名に対して「府中(東京)」、「府中(広島)」、「府中(徳島)」などが駅名選択画面に表示される。ユーザはこの駅名一覧から意図する駅を選択することで、適切な経路を経路一覧画面で得ることになる。
このような、ユーザの介在を必要とするWebサイトをWebAPI化するためには、従来では以下に示す2つの手法が挙げられる。
第1の手法は細分化である。この細分化とは、ユーザの介在を必要としない細かい単位の複数個のWebAPIを用意し、それらをマッシュアップする側であるユーザ側のアプリケーションで組合せて使う事である。
【0010】
第2の手法は自動化である。この自動化とは、ユーザの介在が不要となる様に、ユーザが従来介在していた部分の処理の実行を自動化する事である。
【0011】
図11は、従来のWebAPIの利用形態の第1の例を示す図である。
図11に示した手法は、前述した細分化の手法(第1の手法)であり、WebAPIとして、駅名一覧取得APIおよび経路探索APIを用いる。
【0012】
駅名一覧取得APIは、ユーザ端末装置側のアプリケーションプログラム(以下、アプリケーションと称する)である旅費精算アプリケーション(以下、旅費精算アプリと称する)を介した文字列を入力として、その文字列にマッチする駅名一覧を経路探索Webサイトから駅名候補として取得して旅費精算アプリに返す。
【0013】
また、経路探索APIは、前述した駅名一覧から旅費精算アプリを介して選択された乗車駅名と下車駅名、つまり乗車駅と下車駅をそれぞれ一意に特定できる情報を入力として、これらの乗車駅から下車駅までの乗り換え経路を経路探索Webサイトから取得して旅費精算アプリに返す。
【0014】
図12は、従来のWebAPIの利用形態の第2の例を示す図である。
図12に示した手法は、前述した自動化の手法(第2の手法)であり、WebAPIとして経路探索APIを用いる。
【0015】
この経路探索WebAPIは、ユーザ端末装置側の旅費精算アプリを介して入力された乗車駅と下車駅のそれぞれの文字列にマッチした駅名一覧を経路探索Webサイトから取得する。そして、経路探索WebAPIは、この駅名一覧からユーザが意図する駅を推測することで自動的に選択し、この選択した乗車駅から下車駅までの乗り換え経路を経路探索Webサイトから取得して旅費精算アプリに返す。
【先行技術文献】
【特許文献】
【0016】
【特許文献1】特開2006−178887号公報
【発明の概要】
【発明が解決しようとする課題】
【0017】
前述したように、ユーザの介在を必要とするWebサイトをWebAPI化するための細分化の方法では、WebAPIは、機能が細切れのサブルーチンWebAPI群に分かれて提供されるため、システムでの利用方法が複雑になる。
【0018】
図11に示した例では、経路探索のためのAPIの他に、駅名一覧取得のためのAPIという本質的ではないAPIが別途必要となってしまう。
また、この細分化の手法では、ユーザが介在するためのユーザインタフェース(以下、UIと称する)をマッシュアップアプリ側のUIとして別途開発しなければならない。図11に示した例では、駅名一覧から駅を一つ選択するためのUIが別途必要になる。
【0019】
また、前述した自動化の手法では、ユーザの介在を要していた処理を自動化するためのロジックがサーバ側に必要となる。図11に示した例では、ユーザの介在部分、つまり駅名一覧におけるユーザが意図する駅名はユーザの現在位置や嗜好など様々な要因に関係しているので、駅名一覧からユーザの意図する駅をサーバ側で適切に推測することは容易ではない。
【0020】
また、サーバ側でユーザの意図する駅名の推測を誤るとユーザの意図に沿えなくなる可能性がある。例えば、「駅名一覧の中から一番上の駅を選択する」というような単純な規則では、必ずしもユーザの意図にそぐわない可能性がある。
【0021】
以上説明したように、従来技術における、ユーザの介在を必要とするWebサイトをWebAPI化するため技術では、WebAPIの複雑化に伴って、これを用いるためのシステムが複雑になったり、ユーザの意図に沿えない処理を行なったりしてしまうといった課題がある。
【0022】
そこで、本発明の目的は、ユーザの介在が必要なWebサイトのWebAPI化を容易に行なうことが可能になる情報処理装置を提供することにある。
【課題を解決するための手段】
【0023】
すなわち、本発明に係わる情報処理装置は、ユーザ側の端末装置で実行されるユーザ側アプリケーションからのリクエストがなされた場合に、Webサーバにより構築されるWebサイトへのアクセスを行なうことで、前記リクエストを受けて、データ加工手段による処理結果を返却値データとして前記ユーザ側アプリケーションに出力するアプリケーションプログラミングインタフェース手段と、前記ユーザ側アプリケーションからのリクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Webサイトから取得した中間値データを保持するデータ保持手段と、前記中間値データを前記ユーザ側アプリケーションを介さずに前記端末装置に表示する表示手段と、前記表示手段による表示結果に対する入力を受け付ける入力手段と、前記入力手段による入力結果にしたがって、前記データ保持手段により保持される前記中間値データをもとに前記Webサイトへのアクセスを行なうことで、当該Webサイトへのさらなるアクセスを要しないデータを取得するデータ取得手段とを備え、前記データ加工手段は、前記データ取得手段により取得したデータの形式を前記ユーザ側アプリケーションによる処理に適合する形式に加工することを特徴とする。
【発明の効果】
【0024】
本発明によれば、ユーザの介在が必要なWebサイトのWebAPI化を容易に行なうことができる。
【図面の簡単な説明】
【0025】
【図1】本発明の実施形態における情報処理システムの構成例を示す図。
【図2】本発明の実施形態における情報処理システムのスクレイピングサーバの構成例を示すブロック図。
【図3】本発明の実施形態における情報処理システムのユーザ端末装置の構成例を示すブロック図。
【図4】本発明の実施形態における情報処理システムのスクレイピングサーバの機能を示す図。
【図5】本発明の実施形態における情報処理システムのスクレイピングサーバのリクエスト管理テーブルの構成例を表形式で示す図。
【図6】本発明の実施形態における情報処理システムのスクレイピングサーバのスクレイピングルールテーブルの構成例を表形式で示す図。
【図7】本発明の実施形態における情報処理システムのWebサーバが提供する経路探索サイトの画面遷移例を示す図。
【図8】本発明の実施形態における情報処理システムによる処理動作の概要を示す図。
【図9】本発明の実施形態における情報処理システムによる処理動作の一例を示すシーケンス図。
【図10】従来の経路探索Webサイトの画面表示例を示す図。
【図11】従来のWebAPIの利用形態の第1の例を示す図。
【図12】従来のWebAPIの利用形態の第2の例を示す図。
【発明を実施するための形態】
【0026】
以下図面により本発明の実施形態について説明する。
図1は、本発明の実施形態における情報処理システムの構成例を示す図である。
図1に示すように、本発明の実施形態における情報処理システムは、スクレイピングサーバ1、Webサーバ2およびユーザ端末装置3を有する。
【0027】
スクレイピングサーバ1およびWebサーバ2はネットワークを介して接続される。Webサーバ2およびユーザ端末装置3は図1に示したようなローカル接続もしくはネットワーク経由で接続される。
【0028】
スクレイピングサーバ1は、ユーザの介在を必要とするWebAPIを提供し、さらに当該WebAPIの実行にユーザが介在するためのUIを提供する。
Webサーバ2は、ユーザからのリクエストに応じたWebアプリケーションのサービス提供のためのWebサイトが構築されるサーバである。
また、ユーザ端末装置3は、例えばパーソナルコンピュータであり、Webアプリケーションのサービスを利用するためのアプリケーションを格納し、これを実行する。図1ではユーザ端末装置3は1台のみ図示しているが、この台数は限定されない。
【0029】
スクレイピングサーバ1は、ユーザ端末装置3側のアプリケーションからの一回のWebAPIの呼び出しを起点とし、この呼び出しに続けてバックエンドで発生する、Webサーバ2側のWebサイトへの複数回のアクセスを管理し、これら一連のWebサイトアクセスの最終結果から必要なデータを抜き出した値をWebAPIの返却値データとしてアプリケーションに返す。
【0030】
その際、スクレイピングサーバ1は、一連のWebサイトアクセスにユーザが直接介在できるように、WebサイトのUIを元にユーザ向けUIをユーザ端末装置3側に提供する。これにより、ユーザ端末装置3側のアプリケーションからの一回のWebAPI呼出/応答と、WebサイトのUIを用いたユーザの介在とを非同期に連携して実行する。
【0031】
図2は、本発明の実施形態における情報処理システムのスクレイピングサーバの構成例を示すブロック図である。
図2に示すように、スクレイピングサーバ1は、装置全体の処理動作を司る制御部11、記憶装置12、WebAPI提供処理部13、UI提供処理部14、リクエスト管理部15、スクレイピング実行部16および通信インタフェース17を備え、それぞれがバス18を介して接続される。
【0032】
記憶装置12は、ハードディスクドライブや不揮発性メモリなどの記憶媒体であり、WebAPI提供処理部13、UI提供処理部14、リクエスト管理部15、スクレイピング実行部16による処理動作のためのプログラムを記憶する他、リクエスト管理テーブル格納部21およびスクレイピングルールテーブル格納部22を有する。
【0033】
WebAPI提供処理部13は、ユーザ端末装置3側のアプリケーションからのWebAPIへのリクエストを受け付けるシステム向けインタフェース(アプリケーションプログラミングインタフェース手段)として機能する。例えば、WebAPI提供処理部13は、URL形式のリクエストをHTTPプロトコルで受け付け、XML形式の返却値データをリクエスト元に返す。ただし、リクエストの入出力はURL形式やXML形式に限定されない。
【0034】
UI提供処理部14は、WebAPIの実行にユーザが介在するためのUIとして機能する(データ加工手段の一例)。例えば、UI提供処理部14は、ユーザ端末装置3側のWebブラウザ上にHTMLページを表示する事でユーザに情報を提示したり、ユーザ端末装置3により入力された情報を得たりする。ただし、UIの実現形態はWebブラウザに限定されない。
【0035】
リクエスト管理部15は、ユーザ端末装置3側のアプリケーションからのWebAPIへのリクエストによって開始されたWebサイトアクセスの状態をリクエストごとに区分して管理する。リクエスト管理部15を介して、アプリケーションからの一回のWebAPI呼び出しを起点として、その後、ユーザによる複数回のWebサイトアクセスが発生する場合がある。
【0036】
また、リクエスト管理部15は、ユーザの介在が必要なWebページであるHTMLページと、ユーザの介在によってWebサーバ2側のWebサイトから得られた最終的な返却値とを記憶装置12に保持する処理を行なう。
【0037】
スクレイピング実行部16は、Webサイトから返却されたWebページを所定のルールにしたがって加工する。このルールは後述するスクレイピングルールテーブルで定義される。
通信インタフェース17は、Webサーバ2やユーザ端末装置3との間の入出力を行なう。
【0038】
スクレイピングサーバ1は、ハードウェア構成、またはハードウェア構成とソフトウェア構成との組合せにより実現可能である。後者の場合、ソフトウェア構成は、予めコンピュータ読み取り可能な記憶媒体またはネットワークから得られたプログラムがコンピュータにインストールされることにより、スクレイピングサーバ1としての各機能が実現される。
【0039】
図3は、本発明の実施形態における情報処理システムのユーザ端末装置の構成例を示すブロック図である。
図3に示すように、ユーザ端末装置3は、装置全体の処理動作を司る制御部31、記憶装置32、キーボードやマウスなどの入力装置33、液晶ディスプレイなどの表示装置34および通信インタフェース35を備え、それぞれがバス36を介して接続される。
記憶装置32は、ハードディスクドライブや不揮発性メモリなどの記憶媒体であり、アプリケーションを格納するアプリケーション格納部41やWebブラウザを格納するWebブラウザ格納部42を有する。
【0040】
図4は、本発明の実施形態における情報処理システムのスクレイピングサーバの機能を示す図である。
図4に示すように、本実施形態では、ユーザ側への提供対象のサービスは経路探索であり、ユーザ端末装置3側のマッシュアップアプリとして旅費精算アプリを用い、Webサーバ2側のWebサイトとして経路探索Webサイトを用いる。また、ユーザ端末装置3では、WebAPI実行時にユーザが介在するためUIとして、マッシュアップアプリとは別個のWebブラウザを用いる。
【0041】
図5は、本発明の実施形態における情報処理システムのスクレイピングサーバのリクエスト管理テーブルの構成例を表形式で示す図である。
図6は、本発明の実施形態における情報処理システムのスクレイピングサーバのスクレイピングルールテーブルの構成例を表形式で示す図である。
図7は、本発明の実施形態における情報処理システムのWebサーバが提供する経路探索サイトの画面遷移例を示す図である。
スクレイピングサーバ1の記憶装置12のリクエスト管理テーブル格納部21には、図5に示した形式のリクエスト管理テーブルが格納される。このリクエスト管理テーブルは、ユーザ端末装置3側のアプリケーションからのWebAPIへのリクエストによって開始されたWebサイトアクセスの状態をリクエスト管理部15により管理するための情報を記憶するテーブルである。
【0042】
また、スクレイピングサーバ1の記憶装置12のスクレイピングルールテーブル格納部22には、図6に示した形式のスクレイピングルールテーブルが格納される。このテーブルは、スクレイピング実行部16による、Webサイトから返却されたデータの加工方法を定義するためのテーブルである。
【0043】
図7に示すように、経路探索Webサイトの状態は、「状態0」、「状態1」および「状態2」に区分される。
この「状態0」はWebブラウザの画面の初期状態であり、乗車駅名と下車駅名を入力する駅名入力画面を指す。また、「状態1」は駅名選択画面を指し、「状態2」は経路一覧画面を指す。
【0044】
本実施形態では、「状態0」である駅名入力画面にてユーザ端末装置3により乗車駅「府中」と下車駅「横浜」とを入力して画面上の検索ボタンを押すと、ユーザが意図する駅名を選択するための「状態1」に遷移する。
【0045】
図7に示した例では、「状態0」の駅名入力画面にて入力された「府中」という駅名に対して「府中(東京)」、「府中(広島)」、「府中(徳島)」といった選択肢が駅名選択画面に提示される。また、「状態0」の駅名入力画面にて入力された「横浜」という駅名に対して「横浜」、「陸奥横浜」といった選択肢が駅名選択画面に提示される。
【0046】
この駅名選択画面上でユーザが意図する駅名を選択すると、「状態2」に遷移して乗車駅から下車駅までの経路が表示されることになる。図7に示した例では、駅名選択画面上で乗車駅名として「府中(東京)」が選択されて、下車駅名として「横浜」が選択されたことにより、途中駅である「新宿」を含む経路が経路一覧画面に表示される。
【0047】
図5に示すように、リクエスト管理テーブルは、リクエストごとに「リクエストID」、「状態」、「最初の画面」および「返却値」を保持する。
リクエスト管理テーブル上の「リクエストID」は、ユーザ端末装置3側からのWebAPIへのリクエストを一意に識別するためのデータである。つまり、リクエストID(リクエスト識別情報)が、リクエスト管理テーブルで各リクエストに対して付与されることになる(リクエスト識別情報付与手段の一例)。
【0048】
リクエスト管理テーブル上の「状態」は、前述したリクエストに伴うWebサイトアクセスの状態を示す。図5に示したリクエスト管理テーブルは前述した経路探索に適合したテーブルであり、このテーブル上の「状態」が取り得る値は、図7に示した状態遷移例における駅名入力画面である「状態1」、経路一覧画面である「状態2」、および「終了」である。
【0049】
リクエスト管理テーブル上の「最初の画面」は、ユーザの介在が必要な最初のWebページの画面の種別を示す。本実施形態では、この画面にはスクレイピング実行部16によって前述したリクエストIDが埋め込まれ、当該画面がスクレイピングサーバ1の記憶装置12に保存される。
【0050】
また、リクエスト管理テーブル上の「返却値」は、WebAPIの返却値としてアプリケーションに返す返却値データである。この返却値データは、ユーザ端末装置3によるWebページ操作を経て得られた最終的なWebページから、スクレイピング実行部16によって必要なデータを抜き取ることで作成され、スクレイピングサーバ1の記憶装置12に保存される。
また、図6に示すように、スクレイピングルールテーブル上のルールは、ユーザ向けルールとWebAPI向けルールとに区分され、図7に示した状態遷移の各状態に対して、前述したユーザ向けルールとWebAPI向けルールとがそれぞれ対応付けられる。ルールの定義方法には例えばXSLTやXQueryといった既存の言語を用いることができる。
【0051】
スクレイピングルールテーブル上のWebAPI向けルールとは、ユーザの介在によってWebサイトから最終的に得られたWebページからアプリケーションへの出力に必要なデータを抜き取ることで返却値データを作成するためのルールである。
【0052】
図6に示したテーブルは前述した経路探索に適合したテーブルであり、「状態2」に対応するWebAPI向けルールとしてルール1「システム向けに、経路一覧画面から経路データを抜き出し、XML形式に変換する」が定義され、「状態1」に対応するユーザ向けルールとしてルール2「ユーザ向けに、駅名選択画面にリクエストIDを埋め込む」が定義され、「状態2」に対応するユーザ向けルールとしてルール3「ユーザ向けに、経路一覧画面を読みやすく変更する」が定義される。
【0053】
次に、以上示した構成の情報処理システムの動作について説明する。
図8は、本発明の実施形態における情報処理システムによる処理動作の概要を示す図である。
図9は、本発明の実施形態における情報処理システムによる処理動作の一例を示すシーケンス図である。
図8および図9は、経路探索のためのメッセージの流れを具体的に示すものである。ここでは、本発明の理解を容易にするために、図8と図9にて同じメッセージシーケンスを異なる表現形式で示している。図8は、図4にメッセージの流れを重ねた図である。
【0054】
この情報処理システムは、ユーザ端末装置3側の旅費精算アプリを用いてユーザが乗車駅名と下車駅名を入力すると経路探索WebAPIを呼び出し、移動経路を補完する。
本実施形態では説明を単純にするため移動経路だけを考慮するが、移動経路だけでなく交通費を補完するなど様々な応用も考えられる。
【0055】
以下、経路探索のためのメッセージの流れを順に説明する。
まず、ユーザ端末装置3の入力装置33への所定の操作がなされると、記憶装置12のアプリケーション格納部41に格納される旅費精算アプリが起動する。この旅費精算アプリはWebブラウザを起動して駅名入力画面を表示装置34に表示させる(表示手段の一例)。
【0056】
この駅名入力画面で、ユーザが入力装置33により所望の乗車駅名および下車駅名を入力すると、旅費精算アプリは、スクレイピングサーバ1のWebAPI提供処理部13を介して経路探索WebAPIを呼び出す。ここでは、乗車駅名として「府中」が入力されて、下車駅名として「横浜」が入力されたとする。
【0057】
この際、旅費精算アプリは、「リクエストID」を発行し、このリクエストIDおよび前述した「乗車駅」、「下車駅」を引数としてWebAPI提供処理部13に渡すことで経路探索を要求する(ステップS1)。
リクエストIDは、APIの呼び出しを一意に識別するためのデータである。本実施形態では、呼び出し側であるユーザ端末装置3でUUID(Universally Unique Identifier)を作成してスクレイピングサーバ1側に渡している。このリクエストIDはスクレイピングサーバ1側で発行して呼び出し側に提示するようにしてもよい。
【0058】
WebAPI提供処理部13は、旅費精算アプリから渡された「乗車駅」、「下車駅」および「リクエストID」をもとに、乗車駅から下車駅までの経路を取得するために、Webサーバ2側の経路探索Webサイトへの経路探索のためのアクセスを行なう(ステップS2)。
【0059】
経路探索Webサイトは、旅費精算アプリから渡された「乗車駅」および「下車駅」の駅名候補が示されて当該駅名候補の識別番号が含まれるページデータである駅名選択HTMLページデータをWebAPI提供処理部13に返す。
【0060】
WebAPI提供処理部13は、駅名選択HTMLページデータを経路探索Webサイトから取得すると、この駅名選択HTMLページデータの解析(加工)をスクレイピング実行部16に依頼する(ステップS3)。
【0061】
この駅名選択HTMLページデータの状態は、図6に示したスプレイピングルールテーブル上の「状態1」に該当する。この場合、スクレイピング実行部16は、ステップS3の処理による依頼を受けると、図6に示したスプレイピングルールテーブル上の「状態1」に対応するユーザ向けルールの「ルール2」にしたがって、駅名選択HTMLページデータに対し、ステップS1の処理により旅費精算アプリから渡されたリクエストIDを埋め込むことで、「リクエストID入り駅名選択HTMLページ」を作成する。
【0062】
このようにリクエストIDをページデータに埋め込むことにより、この後のユーザの介在によるWebサイトへの一連のアクセスが前述した最初のWebAPI呼び出しに対応付けられる。よって、異なるユーザのそれぞれが用いるユーザ端末装置3からのリクエストがなされた場合でも、それぞれのリクエストについてのスクレイピングサーバ1による経路探索処理を行なうことができる。
【0063】
WebAPI提供処理部13は、スクレイピング実行部16による加工後のデータである「リクエストID入り駅名選択HTMLページ」の保存をリクエスト管理部15に依頼する(ステップS4)。すると、リクエスト管理部15は、この「リクエストID入り駅名選択HTMLページ」を記憶装置12に保存する。
【0064】
また、ステップS1の処理後、ユーザ端末装置3側の旅費精算アプリは、駅名選択画面を起動するために、リクエストIDを含むURLを引数として、WebAPI実行時にユーザが介在するための駅名選択UIであるWebブラウザを起動する(ステップS5)。
【0065】
すると、このWebブラウザは、スクレイピングサーバ1のUI提供処理部14に対して、ステップS1の処理で説明したリクエストIDをキーとして、このリクエストIDを含むURL、つまり駅名選択画面用のURLの取得をスクレイピングサーバ1のUI提供処理部14に依頼する(ステップS6)。
【0066】
UI提供処理部14は、WebブラウザからのリクエストIDをキーとして、リクエスト管理部15に対し、記憶装置12に保存される「リクエストID入り駅名選択HTMLページ」の取得を依頼する(ステップS7)。
【0067】
リクエスト管理部15は、この依頼にしたがって、記憶装置12に保存されるリクエストID入り駅名選択HTMLページのうち、UI提供処理部14からのリクエストIDに対応するページを取得する。このページは、UI提供処理部14を介し、リクエスト元のユーザ端末装置3側のWebブラウザにより駅名選択画面として表示装置34に表示される(表示手段の一例)。
【0068】
ユーザは、Webブラウザ上の駅名選択画面に表示される乗車駅名および下車駅名の候補のうち、意図する駅名を入力装置33への操作により選択する(ステップS8)。ここでは、乗車駅名として「府中(東京)」が選択され、下車駅名として「横浜」が選択されたとする。
【0069】
すると、Webブラウザは、ステップS1の処理で説明したリクエストIDに加え、駅名選択画面で選択された駅名をUI提供処理部14に送信する(ステップS9)。
UI提供処理部14は、WebブラウザからのリクエストID、選択済みの乗車駅名と下車駅名を受信すると、当該選択済みの乗車駅名及び下車駅名をキーとして、Webサーバ2側の経路探索Webサイトへの経路探索のためのアクセスを行ない(ステップS10)、この経路探索Webサイトから、前述した乗車駅から下車駅までの経路が示される経路一覧HTMLページを取得する。
【0070】
この経路一覧HTMLページは、経路一覧HTMLページを経路探索Webサイトからの最終的なデータ、つまり前述したリクエストにしたがって経路探索Webサイトへのさらなるアクセスを要しないデータであり、前述したリクエストIDが含まれる。ここでは、乗車駅「府中(東京)」から下車駅「横浜」までの途中駅を含む「府中(東京)→新宿→横浜」が経路として示されるとする。
【0071】
そして、UI提供処理部14は、経路探索Webサイトから取得した経路一覧HTMLページの解析、つまりデータ加工をスクレイピング実行部16に依頼する(ステップS11)。
【0072】
経路一覧HTMLページが生成された状態は、図6に示すスクレイピングテーブルの「状態2」に該当する。よって、スクレイピング実行部16は、UI提供処理部14からの依頼に従って、スクレイピングルールテーブル格納部22に格納される図6に示すスクレイピングルールのうち、「状態2」に対応するWebAPI向けルールである「システム向けに、経路一覧画面から経路データを抜き出し、XML形式に変換する」にしたがって、前述した経路一覧HTMLページから旅費精算アプリに必要な経路データを抜き取り、旅費精算アプリによる処理に適合した形式であるXML形式の経路一覧XMLデータを生成する。スクレイピング実行部16は、この生成した経路一覧XMLデータをUI提供処理部14に出力する。
【0073】
また、スクレイピング実行部16は、スクレイピングルールテーブル格納部22に格納される図6に示すスクレイピングルールのうち、「状態2」に対応するユーザ向けルールである「ユーザ向けに、経路一覧画面を読みやすく変更する」にしたがって、経路一覧HTMLページにおける文字のフォントやレイアウトをWebブラウザでの表示に適合した形式に変更してUI提供処理部14に出力する。
【0074】
UI提供処理部14は、スクレイピング実行部16からの経路一覧XMLデータを入力すると、この経路一覧XMLデータの保存をリクエスト管理部15に依頼する(ステップS12)。リクエスト管理部15は、この依頼にしたがって経路一覧XMLデータを記憶装置12に保存する。
【0075】
UI提供処理部14は、ステップS12の処理後、ユーザの介在を必要とする一連の作業が完了したことをWebAPI提供処理部13に通知する(ステップS13)。そして、UI提供処理部14は、前述したようにスクレイピング実行部16から出力された経路一覧HTMLページを入力してユーザ端末装置3側のWebブラウザにより経路一覧画面を表示させる。
【0076】
WebAPI提供処理部13は、リクエストIDに対応する経路一覧XMLデータの取得をリクエスト管理部15からに依頼する(ステップS14)。
リクエスト管理部15は、WebAPI提供処理部13からの依頼に従って、記憶装置12に保存される経路一覧XMLデータのうち、UI提供処理部14からのリクエストIDに対応する経路一覧XMLデータを取得して、WebAPI提供処理部13に返す。
WebAPI提供処理部13は、この経路一覧XMLデータを旅費精算アプリに返却する。旅費精算アプリは、この経路一覧XMLデータで示される経路の旅費を計算する。
【0077】
以上のように、本発明の実施形態における情報処理システムでは、スクレイピングサーバ1が、一回のWebAPI呼び出しを起点とし、そのバックエンドで続いて発生する複数回のWebサイトアクセスを管理し、一連の複数Webサイトアクセスの最終結果からデータを抜き出してWebAPI返却値として返す。このシステムは、その際、一連のWebサイトアクセスにユーザが直接介在できるように、WebサイトのUIを元にユーザ向けUIを提供する。
【0078】
よって、一回のWebAPI呼出/応答と、WebサイトのUIを用いたユーザの介在とを非同期に連携して実行できる。また、ユーザの介在が必要なWebサイトをスクレイピングの対象とした場合、WebAPIをシンプルな入出力として定義できる。
【0079】
また、このように、ユーザの介在が必要なWebAPIの実行において、WebAPIを呼び出すアプリケーションを介さずに、別の手段を使ってユーザを介在させることにより、WebAPIを呼び出すユーザ端末装置3側のアプリケーションからは、ユーザによる複数回のWebサイトアクセスという“ユーザの介在”は隠蔽されることになる。
【0080】
さらに、WebAPIを利用したマッシュアップアプリケーションの開発時には、ユーザが介在するためのUIとして既存Webサイトを流用することができる。WebAPIを利用するマッシュアップアプリケーション側では、ユーザが介在するためのUIを別途用意する必要はない。つまり、WebAPIやマッシュアップアプリケーションの開発が容易になる。
【0081】
なお、この発明は前記実施形態そのままに限定されるものではなく実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を省略してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【0082】
なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク(フロッピー(登録商標)ディスク、ハードディスクなど)、光ディスク(CD−ROM、DVDなど)、光磁気ディスク(MO)、半導体メモリなどの記憶媒体に格納して頒布することもできる。
【0083】
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
【0084】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているOS(オペレーティングシステム)や、データベース管理ソフト、ネットワークソフト等のMW(ミドルウェア)等が上記実施形態を実現するための各処理の一部を実行しても良い。
【0085】
さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、LANやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
【0086】
また、記憶媒体は1つに限らず、複数の媒体から上記実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【0087】
尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記実施形態における各処理を実行するものであって、パソコン等の1つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
【0088】
また、本発明におけるコンピュータとは、パーソナルコンピュータに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【符号の説明】
【0089】
1…スクレイピングサーバ、2…Webサーバ、3…ユーザ端末装置、11,31…制御部、12,32…記憶装置、13…WebAPI提供処理部、14…UI(ユーザインタフェース)提供処理部、15…リクエスト管理部、16…スクレイピング実行部、17,35…通信インタフェース、18,36…バス、21…リクエスト管理テーブル格納部、22…スクレイピングルールテーブル格納部、33…入力装置、34…表示装置、41…アプリケーション格納部、42…Webブラウザ格納部。
【技術分野】
【0001】
本発明は、ユーザ端末装置からのリクエストにしたがってWebアプリケーションのサービスを提供する情報処理装置に関する。
【背景技術】
【0002】
従来、Webサイトの機能をシステム向けにAPI(アプリケーションプログラミングインタフェース:Application Programming Interface)として提供する技術(以下、WebAPIと称する)や、複数のWebサイトの機能やWebAPIを組み合わせて新たなサービスを提供する技術(マッシュアップなどと呼ばれる)が成熟してきた。
【0003】
前述した、Webサイトの機能を提供する技術としては、例えば特許文献1に開示されるように、複数のWebアプリケーションを実行する場合に、汎用Webブラウザを用いて、前段の処理結果を後段のWebアプリケーションに引き継ぐものがある。
【0004】
また、Webサイトの機能を提供する他の技術としては、例えば、Webサイト提供者自らシステム向けにAPIを提供する技術が挙げられ、また、Webサイト画面からデータを抜き出してシステム向けのAPI化を行なうスクレイピング(scraping)ライブラリや環境が挙げられ、また、システム向けAPIを組み合わせて新たなサービスを構築するマッシュアップ環境が挙げられる。
【0005】
ところで、Webサイトが提供するサービスには、利用時にユーザの介在を必要とするものもある。例として、WebAPIが、オンライン書店での検索を行なってユーザの好む本の情報を取得する事や、経路探索用のWebサイトがユーザからの選択にしたがって適切な乗車駅/下車駅を特定して経路を探索する事が挙げられる。
【0006】
このように、WebサイトをスクレイピングしてWebAPI化を行なう際には、WebAPIの実行時にユーザが介在する仕組みを考慮する必要がある。以下、この仕組みについて経路探索Webサイトを例として説明を行なう。
【0007】
図10は、従来の経路探索Webサイトの画面表示例を示す図である。
図10に示した経路探索Webサイトでは、駅名入力画面にてユーザがユーザ端末装置を用いて乗車駅名と下車駅名を入力して画面上の検索ボタンを押すと、経路一覧画面にて乗車駅から下車駅までの乗り換え経路が提示される。
【0008】
ただし駅名入力画面で入力した駅名に曖昧性があると、この駅名入力画面が駅名選択画面に遷移し、ユーザが意図する駅名を選択するよう促す。
【0009】
図10に示した例では、駅名入力画面で入力された「府中」という駅名に対して「府中(東京)」、「府中(広島)」、「府中(徳島)」などが駅名選択画面に表示される。ユーザはこの駅名一覧から意図する駅を選択することで、適切な経路を経路一覧画面で得ることになる。
このような、ユーザの介在を必要とするWebサイトをWebAPI化するためには、従来では以下に示す2つの手法が挙げられる。
第1の手法は細分化である。この細分化とは、ユーザの介在を必要としない細かい単位の複数個のWebAPIを用意し、それらをマッシュアップする側であるユーザ側のアプリケーションで組合せて使う事である。
【0010】
第2の手法は自動化である。この自動化とは、ユーザの介在が不要となる様に、ユーザが従来介在していた部分の処理の実行を自動化する事である。
【0011】
図11は、従来のWebAPIの利用形態の第1の例を示す図である。
図11に示した手法は、前述した細分化の手法(第1の手法)であり、WebAPIとして、駅名一覧取得APIおよび経路探索APIを用いる。
【0012】
駅名一覧取得APIは、ユーザ端末装置側のアプリケーションプログラム(以下、アプリケーションと称する)である旅費精算アプリケーション(以下、旅費精算アプリと称する)を介した文字列を入力として、その文字列にマッチする駅名一覧を経路探索Webサイトから駅名候補として取得して旅費精算アプリに返す。
【0013】
また、経路探索APIは、前述した駅名一覧から旅費精算アプリを介して選択された乗車駅名と下車駅名、つまり乗車駅と下車駅をそれぞれ一意に特定できる情報を入力として、これらの乗車駅から下車駅までの乗り換え経路を経路探索Webサイトから取得して旅費精算アプリに返す。
【0014】
図12は、従来のWebAPIの利用形態の第2の例を示す図である。
図12に示した手法は、前述した自動化の手法(第2の手法)であり、WebAPIとして経路探索APIを用いる。
【0015】
この経路探索WebAPIは、ユーザ端末装置側の旅費精算アプリを介して入力された乗車駅と下車駅のそれぞれの文字列にマッチした駅名一覧を経路探索Webサイトから取得する。そして、経路探索WebAPIは、この駅名一覧からユーザが意図する駅を推測することで自動的に選択し、この選択した乗車駅から下車駅までの乗り換え経路を経路探索Webサイトから取得して旅費精算アプリに返す。
【先行技術文献】
【特許文献】
【0016】
【特許文献1】特開2006−178887号公報
【発明の概要】
【発明が解決しようとする課題】
【0017】
前述したように、ユーザの介在を必要とするWebサイトをWebAPI化するための細分化の方法では、WebAPIは、機能が細切れのサブルーチンWebAPI群に分かれて提供されるため、システムでの利用方法が複雑になる。
【0018】
図11に示した例では、経路探索のためのAPIの他に、駅名一覧取得のためのAPIという本質的ではないAPIが別途必要となってしまう。
また、この細分化の手法では、ユーザが介在するためのユーザインタフェース(以下、UIと称する)をマッシュアップアプリ側のUIとして別途開発しなければならない。図11に示した例では、駅名一覧から駅を一つ選択するためのUIが別途必要になる。
【0019】
また、前述した自動化の手法では、ユーザの介在を要していた処理を自動化するためのロジックがサーバ側に必要となる。図11に示した例では、ユーザの介在部分、つまり駅名一覧におけるユーザが意図する駅名はユーザの現在位置や嗜好など様々な要因に関係しているので、駅名一覧からユーザの意図する駅をサーバ側で適切に推測することは容易ではない。
【0020】
また、サーバ側でユーザの意図する駅名の推測を誤るとユーザの意図に沿えなくなる可能性がある。例えば、「駅名一覧の中から一番上の駅を選択する」というような単純な規則では、必ずしもユーザの意図にそぐわない可能性がある。
【0021】
以上説明したように、従来技術における、ユーザの介在を必要とするWebサイトをWebAPI化するため技術では、WebAPIの複雑化に伴って、これを用いるためのシステムが複雑になったり、ユーザの意図に沿えない処理を行なったりしてしまうといった課題がある。
【0022】
そこで、本発明の目的は、ユーザの介在が必要なWebサイトのWebAPI化を容易に行なうことが可能になる情報処理装置を提供することにある。
【課題を解決するための手段】
【0023】
すなわち、本発明に係わる情報処理装置は、ユーザ側の端末装置で実行されるユーザ側アプリケーションからのリクエストがなされた場合に、Webサーバにより構築されるWebサイトへのアクセスを行なうことで、前記リクエストを受けて、データ加工手段による処理結果を返却値データとして前記ユーザ側アプリケーションに出力するアプリケーションプログラミングインタフェース手段と、前記ユーザ側アプリケーションからのリクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Webサイトから取得した中間値データを保持するデータ保持手段と、前記中間値データを前記ユーザ側アプリケーションを介さずに前記端末装置に表示する表示手段と、前記表示手段による表示結果に対する入力を受け付ける入力手段と、前記入力手段による入力結果にしたがって、前記データ保持手段により保持される前記中間値データをもとに前記Webサイトへのアクセスを行なうことで、当該Webサイトへのさらなるアクセスを要しないデータを取得するデータ取得手段とを備え、前記データ加工手段は、前記データ取得手段により取得したデータの形式を前記ユーザ側アプリケーションによる処理に適合する形式に加工することを特徴とする。
【発明の効果】
【0024】
本発明によれば、ユーザの介在が必要なWebサイトのWebAPI化を容易に行なうことができる。
【図面の簡単な説明】
【0025】
【図1】本発明の実施形態における情報処理システムの構成例を示す図。
【図2】本発明の実施形態における情報処理システムのスクレイピングサーバの構成例を示すブロック図。
【図3】本発明の実施形態における情報処理システムのユーザ端末装置の構成例を示すブロック図。
【図4】本発明の実施形態における情報処理システムのスクレイピングサーバの機能を示す図。
【図5】本発明の実施形態における情報処理システムのスクレイピングサーバのリクエスト管理テーブルの構成例を表形式で示す図。
【図6】本発明の実施形態における情報処理システムのスクレイピングサーバのスクレイピングルールテーブルの構成例を表形式で示す図。
【図7】本発明の実施形態における情報処理システムのWebサーバが提供する経路探索サイトの画面遷移例を示す図。
【図8】本発明の実施形態における情報処理システムによる処理動作の概要を示す図。
【図9】本発明の実施形態における情報処理システムによる処理動作の一例を示すシーケンス図。
【図10】従来の経路探索Webサイトの画面表示例を示す図。
【図11】従来のWebAPIの利用形態の第1の例を示す図。
【図12】従来のWebAPIの利用形態の第2の例を示す図。
【発明を実施するための形態】
【0026】
以下図面により本発明の実施形態について説明する。
図1は、本発明の実施形態における情報処理システムの構成例を示す図である。
図1に示すように、本発明の実施形態における情報処理システムは、スクレイピングサーバ1、Webサーバ2およびユーザ端末装置3を有する。
【0027】
スクレイピングサーバ1およびWebサーバ2はネットワークを介して接続される。Webサーバ2およびユーザ端末装置3は図1に示したようなローカル接続もしくはネットワーク経由で接続される。
【0028】
スクレイピングサーバ1は、ユーザの介在を必要とするWebAPIを提供し、さらに当該WebAPIの実行にユーザが介在するためのUIを提供する。
Webサーバ2は、ユーザからのリクエストに応じたWebアプリケーションのサービス提供のためのWebサイトが構築されるサーバである。
また、ユーザ端末装置3は、例えばパーソナルコンピュータであり、Webアプリケーションのサービスを利用するためのアプリケーションを格納し、これを実行する。図1ではユーザ端末装置3は1台のみ図示しているが、この台数は限定されない。
【0029】
スクレイピングサーバ1は、ユーザ端末装置3側のアプリケーションからの一回のWebAPIの呼び出しを起点とし、この呼び出しに続けてバックエンドで発生する、Webサーバ2側のWebサイトへの複数回のアクセスを管理し、これら一連のWebサイトアクセスの最終結果から必要なデータを抜き出した値をWebAPIの返却値データとしてアプリケーションに返す。
【0030】
その際、スクレイピングサーバ1は、一連のWebサイトアクセスにユーザが直接介在できるように、WebサイトのUIを元にユーザ向けUIをユーザ端末装置3側に提供する。これにより、ユーザ端末装置3側のアプリケーションからの一回のWebAPI呼出/応答と、WebサイトのUIを用いたユーザの介在とを非同期に連携して実行する。
【0031】
図2は、本発明の実施形態における情報処理システムのスクレイピングサーバの構成例を示すブロック図である。
図2に示すように、スクレイピングサーバ1は、装置全体の処理動作を司る制御部11、記憶装置12、WebAPI提供処理部13、UI提供処理部14、リクエスト管理部15、スクレイピング実行部16および通信インタフェース17を備え、それぞれがバス18を介して接続される。
【0032】
記憶装置12は、ハードディスクドライブや不揮発性メモリなどの記憶媒体であり、WebAPI提供処理部13、UI提供処理部14、リクエスト管理部15、スクレイピング実行部16による処理動作のためのプログラムを記憶する他、リクエスト管理テーブル格納部21およびスクレイピングルールテーブル格納部22を有する。
【0033】
WebAPI提供処理部13は、ユーザ端末装置3側のアプリケーションからのWebAPIへのリクエストを受け付けるシステム向けインタフェース(アプリケーションプログラミングインタフェース手段)として機能する。例えば、WebAPI提供処理部13は、URL形式のリクエストをHTTPプロトコルで受け付け、XML形式の返却値データをリクエスト元に返す。ただし、リクエストの入出力はURL形式やXML形式に限定されない。
【0034】
UI提供処理部14は、WebAPIの実行にユーザが介在するためのUIとして機能する(データ加工手段の一例)。例えば、UI提供処理部14は、ユーザ端末装置3側のWebブラウザ上にHTMLページを表示する事でユーザに情報を提示したり、ユーザ端末装置3により入力された情報を得たりする。ただし、UIの実現形態はWebブラウザに限定されない。
【0035】
リクエスト管理部15は、ユーザ端末装置3側のアプリケーションからのWebAPIへのリクエストによって開始されたWebサイトアクセスの状態をリクエストごとに区分して管理する。リクエスト管理部15を介して、アプリケーションからの一回のWebAPI呼び出しを起点として、その後、ユーザによる複数回のWebサイトアクセスが発生する場合がある。
【0036】
また、リクエスト管理部15は、ユーザの介在が必要なWebページであるHTMLページと、ユーザの介在によってWebサーバ2側のWebサイトから得られた最終的な返却値とを記憶装置12に保持する処理を行なう。
【0037】
スクレイピング実行部16は、Webサイトから返却されたWebページを所定のルールにしたがって加工する。このルールは後述するスクレイピングルールテーブルで定義される。
通信インタフェース17は、Webサーバ2やユーザ端末装置3との間の入出力を行なう。
【0038】
スクレイピングサーバ1は、ハードウェア構成、またはハードウェア構成とソフトウェア構成との組合せにより実現可能である。後者の場合、ソフトウェア構成は、予めコンピュータ読み取り可能な記憶媒体またはネットワークから得られたプログラムがコンピュータにインストールされることにより、スクレイピングサーバ1としての各機能が実現される。
【0039】
図3は、本発明の実施形態における情報処理システムのユーザ端末装置の構成例を示すブロック図である。
図3に示すように、ユーザ端末装置3は、装置全体の処理動作を司る制御部31、記憶装置32、キーボードやマウスなどの入力装置33、液晶ディスプレイなどの表示装置34および通信インタフェース35を備え、それぞれがバス36を介して接続される。
記憶装置32は、ハードディスクドライブや不揮発性メモリなどの記憶媒体であり、アプリケーションを格納するアプリケーション格納部41やWebブラウザを格納するWebブラウザ格納部42を有する。
【0040】
図4は、本発明の実施形態における情報処理システムのスクレイピングサーバの機能を示す図である。
図4に示すように、本実施形態では、ユーザ側への提供対象のサービスは経路探索であり、ユーザ端末装置3側のマッシュアップアプリとして旅費精算アプリを用い、Webサーバ2側のWebサイトとして経路探索Webサイトを用いる。また、ユーザ端末装置3では、WebAPI実行時にユーザが介在するためUIとして、マッシュアップアプリとは別個のWebブラウザを用いる。
【0041】
図5は、本発明の実施形態における情報処理システムのスクレイピングサーバのリクエスト管理テーブルの構成例を表形式で示す図である。
図6は、本発明の実施形態における情報処理システムのスクレイピングサーバのスクレイピングルールテーブルの構成例を表形式で示す図である。
図7は、本発明の実施形態における情報処理システムのWebサーバが提供する経路探索サイトの画面遷移例を示す図である。
スクレイピングサーバ1の記憶装置12のリクエスト管理テーブル格納部21には、図5に示した形式のリクエスト管理テーブルが格納される。このリクエスト管理テーブルは、ユーザ端末装置3側のアプリケーションからのWebAPIへのリクエストによって開始されたWebサイトアクセスの状態をリクエスト管理部15により管理するための情報を記憶するテーブルである。
【0042】
また、スクレイピングサーバ1の記憶装置12のスクレイピングルールテーブル格納部22には、図6に示した形式のスクレイピングルールテーブルが格納される。このテーブルは、スクレイピング実行部16による、Webサイトから返却されたデータの加工方法を定義するためのテーブルである。
【0043】
図7に示すように、経路探索Webサイトの状態は、「状態0」、「状態1」および「状態2」に区分される。
この「状態0」はWebブラウザの画面の初期状態であり、乗車駅名と下車駅名を入力する駅名入力画面を指す。また、「状態1」は駅名選択画面を指し、「状態2」は経路一覧画面を指す。
【0044】
本実施形態では、「状態0」である駅名入力画面にてユーザ端末装置3により乗車駅「府中」と下車駅「横浜」とを入力して画面上の検索ボタンを押すと、ユーザが意図する駅名を選択するための「状態1」に遷移する。
【0045】
図7に示した例では、「状態0」の駅名入力画面にて入力された「府中」という駅名に対して「府中(東京)」、「府中(広島)」、「府中(徳島)」といった選択肢が駅名選択画面に提示される。また、「状態0」の駅名入力画面にて入力された「横浜」という駅名に対して「横浜」、「陸奥横浜」といった選択肢が駅名選択画面に提示される。
【0046】
この駅名選択画面上でユーザが意図する駅名を選択すると、「状態2」に遷移して乗車駅から下車駅までの経路が表示されることになる。図7に示した例では、駅名選択画面上で乗車駅名として「府中(東京)」が選択されて、下車駅名として「横浜」が選択されたことにより、途中駅である「新宿」を含む経路が経路一覧画面に表示される。
【0047】
図5に示すように、リクエスト管理テーブルは、リクエストごとに「リクエストID」、「状態」、「最初の画面」および「返却値」を保持する。
リクエスト管理テーブル上の「リクエストID」は、ユーザ端末装置3側からのWebAPIへのリクエストを一意に識別するためのデータである。つまり、リクエストID(リクエスト識別情報)が、リクエスト管理テーブルで各リクエストに対して付与されることになる(リクエスト識別情報付与手段の一例)。
【0048】
リクエスト管理テーブル上の「状態」は、前述したリクエストに伴うWebサイトアクセスの状態を示す。図5に示したリクエスト管理テーブルは前述した経路探索に適合したテーブルであり、このテーブル上の「状態」が取り得る値は、図7に示した状態遷移例における駅名入力画面である「状態1」、経路一覧画面である「状態2」、および「終了」である。
【0049】
リクエスト管理テーブル上の「最初の画面」は、ユーザの介在が必要な最初のWebページの画面の種別を示す。本実施形態では、この画面にはスクレイピング実行部16によって前述したリクエストIDが埋め込まれ、当該画面がスクレイピングサーバ1の記憶装置12に保存される。
【0050】
また、リクエスト管理テーブル上の「返却値」は、WebAPIの返却値としてアプリケーションに返す返却値データである。この返却値データは、ユーザ端末装置3によるWebページ操作を経て得られた最終的なWebページから、スクレイピング実行部16によって必要なデータを抜き取ることで作成され、スクレイピングサーバ1の記憶装置12に保存される。
また、図6に示すように、スクレイピングルールテーブル上のルールは、ユーザ向けルールとWebAPI向けルールとに区分され、図7に示した状態遷移の各状態に対して、前述したユーザ向けルールとWebAPI向けルールとがそれぞれ対応付けられる。ルールの定義方法には例えばXSLTやXQueryといった既存の言語を用いることができる。
【0051】
スクレイピングルールテーブル上のWebAPI向けルールとは、ユーザの介在によってWebサイトから最終的に得られたWebページからアプリケーションへの出力に必要なデータを抜き取ることで返却値データを作成するためのルールである。
【0052】
図6に示したテーブルは前述した経路探索に適合したテーブルであり、「状態2」に対応するWebAPI向けルールとしてルール1「システム向けに、経路一覧画面から経路データを抜き出し、XML形式に変換する」が定義され、「状態1」に対応するユーザ向けルールとしてルール2「ユーザ向けに、駅名選択画面にリクエストIDを埋め込む」が定義され、「状態2」に対応するユーザ向けルールとしてルール3「ユーザ向けに、経路一覧画面を読みやすく変更する」が定義される。
【0053】
次に、以上示した構成の情報処理システムの動作について説明する。
図8は、本発明の実施形態における情報処理システムによる処理動作の概要を示す図である。
図9は、本発明の実施形態における情報処理システムによる処理動作の一例を示すシーケンス図である。
図8および図9は、経路探索のためのメッセージの流れを具体的に示すものである。ここでは、本発明の理解を容易にするために、図8と図9にて同じメッセージシーケンスを異なる表現形式で示している。図8は、図4にメッセージの流れを重ねた図である。
【0054】
この情報処理システムは、ユーザ端末装置3側の旅費精算アプリを用いてユーザが乗車駅名と下車駅名を入力すると経路探索WebAPIを呼び出し、移動経路を補完する。
本実施形態では説明を単純にするため移動経路だけを考慮するが、移動経路だけでなく交通費を補完するなど様々な応用も考えられる。
【0055】
以下、経路探索のためのメッセージの流れを順に説明する。
まず、ユーザ端末装置3の入力装置33への所定の操作がなされると、記憶装置12のアプリケーション格納部41に格納される旅費精算アプリが起動する。この旅費精算アプリはWebブラウザを起動して駅名入力画面を表示装置34に表示させる(表示手段の一例)。
【0056】
この駅名入力画面で、ユーザが入力装置33により所望の乗車駅名および下車駅名を入力すると、旅費精算アプリは、スクレイピングサーバ1のWebAPI提供処理部13を介して経路探索WebAPIを呼び出す。ここでは、乗車駅名として「府中」が入力されて、下車駅名として「横浜」が入力されたとする。
【0057】
この際、旅費精算アプリは、「リクエストID」を発行し、このリクエストIDおよび前述した「乗車駅」、「下車駅」を引数としてWebAPI提供処理部13に渡すことで経路探索を要求する(ステップS1)。
リクエストIDは、APIの呼び出しを一意に識別するためのデータである。本実施形態では、呼び出し側であるユーザ端末装置3でUUID(Universally Unique Identifier)を作成してスクレイピングサーバ1側に渡している。このリクエストIDはスクレイピングサーバ1側で発行して呼び出し側に提示するようにしてもよい。
【0058】
WebAPI提供処理部13は、旅費精算アプリから渡された「乗車駅」、「下車駅」および「リクエストID」をもとに、乗車駅から下車駅までの経路を取得するために、Webサーバ2側の経路探索Webサイトへの経路探索のためのアクセスを行なう(ステップS2)。
【0059】
経路探索Webサイトは、旅費精算アプリから渡された「乗車駅」および「下車駅」の駅名候補が示されて当該駅名候補の識別番号が含まれるページデータである駅名選択HTMLページデータをWebAPI提供処理部13に返す。
【0060】
WebAPI提供処理部13は、駅名選択HTMLページデータを経路探索Webサイトから取得すると、この駅名選択HTMLページデータの解析(加工)をスクレイピング実行部16に依頼する(ステップS3)。
【0061】
この駅名選択HTMLページデータの状態は、図6に示したスプレイピングルールテーブル上の「状態1」に該当する。この場合、スクレイピング実行部16は、ステップS3の処理による依頼を受けると、図6に示したスプレイピングルールテーブル上の「状態1」に対応するユーザ向けルールの「ルール2」にしたがって、駅名選択HTMLページデータに対し、ステップS1の処理により旅費精算アプリから渡されたリクエストIDを埋め込むことで、「リクエストID入り駅名選択HTMLページ」を作成する。
【0062】
このようにリクエストIDをページデータに埋め込むことにより、この後のユーザの介在によるWebサイトへの一連のアクセスが前述した最初のWebAPI呼び出しに対応付けられる。よって、異なるユーザのそれぞれが用いるユーザ端末装置3からのリクエストがなされた場合でも、それぞれのリクエストについてのスクレイピングサーバ1による経路探索処理を行なうことができる。
【0063】
WebAPI提供処理部13は、スクレイピング実行部16による加工後のデータである「リクエストID入り駅名選択HTMLページ」の保存をリクエスト管理部15に依頼する(ステップS4)。すると、リクエスト管理部15は、この「リクエストID入り駅名選択HTMLページ」を記憶装置12に保存する。
【0064】
また、ステップS1の処理後、ユーザ端末装置3側の旅費精算アプリは、駅名選択画面を起動するために、リクエストIDを含むURLを引数として、WebAPI実行時にユーザが介在するための駅名選択UIであるWebブラウザを起動する(ステップS5)。
【0065】
すると、このWebブラウザは、スクレイピングサーバ1のUI提供処理部14に対して、ステップS1の処理で説明したリクエストIDをキーとして、このリクエストIDを含むURL、つまり駅名選択画面用のURLの取得をスクレイピングサーバ1のUI提供処理部14に依頼する(ステップS6)。
【0066】
UI提供処理部14は、WebブラウザからのリクエストIDをキーとして、リクエスト管理部15に対し、記憶装置12に保存される「リクエストID入り駅名選択HTMLページ」の取得を依頼する(ステップS7)。
【0067】
リクエスト管理部15は、この依頼にしたがって、記憶装置12に保存されるリクエストID入り駅名選択HTMLページのうち、UI提供処理部14からのリクエストIDに対応するページを取得する。このページは、UI提供処理部14を介し、リクエスト元のユーザ端末装置3側のWebブラウザにより駅名選択画面として表示装置34に表示される(表示手段の一例)。
【0068】
ユーザは、Webブラウザ上の駅名選択画面に表示される乗車駅名および下車駅名の候補のうち、意図する駅名を入力装置33への操作により選択する(ステップS8)。ここでは、乗車駅名として「府中(東京)」が選択され、下車駅名として「横浜」が選択されたとする。
【0069】
すると、Webブラウザは、ステップS1の処理で説明したリクエストIDに加え、駅名選択画面で選択された駅名をUI提供処理部14に送信する(ステップS9)。
UI提供処理部14は、WebブラウザからのリクエストID、選択済みの乗車駅名と下車駅名を受信すると、当該選択済みの乗車駅名及び下車駅名をキーとして、Webサーバ2側の経路探索Webサイトへの経路探索のためのアクセスを行ない(ステップS10)、この経路探索Webサイトから、前述した乗車駅から下車駅までの経路が示される経路一覧HTMLページを取得する。
【0070】
この経路一覧HTMLページは、経路一覧HTMLページを経路探索Webサイトからの最終的なデータ、つまり前述したリクエストにしたがって経路探索Webサイトへのさらなるアクセスを要しないデータであり、前述したリクエストIDが含まれる。ここでは、乗車駅「府中(東京)」から下車駅「横浜」までの途中駅を含む「府中(東京)→新宿→横浜」が経路として示されるとする。
【0071】
そして、UI提供処理部14は、経路探索Webサイトから取得した経路一覧HTMLページの解析、つまりデータ加工をスクレイピング実行部16に依頼する(ステップS11)。
【0072】
経路一覧HTMLページが生成された状態は、図6に示すスクレイピングテーブルの「状態2」に該当する。よって、スクレイピング実行部16は、UI提供処理部14からの依頼に従って、スクレイピングルールテーブル格納部22に格納される図6に示すスクレイピングルールのうち、「状態2」に対応するWebAPI向けルールである「システム向けに、経路一覧画面から経路データを抜き出し、XML形式に変換する」にしたがって、前述した経路一覧HTMLページから旅費精算アプリに必要な経路データを抜き取り、旅費精算アプリによる処理に適合した形式であるXML形式の経路一覧XMLデータを生成する。スクレイピング実行部16は、この生成した経路一覧XMLデータをUI提供処理部14に出力する。
【0073】
また、スクレイピング実行部16は、スクレイピングルールテーブル格納部22に格納される図6に示すスクレイピングルールのうち、「状態2」に対応するユーザ向けルールである「ユーザ向けに、経路一覧画面を読みやすく変更する」にしたがって、経路一覧HTMLページにおける文字のフォントやレイアウトをWebブラウザでの表示に適合した形式に変更してUI提供処理部14に出力する。
【0074】
UI提供処理部14は、スクレイピング実行部16からの経路一覧XMLデータを入力すると、この経路一覧XMLデータの保存をリクエスト管理部15に依頼する(ステップS12)。リクエスト管理部15は、この依頼にしたがって経路一覧XMLデータを記憶装置12に保存する。
【0075】
UI提供処理部14は、ステップS12の処理後、ユーザの介在を必要とする一連の作業が完了したことをWebAPI提供処理部13に通知する(ステップS13)。そして、UI提供処理部14は、前述したようにスクレイピング実行部16から出力された経路一覧HTMLページを入力してユーザ端末装置3側のWebブラウザにより経路一覧画面を表示させる。
【0076】
WebAPI提供処理部13は、リクエストIDに対応する経路一覧XMLデータの取得をリクエスト管理部15からに依頼する(ステップS14)。
リクエスト管理部15は、WebAPI提供処理部13からの依頼に従って、記憶装置12に保存される経路一覧XMLデータのうち、UI提供処理部14からのリクエストIDに対応する経路一覧XMLデータを取得して、WebAPI提供処理部13に返す。
WebAPI提供処理部13は、この経路一覧XMLデータを旅費精算アプリに返却する。旅費精算アプリは、この経路一覧XMLデータで示される経路の旅費を計算する。
【0077】
以上のように、本発明の実施形態における情報処理システムでは、スクレイピングサーバ1が、一回のWebAPI呼び出しを起点とし、そのバックエンドで続いて発生する複数回のWebサイトアクセスを管理し、一連の複数Webサイトアクセスの最終結果からデータを抜き出してWebAPI返却値として返す。このシステムは、その際、一連のWebサイトアクセスにユーザが直接介在できるように、WebサイトのUIを元にユーザ向けUIを提供する。
【0078】
よって、一回のWebAPI呼出/応答と、WebサイトのUIを用いたユーザの介在とを非同期に連携して実行できる。また、ユーザの介在が必要なWebサイトをスクレイピングの対象とした場合、WebAPIをシンプルな入出力として定義できる。
【0079】
また、このように、ユーザの介在が必要なWebAPIの実行において、WebAPIを呼び出すアプリケーションを介さずに、別の手段を使ってユーザを介在させることにより、WebAPIを呼び出すユーザ端末装置3側のアプリケーションからは、ユーザによる複数回のWebサイトアクセスという“ユーザの介在”は隠蔽されることになる。
【0080】
さらに、WebAPIを利用したマッシュアップアプリケーションの開発時には、ユーザが介在するためのUIとして既存Webサイトを流用することができる。WebAPIを利用するマッシュアップアプリケーション側では、ユーザが介在するためのUIを別途用意する必要はない。つまり、WebAPIやマッシュアップアプリケーションの開発が容易になる。
【0081】
なお、この発明は前記実施形態そのままに限定されるものではなく実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を省略してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【0082】
なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク(フロッピー(登録商標)ディスク、ハードディスクなど)、光ディスク(CD−ROM、DVDなど)、光磁気ディスク(MO)、半導体メモリなどの記憶媒体に格納して頒布することもできる。
【0083】
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
【0084】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているOS(オペレーティングシステム)や、データベース管理ソフト、ネットワークソフト等のMW(ミドルウェア)等が上記実施形態を実現するための各処理の一部を実行しても良い。
【0085】
さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、LANやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
【0086】
また、記憶媒体は1つに限らず、複数の媒体から上記実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【0087】
尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記実施形態における各処理を実行するものであって、パソコン等の1つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
【0088】
また、本発明におけるコンピュータとは、パーソナルコンピュータに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【符号の説明】
【0089】
1…スクレイピングサーバ、2…Webサーバ、3…ユーザ端末装置、11,31…制御部、12,32…記憶装置、13…WebAPI提供処理部、14…UI(ユーザインタフェース)提供処理部、15…リクエスト管理部、16…スクレイピング実行部、17,35…通信インタフェース、18,36…バス、21…リクエスト管理テーブル格納部、22…スクレイピングルールテーブル格納部、33…入力装置、34…表示装置、41…アプリケーション格納部、42…Webブラウザ格納部。
【特許請求の範囲】
【請求項1】
ユーザ側の端末装置で実行されるユーザ側アプリケーションからのリクエストがなされた場合に、Webサーバにより構築されるWebサイトへのアクセスを行なうことで、前記リクエストを受けて、データ加工手段による処理結果を返却値データとして前記ユーザ側アプリケーションに出力するアプリケーションプログラミングインタフェース手段と、
前記ユーザ側アプリケーションからのリクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Webサイトから取得した中間値データを保持するデータ保持手段と、
前記中間値データを前記ユーザ側アプリケーションを介さずに前記端末装置に表示する表示手段と、
前記表示手段による表示結果に対する入力を受け付ける入力手段と、
前記入力手段による入力結果にしたがって、前記データ保持手段により保持される前記中間値データをもとに前記Webサイトへのアクセスを行なうことで、当該Webサイトへのさらなるアクセスを要しないデータを取得するデータ取得手段と
を備え、
前記データ加工手段は、前記データ取得手段により取得したデータの形式を前記ユーザ側アプリケーションによる処理に適合する形式に加工する
ことを特徴とする情報処理装置。
【請求項2】
前記ユーザ側アプリケーションからのリクエストには、当該リクエストを識別するリクエスト識別情報が含まれ、
当該リクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Webサイトから取得した中間値データに当該リクエストに対応するリクエスト識別情報を付与するリクエスト識別情報付与手段をさらに備え、
前記データ保持手段は、
前記リクエスト識別情報付与手段による処理結果を保持し、
前記入力手段による入力内容には、当該入力に関わるリクエストに対応するリクエスト識別情報が含まれ、
前記データ取得手段は、
前記入力手段による入力結果にしたがって、前記データ保持手段による保持される中間値データのうち、前記入力内容に含まれる前記リクエスト識別情報に対応する中間値データをもとに前記Webサイトへのアクセスを行なうことで、当該Webサイトへのさらなるアクセスを要しないデータを取得する
ことを特徴とする請求項1に記載の情報処理装置。
【請求項1】
ユーザ側の端末装置で実行されるユーザ側アプリケーションからのリクエストがなされた場合に、Webサーバにより構築されるWebサイトへのアクセスを行なうことで、前記リクエストを受けて、データ加工手段による処理結果を返却値データとして前記ユーザ側アプリケーションに出力するアプリケーションプログラミングインタフェース手段と、
前記ユーザ側アプリケーションからのリクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Webサイトから取得した中間値データを保持するデータ保持手段と、
前記中間値データを前記ユーザ側アプリケーションを介さずに前記端末装置に表示する表示手段と、
前記表示手段による表示結果に対する入力を受け付ける入力手段と、
前記入力手段による入力結果にしたがって、前記データ保持手段により保持される前記中間値データをもとに前記Webサイトへのアクセスを行なうことで、当該Webサイトへのさらなるアクセスを要しないデータを取得するデータ取得手段と
を備え、
前記データ加工手段は、前記データ取得手段により取得したデータの形式を前記ユーザ側アプリケーションによる処理に適合する形式に加工する
ことを特徴とする情報処理装置。
【請求項2】
前記ユーザ側アプリケーションからのリクエストには、当該リクエストを識別するリクエスト識別情報が含まれ、
当該リクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Webサイトから取得した中間値データに当該リクエストに対応するリクエスト識別情報を付与するリクエスト識別情報付与手段をさらに備え、
前記データ保持手段は、
前記リクエスト識別情報付与手段による処理結果を保持し、
前記入力手段による入力内容には、当該入力に関わるリクエストに対応するリクエスト識別情報が含まれ、
前記データ取得手段は、
前記入力手段による入力結果にしたがって、前記データ保持手段による保持される中間値データのうち、前記入力内容に含まれる前記リクエスト識別情報に対応する中間値データをもとに前記Webサイトへのアクセスを行なうことで、当該Webサイトへのさらなるアクセスを要しないデータを取得する
ことを特徴とする請求項1に記載の情報処理装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公開番号】特開2011−81510(P2011−81510A)
【公開日】平成23年4月21日(2011.4.21)
【国際特許分類】
【出願番号】特願2009−231815(P2009−231815)
【出願日】平成21年10月5日(2009.10.5)
【出願人】(000003078)株式会社東芝 (54,554)
【出願人】(301063496)東芝ソリューション株式会社 (1,478)
【Fターム(参考)】
【公開日】平成23年4月21日(2011.4.21)
【国際特許分類】
【出願日】平成21年10月5日(2009.10.5)
【出願人】(000003078)株式会社東芝 (54,554)
【出願人】(301063496)東芝ソリューション株式会社 (1,478)
【Fターム(参考)】
[ Back to top ]