JP2008186105A - Service function providing device, service function providing method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To solve the problem of an enterprise service bus (ESB) execution computer in which a service function cannot be dynamically provided to a requester execution computer differed in communication protocol from a service execution computer since the ESB execution computer must preliminarily acquire information to be transmitted and received between the service execution computer and the requester execution computer to generate a request receptor corresponding to the requester execution computer or an adaptor corresponding to the service execution computer in advance. <P>SOLUTION: Disclosure information from the requester execution computer 160 and the service execution computer 100 is registered in a memory 170 of the ESB execution computer 110, and a CPU 180 of the ESB execution computer 110 creates the request receptor 150 and adaptor 140 corresponding respectively to a requester 160A and a service 100A from the disclosure information in the memory 170. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a technique for providing a service function from a service execution computer to a requester execution computer.

  In recent years, a system architecture called SOA (Service Oriented Architecture) has been attracting attention, in which software components called services are constructed for the purpose of efficient system reuse, and these services are used in combination. The SOA system includes a requester execution computer that includes a requester that is a program that requests a service execution computer to execute a service, and a service execution computer that executes a service according to the request. The requester execution computer requests a service and the service execution computer accepts the request, but the communication protocol used between the service execution computer and the requester execution computer may be different.

  As a technique corresponding to the case where different communication protocols are used between the service execution computer and the requester execution computer, a technique using ESB (Enterprise Service Bus) can be cited (Non-patent Document 1, etc.). According to the ESB execution computer that executes ESB, it is possible to provide a service function to the requester execution computer even between a service execution computer and a requester execution computer that use different communication protocols.

In addition, the system using the ESB execution computer has a technology that includes an adapter corresponding to the communication protocol of the service execution computer and receives a request corresponding to the communication protocol of the requester execution computer (Non-patent Document 2). .
Japan BEA Systems Co., Ltd. “SOA Service Oriented Architecture” published by Shosuisha May 15, 2005 P17-39 http: // www-06. ibm. com / jp / developerworks / webservices / 060120 / j_ws-soa-programmodel4. shml

  However, in the case of using the conventional technology, it is necessary to prepare in advance an adapter for receiving a request for receiving a request from the requester execution computer and for calling the service execution computer. For this purpose, the ESB execution computer grasps in advance the information transmitted and received between the service execution computer and the requester execution computer, and the request reception corresponding to the requester execution computer and the adapter corresponding to the service execution computer are prepared in advance. There is a problem that it is impossible to dynamically provide a service function to a requester execution computer having a communication protocol different from that of the service execution computer.

  Therefore, an object of the present invention is to make it possible to dynamically provide a service function to a requester execution computer having a communication protocol different from that of the service execution computer.

  In order to solve the above problems, the present invention registers a requester execution computer and public information from a service execution computer in a storage unit of a service function providing device, and a processing unit of the service function providing device uses a requester from the public information in the storage unit. And request reception and adapter corresponding to each of the service.

  According to the present invention, it is possible to dynamically provide a service function to a requester execution computer having a communication protocol different from that of the service execution computer.

Next, the best mode for carrying out the present invention (hereinafter referred to as “embodiment”) will be described in detail with reference to the drawings as appropriate.
FIG. 1 is a diagram showing a configuration of a service function providing system in the present embodiment. As shown in FIG. 1, in the service function providing system 10, a service execution computer 100, a requester execution computer 160, and an ESB execution computer (service function providing device) 110 can communicate with each other via a network 1200. Configured.

  The requester execution computer 160 includes a memory 1105 as a storage unit and a CPU (Central Processing Unit) 1104 as a processing unit. The memory 1105 stores a stub 1106 and a requester 160A that is a program for requesting the service execution computer 100 to execute the service 100A. The CPU 1104 executes the requester 160A, thereby causing the request to execute via the ESB execution computer 110. The service execution computer 100 is requested to execute the service 100A. Although three requester execution computers 160 are shown in FIG. 1, the number of requester execution computers 160 is not particularly limited. The stub 1106 may be generated by inputting a command provided by an execution environment such as a J2EE (Java (registered trademark) 2 Enterprise Edition) server when the user creates the requester 160A, or a J2EE server or the like. It is good also as producing | generating by taking in what the product of no. The stub 1106 is used in the process of step S701 in FIG.

  The service execution computer 100 includes a memory 1102 and a CPU 1101. The memory 1102 stores a service 100A, which is a program for providing a function to the requester execution computer 160, and the CPU 1101 executes the service 100A according to a request from the requester execution computer 160, thereby performing the function of the service 100A. This is provided to the requester execution computer 160. In the service 100A, for example, codes for executing deposit processing and withdrawal processing are described. Although three service execution computers 100 are shown in FIG. 1, the number of service execution computers 100 is not particularly limited.

  The ESB execution computer 110 includes a memory 170 and a CPU 180. The memory 170 stores an ESB program (service function providing program) 130, a service registry 190, and a message format 1300. The ESB program 130 includes an adapter generation processing unit 120, a request reception generation processing unit 121, an operation control unit 122, an adapter selection control unit 123, a matching control unit 124, an adapter 140, and a request reception 150. Composed. The service registry 190 includes a requester public information table 191 and a service public information table 192.

  The request reception 150 is a program in which processing for receiving a service request from the requester 160A, transferring it to the adapter 140, receiving a processing result from the adapter 140, and returning it to the requester 160A is described. This program is executed by the CPU 180. In FIG. 1, three request receptions 150 are shown, and the number of request receptions 150 is not particularly limited, but the request receptions 150 correspond one-to-one with the requester 160A.

  The adapter 140 is a program in which processing for receiving a service request from the request reception 150, transferring it to the service 100A, receiving a processing result from the service 100A, and returning it to the request reception 150 is described. This program is executed by the CPU 180. In FIG. 1, three adapters 140 are shown, and the number of adapters 140 is not particularly limited, but the adapters 140 correspond one-to-one with the service 100A.

  The adapter generation processing unit 120 is a program in which processing for generating the adapter 140 is described. This program is executed by the CPU 180. Details of the adapter generation processing unit 120 will be described later (see FIG. 18).

  The request reception generation processing unit 121 is a program in which processing for generating the request reception 150 is described. This program is executed by the CPU 180. Details of the request reception generation processing unit 121 will be described later (see FIG. 8).

  The operation control unit 122 is a program in which processing for controlling the activation of the service 100A is described. This program is executed by the CPU 180. Details of the operation control unit 122 will be described later (see FIG. 24).

  The adapter selection control unit 123 is a program in which processing for selecting the adapter 140 is described. This program is executed by the CPU 180. Details of the adapter selection control unit 123 will be described later (see FIG. 16).

  The matching control unit 124 is a program in which processing for selecting an optimum service 100A from among a plurality of services 100A is described. This program is executed by the CPU 180. Details of the matching control unit 124 will be described later (see FIG. 17).

  FIG. 2 is a diagram showing a data structure of the requester public information table in the present embodiment. As shown in FIG. 2, the requester public information table 191 includes a public information entry 201. The number of public information entries 201 is not particularly limited. The public information entry 201 indicates public information of the requester 160A, and includes a requester name 202, I / F (interface) information 203, and an operation policy 204.

  The requester name 202 is information for uniquely identifying the requester 160A (see FIG. 1).

  The I / F information 203 includes protocol information 205, message information 206, and destination information 207. The protocol information 205 indicates a communication protocol such as HTTP (HyperText Transfer Protocol), SOAP (Simple Object Access Protocol), and JMS (Java (registered trademark) Message Service). The message information 206 indicates the format type of the message transmitted from the requester execution computer 160 (see FIG. 1) to the ESB execution computer 110 (see FIG. 1). The destination information 207 includes an IP (Internet Protocol) address, a URL (Uniform Resource Locator), a queue name, and the like of a request reception 150 (see FIG. 1) that is a destination of a message transmitted by the requester execution computer 160 (see FIG. 1). Is shown.

  The operation policy 204 includes a priority 208 and an operation 209 at the time of failure. The priority 208 indicates the priority when the ESB execution computer 110 (see FIG. 1) transmits a message to the service execution computer 100 (see FIG. 1). The operation 209 at the time of failure indicates an operation when a failure occurs when the ESB execution computer 110 (see FIG. 1) transmits a message to the service execution computer 100 (see FIG. 1).

  FIG. 3 is a diagram showing an example of data and a message format registered in the requester public information table in the present embodiment, and FIG. 3A is an example of data registered in the requester public information table. 3 (b) is a diagram illustrating an example of a message format described in the XSD format, and FIG. 3 (c) is a diagram illustrating an example of a message format described in a WSDL (Web Services Description Language) format. .

  As shown in FIG. 3A, two pieces of data are registered in the requester public information table 191, but the number of pieces of information to be registered is not limited to this. FIG. 3B shows an example in which the electronic message format 1300 (see FIG. 1) is defined by XML Schema (Extensible Markup Language Schema). This is a format corresponding to the message information of the first data (# 1) in FIG. FIG. 3C shows an example in which the message format 1300 (see FIG. 1) is defined in WSDL (Web Services Description Language). This is a format corresponding to the message information of the second data (# 2) in FIG.

  FIG. 4 is a diagram showing a data structure of the service disclosure information table in the present embodiment. As shown in FIG. 4, the service public information table 192 includes a public information entry 301. The number of public information entries 301 is not particularly limited. The public information entry 301 indicates public information of the service 100A, and includes a service name 302, I / F information 303, an operation policy 304, and adapter information 305.

  The service name 302 is information for uniquely identifying the service 100A (see FIG. 1).

  The I / F information 303 includes protocol information 306, message information 307, and destination information 308. The protocol information 306 indicates a communication protocol such as HTTP, SOAP, and JMS. The message information 307 indicates the format type of the message transmitted from the ESB execution computer 110 (see FIG. 1) to the service execution computer 100 (see FIG. 1). The destination information 308 indicates the IP address, URL, queue name, and the like of the service 100A (see FIG. 1) that is the destination of the message transmitted by the ESB execution computer 110 (see FIG. 1).

  The operation policy 304 includes an operation time 309 and a load capacity 310. The operating time 309 indicates the time during which the service 100A (see FIG. 1) is operating. The load capacity 310 indicates an amount that can be transmitted to the service execution computer 100 (see FIG. 1) by processing the message received from the request reception 150 (see FIG. 1) by the adapter 140 (see FIG. 1). is there.

  The adapter information 305 includes generation information 311 and address information 312. The generation information 311 indicates whether or not the adapter 140 (see FIG. 1) has been generated. The address information 312 indicates an address of the service 100A that is a transfer destination of the generated adapter 140 (see FIG. 1) by an IP address, a URL, or the like.

  FIG. 5 is a diagram illustrating an example of data registered in the service disclosure information table in the present embodiment. As shown in FIG. 5, although two pieces of data are registered in the service disclosure information table 192, the number of pieces of data to be registered is not limited to this.

  FIG. 6 is a diagram showing a request request transmitted from the requester to the ESB execution computer in this embodiment. As shown in FIG. 6, the request request 400 includes a control unit 401 and a data unit 402. In addition, the control unit 401 includes a requester name 403 and a destination service name 404.

  The requester name 403 is information for uniquely identifying the requester execution computer 160 (see FIG. 1) that is the transmission source of the request request 400. The destination service name 404 is information for uniquely identifying the destination service 100A of the request request 400 (see FIG. 1). The data part 402 is a message indicating the contents of the service function requested by the requester execution computer 160 (see FIG. 1).

  FIG. 7 is a diagram illustrating an example of the request request in FIG. As an example, data described in XML is set in the data portion 402.

  FIG. 8 is a flowchart showing the requester public information registration process in this embodiment. This requester public information registration process is performed by the CPU 180 executing the request reception generation processing unit 121. Hereinafter, the flow of the requester public information registration process S500 will be described with reference to FIG. 8 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 receives the requester public information from the requester execution computer 160 by executing the request reception generation processing unit 121 (step S501). As a method of receiving the requester public information, there is a method of receiving the requester execution computer 160 by executing a command or the like provided by the request reception generation processing unit 121. Next, the CPU 180 registers the received requester public information as a public information entry 201 in the requester public information table 191 (step S502), and generates a request reception from the I / F information 203 of the received requester public information (step S503). ). The CPU 180 starts accepting the generated request (step S504), notifies the requester execution computer 160 of registration completion (step S505), and ends the process (step S506).

  FIG. 9 is a flowchart showing details of the request reception generation process of FIG. This request reception generation process is performed by the request reception generation processing unit 121 being executed by the CPU 180. Hereinafter, the flow of processing S503 for generating the request reception 150 from the I / F information 203 of the requester public information will be described with reference to FIG. 9 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 determines the protocol information 205 of the requester public information (step S1500). When the protocol information 205 is “SOAP” or “EJB (registered trademark) (Enterprise JavaBeans (registered trademark))” (“SOAP” or “EJB (registered trademark)” in step S1500), the synchronous request reception generation process (Step S1501), and the process ends (step S1503). If the protocol information 205 is “JMS”, an asynchronous request reception generation process is performed (step S1502), and the process ends (step S1503). Here, the case where the protocol information 205 is “SOAP”, “EJB (registered trademark)” or “JMS” has been described, but even in other cases, if the protocol information 205 is a synchronous communication protocol, step S1501 is performed. If the protocol information 205 is an asynchronous communication protocol, step S1502 is executed.

  FIG. 10 is a diagram showing a structure of a request reception generated by the request reception generation process in the present embodiment.

  The EJB (registered trademark) request reception 2200 includes a request reception definition file 2202 and an EJB (registered trademark) application 2203. The request reception definition file 2202 is a file in which information necessary for the request reception 150 is defined, and detailed description thereof will be described later (see FIG. 11). The EJB (registered trademark) application 2203 is an application used when receiving and processing a service request (a data part 402 (see FIG. 6) of the request request 400 (see FIG. 6)).

  The SOAP request reception 2205 includes a request reception definition file 2206 and a SOAP application 2207. The request reception definition file 2206 is a file that defines information necessary for the request reception 150, and a detailed description thereof will be described later (see FIG. 11). The SOAP application 2207 is an application used when receiving and processing a service request (the data part 402 (see FIG. 6) of the request request 400 (see FIG. 6)).

  The JMS request reception 2208 includes a queue 2210, a request reception definition file 2209, and a JMS application 2211. The request reception definition file 2209 is a file that defines information necessary for the request reception 150, and a detailed description thereof will be given later (see FIG. 12). The queue 2210 stores the data part 402 (see FIG. 6) of the request request (see FIG. 6). When the JMS application 2211 receives the service request (the data part 402 (see FIG. 6) of the request request 400 (see FIG. 6)), the JMS application 2211 stores the service request in the queue 2210, and the service request (request request 400 (see FIG. 6 in FIG. 6) in order The data portion 402 (see FIG. 6)) is retrieved and processed.

  FIG. 11 is a flowchart showing details of processing for generating the synchronous request reception of FIG. Hereinafter, with reference to FIG. 11 (refer to FIGS. 1 to 7 as appropriate), the flow of processing S1501 for generating a synchronization request reception will be described.

  First, the CPU 180 defines the requester name 202 and the protocol information 205 of the requester public information in the request reception definition file 1700 (step S1701). The request reception definition file 1700 shows an example in which the data (requester name and protocol information) of # 2 public information entry in FIG. 3 is set in the requester name 1710 and the protocol information 1711, respectively. The contents of the first two lines of the request reception definition file 1700 are determined in advance. Next, the CPU 180 acquires the destination information from the WSDL file indicated by the message information 206 of the requester public information, and defines it in the request reception definition file 1700 (step S1702). In the example of the request reception definition file 1700, since the message information of the public information entry # 2 in FIG. 3 is “service1.wsdl”, the destination information is acquired from “service1.wsdl” shown in FIG. . An example in which “http: // aaa” is set in the destination information 1712 of the request reception definition file 1700 is shown.

  The CPU 180 acquires all operations from the WSDL file indicated by the message information 206 (step S1703), and performs processing (steps S1704 to S1706) for all operations (step S1709). That is, an operation name is defined in the <name> tag of the message information 1713 (step S1704), request information is defined in the <input> tag of the message information 1713 (step S1705), and a response is made to the <output> tag of the message information 1713. Information is defined (step S1706). In the example of the request reception definition file 1700, since the message information of the public information entry # 2 in FIG. 3 is “service1.wsdl”, the operation is acquired from “service1.wsdl” shown in FIG. The operation name, request information, and response information are described in the acquired operation. In the request reception definition file 1700, the message format of the request information generated by the WSDL file is defined in <format-file> of the <input> tag, and the format type is defined in <message-type> of the <input> tag. ing. Also, the message format of response information generated from WSDL is defined in <format-file> of the <output> tag, and the format type is defined in <message-type> of the <output> tag. When <format-file> is in the xsd format, XML is set in <message-type>, but the format type is not limited to the xsd format, and a unique format type is set in formats other than the xsd format.

  The generated request reception definition file 1700 (request reception definition file 2202 (see FIG. 10) or 2206 (see FIG. 10)) and protocol-specific application (EJB (registered trademark) application 2203 (see FIG. 10)) or SOAP application 2207 (see FIG. 10)) is packaged (step S1707), and the process is terminated (step S1708). By this packaging, a request reception 150 (EJB (registered trademark) request reception 2200 (see FIG. 10) or SOAP request reception 2205 (see FIG. 10)) is generated. Here, the protocol-specific application (EJB (registered trademark) application 2203 (see FIG. 10) or SOAP application 2207 (see FIG. 10)) is, for example, an application (not shown) provided by a product such as a J2EE server. If stored in the memory 170, it is obtained by copying the application. The message information 1713 is used when a protocol-specific application (EJB (registered trademark) application 2203 (see FIG. 10) or SOAP application 2207 (see FIG. 10)) is executed.

  FIG. 12 is a flowchart showing details of processing for generating the asynchronous request reception of FIG. Hereinafter, the flow of the processing S1502 for generating the asynchronous request reception will be described with reference to FIG. 12 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 defines the requester name 202 and the I / F information 203 of the requester public information in the request reception definition file 1800 (step S1801). In the request reception definition file 1800, the public information entry data (requester name, protocol information, message information, and destination information) of # 1 in FIG. 3 includes <input> of the requester name 1810, the protocol information 1811, and the message information 1813, respectively. An example set in the tag and destination information 1812 is shown. Send is defined as fixed in the <name> tag of the operation of the message information 1813. The contents of the first two lines of the request reception definition file 1800 are determined in advance. Here, when no destination is set in the destination information 207 of the I / F information 203, a method of omitting the <url> line, a method of setting nothing between <url> and </ url>, etc. There is. In the <input> tag as request information, the message format and format type of the request defined by the message information are defined. Next, the CPU 180 determines the presence / absence of the URL of the destination information (step S1802). If the URL exists (“Yes” in step S1803), the CPU 180 creates a transfer queue 2210 (see FIG. 10) with the URL as the transfer destination (step S1804), and proceeds to step S1806. If the URL does not exist (“none” in step S1803), the CPU 180 creates a local queue 2210 (see FIG. 10) (step S1805), and proceeds to step S1806.

  In step S1806, the CPU 180 generates the request reception definition file 1800 (request reception definition file 2209 (see FIG. 10), the created queue 2210 (see FIG. 10), and the application (JMS application 2211 (see FIG. 10)). Is packaged (step S1806), and the process is terminated (step S1807), and a request reception 150 (JMS request reception 2208 (see FIG. 10)) is generated by this packaging. 2211 (see FIG. 10)), for example, when an application (not shown) provided by a product such as a J2EE server is stored in the memory 170, the application is acquired by copying the application. That. Message information 1813 is used when the application (JMS applications 2211 (see FIG. 10)) is performed.

  FIG. 13 is a flowchart showing service public information registration processing in the present embodiment. This service public information registration process is performed by the adapter generation processing unit 120 being executed by the CPU 180. Hereinafter, the flow of the service public information registration process S600 will be described with reference to FIG. 13 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 receives service disclosure information from the service execution computer 100 by the execution of the adapter generation processing unit 120 (step S601). As a method for receiving service public information, there is a method in which the service execution computer 100 receives the service public information by executing a command provided by the adapter generation processing unit 120 or the like. Next, the CPU 180 registers the received service public information in the service public information table 192 as a public information entry 301 (step S602). At this time, the generation information 311 is set to “undeployed”. When the registration is completed, the CPU 180 notifies the service execution computer 100 of the completion of registration (step S603) and ends the process (step S604).

  FIG. 14 is a flowchart showing service call processing in the present embodiment. This service call processing is performed by the ESB program 130 being executed by the CPU 180. Hereinafter, the flow of the service call processing S700 will be described with reference to FIG. 14 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 receives the request request 400 from the requester execution computer 160, and the request reception 150 receives a service request (the data part 402 of the request request 400) (step S701). Here, for example, when using EJB (registered trademark) as a communication protocol, the requester execution computer 160 transmits the request request 400 by calling the stub 1106. The CPU 180 extracts the public information entry 201 corresponding to the requester name 403 of the request request 400 from the requester public information table 191 of the service registry 190 (step S702). Next, the CPU 180 extracts the destination service name 404 from the request request 400 (step S703), and executes adapter selection control processing (step S704). The CPU 180 determines the generation information 311 of the adapter information 305 in the public information entry 301 selected by the adapter selection control process (step S705). When the generation information 311 is “started” (“started” in step S706), the process proceeds to step S708. When the generation information 311 is “undeployed” (“undeployed” in step S706), adapter generation processing is executed (step S707), and the process proceeds to step S708.

  The request reception 150 issues a service request (data part 402 of the request request 400) to the adapter 140 specified by the address information 312 of the adapter information 305 in the public information entry 301 selected by the adapter selection control process (step S708). . The adapter 140 receives the service request (the data part 402 of the request request 400) (step S709). Thereafter, a service request (data portion 402 of the request request 400) is transmitted to the service 100A by the adapter 140, and the service 100A is executed by the service execution computer 100. For example, when the service 100A receives the data part 402 of FIG. 7, the service 100A returns “Hello!”, Which is a character string enclosed in <in0> tags, to the requester 160A, and a browser window (not shown) of the requester execution computer 160 To display. The request reception 150 determines a response from the service execution computer 100 (step S710), and when there is no response (“None” in step S710), the process ends (step S713). For example, there may be no response data when requested asynchronously. If the response is normal (“normal” in step S710), the response data is returned to the requester 160A, and the process ends (step S713). If the response is an error (“error” in step S710), the operation control unit 122 executes the operation control process (step S711) and ends the process (step S713).

  FIG. 15 is a flowchart showing details of processing in which the request reception in FIG. 14 receives a service request. This process is performed by the ESB program 130 being executed by the CPU 180. Further, through this process, the request reception 150 can receive a service request. Hereinafter, the flow of processing S701 in which the request reception 150 receives a service request will be described with reference to FIG.

  First, the CPU 180 retrieves the requester name 403 of the request request 400 (step S2301), and the request reception definition file 1700 (see FIG. 11) or 1800 (see FIG. 12) of the corresponding request reception 150 (request reception definition files 2202, 2206). Alternatively, protocol information 1711 (see FIG. 11) or 1811 (see FIG. 12) is taken out from 2209 (see FIG. 10)) (step S2302). Here, the corresponding request reception 150 is a request reception definition file 2202, 2206, or 2209 (see FIG. 10) in which a requester name 1710 (see FIG. 11) or 1810 (see FIG. 12) that matches the requester name 403 is defined. ) Is obtained by searching.

  When the protocol information 1811 (see FIG. 12) is “JMS” (“JMS” in step S2303), a request request is made to the queue 2210 (see FIG. 10) of the corresponding request reception 150 (JMS request reception 2208 (see FIG. 10)). The data portion 402 of 400 is written (step S2304), and the process ends (step S2307).

  When the protocol information 1711 (see FIG. 11) is “SOAP” (“SOAP” in step S2303), by SOAP communication using an API (Application Program Interface) of SAAJ (SOAP with Attachments API for Java (registered trademark)), The data portion 402 of the request request 400 at the destination (destination information 1712 (see FIG. 11)) defined in the request reception definition file 2206 (see FIG. 10) of the corresponding request reception 150 (SOAP request reception 2205 (see FIG. 10)). Is transmitted (step S2305), and the process is terminated (step S2307).

  When the protocol information 1711 (see FIG. 11) is “EJB (registered trademark)” (“EJB (registered trademark)” in step S2303), the corresponding request reception 150 (EJB (registered trademark) request reception 2200 (see FIG. 10)). ) Is transmitted to the destination defined in the request reception definition file 2202 (destination information 1712 (see FIG. 11)) (step S2306), and the process is terminated (step S2307).

  Here, the case where the protocol information 1711 (see FIG. 11) (the protocol information 1811 (see FIG. 12)) is “SOAP”, “EJB (registered trademark)”, or “JMS” has been described. The process of transmitting the data part 402 of the request request 400 is executed based on various communication protocols.

  FIG. 16 is a flowchart showing details of the adapter selection control process of FIG. This process is performed by the adapter selection control unit 123 being executed by the CPU 180. Hereinafter, the flow of the adapter selection control process S704 will be described with reference to FIG. 16 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 selects the public information entry 301 of the service name 302 that matches the requester name 403 of the request request 400 from the service public information table 192 of the service registry 190 (step S801). The CPU 180 determines whether or not there are a plurality of extracted public information entries 301 (step S802). If there are not more than one (“No” in step S802), the process proceeds to step S804. If there are a plurality (“Yes” in step S802), a matching control process is executed (step S803), and the process proceeds to step S804.

  In step S804, one selected public information entry 301 is returned to the request reception 150 (step S804), and the process ends (step S805).

  FIG. 17 is a flowchart showing details of the matching control process of FIG. This process is performed by the matching control unit 124 being executed by the CPU 180. Hereinafter, the flow of the matching control process S803 will be described with reference to FIG. 17 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 acquires the operating time 309 of the operation policy 304 from the public information entry 301 selected in step S801 (see FIG. 16), and selects the public information entry 301 whose current time is within the operating time 309 (step). S901). The CPU 180 determines whether there are a plurality of selected public information entries 301 (step S902). If the number is not plural (“No” in step S902), the process is terminated (step S907). If there are multiple items (“Yes” in step S902), the priority 208 of the public information entry 201 extracted in step S702 (see FIG. 14) is determined (step S903). When the priority is “high” (“high” in step S904), the public information entry 301 having the largest load capacity 310 value of the operation policy 304 is selected from the selected public information entries 301 (step S905). Then, the process ends (step S907). When the priority is “low” (“low” in step S904), the public information entry 301 having the smallest value of the load capacity 310 of the operation policy 304 is selected from the selected public information entries 301 (step S906). Then, the process ends (step S907).

  As described above, the service execution computer 100 registers the operation time 309 in the public information entry 301, so that the ESB execution computer 110 compares the operation time 309 with the current time, and the range of the operation time 309 from the plurality of services 100A. The service 100A can be selected. In other words, there is an effect that it is not necessary to previously register the operation policy of the service 100A that the requester 160A calls with priority in the ESB execution computer 110.

  The requester execution computer 160 registers the priority 208 in the public information entry 201, and the service execution computer 100 registers the load capacity 310 in the public information entry 301, so that the ESB execution computer 110 matches the priority 208. The service 100A having the load capacity 310 can be selected. In other words, there is an effect that it is not necessary to previously register the operation policy of the service 100A that the requester 160A calls with priority in the ESB execution computer 110.

  FIG. 18 is a flowchart showing details of the adapter generation processing of FIG. This process is performed by the adapter generation processing unit 120 being executed by the CPU 180. Hereinafter, the flow of the adapter generation process S707 will be described with reference to FIG. 18 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 generates the adapter 140 from the I / F information 303 of the service disclosure information (step S610). The CPU 180 starts the generated adapter 140 (step S611), and records the generated adapter information in the adapter information 305 (step S612). Here, the generation information 311 of the adapter information 305 is set to “Started”, and the address of the generated adapter is set to the address information 312. Thereafter, the process is terminated (step S712).

  FIG. 19 is a flowchart showing details of processing for generating an adapter from the I / F information of the service disclosure information shown in FIG. This request reception generation process is performed when the adapter generation processing unit 120 is executed by the CPU 180. Hereinafter, the flow of processing S610 for generating the adapter 140 from the I / F information 303 of the service disclosure information will be described with reference to FIG. 19 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 determines the protocol information 306 of service disclosure information (step S1600). When the protocol information 306 is “SOAP” or “EJB (registered trademark)” (“SOAP” or “EJB (registered trademark)” in step S1600), the synchronization adapter generation processing is performed (step S1601), and the processing is terminated. (Step S1603). If the protocol information 306 is “JMS”, an asynchronous adapter generation process is performed (step S1602), and the process ends (step S1603). Although the case where the protocol information 306 is “SOAP”, “EJB (registered trademark)”, or “JMS” has been described here, even in other cases, if the protocol information 306 is a synchronous communication protocol, step S1601 is performed. If the protocol information 306 is an asynchronous communication protocol, step S1602 is executed.

  FIG. 20 is a diagram illustrating a structure of an adapter generated by the adapter generation process in the present embodiment.

  The EJB (registered trademark) adapter 2100 includes a stub 2101, an adapter definition file 2102, and an EJB (registered trademark) application 2103. The adapter definition file 2102 is a file that defines information necessary for the adapter 140, and a detailed description thereof will be given later (see FIG. 21). The EJB (registered trademark) application 2103 is an application used when receiving and processing a service request (a data part 402 (see FIG. 6) of the request request 400 (see FIG. 6)).

  The SOAP adapter 2105 includes an adapter definition file 2106 and a SOAP application 2107. The adapter definition file 2106 is a file that defines information necessary for the adapter 140, and a detailed description thereof will be given later (see FIG. 21). The SOAP application 2107 is an application used when receiving and processing a service request (a data part 402 (see FIG. 6) of the request request 400 (see FIG. 6)).

  The JMS adapter 2108 includes a queue 2110, an adapter definition file 2109, and a JMS application 2111. The adapter definition file 2109 is a file that defines information necessary for the adapter 140, and a detailed description thereof will be given later (see FIG. 22). The queue 2110 stores the data part 402 (see FIG. 6) of the request request (see FIG. 6). When the JMS application 2111 receives the service request (the data part 402 (see FIG. 6) of the request request 400 (see FIG. 6)), the JMS application 2111 stores the service request in the queue 2110 and from the queue 2110 according to the order (request request 400 (FIG. 6)). The data portion 402 (see FIG. 6)) is retrieved and processed.

  FIG. 21 is a flowchart showing details of processing for generating the synchronous adapter of FIG. Hereinafter, the flow of the processing S1601 for generating the synchronization adapter will be described with reference to FIG. 21 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 defines the service name 302 and the protocol information 306 of the service disclosure information in the adapter definition file 1900 (step S1901). The adapter definition file 1900 shows an example in which the public information entry data (service name and protocol information) # 1 in FIG. 5 is set in the service name 1910 and the protocol information 1911, respectively. The contents of the first two lines of the adapter definition file 1900 are determined in advance. Next, the CPU 180 acquires the destination information from the WSDL file indicated by the message information 307 of the service disclosure information and defines it in the adapter definition file 1900 (step S1902). In the example of the adapter definition file 1900, since the message information of the public information entry # 1 in FIG. 5 is “service2.wsdl”, the destination information is acquired from “service2.wsdl” (not shown). An example in which “http: // yyy /” is set is shown in the destination information 1912 of the adapter definition file 1900.

  The CPU 180 acquires all operations from the WSDL file indicated by the message information 307 (step S1903), and performs processing (steps S1904 to S1906) for all operations (step S1909). That is, an operation name is defined in the <name> tag of the message information 1913 (step S1904), request information is defined in the <input> tag of the message information 1913 (step S1905), and a response is made to the <output> tag of the message information 1913. Information is defined (step S1906). In the example of the adapter definition file 1900, since the message information of the public information entry # 1 in FIG. 5 is “service2.wsdl”, the operation is acquired from “service2.wsdl” (not shown). The operation name, request information, and response information are described in the acquired operation. In the adapter definition file 1900, the message format of the request information generated by the WSDL file is defined in <format-file> of the <input> tag, and the format type is defined in <message-type> of the <input> tag. Yes. Also, the message format of response information generated from WSDL is defined in <format-file> of the <output> tag, and the format type is defined in <message-type> of the <output> tag. When <format-file> is in the xsd format, XML is set in <message-type>, but the format type is not limited to the xsd format, and a unique format type is set in formats other than the xsd format.

  Adapter definition file 1900 (adapter definition file 2102 (see FIG. 20) or 2106 (see FIG. 20)) and protocol-specific application (EJB (registered trademark) application 2103 (see FIG. 20) or SOAP application 2107 (see FIG. 20)) Are packaged (step S1907), and the process is terminated (step S1908). By this packaging, an adapter 140 (EJB (registered trademark) adapter 2100 (see FIG. 20) or SOAP adapter 2105 (see FIG. 20)) is generated. Here, the protocol-specific application (EJB (registered trademark) application 2103 (see FIG. 20) or SOAP application 2107 (see FIG. 20)) is, for example, an application (not shown) provided by a product such as a J2EE server. If stored in the memory 170, it is obtained by copying the application. The message information 1913 is used when a protocol-specific application (EJB (registered trademark) application 2103 (see FIG. 20) or SOAP application 2107 (see FIG. 20)) is executed. Note that the stub 2101 needs to be packaged in the EJB (registered trademark) adapter 2100. The stub 2101 may be generated by executing a command provided by an execution environment such as a J2EE server, or may be generated by taking in a product provided by a product such as a J2EE server.

  FIG. 22 is a flowchart showing a process for generating the asynchronous adapter of FIG. Hereinafter, the flow of the processing S1602 for generating the asynchronous adapter will be described with reference to FIG. 22 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 defines the service name 302 and the I / F information 303 of the service disclosure information in the adapter definition file 2000 (step S2001). In the adapter definition file 2000, the public information entry data (service name, protocol information, message information, and destination information) of # 2 in FIG. 5 is the <input> tag of the service name 2010, the protocol information 2011, and the message information 2013, respectively. In addition, an example set in the destination information 2012 is shown. Send is defined as fixed in the <name> tag of the operation of the message information 2013. The contents of the first two lines of the adapter definition file 2000 are determined in advance. Here, when no destination is set in the destination information 308 of the I / F information 303, a method of omitting the <url> line, a method of setting nothing between <url> and </ url>, etc. There is. In the <input> tag as request information, the message format and format type of the request defined by the message information are defined. Next, the CPU 180 determines whether or not there is a URL of the destination information (step S2002). If the URL exists (“Yes” in step S2003), the CPU 180 creates a transfer queue 2110 (see FIG. 20) with the URL as the transfer destination (step S2004), and proceeds to step S2006. If the URL does not exist (“none” in step S2003), the CPU 180 creates a local queue 2110 (see FIG. 20) (step S2005), and the process proceeds to step S2006.

  In step S2006, the generated adapter definition file 2000 (adapter definition file 2109 (see FIG. 20), created queue 2110 (see FIG. 20), and application (JMS application 2111 (see FIG. 20)) are packaged. (Step S2006), the process ends (Step S2007), and the adapter 140 (JMS adapter 2108 (see FIG. 20)) is generated by this packaging, where the application (JMS application 2111 (see FIG. 20)). For example, when an application (not shown) provided by a product such as a J2EE server is stored in the memory 170, the application is obtained by copying the application. Used in (JMS applications 2111 (see FIG. 20)) is performed.

  FIG. 23 is a flowchart showing details of processing in which the adapter of FIG. 14 receives a service request. This process is performed when the request reception 150 is executed by the CPU 180. Also, this process allows the adapter 140 to receive a service request. Hereinafter, the flow of processing S709 in which the adapter 140 receives a service request will be described with reference to FIG.

  First, the protocol information 1911 (see FIG. 20) from the adapter definition file 1900 (see FIG. 21) or 2000 (see FIG. 22) (adapter definition file 2102, 2106, or 2109 (see FIG. 20)) of the adapter 140 for which the service request is issued in S708. 21) or 2011 (see FIG. 22) is taken out (step S2401).

  When the protocol information 2011 (see FIG. 22) is “JMS” (“JMS” in step S2402), the request request 400 is sent to the queue 2110 (see FIG. 20) of the corresponding adapter 140 (JMS adapter 2108 (see FIG. 20)). The data part 402 is written (step S2403), and the process is terminated (step S2406).

  When the protocol information 1911 (see FIG. 21) is “SOAP” (“SOAP” in step S2402), the adapter definition of the corresponding adapter 140 (SOAP adapter 2105 (see FIG. 20)) by SOAP communication using the SAAJ API. The data part 402 of the request request 400 is transmitted to the destination (destination information 1912 (see FIG. 21)) defined in the file 2106 (see FIG. 20) (step S2404), and the processing is terminated (step S2406).

  When the protocol information 1911 (see FIG. 21) is “EJB (registered trademark)” (“EJB (registered trademark)” in step S2402), the destination (destination information 1912) defined in the adapter definition file 2102 is called by calling the stub 2101. (See FIG. 21)), the data part 402 of the request request 400 is transmitted (step S2405), and the process is terminated (step S2406).

  By such processing, the adapter 140 transmits a service request (the data part 402 of the request request 400) to the service 100A, and the service execution computer 100 executes the service 100A.

  Here, the case where the protocol information 1911 (see FIG. 21) (the protocol information 2011 (see FIG. 22)) is “SOAP”, “EJB (registered trademark)”, or “JMS” has been described. The process of transmitting the data part 402 of the request request 400 is executed based on various communication protocols.

  FIG. 24 is a flowchart showing details of the operation control process of FIG. This operation control process is performed by the operation control unit 122 being executed by the CPU 180. Hereinafter, the flow of the operation control process S711 will be described with reference to FIG. 24 (see FIGS. 1 to 7 as appropriate).

  First, the CPU 180 acquires an operation 209 at the time of failure from the operation policy 204 of the public information entry 201 extracted in step S702 (see FIG. 14) (step S1000). When the operation 209 at the time of failure is “retry” (“retry” in step S1001), a service activation request (request to activate the service 100A) is issued to the service execution computer 100 (step S1002). When the service 100A is activated, the service 100A is executed, and a response is returned from the service 100A, the CPU 180 returns a response to the requester 160A (step S1004) and ends the process (step S1006). If the operation 209 at the time of failure is “error” (“error” in step S1001), an error is returned to the requester 160A (step S1005), and the process is terminated (step S1006).

  As described above, when there is a call request for the service 100A, the ESB execution computer 110 can start the service 100A and start the service 100A even if the service 100A is not started.

  According to the present embodiment, the public information from the requester 160A and the service 100A is registered in the service registry 190 in the ESB execution computer 110, and the request reception corresponding to each of the requester 160A and the service 100A from the public information in the service registry 190 and An adapter can be created. As a result, the function of the service 100A can be dynamically provided to the requester execution computer 160 having a communication protocol different from that of the service execution computer 100.

It is a figure which shows the structure of the service function provision system in this embodiment. It is a figure which shows the data structure of the requester public information table in this embodiment. It is a figure which shows the example of the data and message format which are registered into the requester public information table in this embodiment, (a) is an example of the data registered into a requester public information table, (b) is a XSD format. (C) is a figure which shows the example of the message format described by WSDL format. It is a figure which shows the data structure of the service public information table in this embodiment. It is a figure which shows the example of the data registered into the service public information table in this embodiment. It is a figure which shows the request request | requirement which the requester in this embodiment transmits to an ESB execution computer. It is a figure which shows the example of the request request | requirement of FIG. It is a flowchart which shows the requester public information registration process in this embodiment. It is a flowchart which shows the detail of the request reception production | generation process of FIG. It is a figure which shows the structure of the request reception produced | generated by the request reception production | generation process in this embodiment. 10 is a flowchart showing details of processing for generating the synchronous request reception of FIG. 9. 10 is a flowchart showing details of processing for generating the asynchronous request reception of FIG. 9. It is a flowchart which shows the service public information registration process in this embodiment. It is a flowchart which shows the service call process in this embodiment. It is a flowchart which shows the detail of the process in which the request reception of FIG. 14 receives a service request. It is a flowchart which shows the detail of the adapter selection control process of FIG. It is a flowchart which shows the detail of the matching control process of FIG. It is a flowchart which shows the detail of the adapter production | generation process of FIG. It is a flowchart which shows the detail of the process which produces | generates an adapter from the interface information of the service public information of FIG. It is a figure which shows the structure of the adapter produced | generated by the adapter production | generation process in this embodiment. It is a flowchart which shows the detail of the process which produces | generates the synchronous adapter of FIG. It is a flowchart which shows the process which produces | generates the asynchronous adapter of FIG. It is a flowchart which shows the detail of the process in which the adapter of FIG. 14 receives a service request. It is a flowchart which shows the detail of the operation control process of FIG.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Service function provision system 100 Service execution computer 100A Service 110 ESB execution computer 120 Adapter production | generation part 121 Request reception production | generation part 122 Operation control part 123 Adapter selection control part 124 Matching control part 130 ESB program 140 Adapter 150 Request reception 160 Requester execution Computer 160A Requester 170 Memory 180 CPU
190 Service Registry 191 Requester Public Information Table 192 Service Public Information Table 201 Public Information Entry 202 Requester Name 203 I / F (Interface) Information 204 Operation Policy 205 Protocol Information 206 Message Information 207 Destination Information 208 Priority 209 Operation at Failure 301 Public Information entry 302 Service name 303 I / F (interface) information 304 Operation policy 305 Adapter information 306 Protocol information 307 Message information 308 Destination information 309 Operation time 311 Generation information 312 Address information 400 Request request 401 Control unit 402 Data unit 403 Requester name 404 Destination service name 1101 CPU
1102 Memory 1104 CPU
1105 Memory 1106 Stub 1200 Network 1300 Message format

Claims (10)

A requester execution computer that requests execution of a service, and a service function providing device that can communicate with the service execution computer that executes the service,
A storage unit for storing an adapter used when communicating with the service execution computer;
By receiving protocol information and message information specifying the protocol and message format type used for communication with the requester execution computer from the requester execution computer, respectively, the requester public information entry is stored in the storage unit,
Using the protocol information and the message information in the storage unit, generate a request reception used when communicating with the requester execution computer, and store the request reception in the storage unit,
A processing unit that receives a request to execute the service from the requester execution computer using the request reception of the storage unit, and that performs the request to the service execution computer using the adapter of the storage unit. A service function providing apparatus characterized by the above. A service function providing method by a requester execution computer that requests execution of a service and a service function providing device that can communicate with the service execution computer that executes the service,
The service function providing device includes:
A storage unit that stores an adapter used when communicating with the service execution computer; and a processing unit that processes information.
The processor is
By receiving protocol information and message information specifying the protocol and message format type used for communication with the requester execution computer from the requester execution computer, respectively, the requester public information entry is stored in the storage unit,
Using the protocol information and the message information in the storage unit, generate a request reception used when communicating with the requester execution computer, and store the request reception in the storage unit,
Using the request acceptance of the storage unit to accept a request to execute the service from the requester execution computer, and making the request to the service execution computer using the adapter of the storage unit. To provide service functions. The processor is
The generation of the request reception determines whether to generate an asynchronous request reception or a synchronous request reception according to a communication protocol specified by the protocol information. Service function provision method. A service function providing method by a requester execution computer that requests execution of a service and a service function providing device that can communicate with the service execution computer that executes the service,
The service function providing device includes:
A storage unit that stores a request reception used when communicating with the requester execution computer, and a processing unit that processes information.
The processor is
By receiving protocol information and message information specifying the protocol and message format type used for communication with the service execution computer from the service execution computer, respectively, it is stored in the storage unit as a service public information entry,
Using the protocol information and the message information in the storage unit, generate an adapter to be used when communicating with the service execution computer and store it in the storage unit,
Using the request acceptance of the storage unit to accept a request to execute the service from the requester execution computer, and making the request to the service execution computer using the adapter of the storage unit. To provide service functions. A service function providing method by a requester execution computer that requests execution of a service and a service function providing device that can communicate with the service execution computer that executes the service,
The service function providing device includes:
A storage unit that stores a request reception used when communicating with the requester execution computer, and a processing unit that processes information.
The processor is
By receiving protocol information and message information specifying the protocol and message format type used for communication with the service execution computer from the service execution computer, respectively, it is stored in the storage unit as a service public information entry,
It is determined whether or not an adapter to be used when communicating with the service execution computer is generated. If the adapter is not generated, the adapter is generated using the protocol information and the message information in the storage unit. And store in the storage unit,
Using the request acceptance of the storage unit to accept a request to execute the service from the requester execution computer, and making the request to the service execution computer using the adapter of the storage unit. To provide service functions. The processor is
The protocol information and the message information are received from the service execution computer, and the operation time during which the service can be provided is received, included in the service disclosure information entry, and stored in the storage unit,
5. The adapter that makes the request to the service execution computer is selected based on the service disclosure information entry of the storage unit whose current time is within the operating time of the storage unit. 5. The service function providing method according to 5. The storage unit
Further storing the priority when selecting the adapter that performs the request to the service execution computer,
The processor is
The protocol information and the telegram information are received from the requester execution computer, and the load capacity of the service is received and included in the service disclosure information entry and stored in the storage unit,
7. The adapter that performs the request to the service execution computer is selected based on the service public information entry in the storage unit according to the priority and the load capacity. 2. A service function providing method according to item 1. The storage unit
Further storing an operation at the time of failure, which is an operation when a failure occurs in the service,
The processor is
The service function providing method according to any one of claims 4 to 7, wherein an activation request for the service is issued to the service execution computer according to an operation at the time of the failure. The processor is
The communication protocol specified by the protocol information is used when making the request to the service execution computer using the adapter of the storage unit. Service function providing method described in 1.   A service function providing program for causing a computer to execute the service function providing method according to any one of claims 2 to 9.

Images