JP5548433B2 - Web service platform system - Google Patents

Description

  The present invention relates to a web service infrastructure technology for providing a web service to a client.

  In recent years, various types of Web services have been developed and provided to clients. In some cases, WSDL is used to implement a Web service. WSDL is a standard XML document specified by the World Wide Web Consortium (W3C). WSDL is used to exchange interface information between a service provider that provides a Web service and a service requester (client) that uses the Web service. Patent Document 1 describes a communication system that uses WSDL by a Web service that can interact with a program of a controller device.

JP 2002-215486 A

  By the way, when providing an existing business system as a Web service to a client, it is necessary to develop a program according to a description format of messages exchanged according to a communication protocol such as SOAP (Simple Object Access Protocol). When the message is described in XML (eXtensible Markup language), the data format of the message in XML is different from the data format that can be processed in the programming language on the Web service provider side. A mechanism to absorb the difference in format is required.

  Therefore, when an existing business system is provided to a client as a Web service, there is a problem that the system development scale, development cost, and work load are large, and the existing business system cannot be easily converted to a Web service.

  The present invention has been made in view of the above circumstances, and an object of the present invention is to more easily provide an existing business system as a Web service to a client without changing the existing business system.

  In order to solve the above problems, the present invention is a Web service infrastructure system that provides a client with processing performed by a business system as a Web service, and performs communication for transmitting and receiving messages to and from a client according to a predetermined communication protocol. A processing unit, a plurality of service endpoints provided for each Web service, and a Web service providing unit common to all Web services, wherein the communication processing unit receives a service request from the client, The service request is sent to the Web service providing means via the Web service service endpoint specified in the service request, and the Web service providing means converts the service request into a data format that can be processed by the business system. To the Web service specified in the service request. Transmits to the business system to respond, the converts the processing result of the business system to the communication processing means processes a data format, and sends it to the communication processing unit via a service endpoint for the Web service.

  In the present invention, an existing business system can be provided to a client as a Web service more easily without changing the existing business system.

1 is a configuration diagram of a Web service infrastructure system to which an embodiment of the present invention is applied. It is a figure which shows the hardware structural example of each apparatus. It is a figure which shows an example of a request message. It is a figure which shows an example of a service call definition file. It is a figure which shows an example of a transaction call definition file, a data conversion definition file, and a message definition file. An example of a response message is shown. It is a figure which shows the input / output file in the production | generation process of WSDL. It is a figure which shows the structure of WSDL typically. It is a flowchart which shows the production | generation process of WSDL. It is a figure which shows typically the relationship between WSDL, a transaction call definition file, a data conversion definition file, and a message definition file. It is a figure which shows an example of a WSDL naming rule. It is a figure which shows an example of a WSDL naming rule. It is a figure which shows an example of a WSDL naming rule. It is a figure which shows an example of a WSDL naming rule. It is a figure which shows an example of a WSDL naming rule. It is a figure which shows an example of JavaBeans. It is a figure which shows an example of a service endpoint.

  Embodiments of the present invention will be described below.

  FIG. 1 is an overall configuration diagram of a Web system to which an embodiment of the present invention is applied. In this embodiment, an existing business system is quickly and easily converted into a Web service.

  The illustrated Web system includes a client 1 used by a user, a Web service infrastructure system 2, and a plurality of existing business systems 7 and 8. The first business system 7 executes various services (business processes) by executing application programs (transactions) described in Java (registered trademark). The second business system 8 executes various services (business processes) by executing application programs (transactions) described in COBOL, C language, etc. other than Java (registered trademark).

  The client 1 and the Web service infrastructure system 2 are connected by a network such as the Internet, and the Web service infrastructure system 2 and the business systems 7 and 8 are connected by a network such as a LAN.

  The Web service infrastructure system 2 of this embodiment connects a request transmitted from the client 1 to the transaction of the corresponding business system 7, 8 and transmits the processing result of the transaction to the requesting client 1.

  The web service infrastructure system 2 shown in the figure includes, as an execution environment, a web application unit 21, a SOAP engine 22 (communication processing means), a plurality of service endpoints 23, a general-purpose service class 24, and a connection unit 28 (providing a web service). Means), a service call definition file 31, a data conversion definition file 34, and a message definition file 35.

  Further, the Web service infrastructure system 2 generates, as a development environment, a WSDL 11 installed in the client 1, a service endpoint 23 used in the execution environment of the Web service infrastructure system 2, a service call definition file 31, and a JavaBeans 32. 29.

  The client 1, Web service infrastructure system 2, and business systems 7, 8 described above all include, for example, a CPU 901, a memory 902, an external storage device 903 such as an HDD, a keyboard and a mouse as shown in FIG. 2. A general-purpose computer system including an input device 904 such as a display, an output device 905 such as a display or a printer, and a communication control device 906 for connecting to a network can be used. In this computer system, the CPU 901 executes a predetermined program loaded on the memory 902, thereby realizing each function of each device.

  For example, the functions of the Web service infrastructure system 2 and the business systems 7 and 8 are executed by the CPU 901 of the Web service infrastructure system 2 in the case of a program for the Web service infrastructure system 2 and the program for the business systems 7 and 8. Is implemented by the CPUs 901 of the business systems 7 and 8 respectively.

  In addition, about the input device 904 and the output device 905, each apparatus shall be provided as needed. Further, the Web service infrastructure system 2 may be composed of a plurality of servers. For example, it may be configured by a server for an execution environment and a server for a development environment.

[Execution environment]
The execution environment of the Web service infrastructure system 2 will be described below.

  The Web application unit 21 receives a request message (service request) transmitted from the client 1 and sends it to the SOAP engine 22.

  The SOAP engine 22 exchanges messages such as request messages and response messages with the client 1. SOAP (Simple Object Access Protocol) is a protocol for calling data and services in other computers based on XML, HTTP, and the like. In communication using SOAP, an electronic document / message with accompanying information called an envelope attached to an XML document is exchanged using a protocol such as HTTP. Both the client using the Web service (hereinafter referred to as “service”) and the system providing the service have a SOAP generation / interpretation engine, thereby enabling object calls between different environments.

  The service endpoint 23 is a service port (interface, port) that is open to the client 1 that uses the service. In the present embodiment, a service endpoint 23 is provided for each service.

  The service class 24 is middleware that performs Web processing called from the service endpoint 23. The service class 24 of this embodiment is a general-purpose one that is commonly used by all services. The service class will be described later.

  Next, processing in the execution environment of this embodiment will be described.

  In this embodiment, the WSDL 11 of the client 1, the service endpoint 23, the service call definition file 31, and the JavaBeans 32 of the Web service infrastructure system 2, which are generated in advance by the development environment generation unit 29 described later, are used.

  First, the client 1 receives a user instruction and transmits a request message by SOAP to the Web service infrastructure system 2. That is, the application 13 of the client 1 generates a request message using the stub 12 generated from the WSDL 11 and transmits it to the Web service infrastructure system 2. The request message includes a middle header, application data, and a URL (Uniform Resource Locator) that is the transmission destination of the request message. The middle header is an area for holding control information exchanged between the client and the Web service infrastructure system 2. The WSDL 11 will be described later.

  FIG. 3 shows an example of a request message transmitted from the client 1. The request message shown in the figure has an HTTP header and a SOAP message. The HTTP header includes a URL 301 for identifying a desired service, and a service name (“PT01” in the illustrated example) is set at the end of the URL 301. In the SOAP message, a middle header 302 and application data 303 are set.

  The SOAP engine 22 of the Web service infrastructure system 2 receives the request message via the Web application unit 21 and reads the service call definition file 31 corresponding to the service name set in the URL 301 of the request message. The service call definition file 31 is generated for each service. The service call definition file 31 is generated in advance by the development environment generation unit 29 and stored in a storage unit (not shown) of the Web service infrastructure system 2.

  FIG. 4 shows an example of the service call definition file 31. In the illustrated service call definition file 31, “PT01” 401 is described as a service name, and “TRDOperation” 402 indicating the service class 24 (Web service provider unit 25) is described as a call method name. In the present embodiment, the same call method name (“TRDOoperation”) is set in all service call definition files 31. Thereby, each service end point 23 calls the general-purpose service class 24 common to all the service end points.

  The service call definition file 31 also includes JavaBeans (data holding component) identification information 403 (for middle header: “aifabean”, for application data: “lay029bean”) used in an upstream message transmitted to the business system. JavaBeans identification information 404 (for application data: “pt01returnbean”) used in a downlink message transmitted to the client is described, and further, a message type definition 405 is described.

  The SOAP engine 22 deserializes the SOAP message of the request message based on the corresponding service call definition file 31, and delivers JavaBeans to the service endpoint 23 corresponding to the service name specified in the request message. That is, the SOAP engine 22 converts the SOAP message data described in XML into the Java (registered trademark) language, stores it in the JavaBean for upstream messages specified in the service call definition file 31, and stores the service endpoint 23. To send.

  In the case of the service call definition file 31 shown in FIG. 4, the SOAP engine 22 stores data in the JavaBeans of “aifbean” for the middle header of the SOAP message, and the JavaBeans of “lay029bean” for the application data of the SOAP message. To do.

  In addition, the middle header, the upstream message, and the JavaBeans of the downstream message (empty data holding component that does not contain data) used in each service are generated in advance by the generation unit 29 of the development environment and are stored in the Web service infrastructure system 2. Is provided.

  The service endpoint 23 that has received JavaBeans refers to the service call definition file 31 corresponding to the service of its own service endpoint, and calls the general-purpose service class 24 based on the information set in the service call definition file 31. . Specifically, the service class 24 set in the call method name 402 (see FIG. 4) is called. At that time, the service endpoint 23 passes the received JavaBeans and various information set in the service call definition file (service name, ID of JavaBeans, etc.) to the service class 24 as arguments.

  The data conversion unit 26 of the service class 24 receives an argument such as JavaBeans 32 via the Web service provider unit 25. Then, the data conversion unit 26 performs a data check on the data held in the received JavaBeans 32 and stores the data in the data storage unit 36. The data storage unit 36 of the present embodiment includes a data store bean (DSB), a request data holder (RDH), and a session data holder (SDH).

  The data conversion unit 26 stores the data held in the JavaBeans of the upstream message (application data) in the DSB, and stores the data held in the JavaBeans of the middle header in the RDH and SDH. The data storage unit 36 is a data area that can be accessed from all services of the business systems 7 and 8.

  Then, the data conversion unit 26 calls the transaction calling unit 27 using the DSB, RDH, and SDH data generated from the JavaBeans 32 and stored in the data storage unit 36 and the service name as arguments. The transaction call unit 27 refers to the transaction call definition file 33 and identifies the transaction ID and call destination of the business systems 7 and 8 corresponding to the service name set as an argument. The transaction call definition file 33 is a file that defines a call to the business systems 7 and 8 and is stored in advance in a storage unit (not shown).

  FIG. 5A shows an example of the transaction call definition file 33. In the illustrated transaction call definition file 33, a service name 501 and a transaction ID 502 and a call destination 503 of a business system corresponding to the service name 501 are stored in association with each other. In the call destination 503, identification information (system ID or the like) for identifying the business system to be called is set. In the illustrated transaction call definition file 33, only one set of service name and transaction ID / call destination is described, but actually, a plurality of sets of service name and transaction ID / call destination are associated with each other. It has been described.

  When the transaction to be started is the Java (registered trademark) logic of the first business system 7, the system ID of the first business system 7 is set as the call destination 503. On the other hand, when the transaction to be started is an application program described in COBOL, C language, or the like of the second business system 8, the connection unit 28 is set as the call destination 503.

  The transaction calling unit 27 calls the specified call destination using the specified transaction ID and DSB, RDH, and SDH data as arguments.

  When the first business system 7 is called, the first business system 7 starts a transaction specified as an argument, performs a predetermined business process using data passed as an argument, and processes the processing result as a transaction. The data is transmitted to the data conversion unit 26 via the calling unit 27. The processing result transmitted to the data conversion unit 26 is data in the Java (registered trademark) data format.

  On the other hand, when the connection unit 28 is called, the connection unit 28 refers to the data conversion file 34 corresponding to the transaction ID specified as an argument, and specifies the message definition file ID specified in the data conversion file 34. . And the connection part 28 reads the message | telegram definition file of the specified message | telegram definition file ID. The data conversion file 34 is a file that defines input / output of the business system, and the message definition file 35 is a file that defines a data layout for each input / output. These files 34 and 35 are storage units (not shown). Is stored in advance.

  FIG. 5B shows an example of the data conversion file 34. In the illustrated data conversion file 34, the transaction ID 511 of the second business system 8, the message definition file ID 512 for uplink messages corresponding to the transaction ID 511, and the message definition file ID 513 for downlink messages are stored in association with each other. ing.

  FIG. 5C shows an example of the message definition file 35. In the illustrated message definition file 35, a message definition file ID 521 is associated with a data layout definition 522 (data name, data type, number of digits, data arrangement order, etc.) of the message corresponding to the message definition file ID 521. Is remembered.

  The connection unit 28 reads the message definition file 35 of the message definition file ID 512 for the uplink message specified with reference to the data conversion file 34, and passes it as an argument using the data layout definition 522 of the message definition file 35. The DSB data is converted into a data format that can be used by the transaction (application program) of the second business system 8. Then, the connection unit 28 calls the second business system 8 using the converted data and the transaction ID specified from the transaction call definition file 33 as arguments.

  The second business system 8 starts a transaction specified as an argument, performs a predetermined business process using the data passed as the argument, and transmits the processing result to the connection unit 28.

  The connection unit 28 reads the message definition file 35 corresponding to the message definition file ID 513 for the downlink message specified in the data conversion file 34, and uses the data layout definition of the message definition file 35 to use the second business system 8. The data of the processing result transmitted from is converted to the DSB data format (Java (registered trademark) data). Then, the connection unit 28 transmits the converted DSB data format data to the data conversion unit 26 via the transaction calling unit 27.

  The data conversion unit 26 stores the processing result (downlink message) received from the business systems 7 and 8 in the DSB data format in the DSB of the data storage unit 36 and also in the service call definition file 31 (see FIG. 4). Stored in JavaBeans for the downlink message described. When the service endpoint 23 calls the service class 24, it notifies the service class 24 (data conversion unit 26) of the ID of the JavaBean for the downlink message as an argument.

  Then, the data conversion unit 26 sends JavaBeans for the downlink message to the SOAP engine 22 via the Web service provider unit 25 and the corresponding service endpoint 23. In addition, the data conversion unit 26 may send JavaBeans for the middle header in which the return code is set to the SOAP engine 22 together with JavaBeans for the downlink message.

  The SOAP engine 22 serializes the data stored in the received JavaBeans based on the service call definition file 31 to generate a response message, and transmits the response message to the client 1. That is, the SOAP engine 22 converts Java (registered trademark) data stored in JavaBeans into a SOAP message described in XML.

  FIG. 6 shows an example of a response message. The response message shown has an HTTP header and a SOAP message. The SOAP message describes a middle header 401 in which a return code is set and application data (processing result) 402.

[Development environment processing]
Next, the development environment in this embodiment will be described.

  The generation unit 29 of the Web service infrastructure system 2 generates the WSDL 11 used by the client 1, and the service endpoint 23, JavaBeans 32, and service call definition file 31 used in the execution environment of the Web service infrastructure system 2 (FIG. 1). reference).

<Generation of WSDL>
First, the WSDL generation process will be described.

  WSDL (Web Service Description Language) is a language specification based on XML for describing Web services. WSDL describes the definition of what functions each Web service has and what requests it should make in order to use it. The service provider that provides the Web service and the Web Used to exchange interface information between service requesters (clients) that use the service. WSDL includes information necessary for a client to call a method of a Web service.

  As illustrated in FIG. 7, the generation unit 29 according to the present embodiment generates the WSDL 11 used by the client 1 based on the transaction call definition file 33, the data conversion definition file 34, and the message definition file 35 used in the execution environment. . Note that the generation unit 29 uses a WSDL naming rule 701 described later when generating the WSDL 11.

  FIG. 8 is a diagram schematically showing the structure of the WSDL 11.

  The WSDL 11 includes a type element 71, a message element 72, a port type element 73, a binding element 75, and a service element 76. The port type element 73 has at least one operation element 74 and the service element 76 has at least one port element 77. In addition, the WSDL 11 has a Definitions element 70 as the highest element.

  The type element 71 defines lower data types such as a middle header, an uplink message, a downlink message, and a downlink message structure. Nested types can also be defined. Message element 3 defines the transmission data format. A message received as a request defines what kind of element, which type element 71 includes a data type defined by the name, and the like.

  The port type element 4 logically defines one operation unit by combining several transmission data formats defined in the message element 3. Specifically, a request message (message) and a corresponding response message (message) are defined.

  In the binding element 75, a logical model of the interface defined in the type definition 71, the message definition 72, the port type definition 73, etc. (definition that such a data type is combined and such a message is exchanged in this way), Define a connection with a physical model (for example, the definition that SOAP-RPC is performed on HTTP). SOAP-RPC is a specification for making a remote procedure call (RPC), that is, a remote procedure call, using a communication protocol using SOAP, that is, XML.

  The service element 76 defines a specific access point. The port element 77 defines which interface of which binding element 75 is provided by which URL.

  In this embodiment, the type definition 71 is created based on the transaction call definition file 33, the data conversion definition file 34, and the message definition file 35 used in the execution environment, the message definition 72 is created based on the type definition 71, and the message A port type definition 73 is created based on the definition 72, a binding definition 75 is created based on the port type definition 73, and a service definition 76 is created based on the binding definition 75.

  FIG. 9 is a flowchart showing a flow of processing for generating WSDL 11. FIG. 10 is a related diagram schematically showing the relationship between the transaction call definition file 33, the data conversion definition file 34, the message definition file 35, and the WSDL 11.

  First, the generation unit 29 inputs the transaction call definition file 33, the data conversion definition file 34, and the message definition file 35 and stores them in a storage unit (not shown) (S11).

  In the example of the transaction call definition file 33 shown in FIG. 10, the transaction ID “BE801” is associated with the service name “PT01”. In the illustrated transaction call definition file 33, only one set of service name and transaction ID is described, but actually, a plurality of sets of service name and transaction ID are described in association with each other. To do.

  In the example of the data conversion definition file 34 illustrated in FIG. 10, a message definition file of “Ray029” (message layout ID) is associated with an uplink message with a transaction ID of “BE801”, and a downlink message of the transaction ID is associated with the message ID. Is associated with a message definition file of “Layout 2” (message layout ID). In the example of the message definition file 35 of “Ray029” illustrated in FIG. 10, the data type of the item name (column) of “memno” is a character string type, and the data type of the data item name (column) of “passwd” Is described as a string type.

  And the production | generation part 29 receives the input of WSDL production | generation information (S12). The WSDL generation information includes a service name, a WSDL file output destination directory name, an endpoint URL, and the like. The generation unit 29 generates the WSDL 11 corresponding to the service name input as the WSDL generation information by the subsequent processing.

  Then, the generation unit 29 reads the transaction call definition file 33 input in S11 and stored in the storage unit, and acquires the transaction ID corresponding to the service name input in S12 (S13). In the example illustrated in FIG. 9, when the service name “PT01” is input, the transaction ID “BE801” is acquired.

  Then, the generation unit 29 reads the data conversion definition file 34 stored in the storage unit, acquires the message layout ID corresponding to the transaction ID acquired in S13, and acquires the message definition file of the acquired message layout ID from the storage unit. Read (S14). In the example illustrated in FIG. 9, when the transaction ID “BE801” is acquired, the message layout ID “Ray029” is acquired for the uplink message, and the message layout ID “Layout2” is acquired for the downlink message.

  Then, the generating unit 29 generates a WSDL definition definition based on the service name and the WSDL naming rule 701 input in S12 (S15).

  The WSDL naming rule 701 is stored in advance in a storage unit (not shown), and relates to each of a service ID name, output WSDL file name, XML namespace setting, XML declaration, type definition, message definition, port type definition, binding definition, and service definition. Has naming rules.

  11 to 15 show an example of the WSDL naming rule 701 stored in the storage unit. FIG. 11 shows an example of naming rules related to service names, output WSDL file names, XML namespace settings, and XML declarations.

  The service name is a service name of the Web service and is different for each Web service (application). This service name is input in S12 as WSDL generation information. The output WSDL file name is an output file name of the generated WSDL, and includes a service name and an extension “.wsdl”.

  The naming rule for setting the XML namespace is composed of impl, wsdl, wsdlsoap, xsd, tns1, tns2, and soapap. impl is a name space to which the service belongs, and “service name” is set therein. In wsdl, a fixed value (for example, http://schemas.xmlsoap.org/WSDL/) indicating a WSDL namespace for the WSDL framework is set. In Wsdlsoap, a fixed value (for example, http://schemas.xmlsoap.org/WSDL/soap/) indicating a WSDL namespace for the WSDL SOAP binding is set. xsd is a fixed value indicating the schema namespace defined in XSD (for example, http://www.w3.org/2001/XMLScheme/ is set. tns1 is a fixed value indicating the namespace to which the middle header message belongs. (For example, http://PPPI.header.WSDL.info.nri.co.jp) is set, and tns2 is a name space to which the upstream message and the downstream message belong, for example, http: // [service name]. apl.wsd.info.nri.co.jp is set, soapenc is a fixed value indicating the encoding namespace defined in SOAP1.1 (eg http://schemas.xmlsoap.org/soap/encoding/ ) Is set.

  The naming rule of xml declaration has xml version and encoding. The xml version is a fixed value indicating the XML version, and is 1.0, for example. encoding is a fixed value indicating the encoding, and is, for example, UTF-8.

  An example of a WSDL definition element generated by the generation unit 29 when the service name input in S12 is “PT01” and the WSDL naming rule shown in FIG. 11 is used is shown below.

<? xml version = "1.0" encoding = "UTF-8"?>
<WSDL: definitions targetNamespace = "PT01" xmlns: impl = "PT01"
xmlns: soapenc = "http://schemas.xmlsoap.org/soap/encoding/"
xmlns: tns1 = "http://PPPI.header.wsd.info.nri.co.jp"
xmlns: tns2 = "http: // PT01.apl.wsd.info.nri.co.jp"
xmlns: WSDL = "http://schemas.xmlsoap.org/WSDL/"
xmlns: WSDLsoap = "http://schemas.xmlsoap.org/WSDL/soap/"
xmlns: xsd = "http://www.w3.org/2001/XMLSchema">
And the production | generation part 29 produces a type definition based on the message | telegram definition file 35 and WSDL naming rule which were read by S14 (S16).

  12 and 13 show an example of the WSDL naming rule regarding the type definition stored in the storage unit. As shown in the figure, the type definition is composed of definitions relating to a middle header, an uplink message, a downlink message, and a downlink message structure (middle header + downlink message).

  As shown in FIG. 11, the middle header (O3W header) includes a type definition name (complexType name), a targetNamespace, a namespace prefix, a type item name (element name), and a type attribute (type). As the type definition name, a fixed value (for example, O3WheadBean) indicating the data name of the middle header is set. As the namespace prefix, a fixed value (for example, tns1) indicating the prefix of the namespace to which the middle header message belongs is set. targetNamespace is the name space to which the middle header message belongs, and is set to the name specified by tns1. The type item name is an item set as a middle header, and the item name set in the message definition file 35 is set. In the type attribute, a fixed value (for example, xsd: string) indicating the data type of the middle header is set.

  An example of WSDL corresponding to the type definition of the middle header generated by the generation unit 29 is shown below.

<WSDL: types>
<schema targetNamespace = "http://PPPI.header.wsd.info.nri.co.jp" xmlns = "http://www.w3.org/2001/XMLSchema">
<complexType name = "O3WheadBean">
<sequence>
<element name = "APL_KYOSEI" type = "xsd: string"/>
<element name = "APLSYOGAI" type = "xsd: string"/>
</ sequence>
</ complexType>
<element name = "O3WheadBean" type = "tns1: O3WheadBean"/>
</ schema>
Next, the type-defined uplink message will be described. As shown in FIG. 12, the naming rule of the uplink message has a type definition name (complexType name), a targetNamespace, a namespace prefix, a type item name (element name), and a type attribute (type). The type definition name is the data name of the upstream message, and [message layout ID] + Bean is set. In the namespace prefix, a fixed value (for example, tns2) indicating the prefix of the namespace to which the upstream message belongs is set. targetNamespace is the name space to which the upstream message belongs, and the name space specified by tns2 is set. The item name and data type set in the message definition file 35 are set in the type item name and type attribute.

  Below, an example of WSDL corresponding to the type definition of the uplink message generated by the generation unit 29 is shown.

<schema targetNamespace = "http://PT01.apl.wsd.info.nri.co.jp" xmlns = "http://www.w3.org/2001/XMLSchema">
<complexType name = "Lay029Bean">
<sequence>
<element name = "memmo" type = "xsd: string"/>
<element name = "passwd" type = "xsd: string"/>
</ sequence>
</ complexType>
<element name = "Lay029Bean" type = "tns2: Lay029Bean"/>
Next, a type-defined downlink message will be described. As shown in FIG. 13, the naming rule of the downlink message is composed of a type definition name (complexType name), a targetNamespace, a namespace prefix, a type item name (element name), and a type attribute (type). The type definition name is the data name of the downlink message, [Message layout ID] + Bean is set, and the namespace prefix is set to a fixed value (for example, tns2) indicating the prefix of the namespace to which the downlink message belongs , TargetNamespace is the name space to which the downlink message belongs, is the name space specified by tns2, and is shared with the uplink message.

In the type item name and type attribute, the item name and data type set in the message definition file are set.
An example of WSDL corresponding to the type definition of the downlink message generated by the generation unit 29 will be shown below.

<complexType name = "Layout2Bean">
<sequence>
<element name = "swkl000ap00" type = "xsd: string"/>
<element name = "swkl1100d00" type = "xsd: string"/>
</ sequence>
</ complexType>
</ schema>
</ WSDL: types>
Next, the type-defined downlink message structure will be described. The downlink message structure is composed of a middle header and a downlink message. As shown in FIG. 13, the naming rule of the downlink message is composed of a type definition name (complexType name), a targetNameplace, a namespace prefix, a type item name (element name), and a type attribute (type). The type definition name is the data name of the downlink message structure, and [service name] + ReturnBean is set. As the namespace prefix, a fixed value (for example, tns2) indicating the prefix of the namespace to which the downlink message structure belongs is set.

  targetNamespace is the name space to which the downlink message structure belongs, is the name space specified by tns2, and is shared with the uplink message. The type item name is an item set as a downlink message structure, and the middle header and the type definition name of the downlink message in lower case (for example, o3wheadbean) are set. The type attribute is the data type of the downlink message structure. For example, tns1: O3WheadBean is set for the middle header, and tns2: [type definition name of the downlink message] is set for the downlink simple message.

  Below, an example of WSDL corresponding to the type definition of the downlink message structure generated by the generation unit 29 is shown.

<complexType name = "PT01ReturnBean">
<sequence>
<element name = "o3wheadbean" type = "tns1: O3WheadBean"/>
<element name = "layout2bean" type = "tns2: Layout2Bean"/>
</ sequence>
</ complexType>
<element name = "PT01ReturnBean" type = "tns2: PT01ReturnBean"/>
Then, the generation unit 29 generates a WSDL message definition based on the type definition and WSDL naming rule generated in S16 (S17).

  FIG. 14 shows an example of a WSDL naming rule related to the message definition and the port type definition stored in the storage unit. As shown in FIG. 14, the message definition includes a request definition and a response definition. The request definition and the response definition are composed of a message name (message name), a part name (part name), and a part type (type).

  For the request definition, the message name is the message name of the upstream message, and [service name] + Request is set. The part name and part type are generated in the middle header and upstream message, respectively. For the middle header, the lower part of the type definition name of the middle header is set for the part name. For the part type, [namespace prefix of targetNamespace set in the type definition] + ":" for the middle header + [type definition name] is set. For the upstream message, the part name is set to the lower case version of the type definition name of the upstream message. The part type is [namespace prefix of targetNamespace set in the type definition] + ":" + [type definition name] is set.

  For the response definition, the message name is the message name of the downlink message structure, and [service name] + Response is set. The part name is the part name of the downlink message structure, and [type definition name of the downlink message structure in lower case] is set. The part type is the part type of the downlink message structure, and [namespace prefix of targetNamespace set in the type definition of the downlink message structure] + ":" + [type definition name] is set.

  An example of a WSDL message definition generated by the generation unit 29 is shown below.

<WSDL: message name = "PT01Request">
<WSDL: part name = "o3wheadbean" type = "tns1: O3WheadBean"/>
<WSDL: part name = "lay029bean" type = "tns2: Lay029Bean"/>
</ WSDL: message>
<WSDL: message name = "PT01Response">
<WSDL: part name = "pt01returnbean" type = "tns2: PT01ReturnBean"/>
</ WSDL: message>
Then, the generation unit 29 generates a WSDL port type definition based on the message definition and WSDL naming rule generated in S17 (S18).

  As shown in FIG. 14, the port type definition includes port type name (portType name), parameterOrder, operation name (operation name), input message name (message), data name (name), output message name (message). It consists of a data name (name).

  [Service name] + "Server" is set as the port type name. parameterOrder is an attribute indicating the parameter order, and "o3wheadbean" + [upstream message type definition name in lowercase] is set. As the operation name, a fixed value (for example, TRDOperation) indicating a service call method (service class 24) is set.

  The message name of input is the message name of the upstream message, and “impl:” + [Request message name set in the message definition] is set. The data name of input is the data name of the upstream message, [Service Name] + "Request" is set, the message name of output is the message name of the downstream message structure, and "impl:" + [message definition Response message name set in is set. The data name of output is the data name of the downlink message structure, and [service name] + "Response" is set.

  An example of the WSDL port type definition generated by the generation unit 29 is shown below.

<WSDL: portType name = "PT01Server">
<WSDL: operation name = "TRDOperation" parameterOrder = "o3wheadbean trl_a1bean">
<WSDL: input message = "impl: PT01Request" name = "PT01Request"/>
<WSDL: output message = "impl: PT01Response" name = "PT01Response"/>
</ WSDL: operation>
</ WSDL: portType>
Then, the generation unit 29 generates a WSDL binding definition based on the port type definition and the WSDL naming rule generated in S18 (S19).

  FIG. 15 shows an example of a WSDL naming rule related to the binding definition and service definition stored in the storage unit. As shown in FIG. 15, the binding definition includes a binding name, a binding type, transport, soapAction, a binding style, an operation name, and an input data name (input name). ), Input encoding specification (use), input encoding format (encodingStyle), input namespace (namespace), output data name (output name), output encoding specification (use), output encoding format (encodingStyle) , And output namespace.

  [Service name] + “SoapBinding” is set as the binding name, and “impl:” + [port type name set in the portType definition] is set as the binding type. In transport, a fixed value (for example, http://schemas.xmlsoap.org/soap/http) indicating the protocol to be used is set. A fixed value indicating the value of the SOAPAction header is set in soapAction, and a fixed value (for example, rpc) is set in the binding style. As the operation name, [operation name set in the portType definition] is set.

  The input data name indicates the data name of the upstream message, and [Request message name set in the portType definition] is set. As the input encoding designation, a fixed value (for example, use = "encoded") indicating the encoding designation of the upstream telegram is set. As the input encoding format, a fixed value (for example, http://schemas.xmlsoap.org/soap/encoding/) indicating the encoding format of the upstream message is set. The input name space is the name space of the upstream message, and [service name] is set.

  The data name of output indicates the data name of the downlink message structure, and [Response message name set in the portType definition] is set. In the output encoding specification, a fixed value (for example, use = "encoded") indicating the encoding specification of the downlink message structure is set. As the output encoding format, a fixed value (for example, http://schemas.xmlsoap.org/soap/encoding/) indicating the encoding format of the downlink message structure is set. The name space of output is the name space of the downlink message structure, and [service name] is set.

  An example of the WSDL port type definition generated by the generation unit 29 is shown below.

<WSDL: binding name = "PLTr_A1SoapBinding" type = "impl: PT01Server">
<WSDLsoap: binding style = "rpc" transport = "http://schemas.xmlsoap.org/soap/http"/>
<WSDL: operation name = "TRDOperation">
<WSDLsoap: operation soapAction = ""/>
<WSDL: input name = "PT01Request">
<WSDLsoap: body encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/" namespace = "PLTr_A1" use = "encoded"/>
</ WSDL: input>
<WSDL: output name = "PT01Response">
<WSDLsoap: body encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/" namespace = "PLTr_A1" use = "encoded"/>
</ WSDL: output>
</ WSDL: operation>
</ WSDL: binding>
Then, the generation unit 29 generates a WSDL service definition based on the binding definition and the WSDL naming rule generated in S19 (S20).

  As shown in FIG. 15, the service definition includes a service name (service name), a binding name (port binding), a port name (port name), and an endpoint URL (address location).

  [Service name] + ServerService is set as the service name, and "impl:" + [binding name set in the binding definition] is set as the binding name. [Service name] is set as the port name, and the endpoint URL indicates the destination at the time of access, and is http: // server address / context route / [service name].

  An example of the WSDL port type definition generated by the generation unit 29 is shown below.

<WSDL: service name = "PT01ServerService">
<WSDL: port binding = "impl: PT01SoapBinding" name = "PT01">
<WSDLsoap: address location = "http: // localhost: 8090 / axis / services / PT01"/>
</ WSDL: port>
</ WSDL: service>
The generation unit 29 uses the WSDL file composed of the definitions definition, type definition, message definition, port type definition, binding definition, and service definition generated in S15 to S20, and the WSDL file input in S12 as WSDL generation information. Output to the output destination directory (S21).

<Generation of service call definition file>
Next, generation of the service call definition file 31 will be described.

  The generation unit 29 generates a service call definition file 31 (see FIG. 4) based on the generated WSDL. That is, the generation unit 29 inputs WSDL and generates a service call definition file 31 corresponding to the WSDL using a generation tool (for example, WSDL2Java) provided by the SOAP engine. The generation tool is a tool for generating a Java (registered trademark) workpiece from WSDL. The generation unit 29 generates a service call definition file 31 by processing and editing the input WSDL according to a predetermined condition using a generation tool. In this embodiment, the call method name of the service call definition file 31 is generated not to be a service name but to a fixed value (TRDOperation). Thereby, in this embodiment, a plurality of services can be executed in a general-purpose service class.

<Generation of JavaBeans>
Next, generation of JavaBeans 32 will be described.

  The generation unit 29 generates JavaBeans 32 that is a data holding component used in the execution environment based on the generated WSDL. That is, the generation unit 29 inputs WSDL, and generates JavaBeans of a middle header, an upstream message, and a downstream message used in the WSDL by using the generation tool (for example, WSDL2Java). FIG. 16 shows an example of JavaBeans in the middle header.

<Service endpoint generation>
Next, generation of the service endpoint 23 will be described.

  The generation unit 29 receives an input of a service name as an argument, refers to a naming rule for the service endpoint, and generates a service endpoint with the input service name. FIG. 17 shows an example of a service endpoint whose service name is “BEsearch”. Since it is necessary to provide a service endpoint for each service as shown in FIG. 1, the generation unit 29 generates each service endpoint for all services.

  According to the present embodiment described above, an existing business system can be provided to a client as a Web service more easily without changing the existing business system.

  In other words, the Web service infrastructure system of the present embodiment converts the request message sent from the client into a data format that can be processed by the business system and sends it to the business system, and the client can process the processing result of the business system Is converted to a response message in a simple data format and sent to the requesting client. In other words, the Web service infrastructure system is activated by a request message from the client, and the transaction of the business system is called to absorb the difference in data format without changing the existing business system, making the existing business system easier. Therefore, it can be provided to the client as a Web service more speedily.

  In this embodiment, WSDL used by the client is automatically generated based on the transaction call definition file, data conversion definition file, and message definition file used in the execution environment. This eliminates the need for complicated and error-prone WSDL coding and improves development productivity. In the present embodiment, since service endpoints, JavaBeans, and service call definition files used in the execution environment of the Web service infrastructure system are also automatically generated, the workload of the system developer can be reduced.

  In the present embodiment, the interoperability with an existing business system can be further improved by using a document-centric Web system with WSDL as a connection specification. In the present embodiment, interoperability and portability as a Web service can be improved by supporting the standard specification of the Web service.

  In addition, this invention is not limited to said embodiment, Many deformation | transformation are possible within the range of the summary.

  1: Client, 11: WSDL, 12: Stub, 13: Application, 2: Web service infrastructure system, 21: Web application unit, 22: SOAP engine, 23: Service endpoint, 24: Service class, 25: Web service provider Part: 26: data conversion part, 27: transaction call part, 28: connection part, 29: generation part, 31: service call definition file, 32: JavaBeans, 33: transaction call definition file, 34: data conversion definition file, 35 : Message definition file, 36: data storage unit, 7: first business system, 8: second business system

Claims (3)

A web service infrastructure system that provides a client with processing performed by a business system as a web service,
Communication processing means for transmitting and receiving messages to and from the client according to a predetermined communication protocol;
A plurality of service endpoints provided for each Web service;
A web service providing means common to all web services,
The communication processing means sends a service request from the client to the Web service providing means via a Web service service endpoint specified in the service request,
The Web service providing means converts the service request into a data format that can be processed by the business system, sends the data to a business system corresponding to the Web service specified by the service request, and the processing result of the business system Is converted into a data format that can be processed by the communication processing means, and sent to the communication processing means via the service endpoint for the Web service,
For each Web service, a data holding component for transmitting and receiving data between the communication processing unit and the Web service providing unit, and call destination information indicating the Web service providing unit as a call destination of a service endpoint are set. Service call definition file,
A transaction definition file storing Web services and business system transactions in association with each other;
For each transaction, a data conversion definition file storing the data layout ID of the data layout of the message used in the transaction,
A layout definition file in which a data layout is stored for each data layout ID;
The communication processing means identifies a data holding component set in a service call definition file corresponding to the Web service specified by the service request, stores the service request data in the data holding component, and stores the service end data Send to point,
The service endpoint sends the data holding component received from the communication processing means to the Web service providing means based on call destination information set in the service call definition file,
The web service providing means includes:
Referring to the transaction definition file, specify a transaction corresponding to the Web service specified in the service request,
A business system that reads the data layout corresponding to the identified transaction with reference to the data conversion definition file and the layout definition file, converts data of the data holding component received from the service endpoint according to the read data layout, and A Web service infrastructure system that transmits the specified transaction to the specified transaction . The web service infrastructure system according to claim 1 ,
A Web service infrastructure system, further comprising: generating means for generating WSDL of a predetermined Web service used by the client using the transaction definition file, the data conversion definition file, and the layout definition file. A web service infrastructure system according to claim 2 ,
The generation unit generates a service call definition file and a data holding component for the predetermined Web service by using the WSDL of the generated predetermined Web service.

Images