JP2020009073A - 変換装置および変換プログラム - Google Patents

Abstract

【課題】アプリケーション側がプラットフォーム側のＡＰＩの更新に効率的かつ確実に対応できるようにする。【解決手段】変換装置１０において、ＡＰＩ管理部２２は、各アプリケーション側ＡＰＩ４１についてデータ項目の名前および識別子を示すアプリケーション側スキーマ３２を、各プラットフォーム側ＡＰＩ５１についてデータ項目の名前および識別子を示すプラットフォーム側スキーマ３３と照合して、各アプリケーション側ＡＰＩ４１のデータ項目の名前と、対応するプラットフォーム側ＡＰＩ５１のデータ項目の名前との紐付けを定義するＡＰＩ変換定義３４を生成する。ＡＰＩ変換部２１は、ＡＰＩ変換定義３４に従って、各アプリケーション側ＡＰＩ４１と、対応するプラットフォーム側ＡＰＩ５１との間のデータ変換を行う。【選択図】図１

Description

本発明は、変換装置および変換プログラムに関するものである。

特許文献１には、共通ＡＰＩと独自ＡＰＩとの間で、類似度が高いデータまたはグループを１対１でマッピングさせ、そのマッピングに基づいて、ＡＰＩ変換テーブルを作成する技術が記載されている。「ＡＰＩ」は、Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅの略語である。

特開２０１７−０４１１５８号公報

機器の状態の見える化または遠隔からの制御を行うために、クラウド上のプラットフォームに様々な機器が接続され、そのプラットフォーム上に様々なアプリケーションが構築されているとする。また、プラットフォーム側では、アプリケーション側に対して機器の制御またはデータ参照用の汎用的なＡＰＩを提供しており、アプリケーション側では、そのＡＰＩから本質的に必要な部分を選択し、必要に応じてデータ名称の読み替えまたはデータ構造の変換を設計しているとする。このような場合、プラットフォーム側のＡＰＩのライフサイクルはプラットフォーム依存であり、アプリケーション側のＡＰＩのライフサイクルとは関係なく変更またはバージョンアップが発生する。その結果、アプリケーション側のＡＰＩのデータ名称およびデータ構造とプラットフォーム側のＡＰＩのデータ名称およびデータ構造との間に違いが生じることになる。この違いへ対応するため、また、プラットフォーム側のＡＰＩのライフサイクルに対応するため、アプリケーション側では、違いを吸収する変換ロジックを開発し、プラットフォーム側のＡＰＩが更新される度に、変換ロジックを改変する対応方法をとることが考えられる。しかし、この対応方法では、アプリケーションごとに変換ロジックを開発することになり、プラットフォーム側のＡＰＩの更新時の開発コストも大きくなるため、変換ロジックの開発効率化が課題になる。

特許文献１に記載の技術では、共通ＡＰＩと独自ＡＰＩとの間で、類似度が高いデータまたはグループを１対１でマッピングさせているため、類似度の計算精度によっては両ＡＰＩ間の違いを正しく吸収することができない。

そこで、上記課題に対し、機器データの単純さに着目する。一般的に機器データは構造が単純であり、データ名称の変換またはデータ構造の変換は設定レベルに落とすことが可能である。そのため、設定レベルで上記変換ロジックと同等の仕組みを実現できれば開発が効率化できると考えられる。

本発明は、アプリケーション側がプラットフォーム側のＡＰＩの更新に効率的かつ確実に対応できるようにすることを目的とする。

本発明の一態様に係る変換装置は、
サービスを利用するためのアプリケーションプログラミングインタフェースであるアプリケーション側ＡＰＩで扱われるデータに含まれるデータ項目の名前および識別子を示すアプリケーション側スキーマを、前記サービスを提供するためのアプリケーションプログラミングインタフェースであるプラットフォーム側ＡＰＩで扱われるデータに含まれるデータ項目の名前および識別子を示すプラットフォーム側スキーマと照合して、前記アプリケーション側スキーマに示されているデータ項目の名前と、前記プラットフォーム側スキーマに示されている、対応するデータ項目の名前との紐付けを定義するＡＰＩ変換定義を生成するＡＰＩ管理部と、
前記ＡＰＩ管理部により生成されたＡＰＩ変換定義に従って、前記アプリケーション側ＡＰＩで扱われるデータに含まれるデータ項目の名前と、前記プラットフォーム側ＡＰＩで扱われるデータに含まれるデータ項目の名前との間の変換を行うＡＰＩ変換部と
を備える。

本発明では、アプリケーション側とプラットフォーム側とでデータ項目の識別子を共通化することにより、設定レベルで前述した変換ロジックと同等の仕組みを実現できる。そのため、本発明によれば、アプリケーション側がプラットフォーム側のＡＰＩの更新に効率的かつ確実に対応できるようになる。

実施の形態１に係る変換装置の構成を示すブロック図。 実施の形態１に係るデータ項目一覧の例を示す表。 実施の形態１に係るアプリケーション側スキーマの例を示す図。 実施の形態１に係るアプリケーション側スキーマの例を示す図。 実施の形態１に係るプラットフォーム側スキーマの例を示す図。 実施の形態１に係るプラットフォーム側スキーマの例を示す図。 実施の形態１に係るＡＰＩ変換定義の例を示す図。 実施の形態１に係るＡＰＩ変換定義の例を示す図。 実施の形態１に係る有効条件の例を示す表。 実施の形態１に係る変換装置の動作を示すフローチャート。 実施の形態２に係る変換装置の構成を示すブロック図。 実施の形態２に係る変換装置の動作を示すフローチャート。 実施の形態２に係る変換装置の動作を示すフローチャート。

以下、本発明の実施の形態について、図を用いて説明する。各図中、同一または相当する部分には、同一符号を付している。実施の形態の説明において、同一または相当する部分については、説明を適宜省略または簡略化する。なお、本発明は、以下に説明する実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。例えば、以下に説明する実施の形態のうち、２つ以上の実施の形態が組み合わせられて実施されても構わない。あるいは、以下に説明する実施の形態のうち、１つの実施の形態または２つ以上の実施の形態の組み合わせが部分的に実施されても構わない。

実施の形態１．
本実施の形態について、図１から図１０を用いて説明する。

＊＊＊構成の説明＊＊＊
図１を参照して、本実施の形態に係る変換装置１０の構成を説明する。

変換装置１０は、複数のアプリケーション４０とプラットフォーム５０との間に設置される。変換装置１０は、アプリケーション側ＡＰＩ４１とプラットフォーム側ＡＰＩ５１との間のデータ名称およびデータ構造の変換を行うコンピュータである。なお、変換の対象となるアプリケーション側ＡＰＩ４１は、本実施の形態では２つ以上あるが、１つ以上あればよい。変換対象となるプラットフォーム側ＡＰＩ５１は、本実施の形態では２つ以上あるが、１つ以上あればよい。

それぞれのアプリケーション４０は、図示していない機器からのデータ収集と機器の制御との少なくともいずれかのサービスを利用するプログラムである。それぞれのアプリケーション側ＡＰＩ４１は、１つ以上のアプリケーション４０の開発に用いられる。すなわち、それぞれのアプリケーション側ＡＰＩ４１は、上記サービスを利用するためのアプリケーションプログラミングインタフェースである。

プラットフォーム５０は、上記サービスを提供するプログラムまたはそのプログラムが動作するシステムである。それぞれのプラットフォーム側ＡＰＩ５１は、プラットフォーム５０の開発に用いられる。すなわち、それぞれのプラットフォーム側ＡＰＩ５１は、上記サービスを提供するためのアプリケーションプログラミングインタフェースである。

機器は、インターネット等のネットワークを介してプラットフォーム５０と接続される。本実施の形態では、家電、スマートメータおよびゲートウェイ装置といった各種機器によってフィールド環境が構築され、複数のアプリケーション４０およびプラットフォーム５０によってクラウド環境が構築される。

なお、変換装置１０は、プラットフォーム５０に統合されてもよい。

変換装置１０は、プロセッサ１１を備えるとともに、メモリ１２および通信デバイス１３といった他のハードウェアを備える。プロセッサ１１は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。

変換装置１０は、機能要素として、ＡＰＩ変換部２１と、ＡＰＩ管理部２２とを備える。ＡＰＩ変換部２１は、データ変換機能２３、データ名称変換機能２４およびデータ構造変換機能２５等の機能を持つ。ＡＰＩ管理部２２は、変換定義生成機能２６、データ項目管理機能２７および公開ＡＰＩ削除機能２８等の機能を持つ。ＡＰＩ変換部２１およびＡＰＩ管理部２２の機能は、ソフトウェアにより実現される。具体的には、ＡＰＩ変換部２１およびＡＰＩ管理部２２の機能は、変換プログラムにより実現される。変換プログラムは、ＡＰＩ変換部２１およびＡＰＩ管理部２２により行われる処理をそれぞれＡＰＩ変換処理およびＡＰＩ管理処理としてコンピュータに実行させるプログラムである。変換プログラムは、コンピュータ読取可能な媒体に記録されて提供されてもよいし、記録媒体に格納されて提供されてもよいし、プログラムプロダクトとして提供されてもよい。

プロセッサ１１は、変換プログラムを実行する装置である。プロセッサ１１は、例えば、ＣＰＵである。「ＣＰＵ」は、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略語である。

メモリ１２は、変換プログラムをあらかじめまたは一時的に記憶する装置である。メモリ１２は、例えば、ＲＡＭ、フラッシュメモリまたはこれらの組み合わせである。「ＲＡＭ」は、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略語である。

通信デバイス１３は、変換プログラムに入力されるデータを受信するレシーバ１４と、変換プログラムから出力されるデータを送信するトランスミッタ１５とを備える。通信デバイス１３は、例えば、通信チップまたはＮＩＣである。「ＮＩＣ」は、Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄの略語である。

変換プログラムは、メモリ１２からプロセッサ１１に読み込まれ、プロセッサ１１によって実行される。メモリ１２には、変換プログラムだけでなく、ＯＳも記憶されている。「ＯＳ」は、Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍの略語である。プロセッサ１１は、ＯＳを実行しながら、変換プログラムを実行する。なお、変換プログラムの一部または全部がＯＳに組み込まれていてもよい。

変換プログラムおよびＯＳは、補助記憶装置に記憶されていてもよい。補助記憶装置は、例えば、ＨＤＤ、フラッシュメモリまたはこれらの組み合わせである。「ＨＤＤ」は、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅの略語である。変換プログラムおよびＯＳは、補助記憶装置に記憶されている場合、メモリ１２にロードされ、プロセッサ１１によって実行される。

変換装置１０は、プロセッサ１１を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、変換プログラムの実行を分担する。それぞれのプロセッサは、例えば、ＣＰＵである。

変換プログラムにより利用、処理または出力されるデータ、情報、信号値および変数値は、メモリ１２、補助記憶装置、または、プロセッサ１１内のレジスタまたはキャッシュメモリに記憶される。

変換装置１０は、１台のコンピュータで構成されていてもよいし、複数台のコンピュータで構成されていてもよい。変換装置１０が複数台のコンピュータで構成されている場合は、ＡＰＩ変換部２１およびＡＰＩ管理部２２の機能が、各コンピュータに分散されて実現されてもよい。

本実施の形態では、データ項目一覧３１、アプリケーション側スキーマ３２、プラットフォーム側スキーマ３３、ＡＰＩ変換定義３４および有効条件３５がメモリ１２に記憶される。

データ項目一覧３１の例を図２に示す。データ項目一覧３１は、複数のアプリケーション側ＡＰＩ４１と複数のプラットフォーム側ＡＰＩ５１との間で共通する、データ項目ごとの識別子、型および種別を示すデータである。

アプリケーション側スキーマ３２の例を図３および図４に示す。アプリケーション側スキーマ３２は、各アプリケーション側ＡＰＩ４１で扱われるデータに含まれるデータ項目の名前および識別子を示す情報である。具体的には、アプリケーション側スキーマ３２は、各アプリケーション側ＡＰＩ４１のエンドポイント、リクエストレスポンスで扱われるデータに含まれるデータ項目の名前および識別子を示す情報である。「エンドポイント」はアプリケーション側ＡＰＩ４１の所在を示す識別名であり、ＡＰＩの公開方法により、関数名、ＵＲＩ等がある。「ＵＲＩ」は、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒの略語である。本実施の形態では、アプリケーション側スキーマ３２は、各アプリケーション側ＡＰＩ４１で扱われるデータに含まれるデータ項目の型をさらに示す情報である。また、アプリケーション側スキーマ３２は、各アプリケーション側ＡＰＩ４１で扱われるデータの構造をさらに示す情報である。

プラットフォーム側スキーマ３３の例を図５および図６に示す。プラットフォーム側スキーマ３３は、各プラットフォーム側ＡＰＩ５１で扱われるデータに含まれるデータ項目の名前および識別子を示す情報である。具体的には、プラットフォーム側スキーマ３３は、各プラットフォーム側ＡＰＩ５１のエンドポイント、リクエストレスポンスで扱われるデータに含まれるデータ項目の名前および識別子を示す情報である。本実施の形態では、プラットフォーム側スキーマ３３は、各プラットフォーム側ＡＰＩ５１で扱われるデータに含まれるデータ項目の型をさらに示す情報である。また、プラットフォーム側スキーマ３３は、各プラットフォーム側ＡＰＩ５１で扱われるデータの構造をさらに示す情報である。

ＡＰＩ変換定義３４の例を図７および図８に示す。ＡＰＩ変換定義３４は、各アプリケーション側ＡＰＩ４１についてアプリケーション側スキーマ３２に示されているデータ項目の名前と、対応するプラットフォーム側ＡＰＩ５１についてプラットフォーム側スキーマ３３に示されている、対応するデータ項目の名前との紐付けを定義する情報である。この紐付けは、後述するように、アプリケーション側スキーマ３２に示されている識別子と、プラットフォーム側スキーマ３３に示されている識別子とを突き合わせた結果に応じて行われる。本実施の形態では、ＡＰＩ変換定義３４は、各アプリケーション側ＡＰＩ４１についてアプリケーション側スキーマ３２に示されているデータの構造と、対応するプラットフォーム側ＡＰＩ５１についてプラットフォーム側スキーマ３３に示されているデータの構造との少なくともいずれか一方から他方への変換のしかたをさらに定義する情報である。

有効条件３５の例を図９に示す。有効条件３５は、公開されているアプリケーション側ＡＰＩ４１を削除するための条件を定義するデータである。

＊＊＊動作の説明＊＊＊
図１０を参照して、本実施の形態に係る変換装置１０の動作を説明する。変換装置１０の動作は、本実施の形態に係る変換方法に相当する。

ステップＳ１０１において、ＡＰＩ管理部２２は、アプリケーション側スキーマ３２をプラットフォーム側スキーマ３３と照合してＡＰＩ変換定義３４を生成する。

具体的には、ＡＰＩ管理部２２は、アプリケーション側ＡＰＩ４１ごとに、アプリケーション側スキーマ３２に示されているデータ項目の識別子をキーとしてプラットフォーム側スキーマ３３を検索することで、対応するプラットフォーム側ＡＰＩ５１を抽出する。そして、ＡＰＩ管理部２２は、アプリケーション側ＡＰＩ４１ごとに、アプリケーション側スキーマ３２に示されているデータ項目の名前と、抽出したプラットフォーム側ＡＰＩ５１についてプラットフォーム側スキーマ３３に示されている、対応するデータ項目の名前との紐付けを定義する情報をＡＰＩ変換定義３４として生成する。

本実施の形態では、ＡＰＩ管理部２２は、アプリケーション側ＡＰＩ４１ごとに、対応するプラットフォーム側ＡＰＩ５１を抽出する際に、アプリケーション側スキーマ３２に示されているデータ項目の識別子および型の組み合わせをキーとしてプラットフォーム側スキーマ３３を検索する。

本実施の形態では、ＡＰＩ管理部２２は、アプリケーション側スキーマ３２に２つ以上のデータ項目の識別子が示されているアプリケーション側ＡＰＩ４１については、プラットフォーム側スキーマ３３に当該２つ以上のデータ項目の識別子と同じ識別子を含む複数のデータ項目の識別子が示されているプラットフォーム側ＡＰＩ５１を、対応するプラットフォーム側ＡＰＩ５１として抽出する。そして、ＡＰＩ管理部２２は、アプリケーション側スキーマ３２に示されている２つ以上のデータ項目の名前と、抽出したプラットフォーム側ＡＰＩ５１についてプラットフォーム側スキーマ３３に示されている同数のデータ項目の名前との紐付けを定義する情報をＡＰＩ変換定義３４に含める。

なお、ＡＰＩ管理部２２は、アプリケーション側スキーマ３２およびプラットフォーム側スキーマ３３のほかに、ロール定義および有効期限といった他の情報も利用して、ＡＰＩ変換定義３４を生成してもよい。

ステップＳ１０２において、ＡＰＩ管理部２２は、各アプリケーション側ＡＰＩ４１を公開する。これにより、任意のアプリケーション側ＡＰＩ４１を用いたアプリケーション４０の開発または改修が可能となる。

公開されたアプリケーション側ＡＰＩ４１を用いて開発または改修されたアプリケーション４０が実行されると、ステップＳ１０３の処理が行われる。

ステップＳ１０３において、ＡＰＩ変換部２１は、ＡＰＩ管理部２２により生成されたＡＰＩ変換定義３４に従って、各アプリケーション側ＡＰＩ４１で扱われるデータに含まれるデータ項目の名前と、対応するプラットフォーム側ＡＰＩ５１で扱われるデータに含まれるデータ項目の名前との間の変換を行う。

本実施の形態では、ＡＰＩ変換部２１は、ＡＰＩ変換定義３４に従って、各アプリケーション側ＡＰＩ４１で扱われるデータの構造と、対応するプラットフォーム側ＡＰＩ５１で扱われるデータの構造との間の変換をさらに行う。

このように、ＡＰＩ変換定義３４に従って、公開されたアプリケーション側ＡＰＩ４１への入力がプラットフォーム側ＡＰＩ５１への入力に変換される。出力の変換についても同様である。

図２から図８の例を用いて、変換装置１０の動作の具体例を説明する。

ステップＳ１０１において、ＡＰＩ管理部２２は、アプリケーション側ＡＰＩ４１「ａｐｐ＿ａ＿ａｐｉ１」について、アプリケーション側スキーマ３２から、リクエストデータの第１データ項目の識別子「ｄｅｖｉｃｅ＿ｎａｍｅ」および型「ｓｔｒｉｎｇ」と、リクエストデータの第２データ項目の識別子「ｐｏｗｅｒ＿ｌｉｍｉｔ」および型「ｉｎｔ」と、レスポンスデータのデータ項目の識別子「ｒｅｔｕｒｎ＿ｃｏｄｅ」および型「ｉｎｔ」とを取得する。ＡＰＩ管理部２２は、取得したリクエストデータの第１データ項目の識別子「ｄｅｖｉｃｅ＿ｎａｍｅ」および型「ｓｔｒｉｎｇ」と、リクエストデータの第２データ項目の識別子「ｐｏｗｅｒ＿ｌｉｍｉｔ」および型「ｉｎｔ」と、レスポンスデータのデータ項目の識別子「ｒｅｔｕｒｎ＿ｃｏｄｅ」および型「ｉｎｔ」とをキーとして、プラットフォーム側スキーマ３３を検索する。プラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」について、プラットフォーム側スキーマ３３に、リクエストデータの第１データ項目の識別子「ｄｅｖｉｃｅ＿ｎａｍｅ」および型「ｓｔｒｉｎｇ」と、リクエストデータの第２データ項目の識別子「ｐｏｗｅｒ＿ｌｉｍｉｔ」および型「ｉｎｔ」と、レスポンスデータの第１データ項目の識別子「ｒｅｔｕｒｎ＿ｃｏｄｅ」および型「ｉｎｔ」とが示されている。そのため、ＡＰＩ管理部２２は、アプリケーション側ＡＰＩ４１「ａｐｐ＿ａ＿ａｐｉ１」に対応するプラットフォーム側ＡＰＩ５１として、プラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」を抽出する。プラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」について、プラットフォーム側スキーマ３３には、レスポンスデータの第２データ項目の識別子「ｒｅｔｕｒｎ＿ｍｅｓｓａｇｅ」および型「ｓｔｒｉｎｇ」も示されているが、完全一致は要求されない。すなわち、前述したように、ＡＰＩ管理部２２は、アプリケーション側スキーマ３２に２つ以上のデータ項目の識別子が示されているアプリケーション側ＡＰＩ４１については、プラットフォーム側スキーマ３３に当該２つ以上のデータ項目の識別子と同じ識別子を含む複数のデータ項目の識別子が示されているプラットフォーム側ＡＰＩ５１を、対応するプラットフォーム側ＡＰＩ５１として抽出する。

ＡＰＩ管理部２２は、アプリケーション側ＡＰＩ４１「ａｐｐ＿ａ＿ａｐｉ１」について、アプリケーション側スキーマ３２から、リクエストデータの第１データ項目の名前「ｐａｒａｍ０１」、リクエストデータの第２データ項目の名前「ｐａｒａｍ０２」およびレスポンスデータのデータ項目の名前「ｒｅｓｕｌｔ」を取得する。ＡＰＩ管理部２２は、プラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」について、プラットフォーム側スキーマ３３から、リクエストデータの第１データ項目の名前「ｐｒｏｐｅｒｔｙ０１」、リクエストデータの第２データ項目の名前「ｐｒｏｐｅｒｔｙ０２」およびレスポンスデータの第１データ項目の名前「ｒｅｓｕｌｔ０１」を取得する。また、ＡＰＩ管理部２２は、プラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」について、プラットフォーム側スキーマ３３から、リクエストデータの構造として、第１データ項目および第２データ項目が１つのブロック「ｂｌｏｃｋ０１」に格納される構造を特定する。ＡＰＩ管理部２２は、プラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」について、プラットフォーム側スキーマ３３から、レスポンスデータの構造として、第１データ項目が１つのブロック「ｂｌｏｃｋ０２」に格納される構造を特定する。そして、ＡＰＩ管理部２２は、アプリケーション側ＡＰＩ４１「ａｐｐ＿ａ＿ａｐｉ１」について、リクエストデータの第１データ項目の名前「ｐａｒａｍ０１」、リクエストデータの第２データ項目の名前「ｐａｒａｍ０２」およびレスポンスデータの第１データ項目の名前「ｒｅｓｕｌｔ」と、プラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」のリクエストデータの第１データ項目の名前「ｐｒｏｐｅｒｔｙ０１」、リクエストデータの第２データ項目の名前「ｐｒｏｐｅｒｔｙ０２」およびレスポンスデータの第１データ項目の名前「ｒｅｓｕｌｔ０１」との紐付けを定義する情報をＡＰＩ変換定義３４として生成する。この情報には、プラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」のリクエストデータの構造として、第１データ項目および第２データ項目が１つのブロック「ｂｌｏｃｋ０１」に格納される構造を定義する情報と、プラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」のレスポンスデータの構造として、データ項目が１つのブロック「ｂｌｏｃｋ０２」に格納される構造を定義する情報も含まれる。

識別子「ｄｅｖｉｃｅ＿ｎａｍｅ」および型「ｓｔｒｉｎｇ」の組み合わせと、識別子「ｐｏｗｅｒ＿ｌｉｍｉｔ」および型「ｉｎｔ」の組み合わせと、識別子「ｒｅｔｕｒｎ＿ｃｏｄｅ」および型「ｉｎｔ」の組み合わせは、いずれもデータ項目一覧３１において定義されており、アプリケーション開発者およびプラットフォーム開発者の間で共有されている。アプリケーション側スキーマ３２は、あらかじめアプリケーション開発者から提供される。プラットフォーム側スキーマ３３は、あらかじめプラットフォーム開発者から提供される。

アプリケーション側ＡＰＩ４１「ａｐｐ＿ａ＿ａｐｉ１」以外のアプリケーション側ＡＰＩ４１についても、同様にＡＰＩ変換定義３４に含まれる情報が生成される。

ステップＳ１０２において、ＡＰＩ管理部２２は、アプリケーション側ＡＰＩ４１「ａｐｐ＿ａ＿ａｐｉ１」を公開する。これにより、アプリケーション開発者がアプリケーション側ＡＰＩ４１「ａｐｐ＿ａ＿ａｐｉ１」を用いてアプリケーション４０を開発または改修できるようになる。

アプリケーション側ＡＰＩ４１「ａｐｐ＿ａ＿ａｐｉ１」以外のアプリケーション側ＡＰＩ４１についても、同様に公開される。

公開されたアプリケーション側ＡＰＩ４１「ａｐｐ＿ａ＿ａｐｉ１」を用いて開発または改修されたアプリケーション４０が実行され、アプリケーション側ＡＰＩ４１「ａｐｐ＿ａ＿ａｐｉ１」によって生成されたリクエストデータがアプリケーション４０から送信されたとする。

ステップＳ１０３において、ＡＰＩ変換部２１は、ＡＰＩ管理部２２により生成されたＡＰＩ変換定義３４に従って、アプリケーション４０から送信されたリクエストデータの第１データ項目の名前「ｐａｒａｍ０１」および第２データ項目の名前「ｐａｒａｍ０２」を、それぞれプラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」のリクエストデータの第１データ項目の名前「ｐｒｏｐｅｒｔｙ０１」および第２データ項目の名前「ｐｒｏｐｅｒｔｙ０２」に変換する。その際、ＡＰＩ変換部２１は、プラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」のリクエストデータの構造に合わせて、第１データ項目および第２データ項目を１つのブロック「ｂｌｏｃｋ０１」に格納して、変換後のリクエストデータをプラットフォーム側ＡＰＩ５１「ｄｅｆａｕｌｔ＿ａｐｉ１」に出力する。

このように、本実施の形態では、プラットフォーム５０の開発者からプラットフォーム側スキーマ３３とデータ項目一覧３１とが提供される。プラットフォーム側スキーマ３３には、ＡＰＩの識別子、呼び出し方法の定義、リクエストおよびレスポンスのデータ構造およびデータ項目に期待されるデータ実体の割り当て「＄ｐｒｏｐｅｒｔｙ」が定義されている。図示した例は、ＲＥＳＴ ＡＰＩの形式での定義となっているがデータベースの検索ＡＰＩに対する定義でもよい。「ＲＥＳＴ」は、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒの略語である。データ項目一覧３１には、データ項目の識別子、型および種別が定義されている。データ項目の種別としては、例えば、データ実体「ｐｒｏｐｅｒｔｙ」、補足データ「ｍｅｔａｄａｔａ」および操作に伴うデータ「ｃｏｎｔｒｏｌｄａｔａ」がある。

アプリケーション４０の開発者からはアプリケーション側スキーマ３２が提供され、ＡＰＩの公開が要求される。アプリケーション側スキーマ３２では、プラットフォーム側スキーマ３３と同様に、データ構造およびデータ項目が宣言されている。

ＡＰＩ管理部２２は、提供されたアプリケーション側スキーマ３２からデータ項目に定義されているデータ実体の割り当てを参照し、プラットフォーム側スキーマ３３のデータ項目を検索する。ＡＰＩ管理部２２は、リクエストおよびレスポンスで同様のデータ実体の割り当てを持つプラットフォーム側ＡＰＩ５１を検索し、最初に見つかったＡＰＩをアプリケーション側ＡＰＩ４１から変換して利用するＡＰＩとする。ＡＰＩ管理部２２は、発見したプラットフォーム側ＡＰＩ５１と対応するアプリケーション側ＡＰＩ４１とのマッピング定義であるＡＰＩ変換定義３４を生成し、アプリケーション側ＡＰＩ４１を公開する。

ＡＰＩ変換定義３４は、公開されたアプリケーション側ＡＰＩ４１を通じてアプリケーション４０から利用可能となる。なお、データ項目を別途管理する構成をとれば、ＡＰＩ変換時にデータ形式に応じた値の変換等の拡張も可能である。

プラットフォーム側ＡＰＩ５１に変更があった場合について説明する。

プラットフォーム側スキーマ３３の変更反映とともにＡＰＩ変換定義３４の再生成を行うことで、アプリケーション４０側の作業を必要とせずに対応できる。

プラットフォーム側ＡＰＩ５１にデータ項目の変更があった場合の動作について説明する。ＡＰＩ変換定義３４の更新の必要性で処置が変わる。

データ項目の追加があった場合、ＡＰＩ変換定義３４に更新の必要はないため、特に処置の必要はない。

データ項目の変更があった場合、アプリケーション側ＡＰＩ４１で使われているデータ項目の変更であれば、ＡＰＩ変換定義３４の再生成が必要である。アプリケーション側ＡＰＩ４１で使われていないデータ項目であれば、特に処置の必要はない。アプリケーション側ＡＰＩ４１で使われているかどうかの判断は、アプリケーション側スキーマ３２を検索することで確認できる。

本実施の形態では、ＡＰＩ管理部２２は、複数のプラットフォーム側ＡＰＩ５１のいずれかで扱われるデータに含まれるデータ項目の名前が変更された場合、そのデータ項目の名前がＡＰＩ変換定義３４で定義されている紐付けの対象となっていれば、そのデータ項目の名前の変更をＡＰＩ変換定義３４に反映する。

データ項目の削除があった場合、アプリケーション側ＡＰＩ４１で使われているデータ項目の削除は、そもそもプラットフォーム５０がアプリケーション４０の要件を満たせなくなるため認められない。アプリケーション側ＡＰＩ４１で使われていないデータ項目の削除であれば、特に処置の必要はない。

プラットフォーム側ＡＰＩ５１にデータ構造の変更があった場合は、ＡＰＩ変換定義３４が更新される。

本実施の形態では、アプリケーション４０側のライフサイクルに対する公開ＡＰＩの処置が行われる。アプリケーション側ＡＰＩ４１はアプリケーション４０側の要件に応じて動的に公開されるため、要件の変化によって利用されなくなった公開ＡＰＩを削除する必要がある。そのため、ＡＰＩ管理部２２は、複数のアプリケーション側ＡＰＩ４１の利用状況を監視し、利用状況が基準を満たしていないアプリケーション側ＡＰＩ４１を、複数のアプリケーション側ＡＰＩ４１を公開しているサイトから削除する。

公開ＡＰＩの削除は、ＡＰＩ管理部２２が有効条件３５を参照して制御する。有効条件３５としては、図９に示したような情報が管理されている。

具体的には、ＡＰＩ管理部２２は、メトリクス提供サービスにアクセスして公開ＡＰＩの稼働状況を確認する。ＡＰＩ管理部２２は、取得したデータから削除判断項目の値を参照し、削除閾値と比較する。ＡＰＩ管理部２２は、削除閾値を超えた公開ＡＰＩを削除する。

＊＊＊実施の形態の効果の説明＊＊＊
本実施の形態では、アプリケーション側とプラットフォーム側とでデータ項目の識別子を共通化することにより、設定レベルで前述した変換ロジックと同等の仕組みを実現できる。そのため、本実施の形態によれば、アプリケーション側がプラットフォーム側のＡＰＩの更新に効率的かつ確実に対応できるようになる。

＊＊＊他の構成＊＊＊
本実施の形態では、ＡＰＩ変換部２１およびＡＰＩ管理部２２の機能がソフトウェアにより実現されるが、変形例として、ＡＰＩ変換部２１およびＡＰＩ管理部２２の機能がソフトウェアとハードウェアとの組み合わせにより実現されてもよい。すなわち、ＡＰＩ変換部２１およびＡＰＩ管理部２２の機能の一部が専用のハードウェアにより実現され、残りがソフトウェアにより実現されてもよい。

専用のハードウェアは、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ、ＦＰＧＡ、ＡＳＩＣ、または、これらのうちいくつか、もしくは、すべての組み合わせである。「ＩＣ」は、Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔの略語である。「ＧＡ」は、Ｇａｔｅ Ａｒｒａｙの略語である。「ＦＰＧＡ」は、Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙの略語である。「ＡＳＩＣ」は、Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔの略語である。

プロセッサ１１および専用のハードウェアは、いずれも処理回路である。すなわち、ＡＰＩ変換部２１およびＡＰＩ管理部２２の機能がソフトウェアにより実現されるか、ソフトウェアとハードウェアとの組み合わせにより実現されるかに関わらず、ＡＰＩ変換部２１およびＡＰＩ管理部２２の動作は、処理回路により行われる。

実施の形態２．
本実施の形態について、主に実施の形態１との差異を、図１１から図１３を用いて説明する。

＊＊＊構成の説明＊＊＊
図１１を参照して、本実施の形態に係る変換装置１０の構成を説明する。

本実施の形態では、データ項目一覧３１、プラットフォーム側スキーマ３３、ＡＰＩ変換定義３４および有効条件３５のほかに、公開ＡＰＩアクセスログ３６がメモリ１２に記憶される。公開ＡＰＩアクセスログ３６は、メトリクス提供サービス用に外部に提供される。

本実施の形態では、アプリケーション４０からアプリケーション側スキーマ３２を含むＡＰＩ生成要求が入力される。

＊＊＊動作の説明＊＊＊
図１２および図１３を参照して、本実施の形態に係る変換装置１０の動作を説明する。変換装置１０の動作は、本実施の形態に係る変換方法に相当する。

図１２は、変換装置１０の、アプリケーション４０がトリガとなってＡＰＩを生成する部分のフローを示している。

ステップＳ２０１において、ＡＰＩ管理部２２は、アプリケーション４０からアプリケーション側スキーマ３２を含むＡＰＩ生成要求を受け付ける。ＡＰＩ管理部２２は、この要求に応じて、アプリケーション側スキーマ３２に対応するアプリケーション側ＡＰＩ４１を生成する。その後、生成されたアプリケーション側ＡＰＩ４１について、ステップＳ２０２以降の処理が行われる。

ステップＳ２０２からステップＳ２０４の処理については、図１０に示したステップＳ１０１からステップＳ１０３の処理と同じであるため、説明を省略する。

図１３は、変換装置１０の、有効条件３５からＡＰＩが削除される部分のフローを示している。

ステップＳ２１１において、ＡＰＩ管理部２２は、有効条件３５を取得する。

ステップＳ２１２において、ＡＰＩ管理部２２は、メトリクス提供サービスにアクセスして公開ＡＰＩの稼働状況を取得する。公開ＡＰＩとは、ステップＳ２０３で公開されたアプリケーション側ＡＰＩ４１のことである。

ステップＳ２１３において、ＡＰＩ管理部２２は、削除対象のＡＰＩがあるかどうかを判定する。削除対象のＡＰＩとは、有効条件３５に含まれる削除判断項目の値が削除閾値を超えた公開ＡＰＩのことである。削除対象のＡＰＩがあれば、ステップＳ２１４の処理が行われる。

ステップＳ２１４において、ＡＰＩ管理部２２は、削除対象のＡＰＩの公開を停止する。

＊＊＊実施の形態の効果の説明＊＊＊

本実施の形態では、アプリケーション４０がトリガとなってＡＰＩを生成する部分と、有効条件３５からＡＰＩが削除される部分とが変換装置１０に備えられることで、ライフサイクル管理が可能となる。

１０ 変換装置、１１ プロセッサ、１２ メモリ、１３ 通信デバイス、１４ レシーバ、１５ トランスミッタ、２１ ＡＰＩ変換部、２２ ＡＰＩ管理部、２３ データ変換機能、２４ データ名称変換機能、２５ データ構造変換機能、２６ 変換定義生成機能、２７ データ項目管理機能、２８ 公開ＡＰＩ削除機能、３１ データ項目一覧、３２ アプリケーション側スキーマ、３３ プラットフォーム側スキーマ、３４ ＡＰＩ変換定義、３５ 有効条件、３６ 公開ＡＰＩアクセスログ、４０ アプリケーション、４１ アプリケーション側ＡＰＩ、５０ プラットフォーム、５１ プラットフォーム側ＡＰＩ。

Claims (9)

1. サービスを利用するためのアプリケーションプログラミングインタフェースであるアプリケーション側ＡＰＩで扱われるデータに含まれるデータ項目の名前および識別子を示すアプリケーション側スキーマを、前記サービスを提供するためのアプリケーションプログラミングインタフェースであるプラットフォーム側ＡＰＩで扱われるデータに含まれるデータ項目の名前および識別子を示すプラットフォーム側スキーマと照合して、前記アプリケーション側スキーマに示されているデータ項目の名前と、前記プラットフォーム側スキーマに示されている、対応するデータ項目の名前との紐付けを定義するＡＰＩ変換定義を生成するＡＰＩ管理部と、
   前記ＡＰＩ管理部により生成されたＡＰＩ変換定義に従って、前記アプリケーション側ＡＰＩで扱われるデータに含まれるデータ項目の名前と、前記プラットフォーム側ＡＰＩで扱われるデータに含まれるデータ項目の名前との間の変換を行うＡＰＩ変換部と
   を備える変換装置。
2. 前記プラットフォーム側ＡＰＩは、２つ以上あり、
   前記ＡＰＩ管理部は、前記アプリケーション側スキーマに示されているデータ項目の識別子をキーとして前記プラットフォーム側スキーマを検索することで、対応するプラットフォーム側ＡＰＩを抽出する請求項１に記載の変換装置。
3. 前記アプリケーション側ＡＰＩは、１つ以上あり、
   前記プラットフォーム側ＡＰＩは、２つ以上あり、
   前記ＡＰＩ管理部は、前記アプリケーション側スキーマに２つ以上のデータ項目の識別子が示されているアプリケーション側ＡＰＩについては、前記プラットフォーム側スキーマに当該２つ以上のデータ項目の識別子と同じ識別子を含む複数のデータ項目の識別子が示されているプラットフォーム側ＡＰＩを、対応するプラットフォーム側ＡＰＩとして抽出し、前記アプリケーション側スキーマに示されている２つ以上のデータ項目の名前と、抽出したプラットフォーム側ＡＰＩについて前記プラットフォーム側スキーマに示されている同数のデータ項目の名前との紐付けを定義する情報を前記ＡＰＩ変換定義に含める請求項１または２に記載の変換装置。
4. 前記ＡＰＩ管理部は、前記プラットフォーム側ＡＰＩで扱われるデータに含まれるデータ項目の名前が変更された場合、そのデータ項目の名前が前記ＡＰＩ変換定義で定義されている紐付けの対象となっていれば、そのデータ項目の名前の変更を前記ＡＰＩ変換定義に反映する請求項１から３のいずれか１項に記載の変換装置。
5. 前記アプリケーション側スキーマは、前記アプリケーション側ＡＰＩで扱われるデータの構造をさらに示す情報であり、
   前記プラットフォーム側スキーマは、前記プラットフォーム側ＡＰＩで扱われるデータの構造をさらに示す情報であり、
   前記ＡＰＩ変換部は、前記ＡＰＩ変換定義に従って、前記アプリケーション側ＡＰＩで扱われるデータの構造と、前記プラットフォーム側ＡＰＩで扱われるデータの構造との間の変換をさらに行う請求項１から４のいずれか１項に記載の変換装置。
6. サービスを利用するためのアプリケーションプログラミングインタフェースであるアプリケーション側ＡＰＩで扱われるデータに含まれるデータ項目の名前と、前記サービスを提供するためのアプリケーションプログラミングインタフェースであるプラットフォーム側ＡＰＩで扱われるデータに含まれる、対応するデータ項目の名前との紐付けを定義するＡＰＩ変換定義に従って、前記アプリケーション側ＡＰＩで扱われるデータに含まれるデータ項目の名前と、前記プラットフォーム側ＡＰＩで扱われるデータに含まれるデータ項目の名前との間の変換を行うＡＰＩ変換部と、
   前記プラットフォーム側ＡＰＩで扱われるデータに含まれるデータ項目の名前が変更された場合、そのデータ項目の名前が前記ＡＰＩ変換定義で定義されている紐付けの対象となっていれば、そのデータ項目の名前の変更を前記ＡＰＩ変換定義に反映するＡＰＩ管理部と
   を備える変換装置。
7. 前記ＡＰＩ管理部は、前記アプリケーション側ＡＰＩの利用状況を監視し、利用状況が基準を満たしていなければ、前記アプリケーション側ＡＰＩを、前記アプリケーション側ＡＰＩを公開しているサイトから削除する請求項１から６のいずれか１項に記載の変換装置。
8. コンピュータに、
   サービスを利用するためのアプリケーションプログラミングインタフェースであるアプリケーション側ＡＰＩで扱われるデータに含まれるデータ項目の名前および識別子を示すアプリケーション側スキーマを、前記サービスを提供するためのアプリケーションプログラミングインタフェースであるプラットフォーム側ＡＰＩで扱われるデータに含まれるデータ項目の名前および識別子を示すプラットフォーム側スキーマと照合して、前記アプリケーション側スキーマに示されているデータ項目の名前と、前記プラットフォーム側スキーマに示されている、対応するデータ項目の名前との紐付けを定義するＡＰＩ変換定義を生成するＡＰＩ管理処理と、
   前記ＡＰＩ管理処理により生成されたＡＰＩ変換定義に従って、前記アプリケーション側ＡＰＩで扱われるデータに含まれるデータ項目の名前と、前記プラットフォーム側ＡＰＩで扱われるデータに含まれるデータ項目の名前との間の変換を行うＡＰＩ変換処理と
   を実行させる変換プログラム。
9. コンピュータに、
   サービスを利用するためのアプリケーションプログラミングインタフェースであるアプリケーション側ＡＰＩで扱われるデータに含まれるデータ項目の名前と、前記サービスを提供するためのアプリケーションプログラミングインタフェースであるプラットフォーム側ＡＰＩで扱われるデータに含まれる、対応するデータ項目の名前との紐付けを定義するＡＰＩ変換定義に従って、前記アプリケーション側ＡＰＩで扱われるデータに含まれるデータ項目の名前と、前記プラットフォーム側ＡＰＩで扱われるデータに含まれるデータ項目の名前との間の変換を行うＡＰＩ変換処理と、
   前記プラットフォーム側ＡＰＩで扱われるデータに含まれるデータ項目の名前が変更された場合、そのデータ項目の名前が前記ＡＰＩ変換定義で定義されている紐付けの対象となっていれば、そのデータ項目の名前の変更を前記ＡＰＩ変換定義に反映するＡＰＩ管理処理と
   を実行させる変換プログラム。

Images