JP4701040B2 - Communication apparatus and message transmission method in the apparatus - Google Patents

Description

The present invention relates to a message transmission method in a communication instrumentation 置及 beauty the apparatus for transmitting and receiving messages structured text format via a network such as the Internet.

  In recent years, with the spread of the Internet, Web services on a network are frequently used from computers and digital devices. A Web service is a software component that is released on a network with open specifications. In general, messages transmitted and received between computers, digital devices, and Web services often use XML protocols such as SOAP whose specifications have been formulated by the W3C (World Wide Web Consortium), an Internet technology standardization organization. . Here, the XML protocol is a communication protocol that describes communication contents using XML, which is a markup language whose specifications are defined by the W3C.

  XML is a language for describing structured data in a text format. For this reason, when XML format messages are transmitted and received using only the XML protocol specifications, binary format content data such as image files linked and referenced from XML format messages cannot be transmitted in binary format. In order to solve this problem, W3C, which is a standardization organization, in addition to the specifications of SOAP itself, binary messages such as images are used for messages transmitted and received by SOAP such as SWA (SOAP Messages with Attachments) and MTOM (SOAP Message Transmission Optimization Mechanism). Several specifications are specified for attaching content data in the format. In addition, Microsoft and IBM have once submitted WSA (WS-Attachments), which is an original attachment method, as a draft specification of the IETF, which is a standardization organization.

  Since the specifications for attaching a file to a message transmitted and received XML protocol there exist a plurality of at the moment when the application is to attach a content data to a message, which transmission side, the receiving application program in advance You need to know if you should use the attachment method.

WS-I, which is a standardization organization that aims to improve interoperability between Web services, describes an example using W3C SWA (SOAP Messages with Attachments) as an attachment method with the specification of Attachment Profile 1.0. . Here, in the interface definition document described in the interface definition language (WSDL) between Web services, which parameter constituting the message refers to the content data attached by the SWA method, A method of expressing with the parameter data type swaRef has been proposed. Thereby, it is possible to develop an application on the transmission side and the reception side with reference to the interface definition document, and to correctly transmit and receive a message using the SWA method using the application. Note that the sender and receiver applications that exchange messages using the XML protocol generally do not refer directly to the interface description, but generate software components for message interpretation called stubs from the interface description by the application development tool. In many cases, messages are generated according to the interface definition by using them from an application program and interpreted. The following patent document 1 exists as a prior art using WSDL.
JP 2004-341734 A

  The Attachment Profile 1.0 specification described above describes how to define an interface when an attachment method called SWA is adopted. As a result, the application development tool can generate stubs for applications on the transmission side and reception side corresponding to the SWA method. However, when the receiving side uses an attachment method other than SWA, or the receiving side can accept a plurality of attachment methods, the above interface definition method cannot be described uniformly. Therefore, in order to generate a stub, an application developer has to perform an inefficient process of referring to an interface definition document corresponding to each attachment method and generating a stub corresponding to each attachment method. . In addition, interface description documents corresponding to each type of attachment method must be stored in the memories of the transmission side device and the reception side device, which is not efficient in terms of memory capacity.

  Also, in the above-mentioned Attachment Profile 1.0 specification, sending and receiving messages with binary content data attached is not logically described in the message format definition in the interface definition. In the above Attachment Profile 1.0 specification, it is necessary to describe the message format specifically for the attachment method called SWA. Therefore, when it is necessary to make the content data attachment method compatible with the new method, such as Web service version upgrade, the description of the logical message format that is not originally based on the protocol is greatly changed to the description according to the new attachment method. It is necessary to rewrite.

  The present invention is to solve the above-mentioned drawbacks of the prior art.

Further features of the present invention is to provide a message transmission method to the accompanying method of the content data, in the communication instrumentation 置及 beauty the device can be specified by selecting one of a plurality of attachment method.

A communication apparatus according to one aspect of the present invention has the following configuration. That is,
As a message to be transmitted and received by the communication instrumentation 置間 connected via a network, a communication device for generating a structured document in a text format with attached content data in binary form,
A web service interface definition between a communication device on a transmission side and a reception side, and an abstract data type description indicating a plurality of types of data types indicating attachment methods of content data that can be attached to the structured document, and the message Storage means for storing interface definitions having descriptions of parameters constituting
A determination unit for determining an attachment method that can be supported by the communication device on the transmission side, among attachment methods corresponding to the data type described in the interface definition ;
Code generating means for generating a code for attaching content data in binary format according to the attachment method determined by the determining means , using a description of parameters constituting the message ;
Message generating means for generating a message attached with the binary content data based on the code generated by the code generating means;
Transmitting means for transmitting a message to which the binary format content data generated by the message generating means is attached .

A message transmission method for a communication apparatus according to an aspect of the present invention includes the following steps . That is,
As a message to be transmitted and received by the communication instrumentation 置間 connected via a network, a message transmission method for a communication apparatus for generating a structured document in a text format with attached content data in binary form,
A web service interface definition between a communication device on a transmission side and a reception side, and an abstract data type description indicating a plurality of types of data types indicating attachment methods of content data that can be attached to the structured document, and the message A reference step for referencing an interface definition having a description of parameters comprising
A determination step of determining an attachment method that can be supported by the communication device on the transmission side, among attachment methods corresponding to the data type described in the interface definition;
A code generation step of generating a code for attaching content data in binary format according to the attachment method determined in the determination step, using a description of parameters constituting the message;
A message generation step of generating a message attached with the content data in the binary format based on the code generated by the code generation step;
And a transmission step of transmitting a message to which the binary format content data generated by the message generation step is attached .

  The summary of the present invention does not list all necessary features. Also, a sub-combination of these feature groups can be an invention.

  According to the present invention, there is an effect that a method for attaching content data can be selected and specified from a plurality of attachment methods.

  Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. The following embodiments do not limit the invention according to the claims, and all the combinations of features described in the embodiments are not necessarily essential to the solution means of the invention. .

[Embodiment 1]
FIG. 1 is a diagram illustrating a configuration example of a communication system according to Embodiment 1 of the present invention.

  The network 140 is connected to a message transmission side device (hereinafter referred to as a transmission device) 100 and a message reception side device 120 (hereinafter referred to as a reception device). The transmission device 100 and the reception device 120 transmit and receive messages via the network 140 using SOAP, which is one of XML protocols. Here, as a general transmission apparatus 100 and reception apparatus 120, a personal computer, a server computer, a digital device, etc. can be considered. In this embodiment, only one transmitting device and one receiving device are described, but a plurality of devices may exist.

  The transmission device 100 and the reception device 120 are connected to external storage devices 110 and 130 for storing binary content data such as text data and image data attached to a message, respectively. In the present embodiment, the content data is described as a file. However, the content data may be data expanded on a memory, or may be on a Web server or storage server via a network. As an alternative to the external storage devices 110 and 130, the transmission device 100 and the reception device 120 may incorporate a memory. The “stub” described in the present embodiment refers to a program that interprets a message to be transmitted / received and delivers data to the transmission / reception device application.

  Next, a functional configuration of the transmission apparatus 100 that is a communication apparatus will be described.

  The transmission apparatus 100 includes a transmission-side application 101 that issues a transmission request for a file that stores XML-format application data and binary-format content data that is linked and referenced via the network 140. Furthermore, the transmission apparatus 100 includes a transmission side stub 102 that generates a transmission message in a multipart format such as multipart MIME or DIME from application data in response to a request from the transmission side application 101. Further, the transmission device 100 includes an attached file reading unit 103 that is called from the transmission side stub 102, searches for a description in the application data, and reads a file that needs to be attached. Furthermore, the transmission device 100 includes a message transmission unit 104 that transmits the message created by the transmission side stub 102 to the reception device 120 via the network 140.

  Next, the functional configuration of the receiving device 120 that is a communication device will be described.

  The reception device 120 includes a message reception unit 124 that receives a multipart message such as multipart MIME or DIME received from the transmission device 100 via the network 140. In addition, the receiving device 120 analyzes the message received by the message receiving unit 124, breaks it into a plurality of parts, and performs processing for storing the content data part in the external storage device 130 by the attached file writing unit 123. 122. In addition, the receiving device 120 includes a receiving-side application 121 to which application data extracted from the message by the receiving-side stub 122 is transferred. In FIG. 1 and the drawings shown below, the units that execute each function are realized by software in this embodiment, but these units may be configured by hardware employing a dedicated LSI or the like. good.

  For simplification of explanation, the transmission device 100 and the reception device 120 have been described separately as described above. However, the transmission device 100 and the reception device 120 actually use the reception device 100 and the transmission device 120, respectively.

  Next, a configuration example of the application development apparatus according to the present embodiment will be described using FIG. This application development apparatus is an apparatus for developing an application executed by the transmission apparatus 100 and the reception apparatus 120 described above. Note that the transmission device 100 and the reception device 120 may also function as the application development device. In this case, the interface definition 221 is stored in the external storage devices 100 and 130.

  FIG. 2 is a functional block diagram illustrating a functional configuration of the application development apparatus 210 according to the first embodiment. In FIG. 2, the units that execute the respective functions are realized by software in the present embodiment, but these units may be configured by hardware employing a dedicated LSI or the like.

  The application development device 210 is connected to an external storage device 220 that stores an interface definition 221 that is a document describing the definition of the configuration of messages that are transmitted and received between the transmission device 100 and the reception device 120. In this embodiment, the interface definition 221 is described as a file, but it may be data expanded on a memory. The interface definition 221 may be on a Web server or storage server via a network.

  Next, the functional configuration of the application development apparatus 210 will be described. The interface definition reading unit 212 reads the interface definition 221 stored in the external storage device 220 in response to a request from the stub generation unit 213 that generates software for interpreting a message called a stub from a document describing the interface definition. The data type definition analysis unit 214 extracts an abstract data type definition representing the binary attachment method from the data type definition unit of the interface definition 221 read by the interface definition reading unit 212. Then, the data type definition analyzing unit 214 analyzes which data type the abstract data type is derived from. The attachment method determination unit 211 is used by the transmission side and reception side stubs 102 and 122 from the combined data type name analyzed by the data type definition analysis unit 214 and the contents of the data type / attachment method correspondence table 215. Determine the attachment method of content data in binary format.

  Next, generation processing of the transmission-side stub 102 in the application development apparatus 210 according to the present embodiment as a structured document generation apparatus will be described with reference to FIGS.

  FIG. 3 is a flowchart for explaining a control procedure when the transmission side stub 102 is generated by the application development apparatus 210 according to the first embodiment of the present invention.

  When the stub generation unit 213 detects an instruction to generate the transmission-side stub 102 in response to a request from an application developer or the like, first, in step S301, the interface definition reading unit 212 reads the interface definition 221 from the external storage device 220.

  FIG. 7 is a diagram illustrating an example of an interface definition of a web service described in WSDL.

  In step S302, the interface definition reading unit 212 refers to the data type definition unit 700 (FIG. 7) in the interface definition 221 and refers to an abstract data type (“702” shown in FIG. Determine whether "binaryRef" type) is defined. If it has been defined, the process proceeds to step S303, and the attachment method determination unit 211 extracts from the definition of the data type definition unit 700 what kind of data type the abstract data type (binaryRef type) is derived from. To list the data type names. If the data type indicating the attachment destination is not defined in step S302, the attachment method determination unit 211 determines that the message does not include binary format content data, and skips to step S308.

  In the example of FIG. 7, as indicated by a description 707, the binaryRef type is a data type (swaRef type) 703 used to refer to content data in the SWA method, and data used to refer to content data in the WSA method. It is described as an abstract type combining a type (wsaRef type) 704 and a data type (mtomRef type) 705 used to refer to content data in the MTOM method.

  In step S303, the attachment method determination unit 211 creates a list of data types corresponding to the attachment method. In the example of FIG. 7, a data type (swaRef type) 703 that refers to content data in the SWA method, a data type (wsaRef type) 704 that refers to content data in the WSA method, and a data type (mtomRef) that refers to content data in the MTOM method Type) 705 is listed. Next, in step S304, referring to the data type / attachment method correspondence table 215, the attachment method corresponding to each data type listed in step S303 is specified. Next, in step S305, when it is not the last data type of the list, the process proceeds to step S306, and it is determined whether or not the transmission apparatus 100 supports this attachment method in order from the front of the list. When it corresponds here, it progresses to Step S307, but when it does not correspond, it returns to Step S304.

  FIG. 9 is a diagram showing an example of the data type / attachment method correspondence table 215 according to the present embodiment.

  In FIG. 9, the data type name and the attachment method are registered for the data type name space URI (703 to 705 in FIG. 7). By referring to the data type / attachment method correspondence table 215, it is determined that the swaRef type, the wsaRef type, and the mtomRef type representing the data attachment method correspond to the SWA method, the WSA method, and the MTOM method.

  Note that, in step S306 described above, the criterion for determining whether or not the transmission device 100 supports the attachment method is that the transmission device 100 previously corresponds to the operating environment definition file stored in the stub generation unit 213. Describe information about the attachment method. Information on the attachment method supported by the transmission apparatus 100 is updated every time the transmission apparatus 100 becomes compatible with a new attachment method due to version upgrade. If the attachment method listed in step S306 is supported by the transmission apparatus 100 in this way, the process advances to step S307, and the attachment method determination unit 211 attaches the attachment method adopted by the transmission side stub 102 to be generated. Decide on a method. In consideration of the case where there are a plurality of attachment methods that can be supported by the transmission apparatus 100, the order in which the data type is described in the data type definition unit 700 is described in the order of priority that the developer wants to generate, and the attachment that can be supported. A mode in which the attachment method corresponding to the data type described first is selected from the methods is also conceivable. In this case, the transmission side stubs in the respective transmission devices 100 can be further unified.

  In step S308, the stub generation unit 213 extracts the next parameter constituting the message from the message configuration definition unit (710 in FIG. 7) of the interface definition 221. In the example of FIG. 7, the parameter “type = types: binaryRef” is specified as “ImgaeRef” of “PutImage”, and it is understood that the attachment file can be defined by this parameter. If the parameter can be extracted in step S309, the process proceeds to step S310. In step S310, it is checked whether or not the data type of the parameter is a data type representing an attachment destination reference. If so, the process proceeds to step S311 (defined in 702 and 707 in FIG. 7). In step S311, according to the attachment method determined in step S307, a code for attaching content data in binary format as one part of the multipart transmission message is generated. Generate and return to step S308. If it is determined in step S310 that the data type of the parameter is not a data type representing an attachment destination reference, the process advances to step S312 to generate the transmission-side stub 102 using other definition information of the interface definition 221 and returns to step S308.

  If it is determined in step S305 that there is no attachment method that the transmission apparatus 100 can handle, the process proceeds to step S313, and the generation of the transmission stub 102 is stopped. In step S309, when there are no more parameters, this process is terminated.

  In this way, the transmission-side stub 102 of the transmission device 100 can be generated.

  Next, using FIG. 4 and FIG. 7, the flow of processing for generating the reception-side stub 122 in the application development apparatus 210 according to the first embodiment will be described.

  FIG. 4 is a flowchart for explaining generation of the reception-side stub 122 in the application development apparatus 210 according to the first embodiment.

  When the stub generation unit 213 detects an instruction to generate the reception-side stub 122 according to a request from an application developer or the like, first, in step S401, the interface definition reading unit 212 is used to retrieve the interface definition 221 from the external storage device 220. Read.

  In step S402, the interface definition reading unit 212 refers to the data type definition unit 700 of the interface definition 221, and determines whether or not the data type (binaryRef type in FIG. 7) representing the attachment destination reference is defined. If it has been defined, the process advances to step S403, and the data type definition unit analysis unit 214 combines the data type defined by the data type definition unit 700 with the abstract data type (binaryRef type) representing the attachment destination reference. Extract the data type name and list it. Then, the attachment method determination unit 211 refers to this list and refers to the data type / attachment method correspondence table 215 to determine which attachment method the data type name corresponds to.

  In the example of FIG. 7, the binaryRef type 702 is a data type (swaRef type) 703 used to refer to binary format content data in the SWA format, and data used to refer to binary format content data in the WSA format. This type is a combination of a type (wsaRef type) 704 and a data type (mtomRef type) 705 used for referring to binary content data in the MTOM method. If the data type representing the attachment destination reference is not defined in step S402, it is determined that the binary content data is a message not attached, and the process of step S403 is omitted, and the process proceeds to step S404.

  Next, in step S <b> 404, the stub generation unit 213 extracts parameters constituting the message from the message configuration definition unit 700 of the interface definition 221. If it is determined in step S405 that the parameter is not the last parameter, the process advances to step S406 to determine whether the data type of the parameter is data representing attachment destination reference. If the parameter is a data type representing an attachment destination reference, the process proceeds to step S407. In step S407, processing for generating the receiving stub 122 according to the attachment method is performed, such as generating a code for passing the content data stored in one part of the multipart received message to the application as attachment data. The process returns to step S405.

  On the other hand, if it is determined in step S406 that the parameter is not a data type representing an attachment destination reference, the process proceeds to step S408, the reception side stub 122 is generated using other definition information of the interface definition, and the process returns to step S405.

  Note that the generated receiving side stub 122 must include codes according to all attached methods (SWA method, WSA method, MTOM method) described in the interface definition 221 as much as possible. This is different from the generation of the stub 102. That is, the receiving-side stub 122 includes codes according to all attachment methods supported by the receiving device 120 described in the operation environment definition file stored in the stub generating unit 213.

  Next, with reference to FIG. 5 and FIG. 8, a flow of processing indicating how a message is generated and transmitted by the transmission apparatus 100 according to the present embodiment will be described.

  FIG. 5 is a flowchart for explaining processing in transmitting apparatus 100 according to the first embodiment.

  When sending a message to the receiving device 120, the sending-side application 101 of the sending device 100 first notifies the parameter name and parameter value constituting the specified message to the sending-side stub 102 in step S501. In particular, when a binary file is attached to a message, a path name of the attached file and a parameter name for storing the reference destination are simultaneously specified to the transmission side stub 102 (S502).

  Upon receiving this transmission request, the transmission-side stub 102 uses the attached file reading unit 103 to read a file having the designated path name, and generates an attached part of the transmission message. A transmission message is created in accordance with the attachment method specified when the message attachment portion is generated by the transmission side stub 102. At this time, the data type corresponding to the attachment method is described as the attribute of the parameter for storing the reference destination of the attached data (step S503).

  FIG. 8 is a diagram showing an example of the transmission message created in this way.

  In the example of FIG. 8, the data type for storing the reference destination in the SWA attachment method is specified as the parameter (ImageRef) for storing the reference destination of the attached binary format content data (image0001@example.com) (xsi: type = "types: swaRef) (801).

  As described above, in step S503, the transmission-side stub 102 generates a message according to the attachment method, and then proceeds to step S504. The transmission side stub 102 makes a transmission request to the message transmission unit 104. In response to the transmission request, the message transmission unit 104 transmits a message to the reception device 120 via the network 140 in step S505.

  Next, the flow of processing indicating how messages are received and analyzed by the receiving apparatus 120 according to the first embodiment will be described with reference to FIGS. 6 and 8.

  FIG. 6 is a flowchart for explaining processing in receiving apparatus 120 according to the first embodiment.

  First, in step S <b> 601, when the message receiving unit 124 of the receiving device 120 receives a message transmitted from the transmitting device 100, the message receiving unit 124 notifies the receiving stub 122 of the received message content. Next, in step S602, the receiving stub 122 extracts a parameter (xsi: type = "types: swaRef) from the non-attached part of the received message.Next, in step S603, if there is a parameter to be extracted. In step S604, the reception-side stub 122 determines whether a data type representing a reference destination of attached data is added to the extracted parameter as an attribute, and if it is added as an attribute, the process proceeds to step S605. Then, it is checked whether or not the attachment method is described in the interface definition 221. If the attachment method is described in the interface definition 221, the process proceeds to step S608, and in step S608, the attachment corresponding to the designated data type is performed. The message indicated by the parameter value according to the method (SWA method in the example of FIG. 8) An attached file (“image0001@example.com” in the example of FIG. 8) as binary content data is extracted from the attached portion. In step S609, the file is stored in the external storage device 130 using the attached file writing unit 123. Thereafter, in step S610, the receiving-side stub 122 saves, sets the save destination path name as the parameter value, and returns to step S602.

  FIG. 8 is a diagram illustrating an example of a message received by the receiving device 120.

  In the example of FIG. 8, the data type for storing the reference destination in the SWA attachment method is specified as an attribute (xsi: type = "types: swaRef) in the parameter (ImageRef) for storing the reference destination of the attached data. Accordingly, it can be seen from the data type / attachment method correspondence table 215 shown in Fig. 9 that the template method is the "SWA method".

  On the other hand, if the data type representing the reference destination of the binary-format content data attached to the parameter is not designated as an attribute in step S604, the process proceeds to step S611. In step S611, the receiving stub 122 extracts the parameter value from the non-attached part of the message, and returns to step S602.

  When all parameters and parameter values are extracted in step S603, the process proceeds to step S606, and the receiving stub 122 passes them to the receiving application 121.

  If a received data reference data type other than that described in the interface definition 221 is specified in the received message in step S605, the process proceeds to step S607. In step S607, the receiving side stub 122 notifies the application 121 of an error as an invalid message. For example, if any of swaRef, wsaRef, and mtomRef is defined in the interface definition as in the example of Fig. 8, the message is processed as correct and an error occurs if any other data type is specified. It becomes.

  As described above, according to the first embodiment, it is possible to specify an attachment method for content data in a binary format exchanged with a Web service by simply referring to one interface definition.

  In addition, the receiving device that has received this message can identify and process which content data attachment method is used with reference to the data type specified by “xsi: type”.

[Embodiment 2]
Next, the configuration of the second embodiment of the present invention will be described.

  FIG. 10 is a block diagram showing a configuration of a communication system according to Embodiment 2 of the present invention. The configuration of the message transmission side device (hereinafter referred to as a transmission device) 1000 and the message reception side device (hereinafter referred to as a reception device) 1010 according to the second embodiment is the same as that of the transmission device 100 and the reception device 120 according to the first embodiment. Since this is the same, the description thereof is omitted. In the second embodiment, a transmission apparatus 1000 and a reception apparatus 1010 are connected to a network 1100, and a message relay apparatus 1020 is connected to the network 1010 in addition to these apparatuses. The point that the message transmitted from the transmitting apparatus 1000 is transmitted to the receiving apparatus 1010 via the message relay apparatus 1020 is different from the first embodiment.

  The message relay apparatus 1020 is equipped with a message conversion unit 1023 for converting messages with different data attachment methods. As a result, even if the data attachment method supported by each of the message transmission side device 1000 and the message reception side device 1010 is different, by transmitting a message via the message relay device 1020, an appropriate Conversion of the data attachment method can be performed. In the following description of the second embodiment, a case is described in which the transmission apparatus 1000 and the reception apparatus 1010 are connected to the network one by one.

  The message receiving unit 1021 of the message relay apparatus 1020 receives a message to which content data in binary format as shown in FIG. 8 is attached from the transmission apparatus 1000 via the network 1100, for example. The message reception unit 1021 passes the received message to the message conversion unit 1023. Thereby, the message conversion unit 1023 determines whether or not a data type (for example, “xsi: type = types: swaRef” in FIG. 8) indicating the attachment method of the message is specified for the received message. Then, when specified, the message conversion unit 1023 refers to the data type / attachment method correspondence table 1027 and determines which attachment method the message has been sent to.

  The data structure of the data type / attachment method correspondence table 1027 according to the second embodiment is the same as the data structure shown in FIG.

  Thereafter, the message conversion unit 1023 derives from the data type definition unit analysis unit 1024 the abstract data type representing the data attachment method described in the interface definition 1028 of the receiving apparatus 1010 by combining any types. Ask if they are. The data type definition unit analysis unit 1024 searches from the description of the operating environment definition file stored in the reception device 1010 what data type the abstract data type representing the data attachment method is derived from. Then, the data type definition unit analysis unit 1024 returns the search result data type list to the message conversion unit 1023 as an inquiry result.

  Assume that the interface definition 1028 of the receiving apparatus 1010 according to the second embodiment is the same as that in FIG. 7 according to the first embodiment.

  In FIG. 7, the abstract data type representing the data attachment method is a binaryRef type. It is described that the binaryRef type is defined by derivation by combining the swaRef type, the wsaRef type, and the mtomRef type. Therefore, the data type definition unit interpretation unit 1024 returns these three data type names to the message conversion unit 1023. Through these processes, the message conversion unit 1023 can obtain a list of attachment methods supported by the receiving apparatus 1010 from the returned data type name and the data type attachment method correspondence table 1027.

  Referring to the data type / attachment method correspondence table 1027 shown in FIG. 9, the data types “swaRef type”, “wsaRef type”, and “mtomRef type” are the data attachment methods “SwA method”, “WSA method”, It can be determined that it corresponds to the “MTOM method”.

  Therefore, the message conversion unit 1023 can determine which data attachment method the transmission device 1000 has sent a message and which data attachment method the reception device 1010 supports. Therefore, the message conversion unit 1023 can determine from the data attachment method conversion table 1026 which conversion method can be used to appropriately convert the received message into an attached format supported by the receiving apparatus 1010.

  FIG. 11 is a diagram showing a data example of the data attachment method conversion table 1026 according to the second embodiment.

  In this example, when the received data attachment method is the SWA method and the transmission data attachment method is the MTOM method, it can be seen that the method name used for message conversion is “SwAtoMTOM ()”.

  Through the above processing, the message conversion unit 1023 selects an appropriate method, converts a message with a different attachment method received from the transmission apparatus 1000 into a message with an appropriate attachment method supported by the reception apparatus 1010. Can be transferred.

  Note that, depending on the combination of attachment methods, there may be no method for converting the reception device 1010 into a corresponding attachment method. In this case, the message relay apparatus 1020 performs appropriate error processing such as returning a message conversion failure message to the transmission apparatus 1000.

  As described above, according to the present embodiment, it is possible to use a web service that uses a plurality of attachment methods only by referring to one interface definition in a plurality of transmission / reception apparatuses connected via a network. As a result, it is possible to generate the transmission and reception side stubs without referring to the individual interface definitions according to the respective attachment methods, thereby improving the development efficiency of the application.

  In addition, it is possible to efficiently update the interface definition itself that occurs when the application supports a new attachment method.

  In the present invention, a software program that realizes the functions of the above-described embodiments is supplied directly or remotely to a system or apparatus, and the computer of the system or apparatus reads and executes the supplied program code. In some cases, it can be achieved by In that case, as long as it has the function of a program, the form does not need to be a program. Accordingly, since the functions of the present invention are implemented by computer, the program code installed in the computer also implements the present invention. That is, the present invention includes a computer program itself for realizing the functional processing of the present invention. In this case, the program may be in any form as long as it has a program function, such as an object code, a program executed by an interpreter, or script data supplied to the OS.

  As a storage medium for supplying the program, for example, floppy (registered trademark) disk, hard disk, optical disk, magneto-optical disk, MO, CD-ROM, CD-R, CD-RW, magnetic tape, nonvolatile memory card ROM, DVD (DVD-ROM, DVD-R) and the like. As another program supply method, a client computer browser is used to connect to an Internet homepage, and the computer program itself of the present invention or a compressed file including an automatic installation function is downloaded from the homepage to a storage medium such as a hard disk. Can also be supplied. It can also be realized by dividing the program code constituting the program of the present invention into a plurality of files and downloading each file from a different homepage. That is, a WWW server that allows a plurality of users to download a program file for realizing the functional processing of the present invention on a computer is also included in the claims of the present invention.

  In addition, the program of the present invention is encrypted, stored in a storage medium such as a CD-ROM, distributed to users, and key information for decryption is downloaded from a homepage via the Internet to users who satisfy predetermined conditions. It is also possible to execute the encrypted program by using the key information and install the program on a computer.

  In addition to the functions of the above-described embodiments being realized by the computer executing the read program, the OS running on the computer based on the instruction of the program may be part of the actual processing or The functions of the above-described embodiment can also be realized by performing all of the above processing.

  Furthermore, after the program read from the recording medium is written in a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, the function expansion board or The CPU or the like provided in the function expansion unit performs part or all of the actual processing, and the functions of the above-described embodiments are realized by the processing.

  FIG. 12 is a block diagram illustrating an example of a hardware configuration of the transmission apparatuses 100 and 1000, the reception apparatuses 120 and 1010, the relay apparatus 1020, and the application development apparatus 210 described above.

  In FIG. 12, a CPU 1201 reads out and executes a predetermined program from the ROM 1203 to implement various processes in order to perform overall control of each unit of the apparatus. The RAM 1202 provides a work area necessary for processing by a program. The ROM 1203 stores a program for executing the present embodiment and interface definition information of a web service to be referenced. The input unit 204 includes a keyboard, a mouse, and the like. The secondary storage unit 1205 includes a hard disk built in the apparatus or a non-volatile removable memory card and a storage control unit for reading or writing data. The secondary storage unit 1205 stores not only various types of information but also stubs generated by referring to the web service interface definition. The display unit 1206 displays various data. An I / F (interface) 1207 transmits and receives messages to and from an external device via the Internet or the like.

It is a figure which shows the structural example of the communication system which concerns on Embodiment 1 of this invention. It is a functional block diagram explaining the function structure of the application development apparatus which concerns on this Embodiment 1. FIG. It is a flowchart explaining the control procedure at the time of producing | generating a transmission side stub with the application development apparatus which concerns on Embodiment 1 of this invention. 10 is a flowchart for explaining generation of a reception-side stub in the application development apparatus according to the first embodiment. 6 is a flowchart for describing processing in the transmission apparatus according to the first embodiment. 6 is a flowchart for explaining processing in the receiving apparatus according to the first embodiment. It is a figure explaining an example of the interface definition described by WSDL. It is a figure which shows an example of the message format transmitted to the receiving device from the transmitter in Embodiment 1, 2 of this invention. It is a figure which shows an example of the data type and attachment system corresponding | compatible table which concerns on this Embodiment 1,2. It is a block diagram which shows the structure of the communication system which concerns on Embodiment 2 of this invention. It is a figure which shows the example of data of the data attachment system conversion table which concerns on this Embodiment 2. FIG. It is a block diagram which shows an example of the hardware constitutions of each apparatus which concerns on this Embodiment.

Claims (8)

As a message to be transmitted and received by the communication instrumentation 置間 connected via a network, a communication device for generating a structured document in a text format with attached content data in binary form,
A web service interface definition between a communication device on a transmission side and a reception side, and an abstract data type description indicating a plurality of types of data types indicating attachment methods of content data that can be attached to the structured document, and the message Storage means for storing interface definitions having descriptions of parameters constituting
A determination unit for determining an attachment method that can be supported by the communication device on the transmission side, among attachment methods corresponding to the data type described in the interface definition ;
Code generating means for generating a code for attaching content data in binary format according to the attachment method determined by the determining means , using a description of parameters constituting the message ;
Message generating means for generating a message attached with the binary content data based on the code generated by the code generating means;
Transmitting means for transmitting a message to which the binary content data generated by the message generating means is attached ;
A communication apparatus comprising: The communication apparatus according to claim 1, further comprising a reception unit that receives the message transmitted by the transmission unit.   When the communication device is capable of supporting a plurality of attachment methods among the attachment methods described in the interface, the message generation unit is described first in the interface among the compatible attachment methods. 2. The communication apparatus according to claim 1, wherein the content data in the binary format is attached by an attachment method corresponding to a data type.   The communication apparatus according to any one of claims 1 to 3, wherein the attachment method includes at least one of a SWA method, a WSA method, and an MTOM method. As a message to be transmitted and received by the communication instrumentation 置間 connected via a network, a message transmission method for a communication apparatus for generating a structured document in a text format with attached content data in binary form,
A web service interface definition between a communication device on a transmission side and a reception side, and an abstract data type description indicating a plurality of types of data types indicating attachment methods of content data that can be attached to the structured document, and the message A reference step for referencing an interface definition having a description of parameters comprising
A determination step of determining an attachment method that can be supported by the communication device on the transmission side, among attachment methods corresponding to the data type described in the interface definition ;
A code generation step of generating a code for attaching content data in binary format according to the attachment method determined in the determination step, using a description of parameters constituting the message;
And a message generating step based on the generated code by the code generating step generates a message with attached content data of the binary format,
A transmission step of transmitting a message to which the binary content data generated by the message generation step is attached;
A message transmission method for a communication apparatus, comprising: 6. The message transmission method of the communication device according to claim 5, further comprising a reception step of receiving the message transmitted in the transmission step. In the message generation step, when the communication device is compatible with a plurality of attachment methods among the attachment methods described in the interface, the communication device is described first in the interface among the compatible attachment methods. 6. The message transmission method for a communication apparatus according to claim 5 , wherein the content data in the binary format is attached in an attachment method corresponding to a data type. 8. The message transmission method for a communication apparatus according to claim 5 , wherein the attachment method includes at least one of a SWA method, a WSA method, and an MTOM method.

Images