(57)【要約】【課題】連携サービスに新サービスおよび新ＡＰＩを追加する際の追従コストを低減させる。【解決手段】サービス連携装置１は、サービス（Ｄ社ネットワーク２−１、Ａ社クラウド２−２、アプリＡ２−３、および、Ｂ社クラウド２−４）ごとに用意され、当該サービスの仕様を定義したカタログ（Ｄ社カタログ３−１、Ａ社カタログ３−２、アプリＡカタログ３−３、および、Ｂ社カタログ３−４）を記憶する記憶部と、連携サービスを構成するサービスのカタログの組合せとなる連携カタログ（４−１，４−２）を作成し、記憶部に記憶するカタログ管理部３０と、連携サービスに対する要求があった場合、連携カタログ内のカタログの内容を解釈するカタログ解釈実行部１０と、サービスごとに用意され、連携サービスを構成するサービスのＡＰＩを実行して、要求を処理するアダプタ部（２０−１〜２０−４）と、を備える。【選択図】図１
2018206050.tif 000002
【特許請求の範囲】
【請求項１】
複数種類のサービスを連携させた連携サービスを実行するサービス連携装置であって、
前記サービスごとに用意され、当該サービスの仕様を定義したカタログを記憶する記憶部と、
前記連携サービスを構成するサービスのカタログの組合せとなる連携カタログを作成し、前記記憶部に記憶するカタログ管理部と、
前記連携サービスに対する要求があった場合、前記連携カタログ内の前記カタログの内容を解釈するカタログ解釈実行部と、
前記サービスごとに用意され、前記連携サービスを構成するサービスのＡＰＩ（Application Programmable Interface）を実行して、前記要求を処理するアダプタ部と、を備える、
ことを特徴とするサービス連携装置。
【請求項２】
前記カタログ管理部は、
前記連携サービスを構成するサービスのカタログの各々を、当該サービスの提供状態を示したProductOffering、および、当該サービスの仕様を示したProductSpecificationを含むプロダクトカタログとして前記記憶部に記憶し、
前記連携カタログを、前記連携サービスを構成するサービスの前記プロダクトカタログを纏めたFederatedプロダクトカタログとして前記記憶部に記憶するとともに、当該連携サービスを構成するサービスの前記プロダクトカタログをSourceプロダクトカタログとして前記記憶部に記憶する、
ことを特徴とする請求項１に記載のサービス連携装置。
【請求項３】
前記カタログ管理部は、
前記連携サービスを構成するサービス間の連携を設定するルールを、前記連携カタログに含めて管理する、
ことを特徴とする請求項１または請求項２に記載のサービス連携装置。
【請求項４】
前記ルールは、
前記連携サービスを構成するサービスごとの処理順序を規定する、
ことを特徴とする請求項３に記載のサービス連携装置。
【請求項５】
前記ルールは、
前記連携サービスを構成する第１のサービスへの要求に対する応答値を、前記連携サービスを構成する第２のサービスに流通させることの要否を規定する、
ことを特徴とする請求項３に記載のサービス連携装置。
【請求項６】
前記ルールは、
前記連携サービスを構成するサービスごとに、前記アダプタ部の起動条件を定義して、前記アダプタ部の呼び出し契機を規定する、
ことを特徴とする請求項３に記載のサービス連携装置。
【請求項７】
前記ルールは、
前記連携サービスを構成するサービスの仕様値を用いて、当該連携サービスの仕様値を規定する、
ことを特徴とする請求項３に記載のサービス連携装置。
【請求項８】
複数種類のサービスを連携させた連携サービスを実行するサービス連携装置における連携サービス実行方法であって、
前記サービス連携装置は、
前記サービスごとに用意され、当該サービスの仕様を定義したカタログを用いて、当該カタログを組み合わせた連携カタログを記憶部に記憶しており、
前記連携サービスに対する要求があった場合、前記連携カタログ内の前記カタログの内容を解釈するステップと、
前記サービスごとに用意されたアダプタ部の各々に、前記連携サービスを構成するサービスのＡＰＩを実行させて、前記要求を処理させるステップと、を実行する、
ことを特徴とする連携サービス実行方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス連携装置およびサービス連携方法に関する。
【背景技術】
【０００２】
非特許文献１には、「卸サービスを提供している事業者のネットワーク及びクラウド，アプリを組合せ，連携させたサービスをサービス事業者が一括で構築するための方式／アーキテクチャ」について開示されている。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】高橋謙輔、他４名、“B2B2Xにおける複数事業者間サービス設定連携方式”、電子情報通信学会大会講演論文集  CD-ROM、日本、2016年09月06日、巻：2016、号：ソサイエティ大会、ページ：ROMBUNNO.B‐14‐10
【発明の概要】
【発明が解決しようとする課題】
【０００４】
複数種類のサービスが連携された連携サービスに新サービスおよび新ＡＰＩ（Application Programmable Interface）を追加する際、従来では、連携サービスを実行する装置の追加開発が必要となる。このような追加開発は、サービスおよびＡＰＩの追加の度に行われ、新サービスや新ＡＰＩの追従コストが膨大になるという問題がある。非特許文献１には、このような問題への対策について記載も示唆もない。
【０００５】
本発明は、このような事情に鑑みて、連携サービスに新サービスおよび新ＡＰＩを追加する際の追従コストを低減させることを課題とする。
【課題を解決するための手段】
【０００６】
前記課題を解決するために、請求項１に記載の発明は、複数種類のサービスを連携させた連携サービスを実行するサービス連携装置であって、前記サービスごとに用意され、当該サービスの仕様を定義したカタログを記憶する記憶部と、前記連携サービスを構成するサービスのカタログの組合せとなる連携カタログを作成し、前記記憶部に記憶するカタログ管理部と、前記連携サービスに対する要求があった場合、前記連携カタログ内の前記カタログの内容を解釈するカタログ解釈実行部と、前記サービスごとに用意され、前記連携サービスを構成するサービスのＡＰＩ（Application Programmable Interface）を実行して、前記要求を処理するアダプタ部と、を備える、ことを特徴とする。
【０００７】
また、請求項８に記載の発明は、複数種類のサービスを連携させた連携サービスを実行するサービス連携装置における連携サービス実行方法であって、前記サービス連携装置は、前記サービスごとに用意され、当該サービスの仕様を定義したカタログを用いて、当該カタログを組み合わせた連携カタログを記憶部に記憶しており、前記連携サービスに対する要求があった場合、前記連携カタログ内の前記カタログの内容を解釈するステップと、前記サービスごとに用意されたアダプタ部の各々に、前記連携サービスを構成するサービスのＡＰＩを実行させて、前記要求を処理させるステップと、を実行する、ことを特徴とする。
【０００８】
請求項１，８によれば、カタログおよびアダプタ部を、サービスごとに用意し、新サービスおよび新ＡＰＩの追加があった場合には、当該新サービスおよび新ＡＰＩに対応する新カタログおよび新アダプタ部を用意する。よって、従来のように、サービス連携装置の追加開発を必要とすることはなく、例えば、カタログ解釈実行部の改変は不要である。
したがって、連携サービスに新サービスおよび新ＡＰＩを追加する際の追従コストを低減させることができる。
【０００９】
また、請求項２に記載の発明は、請求項１に記載のサービス連携装置であて、前記カタログ管理部は、前記連携サービスを構成するサービスのカタログの各々を、当該サービスの提供状態を示したProductOffering、および、当該サービスの仕様を示したProductSpecificationを含むプロダクトカタログとして前記記憶部に記憶し、前記連携カタログを、前記連携サービスを構成するサービスの前記プロダクトカタログを纏めたFederatedプロダクトカタログとして前記記憶部に記憶するとともに、当該連携サービスを構成するサービスの前記プロダクトカタログをSourceプロダクトカタログとして前記記憶部に記憶する、ことを特徴とする。
【００１０】
請求項２によれば、プロダクトカタログに階層構造を持たせることができ、連携サービスを透過的にすることができる。
【００１１】
また、請求項３に記載の発明は、請求項１または請求項２に記載のサービス連携装置であって、前記カタログ管理部は、前記連携サービスを構成するサービス間の連携を設定するルールを、前記連携カタログに含めて管理する、ことを特徴とする。
【００１２】
請求項３によれば、連携カタログの構成要素となるカタログ（群）にルールを追加可能とし、構成要素とルールとを分離することで、汎用性の高い連携サービスの実体を構成することができる。
【００１３】
また、請求項４に記載の発明は、請求項３に記載のサービス連携装置であて、前記ルールは、前記連携サービスを構成するサービスごとの処理順序を規定する、ことを特徴とする。
【００１４】
請求項４によれば、サービスの種類によらずに、サービスごとの処理順序をルールに記載することができるため、連携サービスを汎用化させることができる。
【００１５】
また、請求項５に記載の発明は、請求項３に記載のサービス連携装置であて、前記ルールは、前記連携サービスを構成する第１のサービスへの要求に対する応答値を、前記連携サービスを構成する第２のサービスに流通させることの要否を規定する、ことを特徴とする。
【００１６】
請求項５によれば、サービスの種類によらずに、応答値の流通要否をルールに記載することができるため、連携サービスを汎用化させることができる。
【００１７】
また、請求項６に記載の発明は、請求項３に記載のサービス連携装置であて、前記ルールは、前記連携サービスを構成するサービスごとに、前記アダプタ部の起動条件を定義して、前記アダプタ部の呼び出し契機を規定する、ことを特徴とする。
【００１８】
請求項６によれば、アダプタ部の呼び出しを制御し、既存のサービスおよび既存のカタログに対して、新サービスおよび新カタログを、既存のサービスおよび既存のカタログに何ら影響を与えることなく追加することができる。このため、連携サービスにおいて、新サービスおよび新ＡＰＩの柔軟な導入を実現することができる。
【００１９】
また、請求項７に記載の発明は、請求項３に記載のサービス連携装置であて、前記ルールは、前記連携サービスを構成するサービスの仕様値を用いて、当該連携サービスの仕様値を規定する、ことを特徴とする。
【００２０】
請求項７によれば、連携サービスを構成するサービスの仕様値を隠蔽することができるとともに、連携サービスとしての特性を、連携サービスの作成者ごとに生成することができ、連携サービスの生成を柔軟に実現することができる。
【発明の効果】
【００２１】
本発明によれば、連携サービスに新サービスを追加する際の追従コストを低減させることができる。
【図面の簡単な説明】
【００２２】
【図１】本実施形態のサービス連携装置の機能構成図の例である。
【図２】プロダクトカタログの構成の例を示す図である。
【図３】Sourceプロダクトの生成数の指定に関する説明図であり、（ａ）は、ProductOrderリソースの階層構造を示す図、（ｂ）は、Federatedプロダクトカタログの構成を示す図である。
【図４】カタログに含まれるルールの記載例である。
【図５】連携サービスに対する要求の処理を示すフローチャートである。
【図６】新サービスが追加されたときの処理を示すフローチャートである。
【発明を実施するための形態】
【００２３】
続いて、本発明の実施形態について、図面を参照して説明する。
【００２４】
≪構成≫
図１に示すように、本実施形態のサービス連携装置１は、複数種類のサービスを連携させた連携サービスを実行する装置である。サービス連携装置１は、入出力用のＩ／Ｆ（インターフェイス）などで構成される入出力部（図示略）、ハードディスク、フラッシュメモリ、ＲＡＭ（Random Access Memory）などで構成される記憶部（図示略）、ＣＰＵ（Central Processing Unit）などで構成される制御部（図示略）といったハードウェアを備えるコンピュータである。制御部は、例えば、記憶部に記憶されているプログラムを記憶部の記憶領域に展開し実行することにより、上記の処理が実行される。本実施形態のサービス連携装置１は、このようなソフトウェアとハードウェアの協働を実現することができる。
【００２５】
図１には、複数種類のサービスとして、Ｄ社ネットワーク２−１、ＩａａＳ（Infrastructure as a Service）またはＰａａＳ（Platform as a Service）のＡ社クラウド２−２、アプリＡ２−３（「アプリ」はアプリケーションの略）、および、ＩａａＳまたはＰａａＳのＢ社クラウド２−４が示されている。Ｄ社ネットワーク２−１は、卸サービス事業者であるＤ社が提供するサービスである。Ａ社クラウド２−２およびアプリＡ２−３は、卸サービス事業者であるＡ社が提供するサービスである。Ｂ社クラウド２−４は、卸サービス事業者であるＢ社が提供するサービスである。しかし、本発明で取り扱うサービスの種類はこれらに限定されない。
【００２６】
本実施形態では、Ｄ社ネットワーク２−１、Ａ社クラウド２−２、および、アプリＡ２−３が連携して１つの連携サービスをすでに構成しているとする。Ｂ社クラウド２−４は、新たに追加される新サービスである。結果的に、Ｂ社クラウド２−４を用いた新たな連携サービスを構成することができる。
【００２７】
サービス連携装置１は、カタログ解釈実行部１０と、アダプタ部２０−１〜２０−４と、カタログ管理部３０と、を備える。
【００２８】
（カタログ管理部３０）
カタログ管理部３０は、サービスの仕様を定義したカタログを管理する。カタログは、例えば、サービス連携装置１の記憶部に記憶されている。図１には、Ｄ社ネットワーク２−１、Ａ社クラウド２−２、アプリＡ２−３、および、Ｂ社クラウド２−４の各々のカタログとして、Ｄ社カタログ３−１、Ａ社カタログ３−２、アプリＡカタログ３−３、および、Ｂ社カタログ３−４が示されている。しかし、本発明で取り扱うカタログの種類はこれらに限定されない。本実施形態では、Ｄ社カタログ３−１、Ａ社カタログ３−２、および、アプリＡカタログ３−３は、すでに存在しており、Ｂ社カタログ３−４が新たに用意されたとする。カタログは、サービスごとに用意されており、Ｂ社クラウド２−４にようにサービスが新たに追加された場合には、当該サービスに対応するカタログが用意され、カタログ管理部３０によって管理される。
【００２９】
カタログ管理部３０は、連携サービスを構成するサービスのカタログを複数組み合わせることで、連携サービス用のカタログとなる連携カタログを作成し、記憶部に記憶することができる。図１に示すように、カタログ管理部３０は、Ｄ社カタログ３−１、Ａ社カタログ３−２、および、アプリＡカタログ３−３を組み合わせた連携カタログ４−１を作成し、記憶部に記憶する。連携カタログ４−１は、Ｄ社ネットワーク２−１、Ａ社クラウド２−２、および、アプリＡ２−３による連携サービスの仕様を定義する。また、カタログ管理部３０は、Ｄ社カタログ３−１、Ａ社カタログ３−２、および、新たに追加されたＢ社カタログ３−４を組み合わせた連携カタログ４−２を作成し、記憶部に記憶する。連携カタログ４−２は、Ｄ社ネットワーク２−１、Ａ社クラウド２−２、および、Ｂ社クラウド２−４による連携サービスの仕様を定義する。
【００３０】
また、カタログ管理部３０は、すでに存在する連携カタログ４−１にＢ社カタログ３−４を追加して、Ｄ社ネットワーク２−１、Ａ社クラウド２−２、アプリＡ２−３、および、Ｂ社クラウド２−４による連携サービスの仕様を定義することができる。
また、連携カタログ４−１，４−２はそれぞれ、ルール４−１ａ，４−２ａを含む。ルール４−１ａ，４−２ａの説明は、後記する。
【００３１】
（カタログ解釈実行部１０）
カタログ解釈実行部１０は、卸サービス事業者等の顧客の顧客装置から、連携サービスに対する要求があった場合に、当該連携サービスの連携カタログ内のカタログの内容を解釈して要求を処理する。カタログ解釈実行部１０は、連携カタログを構成するすべてのカタログを解釈して要求を処理することになり、カタログに対応するサービスの各々に依存しない、サービス間共通の処理を実行する機能部といえる。
【００３２】
（アダプタ部２０−１〜２０−４）
アダプタ部２０−１〜２０−４は、連携サービスを構成するサービスのＡＰＩを実行して、要求を処理する。アダプタ部２０−１〜２０−４は、サービスごとに用意されており、Ｂ社クラウド２−４にようにサービスが新たに追加された場合には、サービス連携装置１は、アダプタ部２０−４のように新たなアダプタ部を追加して備える。ＡＰＩは、対応のサービスが導入されたときには公開されているとする。アダプタ部２０−１〜２０−４は、サービスの各々に依存して要求を処理する機能部といえる。
【００３３】
本実施形態のサービス連携装置１によれば、Ｂ社クラウド２−４のような新たなサービスを連携サービスの連携対象にしたい場合には、対応のカタログ（Ｂ社カタログ３−４）および対応のアダプタ部（アダプタ部２０−４）を用意するだけでよい。よって、従来のように、装置全体の追加開発を必要とせず、連携サービスに新サービスおよび新ＡＰＩを追加する際の追従コストを低減させることができる。
また、本実施形態のサービス連携装置１によれば、カタログを用いることで、連携サービスを構成するサービス群を、カタログドリブンな疎結合アーキテクチャとして構成することができる。
【００３４】
＜プロダクトカタログ＞
サービス連携装置１は、連携サービスを構成するサービスのカタログを、プロダクトカタログとして保持する（記憶部に記憶する）ことができる。プロダクトカタログは、対応のサービスの提供状態（運用中、停止中など）を示したProductOfferingと、サービスの仕様（サービスの品質、具体的態様など）を示したProductSpecificationとを含む。プロダクトカタログは、TMF（TeleManagement Forum）620やTMF622などに規定される語であるが、TMF620やTMF622などに準拠するか否かにかかわらず、サービス連携装置１は、プロダクトカタログを保持することができる。
【００３５】
カタログを、プロダクトカタログとして保持する場合、カタログ管理部３０は、連携サービスを構成する各サービスのプロダクトカタログを纏める（bundle）ことで、連携カタログを作成、管理することができる。サービス連携装置１は、連携サービスの連携カタログを、サービスのカタログと同様、ProductOfferingとProductSpecificationとを含むプロダクトカタログとして保持することができる。カタログ管理部３０による連携カタログの管理によれば、連携サービスを、各サービスの申込みや提供サービスに関する内容を透過的に連携したサービスとすることができる。「透過的」とは、サービス事業者に対して連携したサービスを提供する際でも、bundleされたプロダクトカタログの提供、および、申込みにおける該当プロダクトへのcharacteristic設定（該当プロダクトの特性を設定）を可能とする意味である。
【００３６】
なお、bundleした（結果の）プロダクトカタログを、「Federatedプロダクトカタログ」と称し、bundleしたプロダクトは、「Federatedプロダクト」と称する。Federatedプロダクトの内容は、Federatedプロダクトカタログで記述される。また、bundleされた（bundleの対象となる）プロダクトカタログを、「Sourceプロダクトカタログ」と称し、bundleされたプロダクトは、「Sourceプロダクト」と称する。Sourceプロダクトの内容は、Sourceプロダクトカタログで記述される。
【００３７】
FederatedプロダクトカタログとSourceプロダクトカタログとの関係は、例えば、図２に示すように表現することができる。Federatedプロダクトカタログは、productOfferingリソース１００ａと、productSpecificationリソース１００ｂとを含む。また、productOfferingリソース１００ａに対して、サービス（群）Ａ，Ｂに対応する２つのbundledProductOfferingリソース１００ｃ，１００ｄが従属する。サービス（群）Ａ，Ｂはそれぞれ、Federatedプロダクトカタログを構成する少なくとも１つのカタログを用いて定義される別個の連携サービスである。
【００３８】
サービス（群）ＡのSourceプロダクトカタログは、bundledProductOfferingリソース１００ｃを参照する。サービス（群）ＡのSourceプロダクトカタログは、productOfferingリソース１０１ａと、productSpecificationリソース１０１ｂとを含む。サービス（群）ＢのSourceプロダクトカタログは、bundledProductOfferingリソース１００ｄを参照する。サービス（群）ＢのSourceプロダクトカタログは、productOfferingリソース１０２ａと、productSpecificationリソース１０２ｂとを含む。
図２に示すように、プロダクトカタログに階層構造を持たせることで、連携サービスを透過的にすることができる。
【００３９】
＜Sourceプロダクトの生成数の指定＞
申込者が、Federatedプロダクトカタログを指定して、Federatedプロダクトの申込みを行うことで、該当FederatedプロダクトにbundleされたSourceプロダクトも含めたサービス申込み（連携サービスの申込み）を一括で行うすることができる。このとき、カタログ管理部３０は、Federatedプロダクトの申込み時に、申込みするFederatedプロダクトのProductOrderリソースの構成において、該当FederatedプロダクトにbundleされたSourceプロダクトの生成数を指定することができる。
【００４０】
具体的には、後記する図３において説明するように、ProductOrderリソース中のorderItem.productOfferingが持つbundledProductOfferingに生成対象のSourceプロダクトカタログを指定するとともに、orderItem.productが持つproductRelationshipに該当Sourceプロダクトのcharacteristicを指定することで、Sourceプロダクトの生成を判断する。同一Sourceプロダクトを複数生成する場合には、それぞれorderItem.productOffering.bundledProductOffering、および、orderItem.product.productRelationshipを複数設定し、リストする。このような手順で、Sourceプロダクトの生成数を指定することができる。
【００４１】
図３（ａ）に示すように、ProductOrderリソース２００は、orderItemリソース２０１を含む。orderItemリソース２０１は、productOfferingリソース２０２ａと、productリソース２０２ｂとを含む。productOfferingリソース２０２ａは、bundledProductOfferingリソース２０３ａ〜２０３ｃを含む。productリソース２０２ｂは、ProductRelationshipリソース２０４ａ〜２０４ｃを含む。図３（ｂ）に示すように、bundledProductOfferingリソース２０３ａ〜２０３ｃはそれぞれ、異なるサービス（群）のSourceプロダクトカタログ［１］〜［３］によって参照される。
【００４２】
カタログ管理部３０は、例えば、Sourceプロダクト［１］の生成数を２と指定する。すると、図３（ａ）にて、bundledProductOfferingリソース２０３ａ，２０３ｂに対してSourceプロダクト［１］が２リソース分生成される。このとき、２つのSourceプロダクト［１］は、ProductRelationshipリソース２０４ａ，２０４ｂに対応する。
また、カタログ管理部３０は、例えば、Sourceプロダクト［３］の生成数を１と指定する。すると、図３（ａ）にて、bundledProductOfferingリソース２０３ｃに対してSourceプロダクト［３］が１リソース分生成される。このとき、１つのSourceプロダクト［３］は、ProductRelationshipリソース２０４ｃに対応する。
また、カタログ管理部３０は、例えば、Sourceプロダクト［２］の生成数を０と指定すると、Sourceプロダクト［２］を生成しない。
【００４３】
上記のように、FederatedプロダクトにbundleされたSourceプロダクトの生成数を指定することで、柔軟な連携サービスを実現することができる。
なお、SourceプロダクトおよびSourceプロダクトカタログに対してそれぞれ、さらにSourceプロダクトおよびSourceプロダクトカタログをbundleすることもでき、その結果、FederatedプロダクトおよびFederatedプロダクトカタログ全体として多段でSourceプロダクトおよびSourceプロダクトカタログをbundleすることもできる。
【００４４】
＜サービス（群）間の連携動作の設定＞
複数のサービス（群）を連携したFederatedプロダクト（連携サービス）を提供する場合、基本的には、サービス（群）間（Sourceプロダクト間）を連携動作させるための設定処理が必要となる。この設定処理は、カタログ管理部３０が、Federatedプロダクトのプロダクト設計時に、各Sourceプロダクト間の連携のための設定処理を動作可能とするルール設定（Bundle Rule）をFederatedプロダクトカタログ上に定義することで実現することができる。
【００４５】
例えば、第１、第２のＶＰＣ（Virtual Private Cloud）（サービス（群）の具体例）に対してＶＰＣピアリング設定を行う場合には、Federatedプロダクトカタログ上に定義するBundle Ruleにて、第１のSourceプロダクトのパラメータを、第２のSourceプロダクトに通知すると記述する。これにより、第１のＶＰＣが第２のＶＰＣにＶＰＣピアリング設定要求をした後、第２のＶＰＣが第１のＶＰＣにＶＰＣピアリング受諾要求をする、という順序で連携動作させることができる。
【００４６】
≪汎用的なカタログ記述方法≫
カタログ管理部３０が連携カタログを作成する際、連携カタログの記述方法として、連携カタログの構成要素とルール（図１中ルール４−１ａ，４−２ａに相当）とを分離することが有用である。ここで、連携カタログの「構成要素」とは、連携サービスを構成する各サービスのカタログを指す。構成要素として、各サービスの性能（例えば、ＣＰＵコア数、メモリ）を含めてもよい。
【００４７】
また、連携カタログの「ルール」とは、連携サービスを構成する各サービス間の連携動作に関する規定を指す。先述した、Bundle Ruleもルールの一例である。ルールとして、連携動作の対象となる構成要素を特定する規定を含めることもできる。したがって、連携カタログ中の構成要素の全部または一部を対象にした連携動作についてのルールを作成することができる。また、１つの連携カタログに複数のルールを含めることもでき、１つの連携サービスに、１または複数のルールを適用することができる。
【００４８】
よって、１つの連携カタログに含まれる構成要素およびルールを選択的に組み合わせることで、対応する連携サービスの実体を複数種類構成することができる。このように、本実施形態の連携カタログは、構成要素とルールとを分離することで、汎用性の高い連携サービスの実体を構成することができる。
なお、従来のカタログは、上記の構成要素とルールが実質的に混在した記述内容なっていたため、連携サービスの実体に汎用性を持たせることができなかった。
【００４９】
また、連携サービスの実体は、汎用化されたとはいえ、連携カタログ中のルールは統一的な記法で記述されている。よって、カタログ解釈実行部１０が連携カタログを解釈するために用意するオーダシナリオは１つで済ませることができる。オーダシナリオは、サービス連携装置１がオーダ（要求）を処理する際、ルールを解釈してそのルールの通りに実行可能なものとすることができる。異なるルールが適用される複数種類の連携サービスがあっても、ルールの記法が統一されているため、同じオーダシナリオでオーダを実行することができる。
なお、従来の連携サービス用のカタログは、もともとルールを含めていなかったため、ルールの記法を統一的にする余地はなかった。このため、連携サービスごとにオーダシナリオを用意する必要があり、オーダの実行に関する汎用性が低かった。
【００５０】
また、本実施形態では、構成要素とルールとの分離は、連携カタログのみならず、個々のサービスのカタログに対しても適用することができる。この場合、各サービスのカタログの構成要素は、例えば、仮想マシン（ＶＭ：Virtual Machine）やネットワーク機能があるが、これらに限定されない。
【００５１】
≪連携カタログのルールの詳細≫
図１中ルール４−１ａ，４−２ａなどのルールの記載例を図４に示す。図４によれば、ルールは、例えば、Attributeカラム、Qualifierカラム、Cardinalityカラム、Contentカラムといった４つのカラムからなる。
Attributeカラムに含まれる要素は、BundleRule、SourceOrdersetting、OrderSettingRules、Rule、Condition、Target、Attribute、ConditionValueといった大要素を含む。
【００５２】
BundleRuleは、sourceOffering、sourceOrderDependency、sourceOrderSettingといった小要素を含む。
sourceOfferingは、このProductOfferingにBundleされたSourceProductOfferingの参照の配列であり、実行順序を示すものである。
sourceOrderDependencyは、SourceProductOffering実行時の同期、非同期制御ルールを示すものである。具体的には、該当するSourceProductOfferingに対して同期制御が指定されていた場合は、当該SourceProductOffering完了後に、次のSourceProductOfferingを実行し、該当するSourceProductOfferingに対して非同期制御が指定されていた場合は、当該SourceProductOffering実行後に、次のSourceProductOfferingを実行することを示すものである。
sourceOrderSettingは、このProductOfferingにBundleされたSourceProductOfferingのProductOrder実行時の設定ルールを示すものである。
【００５３】
SourceOrdersettingは、addRules、modifyRules、deleteRulesといった小要素を含む。
addRulesは、ProductOrderの内部処理としてactionがaddを示されている際に動作させるルール定義である。
modifyRulesは、ProductOrderの内部処理としてactionがmodifyを示されている際に動作させるルール定義である。
deleteRulesは、ProductOrderの内部処理としてactionがdeleteを示されている際に動作させるルール定義である。
【００５４】
OrderSettingRulesは、receivedOrderRules、receivedStateChangeRulesといった小要素を含む。
receivedOrderRulesは、ProductOfferingがProductOrder要求を受領した際に動作させるルール定義である。
receivedStateChangeRulesは、ProductOfferingにBundleされたSourceProductOfferingのProductOrderに対してStateChangeを検知した際に動作させるルールである。
【００５５】
Ruleは、source、condition、action、targetといった小要素を含む。
sourceは、StateChangeを通知したProductOrderを設定し、該当ProductOfferingに対応するProductOrderからのStateChangeであることを示すものである。
conditionは、ルールを実行させるための条件を示すものである。なお、condtionが複数設定された場合は、OR条件として判断される。
Actionは、このルールにおけるアクションを示すものである。例えば、後述するtargetに定義する該当Attributeに対応するValueの設定を示すSETや、targetに定義する該当Attributeの削除を示すDELETEが存在する。
targetは、ルールによって操作されるAttribute及びValueの情報を示すものである。
【００５６】
Conditionは、attributeName、attributeValue、operator、conditionといった小要素を含む。
attributeNameは、参照先のAttribute名を指定するものである。ただし、operatorを用いる際は、Attribute名に対応するValueを指定するものとなる。
attributeValueは、参照先のAttrribute名の値を指定するである。
operatorは、条件を比較する演算子を示すものである。例えば、eqで同値をgtでより大きい、ltでより小さい、geで以上、leで以下、neで等しく無い、isEmpltyで空白との比較を行うものである。
conditionは、もとのConditionとAND条件のルールを実行させる条件を示すものである。
例えば、
“condition”:[
{
“attributeName”: ”$parentOrder.$charValue(flavor)”,
“attributeValue”: ”gold”,
“op”:”eq”
}
]
と記載した場合、親ProductOfferingのProductOrderに含まれるcharcteristic.flavorの値がgoldと等しいかどうかを比較することを示すものとなる。
【００５７】
Targetは、scope、attributesといった小要素を含む。
scopeは、変更対象のリソースを示すものである。
attributesは、変更対象のAttributeを指定するものである。
【００５８】
Attributeは、name、conditionValue、valueといった小要素を含む。
nameは、Targetのscopeで定義されたリソースのAttribute名を指定するものである。
conditionValueは、条件付き値設定の場合の設定条件を指定するものである。
valueは、設定する値を指定するものである。
【００５９】
ConditionValueは、condition、valueといった小要素を含む。
conditionは、値を設定する際の条件を指定するものである。なお、指定方法については、すでに説明した大要素Conditionと同じものである。
valueは、条件に合致した際に設定する値を指定するものである。
【００６０】
＜サービスごとの処理順序、および、応答値流通の規定＞
カタログ管理部３０が連携カタログを作成する際、連携カタログに含まれるルールに、連携サービスを構成する複数種類のサービスを連携させるための、サービスごとの処理順序を記載することができる。また、カタログ管理部３０は、連携カタログに含まれるルールに、あるサービスへの要求に対する応答値を他のサービスに流通させることの要否を示す応答値流通要否を記載することができる。
【００６１】
例えば、Ｄ社ネットワーク２−１（図１参照。第１のサービス。）とＡ社クラウド２−２（図１参照。第２のサービス。）との間でのピアリング設定を採り上げる。このピアリング設定を実現するためには、以下の処理［１］〜処理［１２］が実行される。
【００６２】
処理［１］：カタログ解釈実行部１０（図１）が、アダプタ部２０−２（図１）に、ＧＷ（GateWay）生成を要求する。
処理［２］：アダプタ部２０−２が、Ａ社クラウド２−２にＧＷを生成する。
処理［３］：アダプタ部２０−２が、カタログ解釈実行部１０に、ＧＷ生成の要求に対する応答をする。
処理［４］：カタログ解釈実行部１０が、ＧＷ生成に関する応答値をＤ社ネットワーク２−１に流通させる。
処理［５］：カタログ解釈実行部１０が、アダプタ部２０−１（図１）に、ＧＷ生成を要求する。
処理［６］：アダプタ部２０−１が、Ｄ社ネットワーク２−１にＧＷを生成する。
処理［７］：アダプタ部２０−１が、Ｄ社ネットワーク２−１にピアリングを要求する。
処理［８］：アダプタ部２０−１が、カタログ解釈実行部１０に、ピアリングの要求に対する応答をする。
処理［９］：カタログ解釈実行部１０が、ピアリングの要求に関する応答値をＡ社クラウド２−２に流通させる。
処理［１０］：カタログ解釈実行部１０が、アダプタ部２０−２に、ピアリングの受諾を要求する。
処理［１１］：アダプタ部２０−２が、Ａ社クラウド２−２でのピアリングの受諾する。
処理［１２］：アダプタ部２０−２が、カタログ解釈実行部１０に、ピアリングの受諾に対する応答をする。
【００６３】
カタログ管理部３０は、Ｄ社ネットワーク２−１およびＡ社クラウド２−２を含む連携サービスの連携カタログ内のルールに、上記の処理［１］〜処理［１２］からなる処理順序を記載することができる。具体的には、図４のルールの記載例において、Attributeカラムのうち、BundleRuleのsourceOfferingの値を決定することで、上記の処理順序を決定することができる。
サービスごとの処理順序をルールに記載することは、サービスの種類によらずに行うことができるので、連携サービスを汎用化させることができる。
【００６４】
また、カタログ管理部３０は、Ｄ社ネットワーク２−１およびＡ社クラウド２−２を含む連携サービスの連携カタログ内のルールに、処理［４］および処理［９］で示した応答値の流通の要否を記載することができる。具体的には、図４のルールの記載例において、Attributeカラムのうち、Ruleのconditionとactionとtargetとの値を決定することで、処理［４］および処理［９］における応答値の流通要否を決定することができる（処理［４］および処理［９］では流通要と決定）。
応答値の流通要否をルールに記載することは、サービスの種類によらずに行うことができるので、連携サービスを汎用化させることができる。
【００６５】
＜アダプタ部の呼び出し契機の規定＞
カタログ管理部３０が連携カタログを作成する際、連携カタログに含まれるルールに、ＡＰＩを実行するアダプタ部の起動条件を定義することで、アダプタ部の呼び出し契機を自在に規定することができる。アダプタ部の起動条件に対して、例えば、true（アダプタ部が起動中であることを意味する）およびfalse（アダプタ部が停止中であることを意味する）といった値のいずれかを持たせることができるが、これに限らない。
【００６６】
例えば、ＳＩＭ（Subscriber Identity Module）サービスアダプタ（アダプタ部２０−１〜２０−４と同等の機能）を用いてＳＩＭサービスを提供しているＸ社が、新たにＶＰＮ（Virtual Private Network）サービスを追加する場合を採り上げる。この場合、サービス連携装置１は、まず、ＶＰＮサービスアダプタ（アダプタ部２０−１〜２０−４と同等の機能）を新たに備える。
【００６７】
また、カタログ管理部３０は、ＳＩＭサービスの仕様を定義するカタログを含む連携カタログをすでに管理しているが、この連携カタログ内のルールに、ＳＩＭサービスアダプタの起動条件と、ＳＩＭサービスアダプタの識別子（本例では、識別番号など）とを記載する。なお、ＳＩＭサービスに用いられているＳＩＭについても、連携カタログ内のルールに、ＳＩＭサービスアダプタの起動条件と、ＳＩＭサービスアダプタの識別子とを記載してもよい。
【００６８】
ＳＩＭサービスにＶＰＮサービスを追加する場合、連携カタログにて、ＶＰＮサービスの仕様を新たに定義するカタログを新たに含める。また、カタログ管理部３０は、連携カタログ内のルールに、ＶＰＮサービスアダプタの起動条件と、ＶＰＮサービスアダプタの識別子（本例では、識別番号など）とを記載する。また、ＳＩＭサービスとＶＰＮサービスとを組み合わせたＸ社の統合サービスを設定することもでき、この場合、カタログ管理部３０は、統合サービスについて、連携カタログ内のルールに、ＳＩＭサービスアダプタおよびＶＰＮサービスアダプタの双方の起動条件を記載することができる。
【００６９】
上記のように、既存のＳＩＭサービスにＶＰＮサービスを追加する際は、ＶＰＮサービスのカタログおよびＶＰＮサービスアダプタを追加するだけでよい。また、カタログ管理部３０は、ＳＩＭサービスアダプタの起動条件とＶＰＮサービスアダプタの起動条件とを定義することで、ＳＩＭサービスアダプタの呼び出し契機、および、ＶＰＮサービスアダプタの呼び出し契機を独立して行うことができる。よって、例えば、ＶＰＮサービスを利用する際、ＳＩＭサービスアダプタを呼び出してしまう、という事態を回避することができる。
【００７０】
一般的に、カタログ管理部３０は、サービスごとにアダプタ部の起動条件を定義することで、アダプタ部の呼び出しを制御し、既存のサービスおよび既存のカタログに対して、新サービスおよび新カタログを、既存のサービスおよび既存のカタログに何ら影響を与えることなく追加することができる。その結果、連携サービスにおいて、新サービスおよび新ＡＰＩの柔軟な導入を実現することができる。
上記した、アダプタ部の起動条件の定義は、図４のルールの記載例において、Attributeカラムのうち、sourceOfferingの値を決定することで実現することができる。
【００７１】
＜連携サービス仕様値から市中サービス仕様値への伝搬制御の規定＞
カタログ管理部３０が連携カタログを作成する際、連携カタログに含まれるルールに、連携サービスに専用の仕様値と、連携サービスを構成する市中サービスに専用の仕様値との対応関係を明示することで、当該連携サービスの仕様値を規定することができる。
【００７２】
例えば、Ｘ社のＳＩＭサービスとＹ社のクラウドサービスとを組み合わせた連携サービスを採り上げる。Ｘ社のＳＩＭサービスのカタログおよびアダプタ、並びに、Ｙ社のクラウドサービスのカタログおよびアダプタは用意されているとする。また、Ｘ社のＳＩＭサービスは、その仕様値としての帯域が、slow、standard、highの３段階で設定可能であるとする。また、Ｙ社のクラウドサービスは、その仕様値としてのインスタンスタイプが、minimum、micro、medium、largeの４段階で設定可能であるとする。
【００７３】
カタログ管理部３０は、Ｘ社のＳＩＭサービスとＹ社のクラウドサービスとを組み合わせた第１の連携サービスの連携カタログに含まれるルールに、Gold、Silverといった２段階の仕様値を設定したとする。
Gold仕様値は、Ｘ社のＳＩＭサービスの帯域がhighであり、かつ、Ｙ社のクラウドサービスのインスタンスタイプがlargeであるとする。
Silver仕様値は、Ｘ社のＳＩＭサービスの帯域がhighであり、かつ、Ｙ社のクラウドサービスのインスタンスタイプがmicroであるとする。
【００７４】
また、カタログ管理部３０は、Ｘ社のＳＩＭサービスとＹ社のクラウドサービスとを組み合わせた第２の連携サービスの連携カタログに含まれるルールに、High、Lowといった２段階の仕様値を設定したとする。
High仕様値は、Ｘ社のＳＩＭサービスの帯域がhighであり、かつ、Ｙ社のクラウドサービスのインスタンスタイプがlargeであるとする。
Low仕様値は、Ｘ社のＳＩＭサービスの帯域がslowであり、かつ、Ｙ社のクラウドサービスのインスタンスタイプがminimumであるとする。
【００７５】
第１、第２の連携サービスを利用するユーザに対して示される仕様値は、Gold、Silver、High、Lowであり、Ｘ社のＳＩＭサービスの仕様値（slow、standard、high）でもなく、Ｙ社のクラウドサービスの仕様値（minimum、micro、medium、large）でもない。つまり、連携カタログ内のルールに、連携サービスの仕様値を用いることで、連携サービスを構成する市中サービスの仕様値を隠蔽することができる。また、連携カタログ内のルールに、連携サービスの仕様値を用いることで、連携サービスとしての特性を、連携サービスの作成者ごとに生成することができ、連携サービスの生成を柔軟に実現することができる。
【００７６】
上記した、連携サービスに専用の仕様値と、連携サービスを構成する市中サービスに専用の仕様値との対応関係を明示は、図４のルールの記載例において、Attributeカラムのうち、ConditionValueの値を決定することで実現することができる。
【００７７】
≪処理≫
本実施形態のサービス連携装置１における処理について、図５を参照して説明する（適宜他の図も参照）。この処理は、例えば、顧客装置から連携サービスに対する要求（ProductOrder）があったときに開始する。説明の便宜上、要求のあった連携サービスは、連携カタログ４−１で定義される連携サービスとする。
【００７８】
まず、サービス連携装置１は、連携カタログ４−１に基づいて、ProductOrderを編集する（ステップＳ１）。具体的には、カタログ解釈実行部１０が、ProductOrderリソースを確保し、以降の処理を非同期で実行できるようにする。
【００７９】
次に、サービス連携装置１は、各アダプタ部２０−１〜２０−３に対し、連携カタログ４−１内のルール４−１ａに応じたProductOrderの実行を指示する（ステップＳ２）。具体的には、カタログ解釈実行部１０が、連携カタログ４−１内のＤ社カタログ３−１、Ａ社カタログ３−２、および、アプリＡカタログ３−３を解釈し、ルール４−１ａに従ってProductOrderを各アダプタ部２０−１〜２０−３に処理させる。
【００８０】
次に、サービス連携装置１は、各アダプタ部２０−１〜２０−３によって、対応のサービス（Ｄ社ネットワーク２−１、Ａ社クラウド２−２、および、アプリＡ２−３）のＡＰＩを実行する（ステップＳ３）。ＡＰＩの実行によって、ProductOrderの実行が達成される。
【００８１】
次に、サービス連携装置１は、各アダプタ部２０−１〜２０−３から、ProductOrderの実行結果を取得する（ステップＳ４）。ProductOrderの実行結果は、カタログ解釈実行部１０が有する。
次に、サービス連携装置１は、ルールに応じたProductOrderの補完処理を実行する（ステップＳ５）。具体的には、カタログ解釈実行部１０が、連携カタログ４−１内のルール４−１ａに従い、各アダプタ部２０−１〜２０−３から取得したProductOrderの実行結果のすべてを、連携サービスを構成する各サービス（Ｄ社ネットワーク２−１、Ａ社クラウド２−２、および、アプリＡ２−３）に反映（更新）させる。
【００８２】
サービス連携装置１は、連携カタログ４−１内のルール４−１ａに従い、ステップＳ２〜ステップＳ５の処理を必要に応じて繰り返し、その後、図５の処理を終了する。
【００８３】
また、新サービスが追加されたときのサービス連携装置１における処理について、図６を参照して説明する（適宜他の図も参照）。なお、新サービスのＡＰＩは公開されているとする。また、新サービスの仕様を定義した新カタログが用意されているとする。
【００８４】
まず、サービス連携装置１は、新カタログを記憶部に記憶する（ステップＳ１１）。これにより、カタログ管理部３０が新カタログを管理することができる。
次に、サービス連携装置１は、新サービスのＡＰＩを実行するアダプタ部となる新アダプタ部を実装する（ステップＳ１２）。
【００８５】
次に、サービス連携装置１は、カタログ管理部３０によって、新カタログを含む連携カタログとなる新連携カタログを作成する（ステップＳ１３）。
次に、サービス連携装置１は、カタログ管理部３０によって、新連携カタログに含めるルールとなる新ルールを設定する（ステップＳ１４）。なお、新ルールの設定は、任意であり、ステップＳ１４は省略してもよい。
【００８６】
次に、サービス連携装置１は、カタログ解釈実行部１０によって、新連携カタログに基づいて、新連携カタログ内のカタログで定義されるサービスを一括した連携サービスとなる新連携サービスを構築する（ステップＳ１５）。ステップＳ１４にて、新ルールを設定している場合には、サービス連携装置１は、新ルールにも基づいて新連携サービスを構築する。
【００８７】
構築した新連携サービスに対する要求（ProductOrder）があった場合、サービス連携装置１は、図５の処理をする。
【００８８】
本実施形態によれば、カタログおよびアダプタ部を、サービスごとに用意し、新サービスおよび新ＡＰＩの追加があった場合には、当該新サービスおよび新ＡＰＩに対応する新カタログおよび新アダプタ部を用意する。よって、従来のように、サービス連携装置１の追加開発を必要とすることはなく、例えば、カタログ解釈実行部１０の改変は不要である。
したがって、連携サービスに新サービスおよび新ＡＰＩを追加する際の追従コストを低減させることができる。
【００８９】
≪その他≫
以上、本発明の実施形態について説明したが、本発明は前記実施形態に限定されず、本発明の要旨を逸脱しない範囲で適宜変更可能である。例えば、サービス連携装置１は、図４の記載例に示すルールにて、処理ａ→処理ｂといった順序制御を、サービス間だけでなく同じサービス内であっても規定することができる。また、処理ａ→処理ｂの順序制御が規定されている場合、サービス連携装置１は、図４に記載例に示すルールにて、処理ｂの応答値を、処理ａを要求するオーダに上書きすることを規定することができる。この上書きによって、処理ａを要求するオーダを強制的に再発行することができる。その結果、処理ａ→処理ｂ→処理ａといった順序を、処理ａ→処理ｂ→処理ａの順序制御を別途規定することなく実現することができる。
【００９０】
本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００９１】
１      サービス連携装置
１０    カタログ解釈実行部
２０−１〜２０−４  アダプタ部
３０    カタログ管理部
２−１  Ｄ社ネットワーク（サービス）
２−２  Ａ社クラウド（サービス）
２−３  アプリＡ（サービス）
２−４  Ｂ社クラウド（サービス）
３−１  Ｄ社カタログ
３−２  Ａ社カタログ
３−３  アプリＡカタログ
３−４  Ｂ社カタログ
４−１，４−２  連携カタログ
４−１ａ，４−２ａ  ルール
【図１】
2018206050.tif 000003
【図２】
2018206050.tif 000004
【図３】
2018206050.tif 000005
【図４】
2018206050.tif 000006
【図５】
2018206050.tif 000007
【図６】
2018206050.tif 000008