JP7332950B2

JP7332950B2 - サービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラム

Info

Publication number: JP7332950B2
Application number: JP2021575172A
Authority: JP
Inventors: 亮太片柳; 謙輔高橋; 悟近藤
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2020-02-06
Filing date: 2020-02-06
Publication date: 2023-08-24
Anticipated expiration: 2040-02-06
Also published as: US20230068545A1; JPWO2021156992A1; WO2021156992A1

Description

本発明は、サービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラムに関する。

通信サービスの多様化に伴い、複数種類のサービスが連携された連携サービスの重要性が高まっており、連携サービスに関係する新規サービスの登場や既存サービス仕様の変更に対し、短期間・低コストでの対応が求められている。

このような変更に対応するために、サービス仕様及びＡＰＩ仕様を定義するカタログ管理部と、これらの仕様に基づいてＡＰＩを実行するアダプタとを疎結合化し、新規サービスまたは既存サービスの仕様変更への対応コストを抑制する技術がある（特許文献１）。

また、このようなアダプタの開発容易化については、GUIを用いてアダプタを生成する技術が存在する（非特許文献１）。また、ＡＰＩの特性に依存しないサービス間の連携についても検討されている（非特許文献２）。

特開2018-206050号公報

武直樹, 他5名, "GUIを用いたAPIアダプタ開発容易化方式に関する一検討" 電子情報通信学会ソサイエティ大会講演, B-14-13, 電子情報通信学会, 2018年9月11日～14日片柳亮太, 他2名, " APIの特性に依存しないサービス間連携の実現方式に関する一検討", 電子情報通信学会ネットワークソフトウェア研究会, 2019年10月25日

複数サービスの連携において、上位装置側のステートレスなＡＰＩと下位装置側のステートフルなＡＰＩとの間を対応付ける技術は存在しない。そのため、上位装置側のＡＰＩのリクエストをトリガに、どの下位装置側のＡＰＩをどのような順序で実行するか、というマッピング処理は、連携サービスの提供事業者などにより手動で設計する必要がある。そのため、マッピング処理の実装は容易ではなく、コストおよび時間を要する。

本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、上位装置側のステートレスなＡＰＩと下位装置側のステートフルなＡＰＩとの間のマッピングを容易化するサービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラムを提供することにある。

上記目的を達成するため、本発明の一態様は、サービス連携支援装置であって、複数のサービスを連携させる上位装置に公開するステートレスな上位ＡＰＩの定義情報と、下位装置が公開するステートフルな複数の下位ＡＰＩの定義情報と、を受け付ける受付部と、前記上位ＡＰＩの定義情報および前記下位ＡＰＩの定義情報を用いて、前記上位ＡＰＩに対応する少なくとも１つの下位ＡＰＩを抽出し、抽出した下位ＡＰＩの実行順序を設定したＡＰＩ対応表を生成する解釈部と、を有する。

本発明の一態様は、サービス連携支援装置が行うサービス連携支援方法であって、複数のサービスを連携させる上位装置に公開するステートレスな上位ＡＰＩの定義情報と、下位装置が公開するステートフルな複数の下位ＡＰＩの定義情報と、を受け付ける受付ステップと、前記上位ＡＰＩの定義情報および前記下位ＡＰＩの定義情報を用いて、前記上位ＡＰＩに対応する少なくとも１つの下位ＡＰＩを抽出し、抽出した下位ＡＰＩの実行順序を設定したＡＰＩ対応表を生成する生成ステップと、を行う。

本発明の一態様は、上記サービス連携支援装置として、コンピュータを機能させるサービス連携支援プログラムである。

本発明によれば、上位装置側のステートレスなＡＰＩと下位装置側のステートフルなＡＰＩとの間のマッピングを容易化するサービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラムを提供することができる。

本発明の実施形態のサービス連携システムの構成例を示す図である。連携支援装置の構成を示すブロック図である。サービス連携システムの前提条件を説明する説明図である。定義情報のデータ構造例である。ＡＰＩ対応表の具体的な生成手順を説明するための説明図である。ＡＰＩ対応表の具体的な生成手順を説明するための説明図である。ＡＰＩ対応表の具体的な生成手順を説明するための説明図である。ＡＰＩ対応表の具体的な生成手順を説明するための説明図である。ＡＰＩ対応表の具体的な生成手順を説明するための説明図である。ＡＰＩ対応表の具体的な生成手順を説明するための説明図である。ＡＰＩ対応表の具体的な生成手順を説明するための説明図である。ＡＰＩ対応表の生成を示すシーケンス図である。ＡＰＩ対応表の生成を詳細に示すフローチャートである。サービス連携システムの動作を示すシーケンス図である。ハードウェア構成例である。

以下、本発明の実施の形態について、図面を参照して説明する。

（サービス連携システムの構成）
図１は、本実施形態のサービス連携システムの構成図である。図示するサービス連携システムは、サービス連携装置１と、複数のサービス２Ａ、２Ｂと、２Ｃと、連携支援装置５（サービス連携支援装置）とを備える。

サービス連携装置１は、複数種類のサービスを連携させた連携サービスを実行する装置である。複数の種類のサービスとして、図１では、３つのサービス２Ａ、２Ｂ、２Ｃを示す。サービス２Ａは、Ａ社（サービス事業者）が提供するネットワークサービスである。サービス２Ｂは、Ｂ社（サービス事業者）が提供するサービスであって、ＩａａＳ（Infrastructure as a Service）、ＰａａＳ（Platform as a Service）等のクラウドサービスである。サービス２Ｃは、Ｃ社（サービス事業者）が提供するＷｅｂアプリケーション（以下、「アプリ」とする）のサービスである。なお、本発明で取り扱うサービスの数および種類は、これらに限定されない。

ここでは、サービス２Ａ、２Ｂは、ステートレスなＡＰＩを有し、公開（提供）するサービス（以下、「ステートレスサービス」ともいう）である。一方、サービス２Ｃは、ステートフルなＡＰＩを有し、公開するサービス（以下、「ステートフルサービス」ともいう）である。

ステートレス（ＲＥＳＴｆｕｌ）は、サーバがクライアントとのセッション情報などの内部状態（動的情報）を保持しない通信方式である。そのため、ステートレスな通信方式は、クライアントのリクエストに、ＡＰＩの実行（処理）に必要な全ての情報が含まれる自己完結型の方式である。ステートフルな通信方式は、サーバがクライアントとのセッション情報などの内部状態を保持し、ＡＰＩの実行時に適宜参照する通信方式である。

本実施形態では、ステートフルＡＰＩを公開するサービス２Ｃと、ステートレスＡＰＩを公開するサービス２Ａ、２Ｂとが連携して１つの連携サービスを構成するものとする。すなわち、本実施形態では、サービス連携装置１は、ステートフルＡＰＩを公開するサービス２Ｃを含む複数のサービスを連携させた連携サービスを実行する。

本実施形態のサービス連携装置１は、連携するサービスのＡＰＩの通信方式（ステートレス、ステートフル）によらず、複数のサービスを連携した連携サービスを実現する。ここでは、サービス連携装置１は、ステートフルＡＰＩを公開するアプリサービス２Ｃを含む複数のサービスを連携させた連携サービスを実行する。図示するサービス連携装置１は、カタログ解釈実行部１０と、アダプタ部２１－２３と、カタログ管理部３０と、を備える。

カタログ管理部３０は、サービスの仕様を定義したカタログ（Ｐｒｏｄｕｃｔカタログ）を管理する。カタログは、例えば、カタログ管理部３０が備える記憶部（不図示）に記憶されている。図１は、複数のサービス２Ａ、２Ｂ、２Ｃの各々について、Ａ社カタログ３１と、Ｂ社カタログ３２と、アプリカタログ３３とを示す。本発明で取り扱うカタログはこれらに限定されない。カタログは、サービスごとに用意され、新たなサービスが追加された場合には、当該サービスに対応するカタログが用意され、カタログ管理部３０は当該カタログを記憶部に登録し、管理する。

カタログ管理部３０は、連携サービスを構成する複数のサービスの複数のカタログを組み合わせることで、連携サービス用のカタログとなる連携カタログを作成し、記憶部に記憶する。図１では、カタログ管理部３０は、Ａ社カタログ３１、Ｂ社カタログ３２、および、アプリカタログ３３を組み合わせた連携カタログ４１を作成し、記憶部に記憶する。連携カタログ４１は、３つのサービス２Ａ、２Ｂ、２Ｃを含む連携サービスの仕様を定義する。また、連携カタログ４１は、ルール４１１を含む。ルール４１１は、連携サービスを構成する各サービス間の連係動作に関する規定である。

カタログ解釈実行部１０は、サービス事業者の顧客のクライアント（不図示）から、連携サービスに対する要求があった場合に、当該連携サービスの連携カタログ内のカタログの内容を解釈して要求を処理する。カタログ解釈実行部１０は、連携カタログに含まれる全てのカタログを解釈して要求を処理する。カタログ解釈実行部１０は、カタログに対応するサービスの各々に依存しない、サービス間連携における共通の処理を実行する機能部といえる。

アダプタ部２１～２３は、連携サービスを構成する各サービスのＡＰＩを実行し、クライアントからの要求を処理する。アダプタ部２１～２３は、サービス毎に備えられ、新たなサービスが追加された場合には、サービス連携装置１は、新たなアダプタ部を追加する。アダプタ部２１～２３は、各サービスのＡＰＩ仕様に依存する要求を処理する機能部といえる。

本実施形態のサービス連携装置１では、新たなサービスを連携サービスの連携対象にする場合、新たなサービスに対応するカタログおよびアダプタ部を用意するだけでよい。したがって、サービス連携装置１全体の追加開発を必要とせず、連携サービスに新サービスおよび新ＡＰＩを追加する際の追従コストを低減させることができる。

また、本実施形態のサービス連携装置１では、カタログを用いることで、連携サービスを構成するサービス群を、カタログドリブンな疎結合アーキテクチャとして構成することができる。

連携支援装置５は、ステートフルなＡＰＩを公開するステートフルサービスを、他のサービスと容易に連携させるための装置である。なお、サービス連携システムは、ステートフルなサービス毎に別々の連携支援装置５を備えていてもよい。あるいは、サービス連携システムは、複数のステートフルなサービスに対して１つの連携支援装置５を備え、当該連携支援装置５はサービス毎にステートレスなＡＰＩを公開してもよい。

（連携支援装置の構成）
図２は、本実施形態の連携支援装置５の構成を示すブロック図である。本実施形態の連携支援装置５は、上位装置のステートレスな上位ＡＰＩと、下位装置のステートフルな下位ＡＰＩとの対応関係（マッピング）を示すＡＰＩ対応表を自動生成し、ＡＰＩ対応表に基づいてステートフルな下位ＡＰＩの実行を制御する。具体的には、連携支援装置５は、定義情報の入力を契機に、上位ＡＰＩと下位ＡＰＩとのマッピング処理を実施してＡＰＩ対応表を生成する。そして、連携支援装置５は、上位装置からのステートレスな上位ＡＰＩのリクエストに対し、自動生成したＡＰＩ対応表を用いて、対応するステートフルな下位ＡＰＩを選択し、設定された順序で下位ＡＰＩを実行する。

これにより、本実施形態の連携支援装置５は、ステートレスな下位ＡＰＩを公開するサービスだけでなく、ステートフルな下位ＡＰＩを公開するサービスも含む連携サービスを、短期間かつ低コストで実現することを支援することができる。

図示する連携支援装置５は、実行部５１と、ＵＩ部５２（ユーザインタフェース部）と、ＡＰＩ解析部５３と、管理部５４と、記憶部５５と、ＡＰＩ対応表を格納するＤＢ（データベース）５６とを備える。

実行部５１は、サービス連携装置１（上位装置）からのリクエストに応じて、上位ＡＰＩに対応するステートフルな下位ＡＰＩをＡＰＩ対応表を用いて特定し、特定した下位ＡＰＩをＡＰＩ対応表で指定された順序で実行する。具体的には、実行部５１は、ステートフルサービスを含む複数のサービスを連携させた連携サービスを実行するサービス連携装置１から、ステートフルサービスに対するステートレスな上位ＡＰＩのリクエストを受け付け、当該リクエストをＡＰＩ対応表を用いて下位ＡＰＩにマッピングし、下位ＡＰＩを実行する。上位ＡＰＩは、連携支援装置５がサービス連携装置１に公開するステートレスなＡＰＩである。

実行部５１は、サービス連携装置１に下位ＡＰＩの実行完了を通知し、サービス連携装置１に下位ＡＰＩの実行結果の取得を促してもよい。実行部５１は、下位ＡＰＩへの２回目以降のリクエストに、記憶部５５に記憶された内部状態を含めてもよい。

ＵＩ部５２は、上位ＡＰＩ定義情報９１と、下位ＡＰＩ定義情報９２と、内部状態定義情報９３との入力を受け付ける。上位ＡＰＩ定義情報９１は、複数のサービスを連携させるサービス連携装置１（上位装置）に公開するステートレスな上位ＡＰＩの定義情報である。下位ＡＰＩ定義情報９２は、アプリサービス２Ｃ（下位装置）が公開するステートフルな複数の下位ＡＰＩの定義情報である。内部状態定義情報９３は、下位ＡＰＩの実行時に参照するアプリサービス２Ｃの内部状態の定義情報である。

ＡＰＩ解析部５３は、上位ＡＰＩ定義情報９１および下位ＡＰＩ定義情報９２を用いて、上位ＡＰＩに対応する少なくとも１つの下位ＡＰＩを抽出し、抽出した下位ＡＰＩの実行順序を設定したＡＰＩ対応表を生成する。すなわち、ＡＰＩ解析部５３は、ステートレスな上位ＡＰＩと、ステートフルな下位ＡＰＩとの対応関係を解析し、マッピングする。また、ＡＰＩ解析部５３は、内部状態定義情報９３を用いてＡＰＩ対応表を生成してもよい。

ＡＰＩ解析部５３は、上位ＡＰＩの出力情報を出力する下位ＡＰＩを抽出し、抽出した下位ＡＰＩの入力情報が上位ＡＰＩの入力情報のみの場合、当該下位ＡＰＩの実行順序を他の下位ＡＰＩより優先してもよい。

管理部５４は、記憶部５５およびＤＢ５６を管理する。記憶部５５には、ステートフルな下位ＡＰＩの応答に含まれる内部状態が記憶される。内部状態は、下位ＡＰＩの実行に必要な情報であって、サービス側の下位装置（ここではアプリサービス２Ｃのサーバ）から下位ＡＰＩの実行時に通知される情報である。内部状態には、連携支援装置５と、ステートフルサービスを提供する下位装置とのセッション情報（例えば、Ｃｏｏｋｉｅ）が含まれていてもよい。また、記憶部５５には、下位ＡＰＩの実行結果が記憶される。ＤＢ５６には、ＡＰＩ解析部５３が生成したＡＰＩ対応表が格納される。

（連携支援装置５の動作概要）
連携支援装置５は、サービス連携装置１のメリットを失うことなく、ステートフルな下位ＡＰＩを公開するサービス２Ｃと、他のサービスとの連携を支援する。第１のメリットは、カタログ管理部３０と、アダプタ部２３との疎結合化による新規サービスの追加、または既存サービス仕様変更への適応コストを削減可能なことである。第２のメリットは、ステートフルな下位ＡＰＩを公開するサービス２Ｃであっても、サービス連携装置１では非特許文献１の開発容易化技術を適用したステートレスな上位ＡＰＩ用のアダプタ部２３を実装可能とし、アダプタ部２３の開発コストを削減可能なことである。

そのため、連携支援装置５は、上位側（Ｎｏｒｔｈｂｏｕｎｄ）のステートレスな上位ＡＰＩを公開し、サービス連携装置１からのリクエストを受け付ける。上位ＡＰＩは、連携支援装置５からみて、自装置５を管理・操作するサービス連携装置１（上位装置）に対して公開するＡＰＩである。

サービス連携装置１がステートフルなサービスを連携支援装置５を介して間接的に操作することを目的として、連携支援装置５は、ステートフルなサービス毎に上位ＡＰＩを実装し、サービス連携装置１に公開する。上位ＡＰＩは、サービス側のステートフルＡＰＩおよびカタログの仕様に従って予め生成され、連携支援装置５の実行部５１に実装される。

連携支援装置５は、サービス連携装置１から送信される上位ＡＰＩのリクエストを、ＡＰＩ対応表を用いて下位側（Ｓｏｕｔｈｂｏｕｎｄ）のステートフルな下位ＡＰＩにマッピングして、下位ＡＰＩを実行する。下位ＡＰＩは、連携支援装置５からみて操作の対象となる下位装置が公開するＡＰＩである。

図３は、サービス連携システムの動作概要を示す図である。図示する例では、連携支援装置５が公開するステートレスな上位ＡＰＩには、ステートフルな下位ＡＰＩの実行を指示するためのＡＰＩと、実行結果を取得するためのＡＰＩとが含まれる。したがって、図示するアダプタ部２３は、ステートフルＡＰＩの実行指示リクエストと、実行結果を取得する結果取得リクエストとを連携支援装置５に送信する。

連携支援装置５は、アダプタ部２３からの上位ＡＰＩのリクエストを契機に、当該リクエストに対応する下位装置のステートフルＡＰＩを実行し、実行結果をアダプタ部２３に返却する。このとき、連携支援装置５は、アダプタ部２３のリクエストに対する下位ＡＰＩを、ＡＰＩ対応表で設定された上位ＡＰＩと下位ＡＰＩとの対応関係に基づいて決定する。

図示するように、アダプタ部２３は、上位ＡＰＩを介して、アプリサービス２Ｃの下位ＡＰＩの実行を指示するリクエスト（ＰＯＳＴメソッド）を連携支援装置５に送信する（Ｓ１１）。連携支援装置５は、当該リクエストに対応するアプリサービス２Ｃの下位ＡＰＩを、ＡＰＩ対応表に従って順次実行する（Ｓ１２－Ｓ１４）。連携支援装置５は、実行結果を記憶部５５に保持する。連携支援装置５は、下位ＡＰＩの実行完了後に、実行結果を保持している旨をサービス連携装置１に通知する（Ｓ１５）。具体的には、連携支援装置５は、リクエストが成功してリソースの作成が完了したことを示す「２０１Ｃｒｅａｔｅｄ」（正常応答）をサービス連携装置１に送信する。

サービス連携装置１のアダプタ部２３は、Ｓ１５の応答を受信すると、実行結果を取得するためのリクエスト（ＧＥＴメソッド）を連携支援装置５に送信する（Ｓ１６）。連携支援装置５は、記憶部５５に保持した実行結果を２００ＯＫ（正常応答）とともにサービス連携装置１に送信する（Ｓ１７）。アダプタ部２３は、取得した実行結果をカタログのｃｈａｒａｃｔｅｒｉｓｔｉｃに格納する。

なお、サービス連携装置１のステートフルなサービスのカタログには、連携支援装置５の実行結果を格納するｃｈａｒａｃｔｅｒｉｓｔｉｃ（属性）が必要となる。サービス連携装置１は、ステートフルなアプリサービス２ＣのＰｒｏｄｕｃｔカタログに、実行結果を格納するｃｈａｒａｃｔｅｒｉｓｔｉｃを定義する。

図３では、上位ＡＰＩには、２つのＡＰＩ（下位ＡＰＩの実行を指示するＡＰＩと、実行結果を取得するＡＰＩ）が含まれる場合について説明したが、これに限定されない。連携支援装置５の管理部５４が下位ＡＰＩの実行結果を記憶部５５で管理する目的は、上位ＡＰＩ定義情報９１に含まれる「出力情報」が、対応する全ての下位ＡＰＩの実行完了により全て揃うまでの一時保存と、ある下位ＡＰＩが他の下位ＡＰＩの実行結果を入力情報として必要とするような依存関係にあるときに当該下位ＡＰＩの実行に要する入力情報(他の下位ＡＰＩの実行結果)が全て揃うまでの一時保存である。

そのため、下位ＡＰＩの実行を指示する上位ＡＰＩ定義情報９１に含まれる出力情報が管理部５４配下に全て揃ったタイミング（または、任意のタイミング）で、該当する下位ＡＰＩの実行結果が上位ＡＰＩの出力情報に含まれるように設計することも可能である。例えば、下位ＡＰＩの実行指示による実行結果は、上位ＡＰＩ（ＰＯＳＴメソッド)へのレスポンスに含ませることもできる。

（定義情報）
図４は、本実施形態の定義情報のデータ構造例である。ここでは、連携支援装置５に入力される上位ＡＰＩ定義情報９１と、下位ＡＰＩ定義情報９２と、内部状態定義情報９３との構成イメージを説明する。

上位ＡＰＩ定義情報９１は、連携支援装置５が上位装置に提供するステートレスな上位ＡＰＩの定義情報である。上位ＡＰＩ定義情報９１は、公開されるＡＰＩとメソッドとの組合せ毎に、ＡＰＩ名と、メソッドと、入力情報と、出力情報とを保持する。上位ＡＰＩ定義情報９１の入力情報および出力情報は、下位ＡＰＩ定義情報９２との関連を特定するため、下位ＡＰＩの命名規則に合わせて設定される。

下位ＡＰＩ定義情報９２は、下位装置が提供するステートフルな下位ＡＰＩの定義情報である。下位ＡＰＩ定義情報９２は、公開されるＡＰＩとメソッドとの組合せ毎に、ＡＰＩ名と、メソッドと、内部状態と、入力情報と、出力情報とを保持する。なお、内部状態を参照しない下位ＡＰＩでは、内部状態の欄は空欄となる。

内部状態定義情報９３は、ステートフルな下位ＡＰＩ実行時における、下位装置の内部状態(例えば、セッション情報など)の定義情報である。内部状態定義情報９３は、変数名とデータ形式の組で保持される。変数名は、下位ＡＰＩ定義情報９２との関連を特定するため、下位ＡＰＩの命名規則に合わせて設定される。

（ＡＰＩ対応表の生成）
図５から図１１は、ＡＰＩ対応表の具体的な生成手順を説明するための説明図である。図５に示すように、連携支援装置５（ＡＰＩ解析部５３）は、ＵＩ部５２を介して入力された定義情報６１（上位ＡＰＩ定義情報９１、下位ＡＰＩ定義情報９２、内部状態定義情報９３）を用いてＡＰＩ対応表６２を生成する。入出力対応イメージ６３は、上位ＡＰＩ（ここでは、「/rest01」）と下位ＡＰＩとの関係を便宜的に示すイメージ図である。

図６に示すように、連携支援装置５は、定義情報６１を用いて、上位ＡＰＩ７１の出力情報の一部または全部を出力する下位ＡＰＩを抽出する。連携支援装置５は、該当しない下位ＡＰＩに確認済FLG(chkFLG=1)を設定する。図６では、下位ＡＰＩ７２、７５が抽出され、下位ＡＰＩ７３、７４に確認済FLGが設定される。図６のＡＰＩ対応表６２は、初期状態であって、上位ＡＰＩに処理対象の上位ＡＰＩ名が設定され、下位ＡＰＩは空白である。

次に図７に示すように、連携支援装置５は、抽出した下位ＡＰＩ７２、７５の集合のうち、最も多く出力情報を返す下位ＡＰＩ７５が実行可能な否かを判定する。具体的には、連携支援装置５は、下位ＡＰＩ７５が、上位ＡＰＩ定義情報の入力情報および内部状態定義情報だけで実行可能か否かを判定する。下位ＡＰＩ７５は上位ＡＰＩ７１の入力情報および内部状態ではない「paramG」を入力とし、現時点では下位ＡＰＩ７５を実行するための入力情報が不足している。このため、連携支援装置５は、下位ＡＰＩ７５を現時点では実行できないと判定し、下位ＡＰＩ７５に確認済FLGを設定する。

次に、連携支援装置５は、抽出した下位ＡＰＩ７２が実行可能な否かを判定する。下位ＡＰＩ７２の入力情報は、上位ＡＰＩ７１の入力情報「paramA」である。このため、連携支援装置５は、下位ＡＰＩ７２が、上位ＡＰＩ７１の入力情報および内部状態定義情報だけで実行可能であると判定し、下位ＡＰＩ７２の実行を確定する。そして、連携支援装置５は、ＡＰＩ対応表６２の下位ＡＰＩに実行を確定した下位ＡＰＩ７２のＡＰＩ名「/stateful01」を設定する。下位ＡＰＩ７２は、最初に実行が確定された下位ＡＰＩであるため、連携支援装置５は下位ＡＰＩ７２を下位ＡＰＩ欄の１番目に設定する。

このように、連携支援装置５は、上位ＡＰＩ７１の出力情報を出力する下位ＡＰＩ７２を抽出し、抽出した下位ＡＰＩ７２の入力情報が上位ＡＰＩ７１の入力情報のみの場合、当該下位ＡＰＩ７２の実行順序を他の下位ＡＰＩより優先する。

連携支援装置５は、残りの下位ＡＰＩは、全て確認済FLG が設定されているため、次に下位ＡＰＩ間の連携での要件充足を検証する。

図８に示すように、連携支援装置５は、上位ＡＰＩ７１の出力情報８１（「paramE」、「paramF」）を出力する下位ＡＰＩ７５の入力情報（「paramG」）に着目し、当該入力情報を出力する下位ＡＰＩ７４を抽出する。連携支援装置５は、抽出した下位ＡＰＩ７４の入力情報（「paramC」、「paramH」）を取得する。「paramC」は、上位ＡＰＩ７１の入力情報に含まれるが、「paramH」は、上位ＡＰＩ７１の入力情報、内部状態定義情報、およびＡＰＩ対応表に登録した下位ＡＰＩの出力情報のいずれにも含まれない。そこで、連携支援装置５は、定義情報６１のうち下位ＡＰＩ定義情報を参照し、「paramH」を出力情報とする下位ＡＰＩ７３を取得し、下位ＡＰＩ７３が実行可能な否かを判定する。

図９に示すように、下位ＡＰＩ７３の入力情報（「paramB」、「paramJ」）は、上位ＡＰＩ７１の入力情報および内部状態定義情報である。すなわち、下位ＡＰＩ７３の入力情報は、上位ＡＰＩ７１の入力情報、内部状態定義情報、およびＡＰＩ対応表に登録した下位ＡＰＩの出力情報のいずれかに含まれる。このため、連携支援装置５は、下位ＡＰＩ７３が実行可能であると判定し、下位ＡＰＩ７３の実行を確定する。そして、連携支援装置５は、下位ＡＰＩ７４の実行に先立ち、下位ＡＰＩ７３の実行を確定する。そして、連携支援装置５は、ＡＰＩ対応表６２の下位ＡＰＩに実行を確定した下位ＡＰＩ７３のＡＰＩ名を設定する。ここでは、下位ＡＰＩ７３は２番目に実行が確定された下位ＡＰＩであるため、連携支援装置５は下位ＡＰＩ７３を下位ＡＰＩ欄の２番目に設定する。

図１０に示すように、連携支援装置５は、下位ＡＰＩ７４の判定に戻り、下位ＡＰＩ７４の入力情報（「paramC」、「paramH」）を再度検証する。具体的には、連携支援装置５は、上位ＡＰＩ７１の入力情報（「paramC」）と、ＡＰＩ対応表６２に登録された下位ＡＰＩ７３の出力情報（「paramH」）とを用いて下位ＡＰＩ７４は実行可能であると判定する。そして、連携支援装置５は、下位ＡＰＩ７５の実行に先立ち、下位ＡＰＩ７４の実行を確定する。そして、連携支援装置５は、ＡＰＩ対応表６２の下位ＡＰＩに実行を確定した下位ＡＰＩ７４のＡＰＩ名を設定する。ここでは、下位ＡＰＩ７４は３番目に実行が確定された下位ＡＰＩであるため、連携支援装置５は下位ＡＰＩ７４を下位ＡＰＩ欄の３番目に設定する。

図１１に示すように、次に連携支援装置５は、下位ＡＰＩ７５の判定に戻り、下位ＡＰＩ７５の入力情報（「paramG」）を再度検証する。具体的には、連携支援装置５は、入力情報（「paramG」）はＡＰＩ対応表６２に登録された下位ＡＰＩ７４の実行結果であるため実行可能であると判定し、下位ＡＰＩ７５の実行を確定する。そして、連携支援装置５は、ＡＰＩ対応表６２の下位ＡＰＩ欄に実行を確定した下位ＡＰＩ７５のＡＰＩ名を設定する。ここでは、下位ＡＰＩ７５は４番目に実行が確定された下位ＡＰＩであるため、連携支援装置５は下位ＡＰＩ７５を下位ＡＰＩ情報欄の４番目に設定する。連携支援装置５は、上位ＡＰＩ７１の出力情報を参照し、全ての出力情報を出力可能であるため、処理対象の上位ＡＰＩ７１（「/rest01」）のＡＰＩ対応表の生成（マッピング処理）を完了する。

（サービス連携システムの動作）
図１２は、連携支援装置５が行うＡＰＩ対応表の生成処理を示すシーケンス図である。ＡＰＩ対応表の生成処理は、ユーザによる定義情報の入力をトリガとして行われる。

ＵＩ部５２は、ユーザが入力した定義情報を受け付け（Ｓ２１）、受け付けた定義情報をＡＰＩ解析部５３に送出する（Ｓ２２）。定義情報は、上位ＡＰＩ定義情報と、下位ＡＰＩ定義情報と、内部状態定義情報である。

ＡＰＩ解析部５３は、上位ＡＰＩ定義情報からいずれか１つの上位ＡＰＩを選択する（Ｓ２３）。ＡＰＩ解析部５３は、選択した上位ＡＰＩに対応する上位ＡＰＩ定義情報、下位ＡＰＩ定義情報、および内部状態定義情報を解析して、当該上位ＡＰＩのＡＰＩ対応表を生成する（Ｓ２４）。ＡＰＩ対応表の生成処理については後述する。

ＡＰＩ解析部５３は、Ｓ２３で選択した上位ＡＰＩのＡＰＩ対応表の登録要求を管理部５４に送出する（Ｓ２５）。管理部５４は、例えばクエリなどを用いてＡＰＩ対応表をＤＢ５６に登録する（Ｓ２６）。ＤＢ５６は、登録完了応答を管理部５４に送出する（Ｓ２７）。管理部５４は、登録完了応答をＡＰＩ解析部５３に送出する（Ｓ２８）。

ＡＰＩ解析部５３は、ＡＰＩ対応表を生成していない上位ＡＰＩが上位ＡＰＩ定義情報にある場合、Ｓ２３に戻り次の上位ＡＰＩを選択して以降の処理を行う（Ｓ２９）。上位ＡＰＩ定義情報の全ての上位ＡＰＩのＡＰＩ対応表を生成した場合は、ＡＰＩ解析部５３は、登録完了通知をＵＩ部５２に送出する（Ｓ３０）。ＵＩ部５２は、登録完了通知をディスプレイに表示し、ＡＰＩ対応表の登録が完了したことをユーザに通知する。

なお、ＵＩ部５２によるディスプレイ表示は、グラフィカル(ＧＵＩ：Graphical User Interface）であっても、テキストベース(ＣＬＩ：Command Line Interface）であってもよく、表示デバイスに表示方式は依存しない。

図１３は、図１２のＳ２４の詳細な処理を示すフローチャートである。ＡＰＩ解析部５３は、Ｓ２２でＵＩ部５２から入力された上位ＡＰＩ定義情報、下位ＡＰＩ定義情報および内部状態定義情報を参照して以下の処理を行う。

ＡＰＩ解析部５３は、選択した上位ＡＰＩの出力情報（一部または全部）を出力する下位ＡＰＩを抽出する（Ｓ３１）。ＡＰＩ解析部５３は、抽出した下位ＡＰＩのうち、上位ＡＰＩの入力情報および内部状態定義情報だけで実行可能な下位ＡＰＩを抽出し、抽出した下位ＡＰＩをＡＰＩ対応表に登録する（Ｓ３２）。

ＡＰＩ解析部５３は、ＡＰＩ対応表に登録された全ての下位ＡＰＩを実行することで、上位ＡＰＩの全ての出力情報が出力されるか（すなわち、上位ＡＰＩの全ての出力情報を充足しているか）否かを判定する（Ｓ３３）。上位ＡＰＩの全ての出力情報が出力される場合、ＡＰＩ解析部５３は選択した上位ＡＰＩのＡＰＩ対応表の生成を終了する。上位ＡＰＩの全ての出力情報が出力されない場合、ＡＰＩ解析部５３はＳ３４に進み、下位ＡＰＩ間の依存関係を検証する。

ＡＰＩ解析部５３は、Ｓ３２でＡＰＩ対応表に登録されない下位ＡＰＩのうち、上位ＡＰＩの出力情報を少なくとも１つ以上出力する下位ＡＰＩを抽出し、抽出した下位ＡＰＩの入力情報を取得する（Ｓ３４）。ＡＰＩ解析部５３は、Ｓ３４で抽出された下位ＡＰＩの入力情報を出力情報に含む下位ＡＰＩを抽出する（Ｓ３５）。

ＡＰＩ解析部５３は、Ｓ３５で抽出した下位ＡＰＩ毎に、当該下位ＡＰＩの全ての入力情報が、上位ＡＰＩの入力情報、内部状態定義情報、およびＡＰＩ対応表に登録された下位ＡＰＩの出力情報に含まれるか否かを判定する。ＡＰＩ解析部５３は、全ての入力情報が上位ＡＰＩの入力情報、内部状態定義情報、およびＡＰＩ対応表に登録された下位ＡＰＩの出力情報に含まれる場合は、当該下位ＡＰＩは実行可能と判定し、そうでない場合は、当該下位ＡＰＩは実行不可能と判定する（Ｓ３６）。

実行不可能と判定した下位ＡＰＩについて、ＡＰＩ解析部５３は、上位ＡＰＩの入力情報、内部状態定義情報、およびＡＰＩ対応表に登録された下位ＡＰＩの出力情報に含まれない入力情報を出力情報に含む下位ＡＰＩを抽出し、抽出された下位ＡＰＩの全ての入力情報が、上位ＡＰＩの入力情報、内部状態定義情報、およびＡＰＩ対応表に登録された下位ＡＰＩの出力情報に含まれる場合、当該下位ＡＰＩは実行可能であると判定する。

ＡＰＩ解析部５３は、Ｓ３４～Ｓ３６で確認した下位ＡＰＩの実行の依存関係に基づいて、実行可能と判定された下位ＡＰＩを、実行可能と判定された順番でＡＰＩ対応表に登録する（Ｓ３７）。ＡＰＩ解析部５３は、ＡＰＩ対応表に下位ＡＰＩを登録する度に、上位ＡＰＩの全ての出力情報がＡＰＩ対応表に登録された下位ＡＰＩの出力情報で出力されたか否かを判別する。ＡＰＩ解析部５３は、上位ＡＰＩの全ての出力情報が出力されるまで、Ｓ３４～Ｓ３６の処理を繰り返し行い、上位ＡＰＩの全ての出力情報が出力されると処理を終了する。

図１４は、本実施形態のサービス連携システムのサービス実行時の動作を示すシーケンス図である。

サービス連携装置（上位装置）１は、クライアントから連携サービスに対するオーダー（ＰｒｏｄｕｃｔＯｒｄｅｒ）で指定された連携カタログをカタログ管理部に要求し、連携カタログを取得する。そして、サービス連携装置１は、連携カタログに含まれる複数のサービスの各アダプタ部に、各サービスが公開する下位ＡＰＩの実行を指示する。

図示する例では、アプリサービス２Ｃのアダプタ部は、連携支援装置５がアプリサービス（下位装置）２Ｃ用に公開するステートレスな下位ＡＰＩを実行する。すなわち、アダプタ部は、アプリサービス２ＣのステートフルＡＰＩの実行を指示するリクエスト（例えば、ＰＯＳＴメソッド）を、ステートレスな上位ＡＰＩを介して連携支援装置５に送信する（Ｓ５１）。この下位ＡＰＩの実行指示リクエストは、アプリサービス２Ｃを操作するためのリクエストである。

連携支援装置５の実行部５１は、サービス連携装置１からリクエストを受信し、当該リクエストに含まれる上位ＡＰＩ名、メソッドに対応する下位ＡＰＩリストを、管理部５４に要求する（Ｓ５２）。管理部５４は、上位ＡＰＩ名およびメソッドを検索キーとして、ＤＢ５６に格納されたＡＰＩ対応表の対応する下位ＡＰＩリストを取得する（Ｓ５３、Ｓ５４）。管理部５４は、取得した下位ＡＰＩリストを実行部５１に送出する（Ｓ５５）。下位ＡＰＩリストは、具体的には、図５のＡＰＩ対応表６２の下位ＡＰＩ欄の下位ＡＰＩが実行順に設定されたリストである。

実行部５１は、取得した下位ＡＰＩリストを用いて、アプリサービス２Ｃが公開するステートフルな下位ＡＰＩを実行する。すなわち、実行部５１は、下位ＡＰＩリストの記載順で、下位ＡＰＩを順次実行する（Ｓ５６）。具体的には、実行部５１は、下位ＡＰＩの実行指示リクエストを送信する際に、記憶部５５に記憶した内部状態を付加したリクエストをアプリサービス２Ｃに送信し、下位ＡＰＩを実行する。（Ｓ５６１）。アプリサービス２Ｃは、当該リクエストで指示された下位ＡＰＩを実行し（Ｓ５６２）、実行結果（応答）を実行部５１に送信する（Ｓ５６３）。実行部５１は、下位ＡＰＩから受信した実行結果を記憶部５５に記憶する。

なお、アプリサービス２Ｃは、連携支援装置５との初回の通信時には、セッション情報などの内部状態を実行結果に付加して実行部５１に送信する。実行部５１は、内部状態を取得すると、記憶部５５に内部状態を登録する。実行部５１は、初回通信時など、内部状態が記憶部５５に記憶されていない場合は、内部状態を付加しないリクエストをアプリサービス２Ｃに送信し、下位ＡＰＩを実行してもよい。

実行部５１は、下位ＡＰＩリストの全ての下位ＡＰＩの実行を完了した後に、上位ＡＰＩの仕様に従って、記憶部５５に一時保存していた実行結果をサービス連携装置１に送信する。図示する例では、実行部５１は、下位ＡＰＩの実行結果を保持している旨をサービス連携装置１に通知する（Ｓ５７）。具体的には、実行部５１は、リクエストが成功してリソースの作成が完了したことを示す「２０１Ｃｒｅａｔｅｄ」（正常応答）をサービス連携装置１に送信する。

サービス連携装置１のアダプタ部２３は、Ｓ５７の応答を受信すると、実行結果を取得するためのリクエスト（ＧＥＴメソッド）を、連携支援装置５に送信する（Ｓ５８）。連携支援装置５の実行部５１は、記憶部５５に保持した実行結果を２００ＯＫ（正常応答）とともにサービス連携装置１に送信する（Ｓ５９）。サービス連携装置１は、アプリカタログのcharacteristicに実行結果を格納し、連携カタログのルールに従って、取得した実行結果を連携サービスを構成する各サービスに反映させる補完処理を実行する。なお、サービス連携装置１への実行結果の送信は、Ｓ５７～Ｓ５９の処理に限定されない。

（本実施形態の効果）
以上説明した本実施形態のサービス連携支援装置は、複数のサービスを連携させるサービス連携装置（上位装置）に公開するステートレスな上位ＡＰＩの定義情報と、下位装置が公開するステートフルな複数の下位ＡＰＩの定義情報と、を受け付けるＵＩ部５２と、上位ＡＰＩの定義情報および前記下位ＡＰＩの定義情報を用いて、上位ＡＰＩに対応する少なくとも１つの下位ＡＰＩを抽出し、抽出した下位ＡＰＩの実行順序を設定したＡＰＩ対応表を生成する解釈部５３とを有する。

このように本実施形態では、入力された定義情報を用いてステートレスな上位ＡＰＩとステートフルな下位ＡＰＩとを対応付けたＡＰＩ対応表を生成する。これにより、本実施形態では、ステートレスな上位ＡＰＩとステートフルな下位ＡＰＩとの間のマッピングを容易に行うことができる。すなわち、本実施形態では、ステートフルＡＰＩを公開するサービスを、他のサービスと容易に連携させることができる。したがって、本実施形態では、ステートフルな下位ＡＰＩのサービスを含む複数のサービスを、短期間に低コストで連携させることができる。

（ハードウェア構成）
上記説明した連携支援装置５およびサービス連携装置１は、例えば、図１５に示すような汎用的なコンピュータシステムを用いることができる。図示するコンピュータシステムは、CPU（Central Processing Unit、プロセッサ）９０１と、メモリ９０２と、ストレージ９０３（HDD：Hard Disk Drive、SSD：Solid State Drive）と、通信装置９０４と、入力装置９０５と、出力装置９０６とを備える。メモリ９０２およびストレージ９０３は、記憶装置である。このコンピュータシステムにおいて、CPU９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、連携支援装置５およびサービス連携装置１の各機能は、連携支援装置５用のプログラムの場合は連携支援装置５のCPUが、サービス連携装置１用のプログラムの場合はサービス連携装置１のCPUが、それぞれ実行することにより実現される。

また、連携支援装置５およびサービス連携装置１は、１つのコンピュータで実装されてもよく、あるいは複数のコンピュータで実装されても良い。また、連携支援装置５およびサービス連携装置１は、コンピュータに実装される仮想マシンであっても良い。

連携支援装置５用のプログラムおよびサービス連携装置１用のプログラムは、HDD、SSD、USB（Universal Serial Bus）メモリ、CD (Compact Disc)、DVD (Digital Versatile Disc)などのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。

なお、本発明は上記実施形態および変形例に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

１：サービス連携装置（上位装置）
１０：カタログ解釈実行部
２１、２２、２３：アダプタ部
３０：カタログ管理部
２Ａ、２Ｂ、２Ｃ：サービス
５：連携支援装置（サービス連携支援装置）
５１：実行部
５２：ＵＩ部（受付部）
５３：ＡＰＩ解析部（解釈部）
５４：管理部
５５：記憶部
５６：ＤＢ

Claims

サービス連携支援装置であって、
複数のサービスを連携させる上位装置に公開するステートレスな上位ＡＰＩの定義情報と、下位装置が公開するステートフルな複数の下位ＡＰＩの定義情報と、を受け付ける受付部と、
前記上位ＡＰＩの定義情報および前記下位ＡＰＩの定義情報を用いて、前記上位ＡＰＩに対応する少なくとも１つの下位ＡＰＩを抽出し、抽出した下位ＡＰＩの実行順序を設定したＡＰＩ対応表を生成する解釈部と、を有する
サービス連携支援装置。
請求項１に記載のサービス連携支援装置であって、
前記解釈部は、前記上位ＡＰＩの出力情報を出力する下位ＡＰＩを抽出し、抽出した下位ＡＰＩの入力情報が前記上位ＡＰＩの入力情報のみの場合、当該下位ＡＰＩの実行順序を他の下位ＡＰＩより優先する
サービス連携支援装置。
請求項１または２に記載のサービス連携支援装置であって、
前記受付部は、前記下位ＡＰＩの実行時に通知される内部状態の定義情報を受け付け、
前記解釈部は、前記内部状態の定義情報を用いて前記ＡＰＩ対応表を生成する
サービス連携支援装置。
請求項１から３のいずれか１項に記載のサービス連携支援装置であって、
前記上位装置からのリクエストに応じて、上位ＡＰＩに対応するステートフルな下位ＡＰＩを前記ＡＰＩ対応表を用いて特定し、特定した下位ＡＰＩを前記ＡＰＩ対応表で指定された順序で実行する実行部と、
前記下位ＡＰＩの応答に含まれる内部状態を記憶する記憶部と、を備える
サービス連携支援装置。
サービス連携支援装置が行うサービス連携支援方法であって、
複数のサービスを連携させる上位装置に公開するステートレスな上位ＡＰＩの定義情報と、下位装置が公開するステートフルな複数の下位ＡＰＩの定義情報と、を受け付ける受付ステップと、
前記上位ＡＰＩの定義情報および前記下位ＡＰＩの定義情報を用いて、前記上位ＡＰＩに対応する少なくとも１つの下位ＡＰＩを抽出し、抽出した下位ＡＰＩの実行順序を設定したＡＰＩ対応表を生成する生成ステップと、を行う
サービス連携支援方法。
請求項５に記載のサービス連携支援方法であって、
前記上位装置からのリクエストに応じて、上位ＡＰＩに対応するステートフルな下位ＡＰＩを前記ＡＰＩ対応表を用いて特定し、特定した下位ＡＰＩを前記ＡＰＩ対応表で指定された順序で実行する実行ステップと、
前記下位ＡＰＩの応答に含まれる内部状態を記憶する記憶ステップと、を行う
サービス連携支援方法。
請求項５または６に記載のサービス連携支援方法であって、
前記受付ステップは、前記下位ＡＰＩの実行時に通知される内部状態の定義情報を受け付け、
前記生成ステップは、前記内部状態の定義情報を用いて前記ＡＰＩ対応表を生成する
サービス連携支援方法。
請求項１から４のいずれか１項に記載のサービス連携支援装置として、コンピュータを機能させるサービス連携支援プログラム。