(58)【調査した分野】(Int.Cl.,DB名)
【背景技術】
【0002】
近年、クラウドコンピューティング環境において、様々な外部サービスが提供されている。様々な外部サービスの中からニーズに合うものを選択し、それらを組み合わせて利用するというニーズが高まっている。これらは、いずれかのサービスアプリケーションにより実施される2つ以上のサービスを連携させる「サービス連携」と呼ばれる。例えば、IFTTT(IF This Then That)というサービス連携ツールが登場し、注目されている。ここで、サービス連携ツールの基本的な動作は、あるサービスで発生するイベントをトリガに、他のサービスに対するアクションを起こすというものである。
【0003】
サービス連携の例としては、次のようなものが挙げられる。
・「ソーシャルネットワーキングサービス+ストレージサービス」
ソーシャルネットワーキングサービス上で書き込み行った場合、その内容をクラウド上のストレージサービスに自動保存するものである。
・「天気予報公開サービス+メールサービス」
翌日の天気が雨という予報が出た場合、そのことを通知するメールをユーザに自動送信するものである。
【0004】
ここで、サービス連携のためのイベント発生の検知は、各サービスが提供するWeb API(Application Programming Interface)を利用することで行う。そして、そのイベントをトリガとして起こす他サービスへのアクションも、各サービスが提供するWeb API経由で行う。
【0005】
特許文献1には、個別サービスの仕様とデータ仕様を利用し、サービス連携をビジュアルに構築し、サービス連携の動作をシミュレーションで網羅的に検証することができる連携支援システムに関する技術が開示されている。
【発明の概要】
【発明が解決しようとする課題】
【0007】
ここで、複数の種類のサービス連携が実行される場合には、サービス連携のループが発生し得る。そして、特許文献1では、サービス連携の本登録前の検証をシミュレーションにより行なうことになるが、各種サービスは様々なユーザにより利用されるものであるため、検証自体が他のユーザに影響を与えるおそれがあるという問題点があった。
【0008】
以下では、サービス連携の概要と複数のサービス連携によりループが発生するケースについて例を用いて説明する。
図9は、サービス連携の概念を説明するための図である。まず、サービス提供企業X1ネットワーク21はサービスA211を、サービス提供企業X2ネットワーク22はサービスB221を、それぞれ外部に提供しているものとする。尚、サービス提供企業X1ネットワーク21及びサービス提供企業X2ネットワーク22は、各サービスを提供するためのサーバ(不図示)を備えているものとする。また、企業Y1ネットワーク31及び企業Y1ネットワーク32のそれぞれは、サービスA211及びサービスB221を個別にインターネットNを介して利用可能であるものとする。
【0009】
ここで、サービス連携提供ネットワーク10は、内部のサーバ(不図示)がサービス連携ルール群11という情報を保持しており、サービス連携ルール群11には、複数の連携ルール111及び112等が含まれているものとする。連携ルール111は、サービスAをトリガとし、サービスBをアクションとしたサービス連携の定義情報である。また、連携ルール112は、サービスBをトリガとし、サービスC(不図示)をアクションとしたサービス連携の定義情報である。
【0010】
各企業がサービス連携を行なう場合には、サービス連携用ソフトウェアを自社のネットワーク内のコンピュータにインストールして「サービス連携装置」として利用する。企業Y1ネットワーク31はサービス連携装置311を有し、企業Y1ネットワーク32はサービス連携装置321を有する。ここで、サービス連携装置311とサービス連携装置321とは、別々の企業内のネットワークに存在するため、互いに通信を行うことができず、また、互いを意識せずに動作するものとする。
【0011】
サービス連携装置311及び321のそれぞれは、サービス連携提供ネットワーク10内のサービス連携ルール群11から、任意の連携ルールを選択し、自社のネットワークにダウンロードして利用することができる。ここで、サービスA211及びサービスB221は、WebAPIを公開しており、サービス連携装置311及び321はWebAPIを利用して、各サービスで発生したイベントの検知や、サービスにアクションを起こすことが可能となる。
【0012】
サービス連携装置311は連携ルール312を取り込んでおり、「トリガ:サービスA、アクション:サービスB」というサービス連携の定義が行われている。そのため、サービスAで、あるイベントが発生すると、サービス連携装置311がそれを検知し、サービスBのアクションを実行する。このようにして、サービス連携が実現できる。
【0013】
しかしながら、複数の種類のサービス連携が組み合わせて利用される場合、その組み合わせによってはサービス連携のループを引き起こす可能性がある。例えば、サービス連携装置321が「トリガ:サービスB、アクション:サービスA」というサービス連携の定義を追加するものとする。この場合、すでに、サービス連携装置311には、「トリガ:サービスA、アクション:サービスB」が定義されていることから、サービス連携装置311によりサービスBのアクションが実行されたことで、サービス連携装置321がサービスBのイベントを検知し、サービスAのアクションを実行することとなり得る。そして、サービス連携装置321によりサービスAのアクションが実行されたことで、サービス連携装置311がサービスAのイベントを検知することとなり、サービス連携によるデータのループが発生し得る。
【0014】
また、特許文献1のようにシミュレーションを行う場合、企業Y2のサービス連携の検証のために、企業Y1のネットワークやサービスにも影響を与えてしまう。
【0015】
本発明は、このような問題点を解決するためになされたものであり、他のユーザへの影響を抑えて、複数の種類のサービス連携の管理を利用実態に合わせて行なうためのサービス連携管理システム、装置、方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【0016】
本発明の第1の態様にかかるサービス連携管理システムは、
サービス間の連携を定義した複数のサービス連携ルールに含まれる複数のサービスにおいて発生した複数のイベント情報を収集する収集部と、
前記収集された複数のイベント情報に含まれるデータの流れを分析して、前記複数のサービス連携ルールのうち利用中のものを推定する推定部と、
を備える。
【0017】
本発明の第2の態様にかかるサービス連携管理装置は、
サービス間の連携を定義した複数のサービス連携ルールに含まれる複数のサービスにおいて発生した複数のイベント情報を収集する収集部と、
前記収集された複数のイベント情報に含まれるデータの流れを分析して、前記複数のサービス連携ルールのうち利用中のものを推定する推定部と、
を備える。
【0018】
本発明の第3の態様にかかるサービス連携管理方法は、
サービス間の連携を定義した複数のサービス連携ルールに含まれる複数のサービスにおいて発生した複数のイベント情報を収集し、
前記収集された複数のイベント情報に含まれるデータの流れを分析して、前記複数のサービス連携ルールのうち利用中のものを推定する。
【0019】
本発明の第4の態様にかかるサービス連携管理プログラムは、
サービス間の連携を定義した複数のサービス連携ルールに含まれる複数のサービスにおいて発生した複数のイベント情報を収集する処理と、
前記収集された複数のイベント情報に含まれるデータの流れを分析して、前記複数のサービス連携ルールのうち利用中のものを推定する処理と、
をコンピュータに実行させる。
【0020】
本発明の第5の態様にかかるサービス連携管理システムは、
サービス間の連携を定義した複数のサービス連携ルールに含まれる複数のサービスにおいて発生した複数のイベント情報を収集する収集部と、
前記収集された複数のイベント情報に含まれるデータの流れを分析して、前記複数のサービス連携ルールのうち利用中のものを推定する推定部と、
前記推定されたサービス間の連携をサービス連携推定情報として記憶装置に格納する格納部と、
を備えるサービス連携管理装置と、
新たなサービス連携ルールの追加要求を受け付けた場合に、前記記憶装置から前記サービス連携推定情報を取得し、当該新たなサービス連携ルールの追加により前記データの流れにループが生じるか否かを判定し、前記ループが生じないと判定した場合に当該追加要求を許可し、前記ループが生じると判定した場合に当該追加要求を拒否する旨を要求元へ応答する追加判定処理を行なう追加判定部
を備えるサービス利用装置と、
を備える。
【発明の効果】
【0021】
本発明により、他のユーザへの影響を抑えて、複数の種類のサービス連携の管理を利用実態に合わせて行なうためのサービス連携管理システム、装置、方法及びプログラムを提供することができる。
【発明を実施するための形態】
【0023】
以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。
【0024】
ここで、上述したサービス連携によるデータのループを防ぐためのサービス連携の管理手法について検討する。まず、サービス連携の管理手法1として、連携ルールを一括管理し、ループが発生するなどの不正なルールの組み合わせを登録できないようにする手法が存在する。尚、本発明では、複数のサービス連携装置が独立して動作する場合を対象とする。そのため、各サービス連携装置(つまり、各ユーザ)でサービスの連携が独立して行われ、他のサービス連携装置(他のユーザ)のサービス連携状況を考慮せずにサービスの連携が追加されるものとする。したがって、ループを防ぐためには、複数のサービス連携装置が存在することを考慮した上でサービス連携の管理を行う必要がある。
【0025】
複数のサービス連携装置が存在することを考慮したサービス連携の管理方法1として、各サービスで利用されるために事前に登録されたサービス連携ルールについての情報を1か所にまとめて、それを元にサービス連携の管理を行う方法が考えられる。以下に2つの例を挙げる。
【0026】
管理方法1の1つ目の例は、サービス連携提供企業ネットワーク内のサービス連携ルール群に定義されているルール全てを対象として、ループが発生する可能性の有無を検証するというものである。確かにこの方法により、サービス連携ルール群に定義されているルール間のループの発生可能性を検出することができる。ただし、これでは、サービス連携ルール群として定義はされているが、実際には各サービス連携装置で利用されていないサービスとの連携も不正として検出されてしまうおそれがある。つまり、各サービス連携装置によるルールの利用実態を考慮せず、過度に不正な連携ルールと検出してしまう可能性がある方法と言える。
【0027】
管理方法1の2つ目の例は、各サービス連携装置が実際に利用しているサービス連携ルール(
図9では、サービス連携装置311内で定義されている「連携ルール(A→B)」312)を収集し、実際に利用されているルールを対象としてループの発生可能性の有無を検証するというものである。これは各サービス連携装置のルール利用実態を考慮しており、適切にサービス連携の管理ができると言える。ただし、利用しているサービス連携から業務内容を推測できる可能性がある。そして、各社が利用するサービス連携の一覧は企業の資産とも言える。近年の営業秘密の保護の観点から、自社で利用しているサービス連携ルールを外部(サービス連携提供企業)へ公開することが望まれないケースがある。そのため、各サービス連携装置が実際に利用しているサービス連携ルールを収集することは困難といえる。
【0028】
上記の2例で示したように、サービス連携によるデータのループの検出を、定義されている各種連携ルールの一括管理から行う従来の手法では、上述した課題を解決するためには適用できない。
【0029】
また、他のループを検出する仕組みであるサービス連携の管理方法2として、検出用の情報を付加するという方法がある。これはデータにループ検出用の領域を設け、データ送信時にはループ検出用領域にデータを埋め込み、データ受信時には、ループ検出用領域の内容をチェックするという方法である。チェックした結果、自分が埋め込んだデータであるということが分かれば、そのデータをループしたものとみなすことができる。しかしこの方法は以下の理由から、上述した課題を解決するためには有効でないといえる。
【0030】
・データが送信される間にサービスをはさむので、ループ検出用情報を埋め込んだデータを渡すことができない可能性がある。
・ループ検出用情報を埋め込んだデータをサービスに渡せても、その結果発生するアクションによるイベントにその情報が含まれない可能性がある。あるいは含まれてもループが検出できる形で含まれない可能性がある。
・サービス連携装置間では通信を行うことができないので、サービス連携装置が直接やり取りを行うことによる解決はできない。
【0031】
以上のことから上述したサービス連携によるデータのループを検出するためには、登録された連携ルール自体を一括管理するだけでは不十分であり、また、検証用の情報を付加することも採用できない。そこで、上述した課題を解決すべく以下の実施の形態について説明する。
【0032】
<実施の形態1>
図1は、本発明の実施の形態1にかかるサービス連携管理装置100の構成を示すブロック図である。サービス連携管理装置100は、サービス間の連携を定義したサービス連携ルールを管理するためのコンピュータ装置である。尚、サービス連携管理装置100は、1台のコンピュータに限定されず、複数台のコンピュータ装置で実現されても構わない。その場合、サービス連携管理システムということができる。また、サービス連携ルールには、少なくとも連携元と連携先のサービスが定義されている。尚、1つのサービス連携ルール内に3以上のサービスの連携が定義されていてもよい。
【0033】
サービス連携管理装置100は、収集部110と、推定部120とを備える。収集部110は、複数のイベント情報41〜4n(nは2以上の自然数。)を収集する。ここで、イベント情報41〜4nのそれぞれは、複数のサービス連携ルールのいずれかに含まれる複数のサービスにおいて発生したイベントに関する情報である。推定部120は、収集された複数のイベント情報41〜4nに含まれるデータの流れを分析して、複数のサービス連携ルールのうち利用中のものを推定する。
【0034】
図2は、本発明の実施の形態1にかかるサービス連携管理処理の流れを示すフローチャートである。まず、収集部110は、サービス連携ルールに含まれるサービスにおいて発生した複数のイベント情報を収集する(S1)。次に、推定部120は、収集された複数のイベント情報41〜4nに含まれるデータの流れを分析する。そして、推定部120は、複数のサービス連携ルールのうち利用中のサービス間の連携を推定する(S2)。
【0035】
このように、本発明の実施の形態1では、登録されたサービス連携ルールだけを解析するのではなく、サービス連携ルールに基づいて実際に発生するイベントを監視し、イベント情報を収集する。そして収集したイベント情報を分析して実際に利用されたサービス間の連携を推定するものである。そのため、サービス連携におけるループ等の不整合を検出するために、テストデータの送信等を行う必要がなく、各種サービス単体やサービス連携を利用中のユーザに対してサービスの結果に影響を抑えることができる。よって、他のユーザへの影響を抑え、利用実態に合わせて複数の種類のサービス連携の管理を行なうことができる。
【0036】
<実施の形態2>
本実施の形態2は、上述した実施の形態1の改良例である。まず、前記推定部は、前記複数のサービスのうち第1のサービスにおいて発生したイベント情報に含まれる第1の要素値と、その後に第2のサービスにおいて発生したイベント情報に含まれる第2の要素値とが一致する場合に、前記第1のサービスと前記第2のサービスの間の連携が前記利用中のものと推定する。これにより、複数のイベント情報からサービス間の連携の推定精度を高めることができる。
【0037】
また、サービス連携管理装置は、前記推定されたサービス間の連携をサービス連携推定情報として記憶装置に格納する格納部をさらに備えるとよい。そして、サービス利用装置は、新たなサービス連携ルールの追加要求を受け付けた場合に、前記記憶装置から前記サービス連携推定情報を取得し、当該新たなサービス連携ルールの追加により前記データの流れにループが生じるか否かを判定し、前記ループが生じないと判定した場合に当該追加要求を許可し、前記ループが生じると判定した場合に当該追加要求を拒否する旨を要求元へ応答する追加判定処理を行なう追加判定部と、をさらに備えるとよい。これにより、サービス連携の試行をすることなく、ループとなり得るサービス連携の登録を未然に防ぐことができる。尚、本実施の形態2にかかるサービス連携管理システムとしては、前記追加判定部がサービス連携管理装置内に存在していても構わない。
【0038】
さらに、前記追加判定部は、第1のサービス利用装置が第1のサービス連携ルールを利用中に、第2のサービス利用装置から第2のサービス連携ルールの追加要求を受け付けた場合に、前記追加判定処理を行なうことが望ましい。これにより、異なる企業間で実際に利用しているサービス連携ルールを開示することなく、実際に利用されているサービス連携に基づいて適切なサービス連携の追加を判断することができる。特に、一企業の単独では、利用しているサービス連携に問題がない場合であっても、他の企業への影響を与える場合を検出できるため、有益である。
【0039】
また、前記推定部は、3以上のサービスについての連携を、前記複数のサービス連携ルールのうち利用中のものとして推定するとよい。これにより、複雑なサービスの連携の連鎖によるループについて検出でき、有益である。
【0040】
図3は、本発明の実施の形態2にかかるサービス連携管理システム1000の構成を示すブロック図である。サービス連携管理システム1000は、サービス連携提供ネットワーク10と、サービス提供企業X1ネットワーク21と、サービス提供企業X2ネットワーク22と、企業Y1ネットワーク31と、企業Y1ネットワーク32とを備え、それぞれインターネットNを介して接続されている。
【0041】
尚、サービス連携ルール群11、連携ルール111及び112、サービス提供企業X1ネットワーク21及びサービス提供企業X2ネットワーク22、並びに、サービスA211及びサービスB221は、
図9と同等であるため詳細な説明を省略する。尚、本実施の形態では、サービス連携ルール群11に含まれる連携ルールは3以上であってもよい。また、サービスの種類の3以上であってよい。併せて、サービス提供企業も3以上であってもよい。また、1つのサービス提供企業が2以上のサービスを提供してもよい。尚、本実施の形態にかかる「サービス」とは、例えば、SOAP(Simple Object Access Protocol)を用いたWebサービス等が挙げられるが、これに限定されない。本実施の形態にかかるサービスは、提供元が所定のインタフェースを不特定多数に対して開示し、ネットワークを介した当該所定のインタフェースに基づくアクセスに対して特定のアプリケーション等の処理結果を提供するものであればよい。
【0042】
サービス連携提供ネットワーク10は、サービス連携ルール群11に加え、サービス連携管理装置12を備える。尚、サービス連携ルール群11は、サービス連携管理装置12内の記憶装置に保持されているか、サービス連携管理装置12とは別のサーバ装置等により保持されているものとする。
【0043】
サービス連携管理装置12は、サービスA211及びサービスB221を含む複数のサービスの連携を管理するためのコンピュータ装置である。尚、サービス連携管理装置12は、複数台のコンピュータ装置で実現しても構わない。サービス連携管理装置12は、定められた一定期間毎に、次の処理を実行する。
(1)サービス連携ルール群11内に登録済みの連携ルールを、予め取得しておく。
(2)(1)で取得した連携ルールに基づく全てのイベント情報を収集する。
(3)収集されたイベント情報を元に、データの流れを分析し、現在利用されているサービス連携を推定する。
上記(1)〜(3)の処理について以下の構成により説明する。
【0044】
サービス連携管理装置12は、イベント収集部121と、分析部122と、サービス連携推定情報保持部123とを備える。イベント収集部121は、上述した収集部110の一例である。まず、イベント収集部121は、一定の周期でサービス連携ルール群11内に登録済みの連携ルールの全てを取得し、内部の記憶領域(不図示)に保存する。その後、イベント収集部121は、取得した連携ルール内に定義された各サービスを特定し、特定したサービスにより発生するイベントを特定する。そして、イベント収集部121は、特定した各サービスのWebAPI経由で、特定した各イベントを監視し、イベント発生時にイベント情報を収集し、内部の記憶領域に保存する。ここで、イベント情報は、XML(Extensible Markup Language)形式で得られるものとする。
【0045】
図4は、本発明の実施の形態2にかかる地図情報データサービスにおけるイベント情報の例を示す図である。ここでは、地図情報データサービスにおけるあるイベントにおいては、要素「経度」、「緯度」及び「範囲」について各要素値が含まれることを示す。また、
図5は、本発明の実施の形態2にかかる渋滞情報データサービスにおけるイベント情報の例を示す図である。ここでは、渋滞情報データサービスにおけるあるイベントにおいては、要素「経度」、「緯度」及び「取得範囲」について各要素値が含まれることを示す。
【0046】
分析部122は、上述した推定部120及び格納部の一例である。分析部122は、予めイベント収集部121から各連携ルールのサービス連携におけるサービス間のデータの対応情報を取得し、内部の記憶領域(不図示)に保存する。ここで、サービス間のデータの対応情報とは、「トリガ:サービスA、アクション:サービスB」という連携において、サービスAの要素A−1の値とサービスBの要素B−1の値が対応付けられ、サービスAの要素A−2の値とサービスBの要素B−2の値が対応付けられる、という情報である。
【0047】
図6は、本発明の実施の形態2にかかるサービス連携における要素間の対応情報の例を示す図である。ここでは、例えば、連携元の「地図情報データサービス」における要素「経度」、「緯度」及び「範囲」の各要素値と、連携先の「渋滞データサービス」における要素「経度」、「緯度」及び「取得範囲」の各要素値とが、それぞれ対応付けられていることを示す。
【0048】
そして、分析部122は、イベント収集部121にて収集及び保存された各イベント情報をイベントが発生した時刻を加味してデータの流れを分析し、現在利用されているサービス連携の推定を行う。そして、分析部122は、推定されたサービス間の連携を示す情報をサービス連携推定情報保持部123に格納する。
【0049】
サービス連携推定情報保持部123は、記憶装置の一例である。サービス連携推定情報保持部123は、分析部122により推定情報1231が格納される。推定情報1231は、分析部122により推定されたサービス間の連携を示すサービス連携推定情報である。
【0050】
サービス連携装置313及び323は、第1及び第2のサービス利用装置の一例である。本実施の形態2にかかるサービス連携装置313はサービス連携追加判定部314をさらに備え、連携ルール312に基づくサービス連携が利用されている。サービス連携追加判定部314は、サービス連携装置313に新たなサービス連携ルールを追加する際に、推定情報1231を元に、対象のサービス連携を追加できるかどうかを判断する。すなわち、サービス連携追加判定部314は、新たなサービス連携ルールの追加要求を受け付けた場合に、サービス連携推定情報保持部123から推定情報1231を取得し、当該新たなサービス連携ルールの追加によりデータの流れにループが生じるか否かを判定し、ループが生じないと判定した場合に当該追加要求を許可し、ループが生じると判定した場合に当該追加要求を拒否する旨を要求元へ応答する追加判定処理を行なう。
【0051】
また、本実施の形態2にかかるサービス連携装置323はサービス連携追加判定部324をさらに備えるものとする。サービス連携追加判定部324は、サービス連携追加判定部314と同等の処理を行なう。
【0052】
図7は、本発明の実施の形態2にかかるサービス連携管理装置のサービス連携推定処理の流れを示すフローチャートである。尚、以下の例では、運送会社Y1と運送会社Y2があり、配送経路決定のため、地図情報を公開するサービスと渋滞情報を公開するサービスを利用する場合の動作の説明を行う。運送経路決定という観点で、地図情報データと渋滞情報データは密接に関連し、同時に取得するというニーズがあると考えられるためである。ここではすでに運送会社Y1が、「トリガ:地図情報データサービス、アクション:渋滞情報データサービス」というサービス連携を利用しているものとする。
【0053】
[ステップS11]サービス連携ルール一覧取得
イベント収集部121は、イベント収集の対象となるサービスを決める必要がある。従って、イベント収集部121は、サービス連携ルール群11として定義されているルール一覧を取得する。ここでは、イベント収集部121は、連携ルール111及び112を取得する。そして、分析部122は、予めイベント収集部121経由で各連携ルールのサービス間のデータの対応情報を取得しておく。尚、対応情報は、各連携ルールから抽出又は生成しても構わない。
【0054】
この後、一定の時間間隔で[ステップS12]〜[ステップS14]を繰り返す。
【0055】
[ステップS12]サービスのイベント収集
イベント収集部121は、イベント収集対象のサービスのイベント取得用のAPIを利用して、イベントを取得し、保持する。
【0056】
[ステップS13] サービス連携推定
イベント収集部121が収集したイベント情報を元に、各種データ連携によって生じているデータフローを分析し、サービス連携の推定を行う。今、運送会社Y1が、「トリガ:地図情報データサービス、アクション:渋滞情報データサービス」というサービス連携を利用している。しかし、このことをサービス連携管理装置12は直接的には知らないという状態である。
【0057】
この状態で、以下のようなデータフローの分析により、利用されているサービス連携を、間接的に推定する。
【0058】
[ステップS131]
分析部122は、ある時刻t1に地図情報データサービス及び渋滞情報データサービスのイベント発生有無を確認する。この時、地図情報データサービスのイベントを検知した場合、分析部122は、そのXMLファイルから、渋滞情報データサービスと対応付けられた「経度」「緯度」及び「範囲」タグの値を取得する。仮にこれらの値がそれぞれx1、y1、w1であったとする。
【0059】
[ステップS132]
分析部122は、次のイベント発生有無確認の時刻t2に再度、地図情報データサービス及び渋滞情報データサービスのイベント発生有無を確認する。この時、分析部122は、渋滞情報データサービスのイベントを検知し、そのXMLファイルから得られる情報が、x1、y1、w1であった場合、このイベントはステップS31で検知したイベントをトリガとして発生している、つまり、「トリガ:地図情報データサービス、アクション:渋滞情報データサービス」というサービス連携が利用されているということが推定できる。
【0060】
[ステップS14]サービス連携推定情報の保存
分析部122は、データフローの分析により推定されたサービス連携を推定情報1231としてサービス連携推定情報保持部123に保存する。具体的には、推定されるサービス連携を[連携元]から[連携先]というような形で保存しておく。上記のステップS3の例では[地図情報データサービス]から[渋滞情報データサービス]という情報を保持する。尚、この連携は2つのサービスに限らず、複数のサービスの連携についても表現できる。例えば、[サービスA]、[サービスB]、[サービスC]、[サービスD]の連携順序を推定情報としてもよい。
【0061】
図8は、本発明の実施の形態2にかかるサービス連携装置の連携ルール追加処理の流れを示すフローチャートである。
【0062】
[ステップS21]ユーザによるサービス連携ルール追加要求の受付
サービス連携追加判定部324は、ユーザによるサービス連携ルールを新たに追加して利用するための追加要求を受け付けた場合、以下のステップS22からS26により、連携ルールの追加又は拒否を行う。
【0063】
[ステップS22]サービス連携推定情報の取得
サービス連携追加判定部324は、サービス連携管理装置12のサービス連携推定情報保持部123から、現在の推定情報1231を取得する。
【0064】
[ステップS23]ループの追跡
サービス連携追加判定部324は、ステップS22で取得した推定情報1231とステップS21で受け付けた新たなサービス連携ルールとを用いて、以下の処理によりループの追跡を行なう。
【0065】
サービス連携追加判定部324は、追加要求として受け付けたサービス連携ルールのうちトリガとして指定されたサービス及び要素値をアクションとするサービスが、推定情報1231の中に存在するか否かを判定する(S231)。また、サービス連携追加判定部324は、追加要求として受け付けたサービス連携ルールのうちアクションとして指定されたサービス及び要素値をトリガとするサービスが、推定情報1231の中に存在するか否かを判定する(S232)。そして、ステップS231及びS232を満たす1つのサービスが存在する場合、ループとなり得ると判定する(S233)。また、ステップS231及びS232を満たすサービスが異なる場合には、各サービスと連携するサービスを検索し、同一のサービスに辿り着く場合にも、ループとなり得ると判定する(S234)。
【0066】
[ステップS24〜S26]ループの有無に基づき連携ルールの追加又は許否
サービス連携追加判定部324は、ステップS23の結果、ループの有無を判定する(S24)。ループが存在しない場合、サービス連携追加判定部324は、サービス連携装置323に追加要求されたサービス連携ルールを追加する(S26)。一方、ループが存在する場合、サービス連携追加判定部324は、サービス連携装置323への新たなサービス連携ルールの追加をせず、その旨をユーザに通知する(S25)。
【0067】
例えば、仮に企業Y2のユーザが新たに「トリガ:渋滞情報データサービス、アクション:地図情報データサービス」(企業Y1で利用されている連携ルールと逆のルール)を追加するものとする。この場合、サービス連携がループすると判定され、新たなサービス連携ルールの追加は行われない。尚、企業Y1と同じく、「トリガ:地図情報データサービス、アクション:渋滞情報データサービス」の追加であれば、ループが発生することがないため、追加される。
【0068】
このように、本実施の形態2により、複数のサービス連携を管理する装置が、明示的にサービス連携ルールを知らされない場合においても、データのループを防止することが可能となる。
【0069】
<その他の実施の形態>
尚、前記推定部が複数のサービス間の連携を推定した場合に、前記データの流れにループが生じるか否かを判定する判定部、をさらに備えてもよい。例えば、サービス連携管理装置内で、サービス連携の利用実態からループを検出できるため、ループを早急に特定し、対策を取ることができる。
【0070】
また、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、任意の処理を、CPU(Central Processing Unit)にコンピュータプログラムを実行させることにより実現することも可能である。
【0071】
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、CD−ROM(Read Only Memory)、CD−R、CD−R/W、DVD(Digital Versatile Disc)、BD(Blu-ray(登録商標) Disc)、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(Random Access Memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。