JP6795531B2 - Ａｐｉアダプタ、ａｐｉアダプタ作成方法、およびプログラム - Google Patents

Ａｐｉアダプタ、ａｐｉアダプタ作成方法、およびプログラム Download PDF

Info

Publication number
JP6795531B2
JP6795531B2 JP2018028324A JP2018028324A JP6795531B2 JP 6795531 B2 JP6795531 B2 JP 6795531B2 JP 2018028324 A JP2018028324 A JP 2018028324A JP 2018028324 A JP2018028324 A JP 2018028324A JP 6795531 B2 JP6795531 B2 JP 6795531B2
Authority
JP
Japan
Prior art keywords
api
service provider
execution
wholesale service
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018028324A
Other languages
English (en)
Other versions
JP2019144848A (ja
Inventor
直樹 武
直樹 武
謙輔 高橋
謙輔 高橋
田中　宏幸
宏幸 田中
伸夫 小内
伸夫 小内
啓之 矢崎
啓之 矢崎
加藤　浩
浩 加藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2018028324A priority Critical patent/JP6795531B2/ja
Priority to US16/971,256 priority patent/US10977102B2/en
Priority to PCT/JP2019/006171 priority patent/WO2019163793A1/ja
Publication of JP2019144848A publication Critical patent/JP2019144848A/ja
Application granted granted Critical
Publication of JP6795531B2 publication Critical patent/JP6795531B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/74—Reverse engineering; Extracting design information from source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • General Health & Medical Sciences (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Primary Health Care (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

本発明は、ＡＰＩアダプタ、ＡＰＩアダプタ作成方法、およびプログラムに関する。
近年、新たなデジタルサービスを創出するにあたり、全てを自社の設備で構築するのではなく、他事業者のデジタルサービスを利用してエンドユーザにサービスを提供する、Ｂ２Ｂ２Ｘ（Business to Business to X）モデルの通信サービスが盛んになっている。
Ｂ２Ｂ２Ｘの普及に伴って、複数の卸パートナサービスを組み合わせサービス構築・運用するための、複数サービス連携実行装置の重要性が増している。新たな卸サービスの登場、および既存サービス仕様の変更が頻繁に行われるため、サービス事業者は新たな卸サービスおよび既存サービスの仕様変更に対して、低コスト・短期間で追随することが求められる。
また、各事業者がサービスを管理するためのＡＰＩ（Application Program Interface）をウェブ上にて提供しており、ユーザはＡＰＩを呼び出すソフトウェアを通じてサービスを構築・運用している。ＡＰＩの仕様（ＡＰＩの名称、ＵＲＬ（Uniform Resource Locator）、パラメータ等）は、各事業者が規定し、ユーザは当該規定に従ってＡＰＩを使用する。近年では、事業者によるＡＰＩ提供が増えてきており、単一の事業者が複数のサービス用ＡＰＩを提供したり、複数事業者で同様のサービス用ＡＰＩが提供されるのが一般的になりつつある。
サービス事業者が、卸サービスを提供している複数の卸サービス事業者のネットワークおよびクラウド、アプリを組合せた連携サービスを一括で構築する装置を開発する際に、卸サービスに新サービスやＡＰＩが追加される度に追従へのコストが掛かる。
複数事業者の卸サービスを連携させ、新サービスやＡＰＩへの追従開発を柔軟に実現させるためのアーキテクチャとして、非特許文献１に記載の技術がある。
非特許文献１には、複数サービスの連携実行装置およびそのアーキテクチャ（サービス非依存部とサービス依存部（アダプタ部）に分離）が提案されている。具体的には、複数事業者のサービスの仕様をカタログとして記述するカタログドリブンアーキテクチャを採用し、カタログの記述方法として「構成要素」と「アクションルール」を分離させる。カタログを解釈して実行するサービス非依存部とサービス毎のＡＰＩを実行するサービス依存部を疎結合とすることで、新たなサービスやＡＰＩへの追従を柔軟に実現する複数サービス実行連携方式が提案されている。これにより、新たなサービスやＡＰＩへ対応する場合に、サービス依存部の追加のみで対応可能とする。
非特許文献２には、オーケストレータ部／（「／」は、「および／または」、を表記する。以下同様。）個別サービスとの情報の送受信を行うオーケストレータ／個別サービスＡＰＩ送受信部と、オーケストレータからのオーダ受付および応答処理を行うオーダ受付部と、個別サービスのＡＰＩ呼出しロジック(実行順序、入出力パラメータ指定等)を記述するＡＰＩ呼出しロジック部と、オーケストレータ／個別サービスからの情報取得・登録を代行してロジック記述に使いやすい単位で機能を提供するオーケストレータ／個別ＡＰＩラッパ部と、を備えるＡＰＩアダプタが記載されている。
「複数事業者間サービス連携を柔軟にするアーキテクチャ」，2017 年電子情報通信学会通信ソサイエティ大会講演論文集,高橋 謙輔ら，［online］,［平成３０年２月１日検索］,インターネット 〈URL:https:// www.gakkai-web.net/gakkai/ieice/S_2017/Settings/html/key/fu.html〉 「Web APIアダプタ開発容易化に関する一考察」，武 直樹ら，ネットワークソフトウェア(NWS)研究会ポジションペーパ講演,［online］,［平成３０年２月１日検索］,インターネット 〈URL: http://www.ieice.org/cs/ns/nws/14/program/〉
しかしながら、非特許文献１および非特許文献２には、複数サービスの連携実行装置およびそのアーキテクチャや、ＡＰＩアダプタ機能要件については提案されているが、アダプタ部の作成方法については提案されていない。
このような背景に鑑みて本発明がなされたのであり、本発明は、新規卸サービス／仕様変更で用いられるＡＰＩアダプタ部を効率的に作成することができるＡＰＩアダプタ、ＡＰＩアダプタ作成方法、およびプログラムを提供することを課題とする。
前記した課題を解決するため、請求項１に記載の発明は、複数の卸サービスを組み合わせた連携サービスを一括で構築する連携実行装置に用いられるＡＰＩ（Application Program Interface）アダプタであって、前記連携サービスのオーダを単体オーダに分解する連携実行装置本体部から、前記単体オーダを受付け、かつ、前記連携実行装置本体部への応答処理を行うオーダ受付部と、卸サービス事業者ＡＰＩの起動条件をもとに、決められた実行順序で前記卸サービス事業者ＡＰＩを起動し、前記単体オーダ内から前記卸サービス事業者ＡＰＩの実行に必要なパラメータを取り出し、卸サービス事業者ＡＰＩ実行部に送信するとともに、前記卸サービス事業者ＡＰＩの実行結果を、前記連携実行装置本体部が流通可能なデータ形式に変換するＡＰＩ呼出しロジック部と、前記ＡＰＩ呼出しロジック部から、卸サービス事業者ＡＰＩの実行に必要なパラメータを受領し、リクエストの形に組み立て直して前記卸サービス事業者ＡＰＩに要求するとともに、当該リクエストに対する実行結果としてのレスポンスを受信後、当該レスポンスを所定形式に組み立て直して前記ＡＰＩ呼出しロジック部に返却する前記卸サービス事業者ＡＰＩ実行部と、を備えることを特徴とするＡＰＩアダプタとした。
また、請求項２に記載の発明は、複数の卸サービスを組み合わせた連携サービスを一括で構築する連携実行装置に用いられるＡＰＩアダプタを作成する方法であって、前記ＡＰＩアダプタは、オーダ受付部、ＡＰＩ呼出しロジック部、および卸サービス事業者ＡＰＩ実行部を備えており、前記オーダ受付部が、前記連携サービスのオーダを単体オーダに分解する連携実行装置本体部から、前記単体オーダを受付ける工程と、前記ＡＰＩ呼出しロジック部が、卸サービス事業者ＡＰＩの起動条件をもとに、決められた実行順序で前記卸サービス事業者ＡＰＩを起動し、前記単体オーダ内から前記卸サービス事業者ＡＰＩの実行に必要なパラメータを取り出し、前記卸サービス事業者ＡＰＩ実行部に送信する工程と、前記卸サービス事業者ＡＰＩ実行部が、前記ＡＰＩ呼出しロジック部から、前記卸サービス事業者ＡＰＩの実行に必要なパラメータを受領し、リクエストの形に組み立て直して前記卸サービス事業者ＡＰＩに要求する工程と、前記卸サービス事業者ＡＰＩ実行部が、当該リクエストに対する実行結果としてのレスポンスを受信後、当該レスポンスを所定形式に組み立て直して前記ＡＰＩ呼出しロジック部に返却する工程と、前記ＡＰＩ呼出しロジック部が、前記卸サービス事業者ＡＰＩの実行結果を、前記連携実行装置本体部が流通可能なデータ形式に変換する工程と、オーダ受付部が、前記連携実行装置本体部への応答処理を行う工程と、を有することを特徴とするＡＰＩアダプタ作成方法とした。
また、請求項７に記載の発明は、複数の卸サービスを組み合わせた連携サービスを一括で構築する連携実行装置に用いられるＡＰＩアダプタとしてのコンピュータを、前記連携サービスのオーダを単体オーダに分解する連携実行装置本体部から、前記単体オーダを受付け、かつ、前記連携実行装置本体部への応答処理を行うオーダ受付手段、卸サービス事業者ＡＰＩの起動条件をもとに、決められた実行順序で前記卸サービス事業者ＡＰＩを起動し、前記単体オーダ内から前記卸サービス事業者ＡＰＩの実行に必要なパラメータを取り出し、卸サービス事業者ＡＰＩ実行手段に送信するとともに、前記卸サービス事業者ＡＰＩの実行結果を、前記連携実行装置本体部が流通可能なデータ形式に変換するＡＰＩ呼出しロジック手段、前記ＡＰＩ呼出しロジック手段から、前記卸サービス事業者ＡＰＩの実行に必要なパラメータを受領し、リクエストの形に組み立て直して前記卸サービス事業者ＡＰＩに要求するとともに、当該リクエストに対する実行結果としてのレスポンスを受信後、当該レスポンスを所定形式に組み立て直して前記ＡＰＩ呼出しロジック手段に返却する前記卸サービス事業者ＡＰＩ実行手段、として機能させるためのプログラムとした。
このようにすることで、新規卸サービス／仕様変更で用いられるＡＰＩアダプタ部を効率的に作成することができる。
請求項３に記載の発明は、前記卸サービス事業者ＡＰＩ実行部が、卸サービス事業者ＡＰＩ仕様書をもとに、卸サービス事業者ＡＰＩ実行部ソースコードを自動生成し、自動生成された前記卸サービス事業者ＡＰＩ実行部ソースコードから、卸サービス事業者ＡＰＩ実行部仕様ドキュメントを生成する工程を、さらに有することを特徴とする請求項２に記載のＡＰＩアダプタ作成方法とした。
このようにすることで、卸サービス事業者ＡＰＩ実行部の有する工程に対応する開発が不要になる。また、次工程の卸サービス事業者ＡＰＩ実行部組込み工程に、生成した卸サービス事業者ＡＰＩ実行部仕様ドキュメントを提供することができる。
請求項４に記載の発明は、前記卸サービス事業者ＡＰＩ実行部が、共通ライブラリソースコードおよび生成した前記卸サービス事業者ＡＰＩ実行部ソースコードを、ＡＰＩ呼出ロジック部テンプレートソースコードに組み込む工程をさらに有することを特徴とする請求項３に記載のＡＰＩアダプタ作成方法とした。
このように、共通ライブラリソースコードを用いることで、共通ライブラリ資源を利用して効率良く、卸サービス事業者ＡＰＩ実行部ソースコードを、ＡＰＩ呼出しロジック部テンプレートソースコードに組み込むことができる。また、次工程のＡＰＩ呼出しロジック部作成工程に、卸サービス事業者ＡＰＩ実行部ソースコードを組み込んだＡＰＩ呼出しロジック部テンプレートソースコードを提供することができる。
請求項５に記載の発明は、前記ＡＰＩ呼出しロジック部が、共通ライブラリおよび卸サービスＡＰＩ実行部ソースコードを組み込んだテンプレートソースコード、および各種マニュアル・仕様ドキュメントをもとに、アダプタ部ソースコードを実装し、作成したアダプタ部ソースコードをビルドしてアダプタ部実行ファイルを生成することを特徴とする請求項２に記載のＡＰＩアダプタ作成方法とした。
このようにすることで、アダプタ部実行ファイルを効率良く作成することができるので、新規ＡＰＩへの追随が容易になる。例えば、ＡＰＩアダプタ部１００を新規卸サービス／仕様変更への追随が容易になる。このように、上記卸サービス事業者ＡＰＩ実行部生成工程と、上記共通ライブラリおよび卸サービス事業者ＡＰＩ実行部組込み工程と、上記ＡＰＩ呼出しロジック部作成工程とを組み合わせることで、ＡＰＩアダプタ部を効率的に作成することができる。
請求項６に記載の発明は、ＡＰＩ呼出しロジック部は、作成した前記アダプタ部実行ファイルを前記ＡＰＩアダプタに登録する工程を有することを特徴とする請求項５に記載のＡＰＩアダプタ作成方法とした。
このようにすることで、アダプタ部実行ファイルをＡＰＩアダプタ部に登録して、ＡＰＩアダプタ部を新規卸サービス／仕様変更への追随させることができる。
本発明によれば、新規卸サービス／仕様変更で用いられるＡＰＩアダプタ部を効率的に作成することができるＡＰＩアダプタ、ＡＰＩアダプタ作成方法、およびプログラム。
本発明の実施形態に係るＡＰＩアダプタが適用されるネットワークシステムの全体構成図である。 本発明の実施形態に係るＡＰＩアダプタの主な役割と機能を説明する図である。 本発明の実施形態に係るＡＰＩアダプタを示す構成図である。 本発明の実施形態に係るＡＰＩアダプタの単体オーダの一例を示す図である。 本発明の実施形態に係るＡＰＩアダプタのオーダ受付部の処理を示す図である。 本発明の実施形態に係るＡＰＩアダプタの共通ライブラリを説明する図である。 本発明の実施形態に係るＡＰＩアダプタのＡＰＩ呼出しロジック部の処理を示す図である。 本発明の実施形態に係るＡＰＩアダプタの卸サービス事業者ＡＰＩ実行部の処理を示す図である。 本発明の実施形態に係るＡＰＩアダプタのＡＰＩ仕様書を基にした自動生成を説明する図である。 本発明の実施形態に係るＡＰＩアダプタのSwagger Codegenを説明する図である。 本発明の実施形態に係るＡＰＩアダプタのＡＰＩアダプタ作成方法の概要を示す図である。 本発明の実施形態に係るＡＰＩアダプタの卸サービス事業者ＡＰＩ実行部生成工程を説明する工程図である。 本発明の実施形態に係るＡＰＩアダプタの共通ライブラリおよび卸サービス事業者ＡＰＩ実行部組込み工程を説明する工程図である。 本発明の実施形態に係るＡＰＩアダプタのＡＰＩ呼出しロジック部作成工程を説明する工程図である。 本発明の実施形態に係るＡＰＩアダプタのアダプタ登録処理を示す図である。
以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるＡＰＩアダプタおよびＡＰＩアダプタ作成方法について説明する。
ＡＰＩアダプタおよびＡＰＩアダプタ作成方法は、Ｂ２Ｂ２Ｘモデルに適用した例である。Ｂ２Ｂ２Ｘモデルは、卸サービス事業者がサービス事業者に対してサービスを卸で売り、サービス事業者が卸されたサービスを使って新たなサービスを創出し、更にその先の客に創出したサービスを提供する。Ｂ２Ｂ２Ｘモデルは、一例であり、どのようなサービスモデルのＡＰＩアダプタであってもよい。
（実施形態）
図１は、本発明の実施形態に係るＡＰＩアダプタが適用されるネットワークシステムの全体構成図である。図１中、二重線で示される表記は、各ＡＰＩを示す（以下、各図において同様）。
図１に示すように、サービス事業者１は、サービス４を使いたい旨の連携オーダ３を発行し、複数の卸サービス事業者２−１、卸サービス事業者２−２、卸サービス事業者２−３の卸サービスを組み合わせたサービス４を受け取る。サービス事業者１は、法人・個人がある。なお、卸サービス事業者２−１、卸サービス事業者２−２、卸サービス事業者２−３を総称する場合は、卸サービス事業者２と呼ぶ。
連携実行装置１０は、サービス事業者１と卸サービスを提供している複数の卸サービス事業者２−１、卸サービス事業者２−２、卸サービス事業者２−３との間に配置され、卸サービス事業者２−１、卸サービス事業者２−２、卸サービス事業者２−３のネットワークおよびクラウド、アプリを組合せた連携サービスを一括で連携する。
サービス事業者１と連携実行装置１０との間には、インターフェースである連携実行装置ＡＰＩ４０が設けられる。
卸サービス事業者２−１，卸サービス事業者２−２、卸サービス事業者２−３と連携実行装置１０との間には、卸サービス事業者２−１のＡＰＩ５０−１、卸サービス事業者２−２のＡＰＩ５０−２、卸サービス事業者２−３のＡＰＩ５０−３が設けられる。卸サービス事業者ＡのＡＰＩ５０−１，卸サービス事業者ＢのＡＰＩ５０−２，卸サービス事業者ＣのＡＰＩ５０−３は、卸サービス事業者２−１、卸サービス事業者２−２、卸サービス事業者２−３を連携実行装置１０に接続する際のインターフェースである。
なお、卸サービス事業者２−１のＡＰＩ５０−１、卸サービス事業者２−２のＡＰＩ５０−２、卸サービス事業者２−３のＡＰＩ５０−３を総称する場合は、卸サービス事業者ＡＰＩ５０と呼ぶ。
連携実行装置１０は、連携実行装置本体部２０と、ＡＰＩアダプタ部１００と、連携実行装置本体部２０をＡＰＩアダプタ部１００に接続する際のインターフェースである連携実行装置本体部ＡＰＩ３０と、を備える。
ＡＰＩアダプタ部１００は、各卸サービス事業者２ごとに作成され、各卸サービス事業者２が提供するＡＰＩ仕様差分を吸収する（図３で後記）。ここでは、ＡＰＩアダプタ部１００は、各卸サービス事業者２−１、卸サービス事業者２−２、卸サービス事業者２−３ごとに対応する卸サービス事業者２−１用のＡＰＩアダプタ１０１−１、卸サービス事業者２−２用のＡＰＩアダプタ１０１−２、卸サービス事業者２−３用のＡＰＩアダプタ１０１−３を備える。卸サービス事業者２−１用のＡＰＩアダプタ１０１−１、卸サービス事業者２−２用のＡＰＩアダプタ１０１−２、卸サービス事業者２−３用のＡＰＩアダプタ１０１−３は、各卸サービス事業者２−１、卸サービス事業者２−２、卸サービス事業者２−３が提供するＡＰＩ仕様差分をそれぞれ吸収する。
なお、ＡＰＩアダプタ１０１−１、ＡＰＩアダプタ１０１−２、ＡＰＩアダプタ１０１−３を総称する場合は、ＡＰＩアダプタ１０１と呼ぶ。
連携実行装置本体部２０は、サービス事業者１が発行した連携オーダ３を、各卸サービス事業者２−１用のＡＰＩアダプタ１０１−１、卸サービス事業者２−２用のＡＰＩアダプタ１０１−２、卸サービス事業者２−３用のＡＰＩアダプタ１０１−３が処理できる単位である、単体オーダ３１−１，３１−２，３１−３に分解し、各卸サービス事業者２−１用のＡＰＩアダプタ１０１−１、卸サービス事業者２−２用のＡＰＩアダプタ１０１−２、卸サービス事業者２−３用のＡＰＩアダプタ１０１−３に送信する。
なお、単体オーダ３１−１，３１−２，３１−３を総称する場合は、単体オーダ３１と呼ぶ。単体オーダ３１の具体例については図４で後記する。
［ＡＰＩアダプタの主な役割と機能］
図２は、ＡＰＩアダプタ１０１の主な役割と機能を説明する図である。図１の各部と対応する部材には同一符号を付している。
連携オーダ３は、連携実行装置本体部２０でNW(Network) service用単体オーダ３１−１、Cloud service用単体オーダ３１−２、APL (Application) service用単体オーダ３１−３に分解される。
卸サービス事業者２−１、卸サービス事業者２−２、卸サービス事業者２−３は、順に、Network A２１−１、Cloud B２１−２、APL C２１−３であるとする。
卸サービス事業者２−１用のＡＰＩアダプタ１０１−１，卸サービス事業者２−２用のＡＰＩアダプタ１０１−２，卸サービス事業者２−３用のＡＰＩアダプタ１０１−３は、順に、Network A用のＡＰＩアダプタ１０１−１，Cloud用のＡＰＩアダプタ１０１−２，APL用のＡＰＩアダプタ１０１−３である。
連携実行装置本体部２０は、連携オーダ３を単体オーダ３１に分解するとともに、実行順序制御を行う。例えば、連携実行装置本体部２０は、Network ２１−１から返却されたデータに付与されたＩＰアドレスを、Cloud ２２−２の設定に引き渡す際に、Cloud ２２−２の設定に変える。このような実行順序制御が重要となる。
ＡＰＩアダプタ１０１は、連携実行装置本体部２０側のデータモデル（例えば、TMF Open APIs準拠形式）と卸サービス事業者２側のデータモデルを相互に変換する役割を持つ。なお、データモデルは、ＴＭＦ形式に限らず、独自形式のものでもよい。
ＡＰＩアダプタ１０１は、連携実行装置本体部２０からの単体オーダ３１（例えば、ＴＭＦ形式）を解釈し、各卸サービスＡＰＩ５１の呼び出しに変換、またその応答値を本体部側のデータモデル（例えば、ＴＭＦ形式）に変換し、連携実行装置本体部２０に流通させる機能を持つ。
図２の矢印に示すように、Network ２１−１用のＡＰＩアダプタ１０１−１は、連携実行装置本体部２０からのNW service用単体オーダ３１−１を解釈し、Network ２１−１のＡＰＩ呼び出しに変換し、応答値を連携実行装置本体部２０側に戻す。続いて、Cloud ２１−１用のＡＰＩアダプタ１０１−２は、連携実行装置本体部２０からのCloud service２１−２用単体オーダ３１−２を解釈し、Cloud ２１−２のＡＰＩ呼び出しに変換し、応答値を連携実行装置本体部２０側に戻す。続いて、APL２１−３用のＡＰＩアダプタ１０１−３は、連携実行装置本体部２０からのAPL service２１−３用単体オーダ３１−３を解釈し、ＡＰＬ ２１−３のＡＰＩ呼び出しに変換し、応答値を連携実行装置本体部２０側のデータモデルに変換し流通させる。
図３は、図１のＡＰＩアダプタ部１００を示す構成図である。
図３に示すように、ＡＰＩアダプタ部１００は、連携実行装置本体部２０からのオーダを連携実行装置本体部ＡＰＩ３０を通して受付けるとともに、その応答を連携実行装置本体部ＡＰＩ３０を通して連携実行装置本体部２０に返す。なお、連携実行装置本体部２０は、非特許文献２のオーケストレータ本体に対応し、連携実行装置本体部ＡＰＩ３０は、非特許文献２のオーケストレータＡＰＩに対応する。
ＡＰＩアダプタ部１００は、各卸サービス事業者２との間で各卸サービス事業者２のＡＰＩ５０を通して、個々の卸サービス事業者ＡＰＩ５０に対応したＨＴＴＰ（Hypertext Transfer Protocol）リクエスト送信とレスポンス受信を行う。なお、卸サービス事業者２は、非特許文献２の個別サービスに対応し、卸サービス事業者ＡＰＩ５０は、非特許文献２の個別サービスのＡＰＩに対応する。
ＡＰＩアダプタ部１００は、連携実行装置本体部２０（オーケストレータ）側から受信したオーダを解釈し、規定された順番で卸サービス事業者ＡＰＩ５０（個別サービスのＡＰＩ）を呼び出して、その結果を連携実行装置本体部２０（オーケストレータ）に流通する。
ＡＰＩアダプタ部１００は、オーダ受付部１１０（オーダ受付手段）と、ＡＰＩ呼出しロジック部１２０（ＡＰＩ呼出しロジック手段）と、卸サービス事業者ＡＰＩ実行部１３０（卸サービス事業者ＡＰＩ実行手段）と、を備える。
［オーダ受付部１１０］
オーダ受付部１１０は、連携実行装置本体部２０からの単体オーダ３１を受付け、オーダ内容を取得する。オーダ受付部１１０は、連携実行装置本体部２０への応答処理を行う。具体的には、オーダ受付部１１０は、連携オーダ受付／応答処理として、連携実行装置本体部２０との間で予め決められた手順に従って、単体オーダ３１の受信から単体オーダ３１の実行完了までの状態管理および通知、実行結果の流通を行う。
オーダ受付部１１０は、オーダ内容の取得処理として、ＡＰＩ呼出しロジック部１２０の要請を受け、詳細なオーダ内容（カタログ／オーダパラメータ）を取得する。オーダ受付部１１０の処理については、図５で後記する。
非特許文献２との関係で述べると、オーダ受付部１１０は、オーケストレータＡＰＩ送受信機能として、ＨＴＴＰリクエスト組み立てて送信し、レスポンスを受信する。オーダ受付部１１０は、オーダ受付機能としてオーダ受付と、連携実行装置本体部２０（オーケストレータ）への応答処理を行う。オーダ受付部１１０は、オーケストレータＡＰＩラッパ機能として、連携実行装置本体部２０（オーケストレータ）ＡＰＩ情報取得を代行し、ロジック記述に使いやすい単位の機能を提供する。
なお、上記オーケストレータＡＰＩ送受信と後記する個別サービスＡＰＩ送受信については、定型的なＨＴＴＰ送受信処理を行うのみであるため、ＨＴＴＰ送受信処理用の市中ライブラリ活用もしくは一度開発したものの再利用が可能である。共通ライブラリ（図６で後記する）の利用により、これらは開発不要になる。
［ＡＰＩ呼出しロジック部１２０］
ＡＰＩ呼出しロジック部１２０は、卸サービス事業者ＡＰＩ５０の起動条件をチェックし、決められた実行順序でＡＰＩを起動する。
ＡＰＩ呼出しロジック部１２０は、連携実行装置本体部２０からのオーダ内から卸サービス事業者ＡＰＩ５０の実行に必要なパラメータを取り出し、卸サービス事業者ＡＰＩ実行部１３０に送信する。また、ＡＰＩ呼出しロジック部１２０は、卸サービス事業者ＡＰＩ５０の実行結果を卸サービス事業者ＡＰＩ実行部１３０から受け取り、連携実行装置本体部２０に流通するための適切なデータ形式に変換する。ＡＰＩ呼出しロジック部１２０の処理については、図７で後記する。
ＡＰＩ呼出しロジック部１２０は、ＡＰＩ呼出しロジック（ＡＰＩ呼び出しの実行順序、入出力パラメータ指定等）を記述する。
ＡＰＩ呼出しロジック部１２０は、共通ライブラリ化されたテンプレートソースコードおよび自動生成されたＩＦ仕様ドキュメントをもとに、手動実装される。
［卸サービス事業者ＡＰＩ実行部１３０］
卸サービス事業者ＡＰＩ実行部１３０は、ＡＰＩ呼出しロジック部１２０から、卸サービス事業者ＡＰＩの実行に必要なデータを受領（この時のデータ形式を「オブジェクト」と呼ぶ）する。それをＨＴＴＰリクエストの形に組み立て直して卸サービス事業者２に送信する。
卸サービス事業者ＡＰＩ実行部１３０は、卸サービス事業者２からＨＴＴＰレスポンスを受信後、ステータスコードのチェックおよび例外発出処理、レスポンスヘッダおよびボディの取得を行い、適切な形式に組み立て直してＡＰＩ呼出しロジック部１２０に返却する。卸サービス事業者ＡＰＩ実行部１３０の処理については、図８で後記する。
卸サービス事業者ＡＰＩ実行部１３０は、個々の卸サービス事業者ＡＰＩに対応したＨＴＴＰリクエスト作成して送信するとともに、レスポンス受信し、またレスポンスからの値を取り出し、さらに例外処理を行う（図８で後記）。
非特許文献２との関係で述べると、卸サービス事業者ＡＰＩ実行部１３０は、個別サービスＡＰＩラッパ機能として、個別サービスＡＰＩ呼び出しを代行し、ロジック記述に使いやすい単位の機能を提供する。卸サービス事業者ＡＰＩ実行部１３０は、個別サービスＡＰＩ送受信機能として、ＨＴＴＰリクエスト組み立てて送信し、レスポンスを受信する。なお、個別サービスＡＰＩラッパに関しては、Open API Specの標準化が進み、各個別サービスのＡＰＩ仕様がOpen API Spec形式で公開されることを想定し、対応したＩＦ部自動生成ツールであるSwagger Codegen（図１０で後記）の適用により、当機能部の自動生成が可能である。
［単体オーダ３１］
図４は、単体オーダ３１の一例を示す図であり、ＴＭＦ ＡＰＩに準拠した場合の例である。なお、単体オーダ３１は、必ずしもこの記述形式である必要はない。
図４に示す単体オーダ３１は、
オーダ一般情報３１１（オーダ説明、注文日時、オーダ種別）
“description”: “Set up Cloud A”
“orderDate”: “2018-01-25T10:00:00”
“action”: “add”
を記述する。
また、課金アカウントの指定３１２
“billingAccount”: [
{
“id”: “1”,
“href”: “http://..../bllingAccount/1”
“name”: “Sample Account”
}
],
を記述する。
使用するカタログ（サービスメニュー）の指定３１３
“productOffering”: {
“id”: “80”,
“href”: “http://..../productOffering/80”
“name”: “Cloud A”
},
を記述する。
また、オーダパラメータ（オーダ特有のパラメータ）の指定３１４
“product”: {
“characteristic”: [
{
“name”: “tenantId”,
“value”: “abcde12345”
},
{
“name”: “instanceName”,
“value”: “Web Server”
}
・・・
}
を記述する。
このオーダパラメータの指定については、オーダにより異なる。この例の場合、クラウドのテナントＩＤ、インスタンス名等を指定している。
以下、上述のように構成されたＡＰＩアダプタ部１００の動作について説明する。
［オーダ受付部１１０の処理］
まず、オーダ受付部１１０の処理について説明する。
図５は、オーダ受付部１１０の処理を示す図である。
オーダ受付部１１０は、オーダ受付／応答処理と、オーダ内容の取得処理と、を実行する。
<オーダ受付／応答処理>
オーダ受付部１１０は、連携実行装置本体部２０との間で予め決められた手順に従って、単体オーダ３１の受信から単体オーダ３１の実行完了までの状態管理および通知、実行結果の流通を行う。
なお、連携実行装置本体部２０との間のシーケンスは、連携実行装置１０（図１参照）によって異なる可能性があるが、それぞれの連携実行装置１０については共通化可能である。
オーダ受付／応答処理の例について述べる。
オーダ受付部１１０は、単体オーダ３１を受信した場合、まずstate＝“acknowledged”とし、連携実行装置本体部２０に通知を出すとともに、ＡＰＩ呼出しロジック部１２０を呼出しロジック実行を開始させる。
ＡＰＩ呼出しロジック部１２０が、ロジック実行している中でオーダ受付部１１０に対し単体オーダ３１の内容を取得してほしい要請を出す。オーダ受付部１１０は、ＡＰＩ呼出しロジック部１２０の要請に応える形で、必要な情報をＡＰＩ呼出しロジック部１２０に送る。
オーダ受付部１１０は、ＡＰＩ呼出しロジック部１２０でのロジック実行が始まった場合、state＝“InProgress”とし、連携実行装置本体部２０に通知を出す。なお、本実施形態では、オーダ受付部１１０が、ＡＰＩ呼出しロジック部１２０を呼出した場合に、ＡＰＩ呼出しロジック部１２０でのロジック実行が始まった場合とみなしている。なお、オーダ受付部１１０は、ＡＰＩ呼出しロジック部１２０からのロジック実行開始通知を受け取る態様でもよい。
オーダ受付部１１０は、卸サービス事業者ＡＰＩ５０の応答を連携実行装置本体部２０に返却する。より詳細には、オーダ受付部１１０は、プロダクトという名称のオブジェクトに、卸サービス事業者ＡＰＩ５０から返ってきた値を入れ、その値を入れたオブジェクトを連携実行装置本体部２０に返却する。
オーダ受付部１１０は、ＡＰＩ呼出しロジック部１２０でのロジック処理が正常に終わった場合、state＝“completed”（オーダのステート完了）を連携実行装置本体部２０に通知する。
なお、上記オーダ受付／応答処理は、実装依存にかかるものであり、他の態様も可能である。
<オーダ内容の取得処理>
オーダ受付部１１０は、ＡＰＩ呼出しロジック部１２０の要請を受け、詳細なオーダ内容（カタログ／オーダパラメータ）を取得する。
なお、カタログ／オーダパラメータの記述方法は、連携実行装置１０（図１参照）によって異なる可能性があるが、それぞれについて共通化可能である。
オーダ内容の取得処理の例について述べる。
オーダ受付部１１０は、ＡＰＩ呼出しロジック部１２０の要請を受けて、オーダ内容を取得する。
オーダ受付部１１０は、カタログ取得処理を実行する。カタログ取得処理について説明する。図４に示す単体オーダ３１の具体例の「使用するカタログ（サービスメニュー）の指定」のように、「使用するカタログの指定」には参照先、例えば
“http://..../productOffering/80”が記載されている場合がある。この場合には、参照先にデータを取りに行き、参照先から取得したデータ（値）をＡＰＩ呼出しロジック部１２０に返す。ちなみに、ＴＭＦ形式の場合には、図４に示す単体オーダ３１の「使用するカタログの指定」では、参照先を指定し、「オーダパラメータの指定」では、オーダパラメータを直接記述することになる。
オーダ受付部１１０は、オーダパラメータ取得処理を実行する。
ところで、カタログは、オーダによらないものであるのに対し、オーダパラメータは、オーダそれぞれにあるものである。したがって、ＴＭＦ形式を用いない場合であっても同様のカタログ／オーダパラメータの記述になると考えられる。
オーダ受付部１１０は、基本的には、個々のアダプタに依存しない。このため、予めソースコードを作成しておくことができ、共通ライブラリのソースコード（例えば図１３の共通ライブラリソースコード１０６）という形で提供される。
［共通ライブラリ］
次に、図６を参照して共通ライブラリについて説明する。
図６は、共通ライブラリを説明する図であり、共通ライブラリ１４０の一例を示す図、共通ライブラリ１４０の「オーダ内容を取得」の呼び出し先１４１を示す図である。
共通ライブラリ１４０のメインとなる処理は、図６の符号ａ、ｂ、ｃであり、
前処理であるcreateOrFindMediatorProducts();と、
本処理であるinteractWithPartner();と、
後処理であるreflectToMediatorProducts();と、
を記述している。
このうち、
前処理「createOrFindMediatorProducts();」と後処理「reflectToMediatorProducts();」については、共通する処理であるので、共通ライブラリ内で実際の処理を記述している。
図６の符号ａに示すcreateOrFindMediatorProducts()の実際の処理としては、図６の符号ｄに示す「オーダ内容を取得」処理や、図６の符号ｇに示す「状態変更（InProgress）を通知」処理などを記述する。
図６の符号ｂに示す、本処理「interactWithPartner();」は、それぞれの卸サービスに対してＡＰＩを実行するという個別処理を行う箇所であり、共通ライブラリに共通化できないため、図６の符号ｂ１に示すＡＰＩ呼出しロジック部１２０による「個別実装」の中で記述する。
図６の符号ｃに示すreflectToMediatorProducts();は、「卸サービス事業者ＡＰＩの応答を連携実行装置本体部２０に返却」する処理であり、実際の処理は共通ライブラリ内で実装する（図６では省略）。
図６の符号ｄに示す「オーダ内容を取得」処理では、
productOffering = getProductOffering(id)
を記述することで、図６（ｂ）の符号ｅに示す「オーダ内容取得処理の詳細」を呼び出した後、図６の符号ｆに示すように、図６の符号ｄに示す「オーダ内容を取得」に戻る。
オーダ内容取得処理の詳細の記述イメージは以下である。ProductOffering(カタログ)取得処理が呼び出された場合は、下記getProductOfferingが実行される。
class XXXX {
getProductOffering (id) {
url = …;
header = ….;
pathParams = …;
response = setGetRequest(url, header, pathParams)
return response;
}

getProduct() {

}

getCharacteristic() {

}
}
図６の符号ｇに示すdoUpdateNotifyStatus(INPROGRESS);では、「状態変更（InProgress）を通知」処理を実行する。実際の処理は共通ライブラリ内で実装する（図６では省略）。
［ＡＰＩ呼出しロジック部１２０の処理］
次に、ＡＰＩ呼出しロジック部１２０の処理について説明する。
図７は、ＡＰＩ呼出しロジック部１２０の処理を示す図である。ただし、図７には、ＡＰＩ呼出しロジック部１２０は表記されておらず、ＡＰＩ順序制御とパラメータ詰替え処理が示されている。図７の星印マークは、連携実行装置本体部２０とＡＰＩアダプタ１０１間でＡＰＩの形式が変換されることを表し、図７の三角形は、卸サービス事業者ＡＰＩ同士であるためＡＰＩの形式が変換されないことを表している。
ＡＰＩアダプタ１０１は、Cloud ２１−１用のＡＰＩアダプタ１０１−２を例に採る。また、卸サービス事業者２で実行するＡＰＩは、Auth（Authorization（認証）トークン取得）、Create Network、Show Network、Create Subnet、Create Serverであるとする。
ＡＰＩ呼出しロジック部１２０（図７には図示せず）は、ＡＰＩ順序制御と、パラメータ詰替え処理と、を実行する。
<ＡＰＩ順序制御：１>
図７の符号ｈ１−ｈ６に示すように、ＡＰＩ呼出しロジック部１２０は、卸サービス事業者ＡＰＩ５０の起動条件をチェックし、決められた実行順序で卸サービス事業者ＡＰＩ５０を起動する。上記起動条件とは、下記の通りである。例えばあるパラメータがtrueになっていることを条件に、ＡＰＩを実行する、というように起動に条件がついている場合がある。ＡＰＩ呼出しロジック部１２０は、このような起動条件の有無をチェックし、起動条件を満たしていれば該当する卸サービス事業者ＡＰＩ５０を起動する。なお、上記実行順序は、設計段階で定めておく。
図７では、ＡＰＩ呼出しロジック部１２０（図７には図示せず）は、連携実行装置本体部２０からの単体オーダを受け取ると（図７の星印マーク参照）、決められた実行順序に従い、まず最初に卸サービス事業者ＡＰＩ５０（ここではAuth（認証）トークンのＡＰＩ５０）を起動する（図７の符号ｈ１参照）。
<パラメータ詰替え処理：２>
ＡＰＩ呼出しロジック部１２０（図７には図示せず）は、連携実行装置本体部２０からのオーダ内から卸サービス事業者ＡＰＩ５０（ここではAuthの卸サービス事業者ＡＰＩ５０）の実行に必要なパラメータを取り出し、卸サービス事業者ＡＰＩ実行部１３０（図７には図示せず）に送信する。
ここで、卸サービス事業者ＡＰＩ５０の実行に必要なパラメータについては、ＡＰＩアダプタの設計段階で、その値をどう設定するかを決定しておくものとする。例えば、予め決めた既定値を使うのか、サービス事業者のオーダから読み取るのか、設定ファイルから読み取るのか、等である。また、「サービス事業者のオーダから読み取る」としたパラメータについては、オーダ内でのデータ構成とパラメータ名を定めておく。例えば“name”: “user.id”, “value”: “100”等となる。
図７の符号ｉに示すように、ＡＰＩ呼出しロジック部１２０（図７には図示せず）は、
オーダから取り出したパラメータ
“name”: “user.id”
“value”: “100”
を
“userId”: 100
に詰め替える。
すなわち、図７の符号ｉに示すように、オーダから取り出したパラメータは、パラメータ名「“name”」の値が「“user.id”」、パラメータ名「“value”」の値が「“100”」になっている。一方、卸サービス事業者ＡＰＩ５０を実行する際には、「“userId”: 100」というように、パラメータ名が「“userId”」、値が「100」という形式に変換する必要がある。ＡＰＩ呼出しロジック部１２０（図７には図示せず）は、このようなパラメータ詰替え（変換）処理を行うことで、適切なデータ形式に変換している。
<ＡＰＩ順序制御：２>
そして、上記Auth（認証）トークンに関するAuthのＡＰＩ５０の処理が終わると、ＡＰＩ順序制御により、決められた実行順序に従って次の卸サービス事業者ＡＰＩ５０（ここではCreate Network）の卸サービス事業者ＡＰＩ５０を起動する（図７の符号ｈ２参照）。
次に、上記ＡＰＩ順序制御により、決められた実行順序に従って次の卸サービス事業者ＡＰＩ５０（ここではShow Networkの卸サービス事業者ＡＰＩ５０）を起動する（図７の符号ｈ３参照）。以下、上記ＡＰＩ順序制御により、同様の処理を繰り返してCreate Networkの卸サービス事業者ＡＰＩ５０の起動まで行う（図７の符号ｈ２参照）。
なお、一般的には、図７に示すように、Auth（認証）ＡＰＩを実行し、次にネットワーク構築するためCreate Networkの卸サービス事業者ＡＰＩ５０を起動し（図７の符号ｈ３参照）、さらにそのネットワークの中にサブネットを生成するためにCreate Subnetの卸サービス事業者ＡＰＩ５０を起動し（図７の符号ｈ４参照）(すなわちShow NetworkはCreate Networkの結果を確認するために起動している)、そのサブネットの中にサーバを作成するCreate Serverの卸サービス事業者ＡＰＩ５０を起動する（図７の符号ｈ５参照）、という実行順序となる。
Cloud ２１−２用のＡＰＩアダプタ１０１−２が、サブネットの中にサーバを作成するアダプタである場合、このサーバ作成完了で処理が終了する。
図７では、Create Networkの卸サービス事業者ＡＰＩ５０の起動と、Create Subnetの卸サービス事業者ＡＰＩ５０の起動との間に、Show Networkの卸サービス事業者ＡＰＩ５０を起動しているが、Show Networkの卸サービス事業者ＡＰＩ５０を起動する理由は下記の通りである。
Create Networkの卸サービス事業者ＡＰＩ５０は、非同期のＡＰＩである。このため、Create Networkの卸サービス事業者ＡＰＩ５０から応答が返ってきても、実際にネットワークが完成するまでには時間がかかる。そこで、Create Networkの卸サービス事業者ＡＰＩ５０の次の実行順序に、Show Networkの卸サービス事業者ＡＰＩ５０を置くことで、Create Networkの卸サービス事業者ＡＰＩ５０によりネットワークが完成したことを確認する。
<パラメータ詰替え処理：２>
上記ＡＰＩ順序制御による、決められた実行順序の最後の卸サービス事業者ＡＰＩ５０（ここではCreate Networkの卸サービス事業者ＡＰＩ５０）の実行では、上記パラメータ詰替え処理を行う。
ＡＰＩ呼出しロジック部１２０（図７には図示せず）は、卸サービス事業者ＡＰＩ（Create Networkの卸サービス事業者ＡＰＩ５０）の実行結果を卸サービス事業者ＡＰＩ実行部１３０（図７には図示せず）から受け取り、連携実行装置本体部２０に流通するための適切なデータ形式に変換する。
図７の符号ｊに示すように、ＡＰＩ呼出しロジック部１２０（図７には図示せず）は、
Create Networkの卸サービス事業者ＡＰＩ５０のパラメータ
server: {
“id” : “xxx”,
“status”: “active”,
(中略)
}
を
“name”: “server.status”
“value”: “active”
に詰め替える。
すなわち、図７の符号ｊに示すように、Create Serverの卸サービス事業者ＡＰＩ５０の実行結果として、例えばパラメータ名「“status”」の値が「“active”」で返ってきた場合、パラメータ名「“name”」の値が「“server.status”」、パラメータ名「“value”」の値が「“active”」というようにパラメータ詰替え（変換）処理を行う。
<ＡＰＩ順序制御：３>
図７の符号ｈ６に示すように、この例では、ＡＰＩ呼出しロジック部１２０（図７には図示せず）は、決められた実行順序の最後のCreate Networkの卸サービス事業者ＡＰＩ５０の実行結果をパラメータ詰替え処理したデータを連携実行装置本体部２０に流通させる（図７の星印マーク参照）。なお、この例（図７）では最後のＡＰＩの結果のみを流通しているが、流通するのは必ずしも最後のＡＰＩの結果だけに限らない。
［卸サービス事業者ＡＰＩ実行部１３０の処理］
次に、卸サービス事業者ＡＰＩ実行部１３０の処理について説明する。
図８は、卸サービス事業者ＡＰＩ実行部１３０の処理を示す図である。
上述したように、オーダ受付部１１０は、連携実行装置本体部２０（図示省略）からの単体オーダの受付／応答処理を行う。オーダ受付部１１０は、オーダ内容の取得を行う。ＡＰＩ呼出しロジック部１２０は、ＡＰＩ呼出しロジック（実行順序、入出力パラメータ指定等）を記述している。
図８に示すように、卸サービス事業者ＡＰＩ実行部１３０は、ＡＰＩ呼出しロジック部１２０から、卸サービス事業者ＡＰＩの実行に必要なデータ（オブジェクト６４）を受領する。
図８の符号ｋに示すように、卸サービス事業者ＡＰＩ実行部１３０は、オブジェクト６１をＨＴＴＰリクエスト６２の形に組み立て直す。ＨＴＴＰリクエスト６２は、ヘッダ６２ａと、ボディ６２ｂと、からなる。
図８の符号ｌに示すように、卸サービス事業者ＡＰＩ実行部１３０は、ＨＴＴＰリクエスト６２を卸サービス事業者２に送信する。
図８の符号ｍに示すように、卸サービス事業者ＡＰＩ実行部１３０は、卸サービス事業者２からＨＴＴＰレスポンス６３を受信する。ＨＴＴＰレスポンス６３は、ステータスコード６３ａ、ヘッダ６３ｂ、およびボディ６３ｃからなる。
図８の符号ｎに示すように、卸サービス事業者ＡＰＩ実行部１３０は、ステータスコードのチェックおよび例外発出処理（「例外」を発出する処理）を行う。
卸サービス事業者ＡＰＩ実行部１３０は、卸サービス事業者２にＨＴＴＰリクエスト６２を送信したとしても、正常応答が返ってくるとは限らないので、ステータスコードのチェックを行っている。例えば、卸サービス事業者２から、「Create Networkの生成に成功した旨のステータスコード」または「Create Networkの生成に失敗した旨のステータスコード（エラーコード）」を受け取る。
例外発出処理は、例外的な事態が発生した場合は、発生した例外の種類を示すコードを外部（卸サービス事業者ＡＰＩ実行部１３０の外部）に出力する。また、外部には、発生した例外の処理があらかじめライブラリとして用意されており、この例外（コード）を受け取る機能部（ソフトウェア）が例外処理を実行する。本実施形態では、卸サービス事業者ＡＰＩ実行部１３０が、例外発出を行うことで処理を終える。
図８の符号ｏに示すように、卸サービス事業者ＡＰＩ実行部１３０は、レスポンスヘッダの取得（token等）する。
図８の符号ｐに示すように、卸サービス事業者ＡＰＩ実行部１３０は、レスポンスヘッダおよびボディをもとに、適切な形式（例えばｈｔｔｐ形式をオブジェクト形式）に組み立て直してオブジェクト６４を作成する。卸サービス事業者ＡＰＩ実行部１３０は、オブジェクト６４をＡＰＩ呼出しロジック部１２０に返却する。
［ＡＰＩ仕様書を基にした自動生成］
次に、ＡＰＩ仕様書を基にした自動生成について説明する。
図９は、ＡＰＩ仕様書を基にした自動生成を説明する図である。
標準化団体Open API Initiativeでは、Google、Microsoft等が中心となって、マシンリーダブルなWeb API仕様書の記述方法の標準化を目指している。
Web API仕様書が、マシンリーダブルになることにより、クライアント側（アダプタ側）のＳＤＫ（Software Development Kit）部およびサーバ側（卸サービス側）のサーバモックが自動生成可能になる。この技術をサポートするＯＳＳ（Open-source software）である、Swagger Codegen（後記）を、本実施形態のＡＰＩアダプタ作成へ適用することにより、卸サービス事業者ＡＰＩ実行部１３０を自動生成する。なお、Swagger Codegenはあくまで一例であり、サーバ側ＡＰＩ仕様を基にした同様の自動生成技術であれば適用が可能である。
図９に示すように、サーバＩＦ仕様７１を準備する。サーバＩＦ仕様７１は、例えばOpen API Specification／Swagger Specification (以下、Swagger Spec)であり、ＷｅｂサービスにおけるＷＳＤＬ（Ｗｅｂサービスを記述するためのＸＭＬ表記）に相当する。
サーバＩＦ仕様７１からSwagger Codegenを適用してクライアントＩＦソースコード７２を生成する。Swagger Codegenは、WSDL2Javaに相当する。また、生成されたクライアントＩＦソースコード７２は、クライアントＳＤＫ （Ｗｅｂサービスにおけるスタブ）に相当する。
クライアントＩＦソースコード７２からクライアントＩＦ部７３を作成し、卸サービス事業者ＡＰＩ実行部１３０に実装する。
クライアントロジック部ソースコード７４を準備する。クライアントロジック部ソースコード７４をもとに、クライアントロジック部７５を作成する。
クライアントロジック部７５と卸サービス事業者ＡＰＩ実行部１３０とを組み合わせてクライアント側（アダプタ側）が完成する。
一方、サーバ側は各卸事業者が開発し、ＡＰＩ５０を公開することになる。本実施形態では、特にSwagger Codegenを利用しないが、例示しておくと、サーバ側では、サーバＩＦ仕様７１からサーバＩＦソースコード７６を生成する。このサーバＩＦソースコード７６は、モックサーバ （Ｗｅｂサービスにおけるスケルトン）に相当する。サーバＩＦソースコード７６からサーバＩＦ部７７を作成する。
サーバロジック部ソースコード７８を準備する。サーバロジック部ソースコード７８をもとに、サーバロジック部７９を作成する。
サーバロジック部７９とサーバＩＦ部７７とを組み合わせてサーバ側（Southbound）が完成する。
クライアント側（アダプタ側）の卸サービス事業者ＡＰＩ実行部１３０とサーバ側（Southbound）は、卸サービス事業者ＡＰＩ５０を通して、個々の卸サービス事業者ＡＰＩ５０に対応したＨＴＴＰリクエスト送信とレスポンス受信を行う。
［Swagger Codegen］
次に、Swagger Codegenについて説明する。
図１０は、Swagger Codegenを説明する図である。
Swagger Codegen８０は、Swagger Specで記載されたＡＰＩ仕様からクライアント／サーバコードを生成するコマンドラインツールである。Swagger Codegen８０は、Swagger Spec （REST APIに対して Swagger の仕様に準じたドキュメント）で記載されたＡＰＩ仕様からドライバもしくはクライアントＳＤＫを自動生成する。
Swagger Codegen８０には、コード自動生成のための変換ルールを定義したテンプレート８１と、各卸サービスのＡＰＩ仕様を定義したビルドに必要なファイルであるSpecファイル８２−１，Specファイル８２−２，Specファイル８２−３が入力される。Specファイル８２−１は、卸サービスＡのSpecファイル、Specファイル８２−２は、卸サービスＢのSpecファイル、Specファイル８２−３は、卸サービスＣのSpecファイルである。
Swagger Codegen８０は、各卸サービス事業者ＡＰＩ仕様を定義したSpecファイル（SpecファイルＡ８２−１、SpecファイルＢ８２−２、SpecファイルＣ８２−３）を入力し、テンプレート８１を参照して、各卸サービスごとの卸サービスＡＰＩ実行部ソースコードを自動生成する。自動生成対象の卸サービスＡＰＩ実行部ソースコードは、卸サービスＡＰＩ実行部ソースコード８３−１、卸サービスＡＰＩ実行部ソースコード８３−２、卸サービスＡＰＩ実行部ソースコード８３−３である。
以下、上述のように構成されたＡＰＩアダプタ部１００の作成方法について説明する。
本実施形態は、ＡＰＩアダプタ部１００の作成方法に特徴がある。
本実施形態のＡＰＩアダプタ作成方法は、オーダ受付部１１０と、ＡＰＩ呼出しロジック部１２０と、卸サービス事業者ＡＰＩ実行部１３０と、を組み合わせることによって、ＡＰＩアダプタ部１００（図３参照）を作成する。
具体的には、ＡＰＩアダプタ作成方法は、
・共通ライブラリ化されたオーダ受付部１１０を用いる方法
・共通ライブラリ化されたテンプレートソースコードおよび自動生成されたＩＦ仕様ドキュメントをもとに、ＡＰＩ呼出しロジック部１２０を実装する方法
・自動生成された卸サービス事業者ＡＰＩ実行部１３０を用いる方法
を有する。
上記各方法は、(1)卸サービス事業者ＡＰＩ実行部生成工程、(2)共通ライブラリおよび卸サービス事業者ＡＰＩ実行部組込み工程、(3)ＡＰＩ呼出しロジック部作成工程で実現される。
なお、共通ライブラリの例については、前記図６で述べた。
［ＡＰＩアダプタ作成方法の概要］
図１１は、ＡＰＩアダプタ作成方法の概要を示す図である。図１１は、ＡＰＩアダプタ作成方法の各工程を示す。
図１１に示すように、ＡＰＩアダプタ作成方法は、下記工程(1)−(3)を有する。
(1)卸サービス事業者ＡＰＩ実行部生成工程
卸サービス事業者ＡＰＩ実行部生成工程Ｓ４０では、卸サービス事業者ＡＰＩ仕様書をもとに、卸サービス事業者ＡＰＩ実行部ソースコードを自動生成する。卸サービスＡＰＩ実行部ソースコードの自動生成については、前記図１０のSwagger Codegenを用いる。なお、Swagger Codegenは一例であり、同様の技術であればこれに限らない。
卸サービス事業者ＡＰＩ実行部生成工程では、自動生成されたソースコードから、卸サービス事業者ＡＰＩ実行部仕様ドキュメントを生成する。
(2)共通ライブラリおよび卸サービス事業者ＡＰＩ実行部組込み工程
共通ライブラリおよび卸サービス事業者ＡＰＩ実行部組込み工程Ｓ４１では、共通ライブラリソースコードおよび生成した卸サービス事業者ＡＰＩ実行部ソースコードを、ＡＰＩ呼出しロジック部テンプレートソースコードに組み込む。
(3)ＡＰＩ呼出しロジック部作成工程
ＡＰＩ呼出しロジック部作成工程Ｓ４２では、共通ライブラリおよび卸サービスＡＰＩ実行部ソースコードを組み込んだテンプレートソースコード、および各種マニュアル・仕様ドキュメントをもとに、アダプタ部ソースコードを手動で実装する。作成したソースコードをビルドすることで、アダプタ部実行ファイルを得る。
以下、卸サービス事業者ＡＰＩ実行部生成工程、共通ライブラリおよび卸サービス事業者ＡＰＩ実行部組込み工程、およびＡＰＩ呼出しロジック部作成工程について順に説明する。
［卸サービス事業者ＡＰＩ実行部生成工程］
図１２は、卸サービス事業者ＡＰＩ実行部生成工程Ｓ４０を説明する工程図である。なお、図１２中の白抜きのファイルは、卸サービス事業者により提供される入力ファイルを、図１２中の網掛けのファイルは、共通ライブラリにより予め提供されるファイルを、図１２中のハッチングのファイルは、ツール等により自動生成されるファイルを、図１２中の格子のファイルは、手動で作成するファイルを、それぞれ示している（以下、ファイルについては同様の表記を採る）。
ステップＳ１１において、卸サービス事業者２（図１参照）は、ＡＰＩ仕様書（独自形式）１１３を提供する。
ステップＳ１２において、卸サービス事業者２が提供するＡＰＩ仕様書（独自形式）１１３を、標準形式の卸サービス事業者ＡＰＩ仕様書（標準形式）１０２に直す（変換する）。卸サービス事業者２によって標準形式のＡＰＩ仕様書が提供されていれば、本ステップＳ１２は不要である。
卸サービス事業者２のＡＰＩ仕様書１０２は、ＡＰＩエンドポイント、メソッド、Input／Outputパラメータ一覧等が記載されたファイルである。Open API Specification形式等を想定するが、これに限定するものではない。
ステップＳ１３において、共通ライブラリ（図６参照）により生成ルールテンプレートファイル１０３（図１０のテンプレート８１参照）を提供する。
生成ルールテンプレートファイル１０３には、標準形式のＡＰＩ仕様書から、卸サービス事業者ＡＰＩ実行部ソースコードを自動生成するためのルールが記載されている。また、生成ルールテンプレートファイル１０３には、ＨＴＴＰレスポンスにおけるステータスコードに応じた例外発出処理（図８の符号ｎに示す例外発出処理参照）、またレスポンスからのヘッダ値取得処理（図８の符号ｏに示すレスポンスヘッダの取得処理参照）がルールとして設定されている。なお、クライアントＩＦ部自動生成部１３１（後記）は、自動生成ツール自体であり、例えばswagger codegenである。
ステップＳ１４において、卸サービス事業者ＡＰＩ仕様書（標準形式）１０２および生成ルールテンプレートファイル１０３をクライアントＩＦ部自動生成部１３１に入力する。
ステップＳ１５において、クライアントＩＦ部自動生成部１３１は、卸サービス事業者ＡＰＩ仕様書（標準形式）１０２および生成ルールテンプレートファイル１０３をもとに、卸サービス事業者ＡＰＩ実行部ソースコード１０４（図９のクライアントＩＦソースコード７２に対応する）を生成する。クライアントＩＦ部自動生成部１３１は、標準形式のＡＰＩ仕様をもとに、卸サービス事業者ＡＰＩ実行部ソースコード１０４を自動生成する機能部であり、具体的にはクライアントＩＦ部自動生成ツールである。このクライアントＩＦ部自動生成ツールは、Swagger Codegen（図１０参照）等を想定するが、これに限定するものではない。
ステップＳ１６において、生成された卸サービス事業者ＡＰＩ実行部ソースコード１０４をビルド（コンパイル）することにより卸サービス事業者ＡＰＩ実行部仕様ドキュメント１０５を生成する。
卸サービス事業者ＡＰＩ実行部ソースコード１０４をビルドすることにより、卸サービス事業者ＡＰＩ実行部仕様ドキュメントおよび、卸サービス事業者ＡＰＩ実行部（クライアントＩＦ部７３）が生成される。ただし、本実施形態におけるＡＰＩアダプタ作成手順では後でまとめてビルドするため、クライアントＩＦ部７３は使用しない（図示を省略している）。
［共通ライブラリおよび卸サービス事業者ＡＰＩ実行部組込み工程］
図１３は、共通ライブラリおよび卸サービス事業者ＡＰＩ実行部組込み工程を説明する工程図である。
ステップＳ２１において、卸サービス事業者ＡＰＩ実行部生成工程（図１２参照）のステップＳ１５で生成された卸サービス事業者ＡＰＩ実行部ソースコード１０４を入力する。
ステップＳ２２において、共通ライブラリ（図６参照）により共通ライブラリソースコード１０６を提供する。共通ライブラリソースコード１０６は、共通ライブラリ化されたソースコードである。共通ライブラリソースコード１０６には、連携実行装置本体部２０（図３参照）からのオーダ受付・応答、オーダ内容取得機能を含む。
ステップＳ２３において、共通ライブラリソースコード１０６および卸サービス事業者ＡＰＩ実行部生成工程（図１２参照）で生成した卸サービス事業者ＡＰＩ実行部ソースコード１０４を、ＡＰＩ呼出しロジック部テンプレートソースコード１０７に組み込む。ＡＰＩ呼出しロジック部テンプレートソースコード１０７は、共通ライブラリ化された、ＡＰＩ呼出しロジック部のテンプレートソースコードである。ＡＰＩ呼出しロジック部テンプレートソースコード１０７は、パラメータ対応関係やＡＰＩ実行順序等以外の定型的な記述部分を含む。
［ＡＰＩ呼出しロジック部作成工程］
図１４は、ＡＰＩ呼出しロジック部作成工程を説明する工程図である。
ステップＳ３１において、共通ライブラリおよび卸サービス事業者ＡＰＩ実行部組込み工程（図１２参照）のステップＳ２３で生成されたＡＰＩ呼出しロジック部テンプレートソースコード１０７を入力する。
ステップＳ３２において、共通ライブラリ（図６参照）により予め提供されるファイルであるアダプタ部実装マニュアル１０８および共通ライブラリ仕様ドキュメント１０９と、ツール等により自動生成されるファイルである卸サービス事業者ＡＰＩ実行部仕様ドキュメント１０５と、を参照可能にする。
ステップＳ３３において、アダプタ部実装マニュアル１０８、共通ライブラリ仕様ドキュメント１０９、および卸サービス事業者ＡＰＩ実行部仕様ドキュメント１０５を参考にしながら、ＡＰＩ呼出しロジック部テンプレートソースコード１０７に、手動で変更を加えることで、ＡＰＩ呼出しロジック部１２０（図３参照）を実装する。すなわち、ステップＳ３３では、共通ライブラリおよび卸サービスＡＰＩ実行部ソースコードを組み込んだテンプレートソースコード、および各種マニュアル・仕様ドキュメントを基に、アダプタ部ソースコード１１４を手動で実装する。
ステップＳ３４において、作成したアダプタ部ソースコードをビルド（コンパイル）することで、アダプタ部実行ファイル１１１を生成する。アダプタ部実行ファイル１１１を得ることで、ＡＰＩ呼出しロジック部作成工程が完了する。アダプタ部実行ファイル１１１は、アダプタ登録処理で用いる。
［アダプタ登録処理］
次に、アダプタ登録処理の処理について説明する。
図１５は、アダプタ登録処理を示す図である。図１と同一構成部分には同一符号を付している。
アダプタ登録処理は、図１４のＡＰＩ呼出しロジック部作成工程で作成したアダプタ部実行ファイル１１１をＡＰＩアダプタ部１００に登録する処理である。アダプタ部実行ファイル１１１をＡＰＩアダプタ部１００に登録することで、ＡＰＩアダプタ部１００は、最新の仕様で、各卸サービス事業者が提供するＡＰＩ仕様差分を吸収することができる。
図１５に示すように、ＡＰＩアダプタ部１００は、作成したアダプタ部実行ファイル１１１と本体部configファイル１１２を所定のフォルダに配置する。本体部configファイル１１２は、新規追加するアダプタの名前等を指定するものである。
連携実行装置本体部２０は、本体部configファイル１１２に、新規追加するアダプタの名前等を指定する。
以上、ＡＰＩアダプタ部１００にアダプタ部実行ファイル１１１を登録し、かつ、連携実行装置本体部２０に本体部configファイル１１２で、新規追加するアダプタの名前等を指定するconfig設定を行うことでアダプタ登録処理が完了し、ＡＰＩアダプタ部１００を新規卸サービス／仕様変更への追随させることができる。
以上説明したように、本実施形態のＡＰＩアダプタ作成方法は、サービス事業者１が、卸サービスを提供している複数の卸サービス事業者のサービスを組合せた連携サービスを一括で構築する連携実行装置１０に用いられるＡＰＩアダプタ１００が、サービス事業者１からの連携オーダ３を単体オーダ３１に分解する連携実行装置本体部２０から、単体オーダ３１を受付け、かつ、連携実行装置本体部２０への応答処理を行うオーダ受付部組込み工程と、卸サービス事業者ＡＰＩ５０の起動条件をもとに、決められた実行順序で卸サービス事業者ＡＰＩ５０を起動し、単体オーダ３１内から卸サービス事業者ＡＰＩ５０の実行に必要なパラメータを取り出し、卸サービス事業者ＡＰＩ実行部組込み工程に送信するとともに、卸サービス事業者ＡＰＩ５０の実行結果を、連携実行装置本体部２０に流通するためのデータ形式に変換するＡＰＩ呼出しロジック部作成工程と、ＡＰＩ呼出しロジック部１２０から、卸サービス事業者ＡＰＩ実行に必要なデータを受領し、ＨＴＴＰリクエストの形に組み立て直して卸サービス事業者２に送信するとともに、卸サービス事業者２からＨＴＴＰレスポンスを受信後、ステータスコードのチェックおよび例外発出処理、レスポンスヘッダおよびボディの取得を行い、適切な形式に組み立て直してＡＰＩ呼出しロジック部１２０に返却する卸サービス事業者ＡＰＩ実行部作成工程および組込み工程と、を有する。
これにより、新規卸サービス／仕様変更への追随において、サービス依存部であるＡＰＩアダプタ部を効率的に作成することができる。
本実施形態では、卸サービス事業者ＡＰＩ仕様書１０２をもとに、卸サービス事業者ＡＰＩ実行部ソースコード１０４を自動生成し、自動生成された卸サービス事業者ＡＰＩ実行部ソースコード１０４から、卸サービス事業者ＡＰＩ実行部仕様ドキュメント１０５を生成する卸サービス事業者ＡＰＩ実行部生成工程（図１２参照）を、さらに有する。これにより、卸サービス事業者ＡＰＩ実行部の開発が不要になる。また、図１２に示すように、次工程の卸サービス事業者ＡＰＩ実行部組込み工程（図１３参照）に、生成した卸サービス事業者ＡＰＩ実行部仕様ドキュメント１０５を提供することができる。
本実施形態では、卸サービス事業者ＡＰＩ実行部組込み工程（図１３参照）は、共通ライブラリソースコード１０６および生成した卸サービス事業者ＡＰＩ実行部ソースコード１０４を、ＡＰＩ呼出しロジック部テンプレートソースコード１０７に組み込む。共通ライブラリソースコード１０６を用いることで、共通ライブラリ資源を利用して効率良く、卸サービス事業者ＡＰＩ実行部ソースコード１０４を、ＡＰＩ呼出しロジック部テンプレートソースコード１０７に組み込むことができる。図１２に示すように、次工程のＡＰＩ呼出しロジック部作成工程（図１４参照）に、卸サービス事業者ＡＰＩ実行部ソースコード１０４を組み込んだＡＰＩ呼出しロジック部テンプレートソースコード１０７を提供することができる。ＡＰＩアダプタ部１００の卸サービス事業者ＡＰＩ実行部１３０（図３参照）を効率良く作成することができる。
本実施形態では、ＡＰＩ呼出しロジック部作成工程（図１４参照）は、共通ライブラリおよび卸サービス事業者ＡＰＩ実行部ソースコード１０４を組み込んだテンプレートソースコード、および各種マニュアル・仕様ドキュメントをもとに、アダプタ部ソースコード１１４を実装し、作成したアダプタ部ソースコード１１４をビルドしてアダプタ部実行ファイル１１１を生成する。既存技術（非特許文献１，２）では、ＡＰＩアダプタの作成方法については述べていないこと、また、既存技術で述べているＡＰＩアダプタの構成をそのまま実装しようとすると、共通部や自動生成可能な部分も手動で実装する必要があるため非効率だったこと、が課題であった。
これに対して、本実施形態では、上記卸サービス事業者ＡＰＩ実行部生成工程と、上記共通ライブラリおよび卸サービス事業者ＡＰＩ実行部組込み工程と、本ＡＰＩ呼出しロジック部作成工程とを組み合わせることで、アダプタ部実行ファイル１１１を作成することができる。アダプタ部実行ファイル１１１を効率良く作成することができるので、新規ＡＰＩへの追随が容易になる。例えば、ＡＰＩアダプタ部１００を新規卸サービス／仕様変更への追随が容易になる。このように、上記卸サービス事業者ＡＰＩ実行部生成工程と、上記共通ライブラリおよび卸サービス事業者ＡＰＩ実行部組込み工程と、上記ＡＰＩ呼出しロジック部作成工程とを組み合わせることで、ＡＰＩアダプタ部１００を効率的に作成することができる。
本実施形態では、ロジック部作成工程で作成したアダプタ部実行ファイル１１１をＡＰＩアダプタ部１００に登録するアダプタ登録処理工程を有することで、アダプタ部実行ファイル１１１をＡＰＩアダプタ部１００に登録して、ＡＰＩアダプタ部１００を新規卸サービス／仕様変更への追随させることができる。
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。
１ サービス事業者
２，２−１，２−２，２−３ 卸サービス事業者
３，３−１，３−２，３−３ 連携オーダ
４ サービス
１０ 連携実行装置
２０ 連携実行装置本体部
３０ 連携実行装置本体部ＡＰＩ
３１ 単体オーダ
３１−１ NW service用単体オーダ
３１−２ Cloud service用単体オーダ
３１−３ APL service用単体オーダ
４０ 連携実行装置ＡＰＩ
５０ 卸サービス事業者ＡＰＩ
５１ 卸サービスＡＰＩ（仕様差分）
１００ ＡＰＩアダプタ部
１０１，１０１−１，１０１−２，１０１−３ ＡＰＩアダプタ
１１０ オーダ受付部（オーダ受付手段）
１２０ ＡＰＩ呼出しロジック部（ＡＰＩ呼出しロジック手段）
１３０ 卸サービス事業者ＡＰＩ実行部（卸サービス事業者ＡＰＩ実行手段）

Claims (7)

  1. 複数の卸サービスを組み合わせた連携サービスを一括で構築する連携実行装置に用いられるＡＰＩ（Application Program Interface）アダプタであって、
    前記連携サービスのオーダを単体オーダに分解する連携実行装置本体部から、前記単体オーダを受付け、かつ、前記連携実行装置本体部への応答処理を行うオーダ受付部と、
    卸サービス事業者ＡＰＩの起動条件をもとに、決められた実行順序で前記卸サービス事業者ＡＰＩを起動し、
    前記単体オーダ内から前記卸サービス事業者ＡＰＩの実行に必要なパラメータを取り出し、卸サービス事業者ＡＰＩ実行部に送信するとともに、前記卸サービス事業者ＡＰＩの実行結果を、前記連携実行装置本体部が流通可能なデータ形式に変換するＡＰＩ呼出しロジック部と、
    前記ＡＰＩ呼出しロジック部から、卸サービス事業者ＡＰＩの実行に必要なパラメータを受領し、リクエストの形に組み立て直して前記卸サービス事業者ＡＰＩに要求するとともに、当該リクエストに対する実行結果としてのレスポンスを受信後、当該レスポンスを所定形式に組み立て直して前記ＡＰＩ呼出しロジック部に返却する前記卸サービス事業者ＡＰＩ実行部と、を備える
    ことを特徴とするＡＰＩアダプタ。
  2. 複数の卸サービスを組み合わせた連携サービスを一括で構築する連携実行装置に用いられるＡＰＩアダプタを作成する方法であって、
    前記ＡＰＩアダプタは、オーダ受付部、ＡＰＩ呼出しロジック部、および卸サービス事業者ＡＰＩ実行部を備えており、
    前記オーダ受付部が、前記連携サービスのオーダを単体オーダに分解する連携実行装置本体部から、前記単体オーダを受付ける工程と、
    前記ＡＰＩ呼出しロジック部が、卸サービス事業者ＡＰＩの起動条件をもとに、決められた実行順序で前記卸サービス事業者ＡＰＩを起動し、
    前記単体オーダ内から前記卸サービス事業者ＡＰＩの実行に必要なパラメータを取り出し、前記卸サービス事業者ＡＰＩ実行部に送信する工程と、
    前記卸サービス事業者ＡＰＩ実行部が、前記ＡＰＩ呼出しロジック部から、前記卸サービス事業者ＡＰＩの実行に必要なパラメータを受領し、リクエストの形に組み立て直して前記卸サービス事業者ＡＰＩに要求する工程と、
    前記卸サービス事業者ＡＰＩ実行部が、当該リクエストに対する実行結果としてのレスポンスを受信後、当該レスポンスを所定形式に組み立て直して前記ＡＰＩ呼出しロジック部に返却する工程と、
    前記ＡＰＩ呼出しロジック部が、前記卸サービス事業者ＡＰＩの実行結果を、前記連携実行装置本体部が流通可能なデータ形式に変換する工程と、
    オーダ受付部が、前記連携実行装置本体部への応答処理を行う工程と、を有する
    ことを特徴とするＡＰＩアダプタ作成方法。
  3. 前記卸サービス事業者ＡＰＩ実行部が、卸サービス事業者ＡＰＩ仕様書をもとに、卸サービス事業者ＡＰＩ実行部ソースコードを自動生成し、自動生成された前記卸サービス事業者ＡＰＩ実行部ソースコードから、卸サービス事業者ＡＰＩ実行部仕様ドキュメントを生成する工程を、さらに有する
    ことを特徴とする請求項２に記載のＡＰＩアダプタ作成方法。
  4. 前記卸サービス事業者ＡＰＩ実行部が、共通ライブラリソースコードおよび生成した前記卸サービス事業者ＡＰＩ実行部ソースコードを、ＡＰＩ呼出ロジック部テンプレートソースコードに組み込む工程をさらに有する
    ことを特徴とする請求項３に記載のＡＰＩアダプタ作成方法。
  5. 前記ＡＰＩ呼出しロジック部が、共通ライブラリおよび卸サービスＡＰＩ実行部ソースコードを組み込んだテンプレートソースコード、および各種マニュアル・仕様ドキュメントをもとに、アダプタ部ソースコードを実装し、作成したアダプタ部ソースコードをビルドしてアダプタ部実行ファイルを生成する
    ことを特徴とする請求項２に記載のＡＰＩアダプタ作成方法。
  6. ＡＰＩ呼出しロジック部は、作成した前記アダプタ部実行ファイルを前記ＡＰＩアダプタに登録する工程を有する
    ことを特徴とする請求項５に記載のＡＰＩアダプタ作成方法。
  7. 複数の卸サービスを組み合わせた連携サービスを一括で構築する連携実行装置に用いられるＡＰＩアダプタとしてのコンピュータを、
    前記連携サービスのオーダを単体オーダに分解する連携実行装置本体部から、前記単体オーダを受付け、かつ、前記連携実行装置本体部への応答処理を行うオーダ受付手段、
    卸サービス事業者ＡＰＩの起動条件をもとに、決められた実行順序で前記卸サービス事業者ＡＰＩを起動し、
    前記単体オーダ内から前記卸サービス事業者ＡＰＩの実行に必要なパラメータを取り出し、卸サービス事業者ＡＰＩ実行手段に送信するとともに、前記卸サービス事業者ＡＰＩの実行結果を、前記連携実行装置本体部が流通可能なデータ形式に変換するＡＰＩ呼出しロジック手段、
    前記ＡＰＩ呼出しロジック手段から、前記卸サービス事業者ＡＰＩの実行に必要なパラメータを受領し、リクエストの形に組み立て直して前記卸サービス事業者ＡＰＩに要求するとともに、当該リクエストに対する実行結果としてのレスポンスを受信後、当該レスポンスを所定形式に組み立て直して前記ＡＰＩ呼出しロジック手段に返却する前記卸サービス事業者ＡＰＩ実行手段、として機能させるためのプログラム。
JP2018028324A 2018-02-20 2018-02-20 Ａｐｉアダプタ、ａｐｉアダプタ作成方法、およびプログラム Active JP6795531B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018028324A JP6795531B2 (ja) 2018-02-20 2018-02-20 Ａｐｉアダプタ、ａｐｉアダプタ作成方法、およびプログラム
US16/971,256 US10977102B2 (en) 2018-02-20 2019-02-19 API adapter, API adapter creation method, and program
PCT/JP2019/006171 WO2019163793A1 (ja) 2018-02-20 2019-02-19 Ａｐｉアダプタ、ａｐｉアダプタ作成方法、およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018028324A JP6795531B2 (ja) 2018-02-20 2018-02-20 Ａｐｉアダプタ、ａｐｉアダプタ作成方法、およびプログラム

Publications (2)

Publication Number Publication Date
JP2019144848A JP2019144848A (ja) 2019-08-29
JP6795531B2 true JP6795531B2 (ja) 2020-12-02

Family

ID=67687800

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018028324A Active JP6795531B2 (ja) 2018-02-20 2018-02-20 Ａｐｉアダプタ、ａｐｉアダプタ作成方法、およびプログラム

Country Status (3)

Country Link
US (1) US10977102B2 (ja)
JP (1) JP6795531B2 (ja)
WO (1) WO2019163793A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7003867B2 (ja) * 2018-08-02 2022-01-21 日本電信電話株式会社 Ａｐｉアダプタ作成装置、ａｐｉアダプタ作成方法およびａｐｉアダプタ作成プログラム
US11221896B2 (en) * 2020-01-22 2022-01-11 Idera, Inc. Systems and methods for API request conversion
US11507351B2 (en) * 2020-05-12 2022-11-22 Vmware, Inc. Intent compiler
JPWO2022215194A1 (ja) * 2021-04-07 2022-10-13
US11567738B2 (en) * 2021-04-15 2023-01-31 Red Hat, Inc. Code generator for creating a unified data model for multiple language specifications
US20230102570A1 (en) * 2021-09-28 2023-03-30 Arteris, Inc. System and method for scripting generators
US11989558B2 (en) * 2022-02-24 2024-05-21 Sap Se Automatic generation of a cloud integration adapter from a standard, programming language-agnostic interface specification
WO2023199414A1 (ja) * 2022-04-12 2023-10-19 日本電信電話株式会社 バーチャルヒューマン開発支援システム、バーチャルヒューマン開発支援方法及びバーチャルヒューマン開発支援プログラム
KR102528717B1 (ko) * 2022-10-07 2023-05-08 이데아텍(주) 보안 기능을 지원하는 api 통합 처리를 위한 게이트웨이 장치 및 이의 동작 방법

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020128919A1 (en) * 2001-03-06 2002-09-12 Cedric-Gaya Rime Order processing system
JP2008134913A (ja) * 2006-11-29 2008-06-12 Nippon Telegr & Teleph Corp <Ntt> 複合サービス提供システムおよび方法
JP6169662B2 (ja) * 2015-09-11 2017-07-26 西日本電信電話株式会社 Ａｐｉ変換アダプタ、ａｐｉ変換システム、及びａｐｉ変換プログラム
US10331505B2 (en) * 2016-06-30 2019-06-25 Microsoft Technology Licensing, Llc. Application programming interface (API) hub
US11461843B2 (en) * 2019-05-23 2022-10-04 Capital One Services, Llc Multi-lender platform that securely stores proprietary information for pre-qualifying an applicant

Also Published As

Publication number Publication date
US20200387415A1 (en) 2020-12-10
JP2019144848A (ja) 2019-08-29
US10977102B2 (en) 2021-04-13
WO2019163793A1 (ja) 2019-08-29

Similar Documents

Publication Publication Date Title
JP6795531B2 (ja) Ａｐｉアダプタ、ａｐｉアダプタ作成方法、およびプログラム
US10331422B1 (en) System and method for generating API devlopment code for integrating platforms
US9311171B1 (en) Execution of end-to-end-processes across applications
JP5911262B2 (ja) 情報処理装置、情報処理装置の制御方法、及びプログラム
US6961760B2 (en) Transforming data automatically between communications parties in a computing network
US8248992B2 (en) Method and apparatus for providing home network device service to an external device through web service
CN107040416B (zh) 一种基于Cairngorm框架的虚拟数据中心可视化管理方法
US9086935B2 (en) Accessing business object resources for a machine-to-machine communication environment
Nguyen et al. Ws2jade: Integrating web service with jade agents
US20060251125A1 (en) System and method for producing notification based web services
US20070118842A1 (en) DDS-assisted CORBA discovery
AU2023251465A1 (en) System and method for generating api development code for integrating platforms
CN102497451A (zh) 服务处理系统和服务处理方法
WO2018116933A1 (ja) Ｒｐｃ変換処理システムおよびｒｐｃ変換方法
CA2543557C (en) System and method for producing notification based web services
CN113778499B (zh) 发布服务的方法、装置、设备和计算机可读介质
US20170353581A1 (en) Content based routing architecture system and method
JP5517255B2 (ja) 複数のサービスノードサーバにおけるサービス連結制御方法、制御ノードサーバ及びプログラム
US8700737B2 (en) Automated method for generating a web service composition
Marinho et al. Extending a software component repository to provide services
Baranda et al. Multi-Administrative Domain Service Onboarding in a ZSM-Based Orchestration Architecture
JP7332950B2 (ja) サービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラム
Chiponga et al. A version-based transformation proxy for service evolution
WO2006040991A1 (ja) 端末装置、サーバ装置、及びWebサービス提供システム
Lundblad Information Logistics Service Router. An ESB for integrating enterprise services

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190731

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200825

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201021

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20201110

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20201112

R150 Certificate of patent or registration of utility model

Ref document number: 6795531

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150