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

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

Info

Publication number
WO2021156992A1
WO2021156992A1 PCT/JP2020/004477 JP2020004477W WO2021156992A1 WO 2021156992 A1 WO2021156992 A1 WO 2021156992A1 JP 2020004477 W JP2020004477 W JP 2020004477W WO 2021156992 A1 WO2021156992 A1 WO 2021156992A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
service
definition information
cooperation support
support device
Prior art date
Application number
PCT/JP2020/004477
Other languages
English (en)
French (fr)
Inventor
亮太 片柳
謙輔 高橋
近藤　悟
Original Assignee
日本電信電話株式会社
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 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to JP2021575172A priority Critical patent/JP7332950B2/ja
Priority to US17/797,535 priority patent/US12067431B2/en
Priority to PCT/JP2020/004477 priority patent/WO2021156992A1/ja
Publication of WO2021156992A1 publication Critical patent/WO2021156992A1/ja

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/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • 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
    • 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/44—Arrangements for executing specific programs
    • 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

Definitions

  • the present invention relates to a service cooperation support device, a service cooperation support method, and a service cooperation support program.
  • Non-Patent Document 1 For facilitating the development of such an adapter, there is a technique for generating an adapter using a GUI (Non-Patent Document 1). In addition, cooperation between services that does not depend on the characteristics of API is also being studied (Non-Patent Document 2).
  • the present invention has been made in view of the above circumstances, and an object of the present invention is a service cooperation support device that facilitates mapping between a stateless API on the upper device side and a stateful API on the lower device side.
  • the purpose is to provide a service cooperation support method and a service cooperation support program.
  • one aspect of the present invention is a service cooperation support device, which is a stateless upper API definition information disclosed to a higher device that links a plurality of services, and a stateful plurality of stateful APIs disclosed by the lower device.
  • At least one lower API corresponding to the higher API is extracted by using the reception unit that receives the definition information of the lower API, the definition information of the upper API, and the definition information of the lower API, and the extracted lower API. It has an interpretation unit that generates an API correspondence table in which the execution order of is set.
  • One aspect of the present invention is a service cooperation support method performed by a service cooperation support device, in which definition information of a stateless upper API published to a higher device that links a plurality of services and a plurality of stateful states published by a lower device. At least one lower API corresponding to the upper API is extracted by using the reception step for accepting the definition information of the lower API, the definition information of the upper API, and the definition information of the lower API, and the extracted lower API Performs a generation step of generating an API correspondence table in which the execution order is set.
  • One aspect of the present invention is a service cooperation support program that causes a computer to function as the service cooperation support device.
  • a service cooperation support device a service cooperation support method, and a service cooperation support program that facilitate mapping between a stateless API on the upper device side and a stateful API on the lower device side are provided. Can be done.
  • FIG. 1 is a configuration diagram of the service cooperation system of the present embodiment.
  • the illustrated service cooperation system includes a service cooperation device 1, a plurality of services 2A, 2B, and 2C, and a cooperation support device 5 (service cooperation support device).
  • the service cooperation device 1 is a device that executes a cooperation service in which a plurality of types of services are linked. As a plurality of types of services, FIG. 1 shows three services 2A, 2B, and 2C.
  • Service 2A is a network service provided by company A (service provider).
  • Service 2B is a service provided by company B (service provider), and is a cloud service such as IaaS (Infrastructure as a Service) and PaaS (Platform as a Service).
  • Service 2C is a service of a Web application (hereinafter referred to as "application") provided by company C (service provider).
  • application Web application
  • services 2A and 2B are services that have a stateless API and are made public (provided) (hereinafter, also referred to as “stateless service”).
  • service 2C is a service that has a stateful API and is open to the public (hereinafter, also referred to as a "stateful service”).
  • Stateless (RESTful) is a communication method in which the server does not hold the internal state (dynamic information) such as session information with the client. Therefore, the stateless communication method is a self-contained method in which the client request includes all the information necessary for executing (processing) the API.
  • the stateful communication method is a communication method in which the server holds the internal state such as session information with the client and appropriately refers to it when executing the API.
  • the service 2C that publishes the stateful API and the services 2A and 2B that publish the stateless API cooperate to form one linked service. That is, in the present embodiment, the service cooperation device 1 executes a cooperation service in which a plurality of services including the service 2C that publishes the stateful API are linked.
  • the service cooperation device 1 of the present embodiment realizes a cooperation service in which a plurality of services are linked regardless of the communication method (stateless, stateful) of the API of the service to be linked.
  • the service cooperation device 1 executes a cooperation service in which a plurality of services including the application service 2C that publishes the stateful API are linked.
  • the service cooperation device 1 shown in the figure includes a catalog interpretation execution unit 10, an adapter unit 21-23, and a catalog management unit 30.
  • the catalog management unit 30 manages a catalog (Product catalog) that defines service specifications.
  • the catalog is stored in, for example, a storage unit (not shown) included in the catalog management unit 30.
  • FIG. 1 shows a company A catalog 31, a company B catalog 32, and an application catalog 33 for each of the plurality of services 2A, 2B, and 2C.
  • the catalogs dealt with in the present invention are not limited to these.
  • a catalog is prepared for each service, and when a new service is added, a catalog corresponding to the service is prepared, and the catalog management unit 30 registers and manages the catalog in the storage unit.
  • the catalog management unit 30 creates a linked catalog as a catalog for the linked service by combining a plurality of catalogs of a plurality of services constituting the linked service, and stores the linked catalog in the storage unit.
  • the catalog management unit 30 creates a linked catalog 41 that combines a company A catalog 31, a company B catalog 32, and an application catalog 33, and stores them in the storage unit.
  • the linkage catalog 41 defines the specifications of the linkage service including the three services 2A, 2B, and 2C.
  • the cooperation catalog 41 includes rule 411. Rule 411 is a regulation regarding a linked operation between each service constituting the linked service.
  • the catalog interpretation execution unit 10 interprets the contents of the catalog in the linked catalog of the linked service and processes the request.
  • the catalog interpretation execution unit 10 interprets all the catalogs included in the linked catalog and processes the request.
  • the catalog interpretation execution unit 10 can be said to be a functional unit that executes common processing in inter-service cooperation that does not depend on each of the services corresponding to the catalog.
  • the adapter units 21 to 23 execute the API of each service constituting the linked service and process the request from the client.
  • the adapter units 21 to 23 are provided for each service, and when a new service is added, the service cooperation device 1 adds a new adapter unit.
  • the adapter units 21 to 23 can be said to be functional units that process requests depending on the API specifications of each service.
  • the service cooperation device 1 of the present embodiment when a new service is to be linked with the cooperation service, it is only necessary to prepare a catalog and an adapter unit corresponding to the new service. Therefore, additional development of the entire service cooperation device 1 is not required, and the follow-up cost when adding a new service and a new API to the cooperation service can be reduced.
  • the service group constituting the cooperation service can be configured as a catalog-driven loosely coupled architecture.
  • the cooperation support device 5 is a device for easily linking a stateful service that publishes a stateful API with other services.
  • the service cooperation system may be provided with a separate cooperation support device 5 for each stateful service.
  • the service cooperation system may include one cooperation support device 5 for a plurality of stateful services, and the cooperation support device 5 may publish a stateless API for each service.
  • FIG. 2 is a block diagram showing the configuration of the cooperation support device 5 of the present embodiment.
  • the cooperation support device 5 of the present embodiment automatically generates an API correspondence table showing the correspondence (mapping) between the stateless upper API of the upper device and the stateful lower API of the lower device, and is stateful based on the API correspondence table. Controls the execution of lower APIs. Specifically, the cooperation support device 5 performs a mapping process between the upper API and the lower API when the definition information is input, and generates an API correspondence table. Then, the cooperation support device 5 selects the corresponding stateful lower API by using the automatically generated API correspondence table in response to the stateless upper API request from the upper device, and executes the lower API in the set order. do.
  • the cooperation support device 5 of the present embodiment supports not only the service of publishing the stateless lower API but also the cooperation service including the service of publishing the stateful lower API in a short period of time and at low cost. can do.
  • the illustrated cooperation support device 5 includes an execution unit 51, a UI unit 52 (user interface unit), an API analysis unit 53, a management unit 54, a storage unit 55, and a DB (database) 56 that stores an API correspondence table. And.
  • the execution unit 51 In response to a request from the service cooperation device 1 (upper device), the execution unit 51 identifies a stateful lower API corresponding to the upper API using the API correspondence table, and specifies the specified lower API in the API correspondence table. Execute in the order. Specifically, the execution unit 51 receives a stateless upper API request for the stateful service from the service cooperation device 1 that executes the cooperation service in which a plurality of services including the stateful service are linked, and receives the request from the API correspondence table. Map to the lower API using and execute the lower API.
  • the higher-level API is a stateless API that the cooperation support device 5 exposes to the service cooperation device 1.
  • the execution unit 51 may notify the service cooperation device 1 of the completion of execution of the lower API and prompt the service cooperation device 1 to acquire the execution result of the lower API.
  • the execution unit 51 may include the internal state stored in the storage unit 55 in the second and subsequent requests to the lower API.
  • the UI unit 52 accepts inputs of the upper API definition information 91, the lower API definition information 92, and the internal state definition information 93.
  • the upper API definition information 91 is stateless upper API definition information disclosed to the service cooperation device 1 (upper device) that links a plurality of services.
  • the lower API definition information 92 is definition information of a plurality of stateful lower APIs disclosed by the application service 2C (lower device).
  • the internal state definition information 93 is the definition information of the internal state of the application service 2C that is referred to when the lower API is executed.
  • the API analysis unit 53 extracts at least one lower API corresponding to the upper API by using the upper API definition information 91 and the lower API definition information 92, and generates an API correspondence table in which the execution order of the extracted lower APIs is set. do. That is, the API analysis unit 53 analyzes and maps the correspondence between the stateless upper API and the stateful lower API. Further, the API analysis unit 53 may generate an API correspondence table using the internal state definition information 93.
  • the API analysis unit 53 extracts the lower API that outputs the output information of the upper API, and when the input information of the extracted lower API is only the input information of the upper API, the execution order of the lower API is prioritized over the other lower APIs. You may.
  • the management unit 54 manages the storage unit 55 and the DB 56.
  • the storage unit 55 stores the internal state included in the response of the stateful lower API.
  • the internal state is information necessary for executing the lower API, and is information notified from the lower device on the service side (here, the server of the application service 2C) when the lower API is executed.
  • the internal state may include session information (for example, Cookie) between the cooperation support device 5 and the lower device that provides the stateful service.
  • the storage unit 55 stores the execution result of the lower API.
  • the API correspondence table generated by the API analysis unit 53 is stored in the DB 56.
  • the cooperation support device 5 supports cooperation between the service 2C that publishes a stateful lower API and other services without losing the merits of the service cooperation device 1.
  • the first merit is that it is possible to reduce the cost of adding a new service or adapting to a change in existing service specifications by loosely coupling the catalog management unit 30 and the adapter unit 23.
  • the second merit is that even in the service 2C that publishes the stateful lower API, the service cooperation device 1 can mount the stateless upper API adapter unit 23 to which the development facilitation technology of Non-Patent Document 1 is applied. , The development cost of the adapter unit 23 can be reduced.
  • the cooperation support device 5 discloses the stateless upper API on the upper side (Northbound) and accepts the request from the service cooperation device 1.
  • the upper API is an API that is open to the service cooperation device 1 (upper device) that manages and operates the own device 5 from the viewpoint of the cooperation support device 5.
  • the cooperation support device 5 implements a higher-level API for each stateful service and publishes it to the service cooperation device 1. ..
  • the upper API is generated in advance according to the specifications of the stateful API and the catalog on the service side, and is implemented in the execution unit 51 of the cooperation support device 5.
  • the cooperation support device 5 maps the request of the upper API transmitted from the service cooperation device 1 to the stateful lower API on the lower side (Southbound) using the API correspondence table, and executes the lower API.
  • the lower API is an API published by the lower device to be operated from the viewpoint of the cooperation support device 5.
  • FIG. 3 is a diagram showing an outline of the operation of the service cooperation system.
  • the stateless upper API disclosed by the cooperation support device 5 includes an API for instructing the execution of the stateful lower API and an API for acquiring the execution result. Therefore, the illustrated adapter unit 23 transmits the execution instruction request of the stateful API and the result acquisition request for acquiring the execution result to the cooperation support device 5.
  • the cooperation support device 5 executes the stateful API of the lower device corresponding to the request triggered by the request of the upper API from the adapter unit 23, and returns the execution result to the adapter unit 23. At this time, the cooperation support device 5 determines the lower API for the request of the adapter unit 23 based on the correspondence relationship between the upper API and the lower API set in the API correspondence table.
  • the adapter unit 23 transmits a request (POST method) instructing the execution of the lower API of the application service 2C to the cooperation support device 5 via the upper API (S11).
  • the cooperation support device 5 sequentially executes the lower APIs of the application service 2C corresponding to the request according to the API correspondence table (S12-S14).
  • the cooperation support device 5 holds the execution result in the storage unit 55.
  • the cooperation support device 5 notifies the service cooperation device 1 that the execution result is held (S15). Specifically, the cooperation support device 5 transmits "201 Created" (normal response) indicating that the request is successful and the resource creation is completed to the service cooperation device 1.
  • the adapter unit 23 of the service cooperation device 1 When the adapter unit 23 of the service cooperation device 1 receives the response of S15, it sends a request (GET method) for acquiring the execution result to the cooperation support device 5 (S16).
  • the cooperation support device 5 transmits the execution result held in the storage unit 55 to the service cooperation device 1 together with 200 OK (normal response) (S17).
  • the adapter unit 23 stores the acquired execution result in the characteristic of the catalog.
  • the stateful service catalog of the service cooperation device 1 requires a characteristic (attribute) for storing the execution result of the cooperation support device 5.
  • the service cooperation device 1 defines a characteristic that stores the execution result in the product catalog of the stateful application service 2C.
  • the management unit 54 of the cooperation support device 5 to manage the execution result of the lower API in the storage unit 55 is that the "output information" included in the upper API definition information 91 is all prepared when the execution of all the corresponding lower APIs is completed. Input information required to execute the lower API when there is a dependency between the temporary storage up to and when one lower API requires the execution result of another lower API as input information (execution result of another lower API) It is a temporary storage until all the items are available.
  • the execution result of the corresponding lower API is output of the upper API. It can also be designed to be included in the information.
  • the execution result of the execution instruction of the lower API can be included in the response to the upper API (POST method).
  • FIG. 4 is an example of a data structure of the definition information of the present embodiment.
  • a configuration image of the upper API definition information 91, the lower API definition information 92, and the internal state definition information 93 input to the cooperation support device 5 will be described.
  • the upper API definition information 91 is stateless upper API definition information provided by the cooperation support device 5 to the upper device.
  • the upper API definition information 91 holds an API name, a method, input information, and output information for each combination of the public API and the method.
  • the input information and the output information of the upper API definition information 91 are set according to the naming convention of the lower API in order to specify the relationship with the lower API definition information 92.
  • the lower API definition information 92 is stateful lower API definition information provided by the lower device.
  • the lower API definition information 92 holds the API name, the method, the internal state, the input information, and the output information for each combination of the published API and the method.
  • the internal state column is blank.
  • the internal state definition information 93 is definition information of the internal state (for example, session information) of the lower device at the time of executing the stateful lower API.
  • the internal state definition information 93 is held as a set of a variable name and a data format.
  • the variable name is set according to the naming convention of the lower API in order to identify the relationship with the lower API definition information 92.
  • the cooperation support device 5 has definition information 61 (upper API definition information 91, lower API definition information 92, internal state definition information 93) input via the UI unit 52.
  • definition information 61 upper API definition information 91, lower API definition information 92, internal state definition information 93
  • the input / output correspondence image 63 is an image diagram for convenience showing the relationship between the upper API (here, “/ rest01”) and the lower API.
  • the cooperation support device 5 uses the definition information 61 to extract a lower API that outputs a part or all of the output information of the upper API 71.
  • lower APIs 72 and 75 are extracted, and confirmed FLGs are set in lower APIs 73 and 74.
  • the API correspondence table 62 of FIG. 6 is an initial state, and the upper API name of the processing target is set in the upper API, and the lower API is blank.
  • the cooperation support device 5 determines whether or not the lower API 75 that returns the most output information among the extracted sets of lower APIs 72 and 75 can be executed. Specifically, the cooperation support device 5 determines whether or not the lower API 75 can be executed only by the input information of the upper API definition information and the internal state definition information. The lower API 75 inputs the input information of the upper API 71 and "paramG" which is not the internal state, and at present, the input information for executing the lower API 75 is insufficient. Therefore, the cooperation support device 5 determines that the lower API 75 cannot be executed at this time, and sets the confirmed FLG in the lower API 75.
  • the cooperation support device 5 determines whether or not the extracted lower API 72 can be executed.
  • the input information of the lower API 72 is the input information "paramA" of the upper API 71. Therefore, the cooperation support device 5 determines that the lower API 72 can be executed only by the input information and the internal state definition information of the upper API 71, and confirms the execution of the lower API 72. Then, the cooperation support device 5 sets the API name “/ stateful01” of the lower API 72 whose execution is confirmed in the lower API of the API correspondence table 62. Since the lower API 72 is the lower API whose execution is confirmed first, the cooperation support device 5 sets the lower API 72 to the first in the lower API column.
  • the cooperation support device 5 extracts the lower API 72 that outputs the output information of the upper API 71, and when the input information of the extracted lower API 72 is only the input information of the upper API 71, the execution order of the lower API 72 is changed to another. Priority is given to lower APIs.
  • the next step is to verify the satisfaction of the requirements for cooperation between the lower APIs.
  • the cooperation support device 5 pays attention to the input information (“paramG”) of the lower API75 that outputs the output information 81 (“paramE”, “paramF”) of the upper API71, and outputs the input information.
  • the lower API 74 to be used is extracted.
  • the cooperation support device 5 acquires the input information (“paramC”, “paramH”) of the extracted lower API 74.
  • "ParamC” is included in the input information of the upper API 71, but "paramH” is not included in any of the input information of the upper API 71, the internal state definition information, and the output information of the lower API registered in the API correspondence table. .. Therefore, the cooperation support device 5 refers to the lower API definition information in the definition information 61, acquires the lower API 73 having "paramH” as the output information, and determines whether or not the lower API 73 can be executed.
  • the input information (“paramB”, “paramJ”) of the lower API 73 is the input information and the internal state definition information of the upper API 71. That is, the input information of the lower API 73 is included in any of the input information of the upper API 71, the internal state definition information, and the output information of the lower API registered in the API correspondence table. Therefore, the cooperation support device 5 determines that the lower API 73 can be executed, and confirms the execution of the lower API 73. Then, the cooperation support device 5 confirms the execution of the lower API 73 prior to the execution of the lower API 74. Then, the cooperation support device 5 sets the API name of the lower API 73 whose execution is confirmed in the lower API of the API correspondence table 62. Here, since the lower API 73 is the lower API whose execution is confirmed second, the cooperation support device 5 sets the lower API 73 to the second in the lower API column.
  • the cooperation support device 5 returns to the determination of the lower API 74 and verifies the input information (“paramC”, “paramH”) of the lower API 74 again.
  • the cooperation support device 5 can execute the lower API 74 by using the input information (“param C”) of the upper API 71 and the output information (“param H”) of the lower API 73 registered in the API correspondence table 62. Is determined to be.
  • the cooperation support device 5 confirms the execution of the lower API 74 prior to the execution of the lower API 75.
  • the cooperation support device 5 sets the API name of the lower API 74 whose execution is confirmed in the lower API of the API correspondence table 62.
  • the cooperation support device 5 sets the lower API 74 to the third lower API column.
  • the cooperation support device 5 then returns to the determination of the lower API 75 and verifies the input information (“paramG”) of the lower API 75 again. Specifically, the cooperation support device 5 determines that the input information (“paramG”) is executable because it is the execution result of the lower API 74 registered in the API correspondence table 62, and confirms the execution of the lower API 75. .. Then, the cooperation support device 5 sets the API name of the lower API 75 whose execution is confirmed in the lower API column of the API correspondence table 62. Here, since the lower API 75 is the fourth lower API whose execution is confirmed, the cooperation support device 5 sets the lower API 75 to the fourth lower API information column. Since the cooperation support device 5 can refer to the output information of the upper API 71 and output all the output information, the generation (mapping process) of the API correspondence table of the upper API 71 (“/ rest01”) to be processed is completed. ..
  • FIG. 12 is a sequence diagram showing an API correspondence table generation process performed by the cooperation support device 5.
  • the API correspondence table generation process is performed with the input of definition information by the user as a trigger.
  • the UI unit 52 receives the definition information input by the user (S21), and sends the received definition information to the API analysis unit 53 (S22).
  • the definition information is upper API definition information, lower API definition information, and internal state definition information.
  • the API analysis unit 53 selects any one of the upper APIs from the upper API definition information (S23).
  • the API analysis unit 53 analyzes the upper API definition information, the lower API definition information, and the internal state definition information corresponding to the selected upper API, and generates an API correspondence table of the upper API (S24).
  • the API correspondence table generation process will be described later.
  • the API analysis unit 53 sends a registration request for the API correspondence table of the higher-level API selected in S23 to the management unit 54 (S25).
  • the management unit 54 registers the API correspondence table in the DB 56 by using, for example, a query (S26).
  • the DB 56 sends a registration completion response to the management unit 54 (S27).
  • the management unit 54 sends a registration completion response to the API analysis unit 53 (S28).
  • the API analysis unit 53 When the upper API that does not generate the API correspondence table is in the upper API definition information, the API analysis unit 53 returns to S23, selects the next upper API, and performs the subsequent processing (S29). When the API correspondence table of all the upper APIs of the upper API definition information is generated, the API analysis unit 53 sends a registration completion notification to the UI unit 52 (S30). The UI unit 52 displays a registration completion notification on the display and notifies the user that the registration of the API correspondence table is completed.
  • the display displayed by the UI unit 52 may be graphical (GUI: Graphical User Interface) or text-based (CLI: Command Line Interface), and the display method does not depend on the display device.
  • GUI Graphical User Interface
  • CLI Command Line Interface
  • FIG. 13 is a flowchart showing the detailed processing of S24 of FIG.
  • the API analysis unit 53 performs the following processing with reference to the upper API definition information, the lower API definition information, and the internal state definition information input from the UI unit 52 in S22.
  • the API analysis unit 53 extracts the lower API that outputs the output information (part or all) of the selected upper API (S31).
  • the API analysis unit 53 extracts a lower API that can be executed only by the input information of the upper API and the internal state definition information from the extracted lower APIs, and registers the extracted lower APIs in the API correspondence table (S32).
  • the API analysis unit 53 outputs all the output information of the upper API by executing all the lower APIs registered in the API correspondence table (that is, whether all the output information of the upper API is satisfied). ) Whether or not (S33).
  • the API analysis unit 53 ends the generation of the API correspondence table of the selected upper API.
  • the API analysis unit 53 proceeds to S34 and verifies the dependency between the lower APIs.
  • the API analysis unit 53 extracts the lower API that outputs at least one output information of the upper API from the lower APIs that are not registered in the API correspondence table in S32, and acquires the input information of the extracted lower API (S34). ..
  • the API analysis unit 53 extracts the lower API that includes the input information of the lower API extracted in S34 in the output information (S35).
  • the API analysis unit 53 converts all the input information of the lower API into the input information of the upper API, the internal state definition information, and the output information of the lower API registered in the API correspondence table for each lower API extracted in S35. Determine if it is included.
  • the API analysis unit 53 determines that the lower API is feasible. If not, the lower API is determined to be infeasible (S36).
  • the API analysis unit 53 uses the input information of the upper API, the internal state definition information, and the input information not included in the output information of the lower API registered in the API correspondence table as the output information. If the lower API to be included is extracted and all the input information of the extracted lower API is included in the input information of the upper API, the internal state definition information, and the output information of the lower API registered in the API correspondence table, the lower API is concerned. The API determines that it is feasible.
  • the API analysis unit 53 registers the lower APIs determined to be executable based on the execution dependency of the lower APIs confirmed in S34 to S36 in the API correspondence table in the order determined to be executable (S37). .. Every time the lower API is registered in the API correspondence table, the API analysis unit 53 determines whether or not all the output information of the upper API is output by the output information of the lower API registered in the API correspondence table. The API analysis unit 53 repeats the processes of S34 to S36 until all the output information of the upper API is output, and ends the process when all the output information of the upper API is output.
  • FIG. 14 is a sequence diagram showing the operation of the service cooperation system of the present embodiment when the service is executed.
  • the service cooperation device (upper device) 1 requests the cooperation catalog specified in the order (Product Order) for the cooperation service from the client from the catalog management unit, and acquires the cooperation catalog. Then, the service cooperation device 1 instructs each adapter unit of the plurality of services included in the cooperation catalog to execute the lower API published by each service.
  • the adapter unit of the application service 2C executes a stateless lower API that the cooperation support device 5 publishes for the application service (lower device) 2C. That is, the adapter unit transmits a request (for example, the POST method) instructing the execution of the stateful API of the application service 2C to the cooperation support device 5 via the stateless upper API (S51).
  • the execution instruction request of this lower API is a request for operating the application service 2C.
  • the execution unit 51 of the cooperation support device 5 receives a request from the service cooperation device 1, and requests the management unit 54 for the upper API name and the lower API list corresponding to the method included in the request (S52).
  • the management unit 54 acquires the corresponding lower API list of the API correspondence table stored in the DB 56 by using the upper API name and the method as a search key (S53, S54).
  • the management unit 54 sends the acquired lower-level API list to the execution unit 51 (S55).
  • the lower API list is a list in which lower APIs in the lower API column of the API correspondence table 62 of FIG. 5 are set in the order of execution.
  • the execution unit 51 executes a stateful lower API published by the application service 2C using the acquired lower API list. That is, the execution unit 51 sequentially executes the lower APIs in the order described in the lower API list (S56). Specifically, when the execution unit 51 transmits the execution instruction request of the lower API, the execution unit 51 transmits the request with the internal state stored in the storage unit 55 to the application service 2C, and executes the lower API. (S561).
  • the application service 2C executes the lower API instructed by the request (S562), and transmits the execution result (response) to the execution unit 51 (S563).
  • the execution unit 51 stores the execution result received from the lower API in the storage unit 55.
  • the application service 2C adds an internal state such as session information to the execution result and transmits it to the execution unit 51 at the time of the first communication with the cooperation support device 5.
  • an internal state such as session information
  • the execution unit 51 registers the internal state in the storage unit 55.
  • the execution unit 51 may send a request without adding the internal state to the application service 2C and execute the lower API.
  • the execution unit 51 After completing the execution of all the lower APIs in the lower API list, the execution unit 51 transmits the execution result temporarily stored in the storage unit 55 to the service cooperation device 1 according to the specifications of the upper API. In the illustrated example, the execution unit 51 notifies the service cooperation device 1 that the execution result of the lower API is held (S57). Specifically, the execution unit 51 transmits "201 Created" (normal response) indicating that the request is successful and the resource creation is completed to the service cooperation device 1.
  • the adapter unit 23 of the service cooperation device 1 Upon receiving the response of S57, the adapter unit 23 of the service cooperation device 1 transmits a request (GET method) for acquiring the execution result to the cooperation support device 5 (S58).
  • the execution unit 51 of the cooperation support device 5 transmits the execution result held in the storage unit 55 to the service cooperation device 1 together with 200 OK (normal response) (S59).
  • the service cooperation device 1 stores the execution result in the characteristic of the application catalog, and executes the complementary process of reflecting the acquired execution result in each service constituting the cooperation service according to the rules of the cooperation catalog.
  • the transmission of the execution result to the service cooperation device 1 is not limited to the processes of S57 to S59.
  • the service cooperation support device of the present embodiment described above includes definition information of a stateless upper API published to a service cooperation device (upper device) that links a plurality of services, and stateful lower APIs published by a lower device.
  • the UI unit 52 that accepts the upper API, the definition information of the upper API, and the definition information of the lower API, at least one lower API corresponding to the upper API is extracted, and the execution order of the extracted lower API is set. It has an interpretation unit 53 that generates an API correspondence table.
  • the API correspondence table in which the stateless upper API and the stateful lower API are associated with each other is generated by using the input definition information.
  • the mapping between the stateless upper API and the stateful lower API can be easily performed. That is, in the present embodiment, the service that exposes the stateful API can be easily linked with other services. Therefore, in the present embodiment, a plurality of services including a stateful lower API service can be linked at low cost in a short period of time.
  • the illustrated computer system includes a CPU (Central Processing Unit, processor) 901, a memory 902, a storage 903 (HDD: Hard Disk Drive, SSD: Solid State Drive), a communication device 904, an input device 905, and an output device. 906 and.
  • the memory 902 and the storage 903 are storage devices.
  • each function of each device is realized by executing a predetermined program loaded on the memory 902 by the CPU 901.
  • each function of the cooperation support device 5 and the service cooperation device 1 has the CPU of the cooperation support device 5 in the case of the program for the cooperation support device 5 and the CPU of the service cooperation device 1 in the case of the program for the service cooperation device 1. However, it is realized by executing each.
  • cooperation support device 5 and the service cooperation device 1 may be implemented on one computer, or may be implemented on a plurality of computers. Further, the cooperation support device 5 and the service cooperation device 1 may be virtual machines mounted on a computer.
  • the program for the cooperation support device 5 and the program for the service cooperation device 1 can be stored on a computer-readable recording medium such as an HDD, SSD, USB (Universal Serial Bus) memory, CD (Compact Disc), or DVD (Digital Versatile Disc). It can be stored or delivered over a network.
  • a computer-readable recording medium such as an HDD, SSD, USB (Universal Serial Bus) memory, CD (Compact Disc), or DVD (Digital Versatile Disc). It can be stored or delivered over a network.
  • Service cooperation device (upper device) 10: Catalog interpretation execution unit 21, 22, 23: Adapter unit 30: Catalog management unit 2A, 2B, 2C: Service 5: Cooperation support device (service cooperation support device) 51: Execution department 52: UI department (reception department) 53: API analysis unit (interpretation unit) 54: Management unit 55: Storage unit 56: DB

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

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

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 (8)

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

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2021575172A JP7332950B2 (ja) 2020-02-06 2020-02-06 サービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラム
US17/797,535 US12067431B2 (en) 2020-02-06 2020-02-06 Service cooperation support apparatus, service cooperation support method and service cooperation support program
PCT/JP2020/004477 WO2021156992A1 (ja) 2020-02-06 2020-02-06 サービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/004477 WO2021156992A1 (ja) 2020-02-06 2020-02-06 サービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラム

Publications (1)

Publication Number Publication Date
WO2021156992A1 true WO2021156992A1 (ja) 2021-08-12

Family

ID=77200818

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/004477 WO2021156992A1 (ja) 2020-02-06 2020-02-06 サービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラム

Country Status (3)

Country Link
US (1) US12067431B2 (ja)
JP (1) JP7332950B2 (ja)
WO (1) WO2021156992A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001265747A (ja) * 2000-03-16 2001-09-28 Hitachi Ltd 分散オブジェクト連携装置
US20020174194A1 (en) * 2001-05-18 2002-11-21 Eoin Mooney Providing access to a plurality of message accounts from a single web-based interface
JP2004348435A (ja) * 2003-05-22 2004-12-09 Nippon Telegr & Teleph Corp <Ntt> 統合Ｗｅｂサービス方法、装置、プログラムおよび記録媒体

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060245358A1 (en) * 2005-04-29 2006-11-02 Beverly Harlan T Acceleration of data packet transmission
JP5199719B2 (ja) * 2008-04-07 2013-05-15 キヤノン株式会社 ネットワークシステム
JP2012213144A (ja) * 2011-03-18 2012-11-01 Ricoh Co Ltd 情報処理装置、情報処理システム、機器連携方法およびプログラム
JP6590861B2 (ja) 2017-06-05 2019-10-16 日本電信電話株式会社 サービス連携装置およびサービス連携方法
JP6995723B2 (ja) * 2018-09-19 2022-01-17 キオクシア株式会社 メモリシステム、ストレージシステム、および制御方法
US11922229B2 (en) * 2022-01-10 2024-03-05 Dell Products L.P. System for determining data center application program interface readiness

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001265747A (ja) * 2000-03-16 2001-09-28 Hitachi Ltd 分散オブジェクト連携装置
US20020174194A1 (en) * 2001-05-18 2002-11-21 Eoin Mooney Providing access to a plurality of message accounts from a single web-based interface
JP2004348435A (ja) * 2003-05-22 2004-12-09 Nippon Telegr & Teleph Corp <Ntt> 統合Ｗｅｂサービス方法、装置、プログラムおよび記録媒体

Also Published As

Publication number Publication date
JP7332950B2 (ja) 2023-08-24
US12067431B2 (en) 2024-08-20
JPWO2021156992A1 (ja) 2021-08-12
US20230068545A1 (en) 2023-03-02

Similar Documents

Publication Publication Date Title
US20140096014A1 (en) Method for enabling dynamic client user interfaces on multiple platforms from a common server application via metadata
US20040015564A1 (en) Method of developing a web service and marketing products or services used in developing a web service
US8949378B2 (en) Method and system for providing a state model of an application program
US20160275577A1 (en) Dynamic cloud solution catalog
US8504981B2 (en) Application development support device, program, and recording medium
US11086763B2 (en) Asynchronous consumer-driven contract testing in micro service architecture
JP2011204228A (ja) 学習メカニズムを用いたマッシュアップインフラストラクチャ
JP7097958B2 (ja) 自動ユニバーサルコネクタパッケージを使用してクラウドアプリケーションをクラウドサービスブローカプラットフォームに統合するためのシステムおよび方法
US20160092208A1 (en) Managing access to resource versions in shared computing environments
US20120137309A1 (en) Workflow integration and portal systems and methods
US10635512B2 (en) In-product notifications targeting specific users selected via data analysis
US11843674B2 (en) Virtual workspace experience visualization and optimization
RU2580079C2 (ru) Инфраструктура активации приложений
JP5936103B2 (ja) クライアントでＪａｖａメソッドを呼び出すシステム、コンピュータ、方法及びプログラム
US9087353B2 (en) Personalized demo environment based on software configuration information
US20230362282A1 (en) System, method, and computer program product for improved embedded application data management
CN113014616B (zh) 用于内容交付嵌入的分析内容网络
WO2021156992A1 (ja) サービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラム
US9612805B2 (en) Rapid mobile app generator
JP7025298B2 (ja) 環境構築支援システムおよび環境構築支援方法
US11243961B2 (en) Complex query optimization
WO2022244368A1 (ja) 情報処理装置、情報処理システム、情報処理方法及びプログラム
WO2021070364A1 (ja) サービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラム
US20240211550A1 (en) System, method, and computer program product for workspace creation in embedded applications
Preibisch et al. API Design

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20917946

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021575172

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20917946

Country of ref document: EP

Kind code of ref document: A1