(57)【要約】【課題】既存システムのＲＥＳＴ  ＡＰＩ化手法として、各種プロトコルに汎用的に対応可能な変換処理技術を確立し、本技術を用いたＡＰＩ変換アダプタ、ＡＰＩ変換システム、及びＡＰＩ変換プログラムを提供する。【解決手段】各種プロトコルに汎用的に対応可能なＲＥＳＴ  ＡＰＩ化変換処理技術として、ＡＰＩ変換アダプタ３０は、既存システム４０をＡＰＩ化するためのＡＰＩ変換アダプタであって、既存システム４０とのパケット送受信シーケンスを予め格納しているデータベース（格納部３６）と、受信したパケット内のパラメータを抽出する抽出部３１と、データベースに格納されているパケット内のパラメータを抽出部３１により抽出されたパラメータに置換する置換部３２と、置換部３２により置換されたパケットを用いて既存システム４０とパケットの送受信を実施するクライアント部３３とを備える。【選択図】図４
2017054411.tif 000002
【特許請求の範囲】
【請求項１】
既存システムをＡＰＩ化するためのＡＰＩ変換アダプタであって、
前記既存システムとのパケット送受信シーケンスを予め格納しているデータベースと、
受信したパケット内のパラメータを抽出する抽出部と、
前記データベースに格納されているパケット内のパラメータを前記抽出部により抽出されたパラメータに置換する置換部と、
前記置換部により置換されたパケットを用いて前記既存システムとパケットの送受信を実施するクライアント部と
を備えることを特徴とするＡＰＩ変換アダプタ。
【請求項２】
前記既存システムとＡＰＩゲートウェイとの間に配備されることを特徴とする請求項１に記載のＡＰＩ変換アダプタ。
【請求項３】
前記ＡＰＩゲートウェイとはＲＥＳＴで要求受付及び応答返却を行い、前記既存システムとは既存のプロトコルで送受信を行うことを特徴とする請求項２に記載のＡＰＩ変換アダプタ。
【請求項４】
既存システムをＡＰＩ化するためのＡＰＩ変換システムであって、
前記既存システムと、
前記既存システムを外部ネットワーク上のアプリケーション側から制御するためのＡＰＩを提供するＡＰＩゲートウェイと、
請求項１〜３のいずれか１項に記載のＡＰＩ変換アダプタと
を備えることを特徴とするＡＰＩ変換システム。
【請求項５】
請求項１〜３のいずれか１項に記載の各機能部としてコンピュータを機能させることを特徴とするＡＰＩ変換プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、既存システムをＡＰＩ化するためのＡＰＩ変換アダプタ、ＡＰＩ変換システム、及びＡＰＩ変換プログラムに関する。
【背景技術】
【０００２】
市場ではＩＴサービスの開発・提供形態やデバイスが変化してきており、公開されたＡＰＩ（Application Programming Interface）を活用し、新たなサービスを短期に、より容易に開発する流れが確立しつつある。公開ＡＰＩ数は近年大幅に増加し、特にＷｅｂアプリケーション設計様式であるＲＥＳＴ（Representational State Transfer）に準拠した設計手法のＡＰＩの増加が顕著である。
【０００３】
ＲＥＳＴは、主にＷｅｂ上にサービスを構築するためのソフトウェア設計様式であり、昨今は複数のサービスを連携させるのに適した方式として知られている。具体的には、図１６に示すように、アプリケーションＡがリソース識別子（ＵＲＩ）とリクエスト種別（ＧＥＴ／ＰＯＳＴ／ＰＵＴ／ＤＥＬＥＴＥ 等）を指定してＨＴＴＰでアクセスすると、アクセス先のアプリケーションＢからＸＭＬ形式やＪＳＯＮ形式で記述されたリソースデータが送られてくるようなシステム及び呼び出しインタフェースのことを指す。ＲＥＳＴは、ＳＯＡＰ等と比較して複雑な事前情報をかならずしも必要とせず、より簡易的に利用できることもあり、利用者が多いと推定される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第５０８９６２１号公報
【特許文献２】特開２００９−００９４５５号公報
【特許文献３】特開２００７−０２６１５０号公報
【特許文献４】特表２００５−５１２２１０号公報
【特許文献５】米国特許出願公開第２００７／００５０４４６号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
既存システムが具備する機能をＲＥＳＴ  ＡＰＩ化するためには、既存システムで採用されている多様なプロトコルをＲＥＳＴ準拠のＨＴＴＰに統一してＡＰＩを整備する必要がある（図１７参照）。従来はシステム毎に個別のプロトコル・データ変換処理プログラム等を作成する技術が必要となり、プログラム等の作成には多大なコストを要していた。
【０００６】
本発明は、上記課題を改善すべく、既存システムのＲＥＳＴ  ＡＰＩ化手法として、各種プロトコルに汎用的に対応可能な変換処理技術の確立を目的とし、本技術を用いたＡＰＩ変換アダプタ、ＡＰＩ変換システム、及びＡＰＩ変換プログラムの提供を目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、第１の態様に係る発明は、既存システムをＡＰＩ化するためのＡＰＩ変換アダプタであって、前記既存システムとのパケット送受信シーケンスを予め格納しているデータベースと、受信したパケット内のパラメータを抽出する抽出部と、前記データベースに格納されているパケット内のパラメータを前記抽出部により抽出されたパラメータに置換する置換部と、前記置換部により置換されたパケットを用いて前記既存システムとパケットの送受信を実施するクライアント部とを備えることを要旨とする。
【０００８】
第２の態様に係る発明は、第１の態様に係る発明において、前記既存システムとＡＰＩゲートウェイとの間に配備されることを要旨とする。
【０００９】
第３の態様に係る発明は、第２の態様に係る発明において、前記ＡＰＩゲートウェイとはＲＥＳＴで要求受付及び応答返却を行い、前記既存システムとは既存のプロトコルで送受信を行うことを要旨とする。
【００１０】
第４の態様に係る発明は、既存システムをＡＰＩ化するためのＡＰＩ変換システムであって、前記既存システムと、前記既存システムを外部ネットワーク上のアプリケーション側から制御するためのＡＰＩを提供するＡＰＩゲートウェイと、第１〜第３のいずれかの態様に係るＡＰＩ変換アダプタとを備えることを要旨とする。
【００１１】
第５の態様に係る発明は、ＡＰＩ変換プログラムであって、第１〜第３のいずれかの態様に係る各機能部としてコンピュータを機能させることを要旨とする。
【発明の効果】
【００１２】
本発明によれば、既存システムのＲＥＳＴ  ＡＰＩ化手法として、各種プロトコルに汎用的に対応可能な変換処理技術が利用可能となり、本技術を用いたＡＰＩ変換アダプタ、ＡＰＩ変換システム、及びＡＰＩ変換プログラムの提供が可能となる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施の形態におけるいくつかのプロトコルに対するＡＰＩ変換アダプタ機能を説明するための図である。
【図２】本発明の実施の形態において既存システムをＲＥＳＴ  ＡＰＩ化する３つの実現方式を示す図であり、（ａ）実現方式１、（ｂ）実現方式２、（ｃ）実現方式３。
【図３】本発明の実施の形態において既存システムをＲＥＳＴ  ＡＰＩ化するためのＡＰＩ変換アダプタの適用例の図であり、（ａ）既存形態、（ｂ）本発明の実施の形態。
【図４】本発明の実施の形態におけるＡＰＩ変換アダプタの機能ブロック図である。
【図５】本発明の実施の形態における格納部が格納するＤＢの構成図である。
【図６】本発明の実施の形態におけるＡＰＩ変換アダプタを用いて複数のアプリケーションが既存システムを利用する様子を示す図である。
【図７】本発明の実施の形態におけるＡＰＩ変換アダプタを用いてＡＰＩ変換を実施する場合のリクエスト、レスポンスの具体例を示す図である。
【図８】本発明の実施の形態におけるＡＰＩ変換アダプタを用いてＡＰＩ変換を実施する場合の動作例を示すフローチャートである。
【図９】本発明の実施の形態における抽出部がパケットからパス及びメソッドを抽出する様子を説明するための図である。
【図１０】本発明の実施の形態における抽出部がＡＰＩ＿ＤＢからＡＰＩを特定する様子を説明するための図である。
【図１１】本発明の実施の形態における抽出部がＥｘｔｒａｃｔ＿Ｒｕｌｅｓ＿ＤＢから抽出ルールを取得する様子を説明するための図である。
【図１２】本発明の実施の形態における抽出部がパケットからパラメータを抽出する様子を説明するための図である。
【図１３】本発明の実施の形態における置換部がＡＰＩ＿Ｆｌｏｗ＿ＤＢからパケットを取得する様子を説明するための図である。
【図１４】本発明の実施の形態における置換部がＲｅｐｌａｃｅｍｅｎｔ＿Ｒｕｌｅｓ＿ＤＢから置換ルールを取得する様子を説明するための図である。
【図１５】本発明の実施の形態における置換部がパケット内のパラメータを置換する様子を説明するための図である。
【図１６】ＲＥＳＴを用いたアプリケーション連携を示す図である。
【図１７】ＡＰＩ公開のためのシステムアーキテクチャ例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について図面を参照して詳細に説明する。なお、以下の実施の形態は、この発明の技術的思想を具体化するためのＡＰＩ変換アダプタを例示するものであり、装置の構成やデータの構成等は以下の実施の形態に限定されるものではない。
【００１５】
（ＡＰＩ変換アダプタ機能）
図１は、本発明の実施の形態におけるＡＰＩ変換アダプタ機能を説明するための図である。本発明の実施の形態は、ＡＰＩ化されていない既存システムを汎用的なＲＥＳＴで活用するために、既存システムをＲＥＳＴ  ＡＰＩ化するアーキテクチャに関する。
【００１６】
図１に示すように、呼制御サーバ４１、ガイダンスサーバ４２、ガイダンス設定サーバ４３、データベースサーバ全般４４、システム全般４５、メールサーバ４６等の既存システムがある。呼制御サーバ４１にはＳＩＰが利用され、ガイダンスサーバ４２にはＦＴＰが利用され、ガイダンス設定サーバ４３にはＨＴＴＰが利用され、データベースサーバ全般４４にはＪＤＢＣが利用され、システム全般４５にはＳＮＭＰが利用され、メールサーバ４６にはＳＭＴＰ，ＰＯＰが利用される。
【００１７】
そこで、本発明の実施の形態におけるＡＰＩ変換アダプタ機能は、各種プロトコルに応じた変換処理を実施し、既存システムを汎用的なＲＥＳＴ  ＡＰＩ化する。これにより、ＡＰＩ間で共通のアーキテクチャとし、汎用性を高める。また、ＡＰＩ変換アダプタ内の手順を統一し、その手順でモジュール分割を行うことによって、可読性の向上、モジュールの再利用、品質の安定化を図る。
【００１８】
（既存システムをＲＥＳＴ  ＡＰＩ化する方式の分類）
図２は、本発明の実施の形態において既存システム４０をＲＥＳＴ  ＡＰＩ化する３つの実現方式１〜３を示す図である。
【００１９】
実現方式１は、図２（ａ）に示すように、データベース等のミドルウェアが提供しているＡＰＩ化モジュール３０ａ等を既存システム４０に適用する方式である。言い換えると、既存ミドルウェアが提供しているＡＰＩラッパモジュールの適用である。
【００２０】
実現方式１のメリットとしては、既存システム４０を有効活用できる点、ＡＰＩゲートウェイ２０の製品（仕様）変更に影響しない点がある。一方、実現方式１のデメリットとしては、ＡＰＩ化モジュール３０ａを提供しているミドルウェアが限定される点、既存システム４０の改造が必要なためコストがかかる点がある。
【００２１】
実現方式２は、図２（ｂ）に示すように、Ｌｉｎｕｘ（登録商標）等に付属するＯＳＳミドルウェアとＡＰＩ化ソフトウェアの連携機能をＡＰＩ変換アダプタ３０ｂとして開発する方式である。言い換えると、オープンソースソフトウェア（ＯＳＳ）を活用したプログラム変換である。
【００２２】
実現方式２のメリットとしては、既存システム４０の改造が不要である点、ＡＰＩゲートウェイ２０の製品（仕様）変更に影響しない点、ＯＳＳ活用でコストを抑制できる点がある。一方、実現方式２のデメリットとしては、プロトコル別に対応する必要がある点がある。このデメリットは、後述する手法によって解消可能である。詳細については後述するが、パケットを利用することによって、パケットで表現されるプロトコルに対応できるようになっている。
【００２３】
実現方式３は、図２（ｃ）に示すように、ＡＰＩゲートウェイ２０に付属したＩＦ変換シナリオを作成する方式（用意された部品を組合せる方式）である。言い換えると、市中ＡＰＩゲートウェイ２０のＩＦ変換機能３０ｃの活用である。
【００２４】
実現方式３のメリットとしては、既存システム４０の改造が不要である点、ＡＰＩゲートウェイ２０に予め用意されたシナリオ生成用の部品を活用するため実装量が少ない点がある。一方、実現方式３のデメリットとしては、ＡＰＩゲートウェイ２０が製品変更になった場合に再度ＡＰＩゲートウェイ２０上で開発が必要となる点、対応できる非Ｗｅｂシステムが限定される点（ＡＰＩゲートウェイ２０製品依存である点）がある。
【００２５】
（各種プロトコルに汎用的に対応可能な変換処理技術の確立）
従来、ＡＰＩ化されていない既存システム４０については、図３（ａ）に示すように、既存システム４０とアプリケーション１０Ａ間においてパケットの送受信を行っていた。それに対して、本発明の実施の形態におけるＡＰＩ変換アダプタ３０は、図３（ｂ）に示すように、既存システム４０とアプリケーション１０Ｂ間のパケット送受信シーケンスを予めデータベース（ＤＢ）に格納しておき、そのパケットを利用してパラメータ部分のみを抽出・置換する。このように、パケットを利用することによって、簡易的にＡＰＩ化を実装することが可能となる。
【００２６】
（ＡＰＩ変換アダプタ）
図４は、本発明の実施の形態におけるＡＰＩ変換アダプタ３０の一例を示す機能ブロック図である。ここでは、電話等のサービスを提供する通信事業者が管理する通信事業者ネットワークに既存システム４０が接続されているものとする。ＡＰＩゲートウェイ２０は、既存システム４０を外部ネットワーク上のアプリケーション１０側から制御するためのＡＰＩ２１を提供する装置である。ＡＰＩ変換アダプタ３０は、実現方式２におけるＡＰＩ変換アダプタ３０ｂに相当する装置であり、ＡＰＩゲートウェイ２０と既存システム４０との間（より具体的には、通信事業者ネットワークの手前側）に配備される。
【００２７】
ＡＰＩ変換アダプタ３０の作成にあたり、各種機能及び各種プロトコルに対応できるようにするために、（１）ＡＰＩ間で共通の構造とすること、（２）ＡＰＩの追加が容易であることを設計方針とする。ＤＢとＷＡＤＬ（Web Application Description Language）を組合せることによって、汎用的なＲＥＳＴ  ＡＰＩ化を実現することが可能である。
【００２８】
図４に示すように、ＡＰＩ変換アダプタ３０は、抽出部３１，３４と、置換部３２，３５と、クライアント部３３と、格納部３６とを備える。格納部３６は、各種のＤＢを予め格納している。抽出部３１，３４は、抽出ルールをＤＢから取得し、ＤＢから取得した抽出ルールに基づいて、受信したパケット内のパラメータを抽出する。置換部３２，３５は、置換ルール、及び既存システム４０もしくはアプリケーション１０方向への送信パケットをＤＢから取得し、ＤＢから取得した置換ルールに基づいて、ＤＢから取得したパケット内のパラメータを抽出部３１，３４により抽出されたパラメータに置換する。図４において、上段の抽出部３１及び置換部３２は、右方向（アプリケーション１０から既存システム４０方向）に送信されるパケットを処理し、下段の抽出部３４及び置換部３５は、左方向（既存システム４０からアプリケーション１０方向）に送信されるパケットを処理するようになっている。クライアント部３３は、置換部３２により置換されたパケットを用いて既存システム４０とパケットの送受信を実施する。
【００２９】
図５は、本発明の実施の形態における格納部３６が格納するＤＢの構成図である。この図に示すように、格納部３６は、ＡＰＩ＿ＤＢ３６Ａと、Ｅｘｔｒａｃｔ＿Ｒｕｌｅｓ＿ＤＢ３６Ｂと、Ｒｅｐｌａｃｅｍｅｎｔ＿Ｒｕｌｅｓ＿ＤＢ３６Ｃと、ＡＰＩ＿Ｆｌｏｗ＿ＤＢ３６Ｄとを格納している。
【００３０】
ＡＰＩ＿ＤＢ３６Ａは、ＡＰＩの種類を格納しているＤＢである。例えば、ＡＰＩ＿ＤＢ３６Ａは、ＡＰＩ＿ＩＤ、ＡＰＩ名、メソッド、パスを紐付けて格納している。ＡＰＩ＿ＩＤは、ＡＰＩ２１の識別子である。ＡＰＩ名は、ＡＰＩ２１の名称である。
【００３１】
Ｅｘｔｒａｃｔ＿Ｒｕｌｅｓ＿ＤＢ３６Ｂは、抽出するパラメータ部分について格納しているＤＢである。例えば、Ｅｘｔｒａｃｔ＿Ｒｕｌｅｓ＿ＤＢ３６Ｂは、ＡＰＩ＿ＩＤ、ｆｌｏｗ通番、ｅｘｔｒａｃｔ通番、抽出ルールを紐付けて格納している。ｆｌｏｗ通番は、パケット毎に付与される通し番号である。ｅｘｔｒａｃｔ通番は、抽出対象のパラメータ毎に付与される通し番号である。抽出ルールは、パケット内のパラメータを抽出する際のルールであり、正規表現又はパケットの位置で規定される。
【００３２】
Ｒｅｐｌａｃｅｍｅｎｔ＿Ｒｕｌｅｓ＿ＤＢ３６Ｃは、受信したパケットに対して、パラメータの置き換え部分について格納しているＤＢである。例えば、Ｒｅｐｌａｃｅｍｅｎｔ＿Ｒｕｌｅｓ＿ＤＢ３６Ｃは、ＡＰＩ＿ＩＤ、ｆｌｏｗ通番、ｒｅｐｌａｃｅｍｅｎｔ通番、置換ルールを紐付けて格納している。ｒｅｐｌａｃｅｍｅｎｔ通番は、置換対象のパラメータ毎に付与される通し番号である。置換ルールは、パケット内のパラメータを置換する際のルールであり、正規表現又はパケットの位置で規定される。
【００３３】
ＡＰＩ＿Ｆｌｏｗ＿ＤＢ３６Ｄは、ＡＰＩに紐づいて行われるパケットの送受信シーケンスを格納しているＤＢである。例えば、ＡＰＩ＿Ｆｌｏｗ＿ＤＢ３６Ｄは、ＡＰＩ＿ＩＤ、ｆｌｏｗ通番、パケットを紐付けて格納している。パケットは、既存システム４０とアプリケーション１０間で送受信されたパケットである。
【００３４】
このようなＡＰＩ変換アダプタ３０によれば、ＡＰＩゲートウェイ２０とはＲＥＳＴで要求受付及び応答返却を行い、既存システム４０とは既存のプロトコルで送受信を行うことができる。すなわち、ＡＰＩゲートウェイ２０側ではＷＡＤＬを利用し、ＡＰＩの定義を記述する。既存システム４０側とのＡＰＩはパケットレベルでのプロトコルシーケンスデータを記録・生成する方式であるため、特定のプロトコルには依存しない。
【００３５】
ここでは、実現方式２を採用した場合を例示したが、その他の実現方式１，３を採用する場合も同様である。すなわち、実現方式１を採用する場合は、既存システム４０内にＡＰＩ変換アダプタ３０を備えればよいし、実現方式３を採用する場合は、ＡＰＩゲートウェイ２０内にＡＰＩ変換アダプタ３０を備えればよい。本明細書でいう「アダプタ」の用語には、装置として実現される場合だけでなく、ソフトウェアとして実現される場合も含まれるものとする。
【００３６】
また、ここでは、通信事業者が管理する通信事業者ネットワークに既存システム４０が接続されている場合を例示したが、これに限定されるものではない。例えば、アミューズメント事業者が管理するゲームプラットフォーム等にも本技術を適用可能である。
【００３７】
また、ここでは、ＡＰＩゲートウェイ２０を備えた構成を例示したが、これに限定されるものではない。すなわち、ＡＰＩゲートウェイ２０がなく直接ＡＰＩを公開する場合にも本技術を適用可能である。
【００３８】
（１対多通信）
図６は、本発明の実施の形態におけるＡＰＩ変換アダプタ３０を用いて複数のアプリケーション１０Ａ，１０Ｂが既存システム４０を利用する様子を示す図である。アプリケーション１０Ａは、ＡＰＩ２１Ａを介して既存システム４０を利用し、アプリケーション１０Ｂは、ＡＰＩ２１Ｂを介して既存システム４０を利用している。アプリケーション１０Ａ−既存システム４０間の通信にはｓｅｓｓｉｏｎ＿ｉｄ「１」が用いられ、アプリケーション１０Ｂ−既存システム４０間の通信にはｓｅｓｓｉｏｎ＿ｉｄ「２」が用いられている。
【００３９】
（リクエスト、レスポンスの具体例）
図７は、本発明の実施の形態におけるＡＰＩ変換アダプタ３０を用いてＡＰＩ変換を実施する場合のリクエスト、レスポンスの具体例を示す図である。ここでは、アプリケーション１０から既存システム４０の音声ファイル一覧取得ＡＰＩを使用した場合を例示している。
【００４０】
まず、ＡＰＩゲートウェイ２０からＡＰＩ変換アダプタ３０に対してリクエスト（ＧＥＴ）６１が送信される。このリクエスト（ＧＥＴ）６１において太字で示される部分は、抽出部３１により抽出されるパラメータ部分を示している。
【００４１】
次いで、ＡＰＩ変換アダプタ３０から既存システム４０に対してリクエスト（ＧＥＴ）６２が送信される。このリクエスト（ＧＥＴ）６２において太字で示される部分は、置換部３２により置換されたパラメータ部分を示している。
【００４２】
次いで、既存システム４０からＡＰＩ変換アダプタ３０に対してレスポンス（ＨＴＭＬ）６３が送信される。このレスポンス（ＨＴＭＬ）６３において太字で示される部分は、抽出部３４により抽出されるパラメータ部分を示している。
【００４３】
最後に、ＡＰＩ変換アダプタ３０からＡＰＩゲートウェイ２０に対してレスポンス（ＪＳＯＮ）６４が送信される。このレスポンス（ＪＳＯＮ）６４において太字で示される部分は、置換部３５により置換されたパラメータ部分を示している。
【００４４】
（ＡＰＩ変換の動作例）
図８は、本発明の実施の形態におけるＡＰＩ変換アダプタ３０を用いてＡＰＩ変換を実施する場合の動作例を示すフローチャートである。図８において、左側に描かれたステップＳ３Ａ，Ｓ４Ａはリクエストフロー特有のステップであり、右側に描かれたステップＳ４Ｂはレスポンスフロー特有のステップであり、中央に描かれたステップＳ１，Ｓ２，Ｓ５〜Ｓ１０はリクエストフロー及びレスポンスフローに共通のステップである。
【００４５】
まず、抽出部３１は、パケットを受信すると、そのパケットにメソッドがあるかどうかを判定する（Ｓ１→Ｓ２）。メソッドとは、ＨＴＴＰで用いられるＧＥＴ，ＰＯＳＴ，ＰＵＴ，ＤＥＬＥＴＥである。
【００４６】
次いで、抽出部３１は、メソッドがあった場合（Ｓ２：ＹＥＳ）、正規表現を利用し、パス及びメソッドを抽出する（Ｓ３Ａ）。具体的には、「／（ＧＥＴ｜ＰＯＳＴ｜ＰＵＴ｜ＤＥＬＥＴＥ）￥ｓ［ａ−ｚＡ−Ｚ０−９￥／￥．￥−￥？］＋￥ｓ／」のような正規表現を利用することによって、図９に太字で示すように、パケットからパス及びメソッド「ＧＥＴ  ／ｎｅｘｔｔｅｌａｐｉ／ｖ１．０／ｍｓ／１／ｖｏｉｃｅｓ」を抽出する。
【００４７】
次いで、抽出部３１は、ＡＰＩ＿ＤＢ３６Ａに問合せ、ＡＰＩを特定する（Ｓ４Ａ）。具体的には、図１０の符号Ｅ１に示すように、ステップＳ３Ａにおいて抽出したパス及びメソッド「ＧＥＴ  ／ｎｅｘｔｔｅｌａｐｉ／ｖ１．０／ｍｓ／１／ｖｏｉｃｅｓ」を利用してＡＰＩ＿ＤＢ３６Ａにアクセスし、そのパス及びメソッドに紐付けて格納されているＡＰＩ＿ＩＤ「１」を特定する。
【００４８】
一方、抽出部３１は、メソッドがなかった場合（Ｓ２：ＮＯ）、ｓｅｓｓｉｏｎ＿ｉｄを利用し、ＡＰＩを特定する（Ｓ４Ｂ）。具体的には、ｓｅｓｓｉｏｎ＿ｉｄを確認し、そのｓｅｓｓｉｏｎ＿ｉｄと対応付けてシステム内部で保持しているＡＰＩ＿ＩＤを特定する。
【００４９】
次いで、抽出部３１は、Ｅｘｔｒａｃｔ＿Ｒｕｌｅｓ＿ＤＢ３６Ｂに問合せ、抽出ルールを取得する（Ｓ５）。具体的には、図１１の符号Ｅ２に示すように、ステップＳ４Ａ又はＳ４Ｂにおいて特定したＡＰＩ＿ＩＤ、システム内部で保持しているｆｌｏｗ通番、及びｅｘｔｒａｃｔ通番を利用することによって、Ｅｘｔｒａｃｔ＿Ｒｕｌｅｓ＿ＤＢ３６Ｂから抽出ルール「１〜６ｂｙｔｅ」を取得する。
【００５０】
次いで、抽出部３１は、ステップＳ５において取得した抽出ルールから、パケット内のパラメータを取得する（Ｓ６）。具体的には、図１２に太字で示すように、ヘッダ部分である１〜６ｂｙｔｅ目の宛先ＭＡＣアドレス「００  ５０  ５６  ａａ  １３  ３９」を抽出する。
【００５１】
次いで、置換部３２は、ＡＰＩ＿Ｆｌｏｗ＿ＤＢ３６Ｄからパケットを取得する（Ｓ７）。具体的には、図１３の符号Ｅ３に示すように、ステップＳ４Ａ又はＳ４Ｂにおいて特定したＡＰＩ＿ＩＤ、及びシステム内部で保持しているｆｌｏｗ通番を利用することによって、ＡＰＩ＿Ｆｌｏｗ＿ＤＢ３６Ｄからパケット「３０  ａ４  ２３  ８０  …」を取得する。
【００５２】
次いで、置換部３２は、Ｒｅｐｌａｃｅｍｅｎｔ＿Ｒｕｌｅｓ＿ＤＢ３６Ｃから置換ルールを取得する（Ｓ８）。具体的には、図１４の符号Ｅ４に示すように、ステップＳ４Ａ又はＳ４Ｂにおいて特定したＡＰＩ＿ＩＤ、システム内部で保持しているｆｌｏｗ通番、及びｒｅｐｌａｃｅｍｅｎｔ通番を利用することによって、Ｒｅｐｌａｃｅｍｅｎｔ＿Ｒｕｌｅｓ＿ＤＢ３６Ｃから置換ルール「７〜１２ｂｙｔｅ」を取得する。
【００５３】
次いで、置換部３２は、ステップＳ７において取得したパケットに対して、ステップＳ８において取得した置換ルールを適用し、ステップＳ６において取得したパラメータに置換する（Ｓ９）。具体的には、図１５に太字で示すように、パケット「３０  ａ４  ２３  ８０  …」のヘッダ部分である７〜１２ｂｙｔｅ目の「２３  ５４  １３  ａ９  ２１  １２」を「００  ５０  ５６  ａａ  １３  ３９」に置換する。
【００５４】
最後に、クライアント部３３は、置換部３２により置換されたパケットを既存システム４０に送信する（Ｓ１０）。図１５中の「０６」はプロトコル情報を示し、「１ｆ  ９０」は宛先ポート番号を示している。このようなパケットに記載されているプロトコル情報や宛先ポート番号を利用し、既存システム４０とパケットの送受信を実施するようになっている。
【００５５】
以上のように、本発明の実施の形態におけるＡＰＩ変換アダプタ３０は、既存システム４０をＡＰＩ化するためのＡＰＩ変換アダプタであって、既存システム４０とのパケット送受信シーケンスを予め格納しているデータベース（格納部３６）と、受信したパケット内のパラメータを抽出する抽出部３１と、データベースに格納されているパケット内のパラメータを抽出部３１により抽出されたパラメータに置換する置換部３２と、置換部３２により置換されたパケットを用いて既存システム４０とパケットの送受信を実施するクライアント部３３とを備える。このように、パケットを利用することによって、既存システム４０をＲＥＳＴ  ＡＰＩ化する手法として各種プロトコルに汎用的に対応可能な変換処理技術を確立できる。
【００５６】
ここで、ＡＰＩ変換アダプタ３０は、既存システム４０とＡＰＩゲートウェイ２０との間に配備されてもよい。このような実現方式は、上述した実現方式２に相当する。実現方式２のメリットとしては、既存システム４０の改造が不要である点、ＡＰＩゲートウェイ２０の製品（仕様）変更に影響しない点、ＯＳＳ活用でコストを抑制できる点がある。
【００５７】
また、ＡＰＩ変換アダプタ３０は、ＡＰＩゲートウェイ２０とはＲＥＳＴで要求受付及び応答返却を行い、既存システム４０とは既存のプロトコルで送受信を行う。すなわち、既存システム４０とのパケット送受信シーケンスを予めデータベースに格納しておき、そのパケットに記述されているプロトコル情報を利用するため、特定のプロトコルに限定せずに通信が可能である。言い換えると、ＲＥＳＴ  ＡＰＩから、パケットレベルで表現可能な全てのプロトコルへの変換が可能である。
【００５８】
また、本発明の実施の形態におけるＡＰＩ変換システムは、既存システム４０をＡＰＩ化するためのＡＰＩ変換システムであって、既存システム４０と、既存システム４０を外部ネットワーク上のアプリケーション１０側から制御するためのＡＰＩ２１を提供するＡＰＩゲートウェイ２０と、上述したいずれかのＡＰＩ変換アダプタ３０とを備える。このように、パケットを利用することによって、既存システム４０をより簡易的にＡＰＩ化することができる。また、主なパケットの送受信がＡＰＩ変換アダプタ３０−既存システム４０間となり、通信量を削減することができるという効果もある。
【００５９】
なお、本発明は、このようなＡＰＩ変換アダプタ３０として実現することができるだけでなく、ＡＰＩ変換アダプタ３０が備える特徴的な各機能部としてコンピュータを機能させるＡＰＩ変換プログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのはいうまでもない。
【符号の説明】
【００６０】
１０…アプリケーション
２０…ＡＰＩゲートウェイ
２１…ＡＰＩ
３０…ＡＰＩ変換アダプタ
３１，３４…抽出部
３２，３５…置換部
３３…クライアント部
３６…格納部
３６Ａ…ＡＰＩ＿ＤＢ
３６Ｂ…Ｅｘｔｒａｃｔ＿Ｒｕｌｅｓ＿ＤＢ
３６Ｃ…Ｒｅｐｌａｃｅｍｅｎｔ＿Ｒｕｌｅｓ＿ＤＢ
３６Ｄ…ＡＰＩ＿Ｆｌｏｗ＿ＤＢ
４０…既存システム
【図１】
2017054411.tif 000003
【図２】
2017054411.tif 000004
【図３】
2017054411.tif 000005
【図４】
2017054411.tif 000006
【図５】
2017054411.tif 000007
【図６】
2017054411.tif 000008
【図７】
2017054411.tif 000009
【図８】
2017054411.tif 000010
【図９】
2017054411.tif 000011
【図１０】
2017054411.tif 000012
【図１１】
2017054411.tif 000013
【図１２】
2017054411.tif 000014
【図１３】
2017054411.tif 000015
【図１４】
2017054411.tif 000016
【図１５】
2017054411.tif 000017
【図１６】
2017054411.tif 000018
【図１７】
2017054411.tif 000019
【手続補正書】
【提出日】平成28年11月29日(2016.11.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
既存システムをＡＰＩ化するためのＡＰＩ変換アダプタであって、
前記既存システムとのパケット送受信シーケンスを予め格納しているデータベースと、
受信したパケット内のパラメータを抽出する抽出部と、
前記データベースに格納されているパケット内のパラメータを前記抽出部により抽出されたパラメータに置換する置換部と、
前記置換部により置換されたパケットを用いて前記既存システムとパケットの送受信を実施するクライアント部と
を備え、
前記ＡＰＩゲートウェイとはＲＥＳＴで要求受付及び応答返却を行い、前記既存システムとは既存のプロトコルで送受信を行うＡＰＩ変換アダプタであって、
前記既存システムとのパケット送受信シーケンスを予め前記データベースに格納しておき、前記データベースに格納されたパケットに記述されているプロトコル情報を利用することにより、ＲＥＳＴからパケットレベルで表現される全てのプロトコルへの変換を行うことを特徴とするＡＰＩ変換アダプタ。
【請求項２】
前記既存システムとＡＰＩゲートウェイとの間に配備されることを特徴とする請求項１に記載のＡＰＩ変換アダプタ。
【請求項３】
既存システムをＡＰＩ化するためのＡＰＩ変換システムであって、
前記既存システムと、
前記既存システムを外部ネットワーク上のアプリケーション側から制御するためのＡＰＩを提供するＡＰＩゲートウェイと、
請求項１又は２に記載のＡＰＩ変換アダプタと
を備えることを特徴とするＡＰＩ変換システム。
【請求項４】
請求項１又は２に記載の各機能部としてコンピュータを機能させることを特徴とするＡＰＩ変換プログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
上記目的を達成するため、第１の態様に係る発明は、既存システムをＡＰＩ化するためのＡＰＩ変換アダプタであって、前記既存システムとのパケット送受信シーケンスを予め格納しているデータベースと、受信したパケット内のパラメータを抽出する抽出部と、前記データベースに格納されているパケット内のパラメータを前記抽出部により抽出されたパラメータに置換する置換部と、前記置換部により置換されたパケットを用いて前記既存システムとパケットの送受信を実施するクライアント部とを備え、前記ＡＰＩゲートウェイとはＲＥＳＴで要求受付及び応答返却を行い、前記既存システムとは既存のプロトコルで送受信を行うＡＰＩ変換アダプタであって、前記既存システムとのパケット送受信シーケンスを予め前記データベースに格納しておき、前記データベースに格納されたパケットに記述されているプロトコル情報を利用することにより、ＲＥＳＴからパケットレベルで表現される全てのプロトコルへの変換を行うことを要旨とする。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】削除
【補正の内容】
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
第３の態様に係る発明は、既存システムをＡＰＩ化するためのＡＰＩ変換システムであって、前記既存システムと、前記既存システムを外部ネットワーク上のアプリケーション側から制御するためのＡＰＩを提供するＡＰＩゲートウェイと、第１又は第２の態様に係るＡＰＩ変換アダプタとを備えることを要旨とする。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】変更
【補正の内容】
【００１１】
第４の態様に係る発明は、ＡＰＩ変換プログラムであって、第１又は第２の態様に係る各機能部としてコンピュータを機能させることを要旨とする。