JP2008040722A - Software module cooperative system and method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To coordinate software modules without requiring complicated processing even when languages in use and environments are different. <P>SOLUTION: A service component 11 generates a service stab 13 from an interface definition 12 as information for accessing the service component 11. A client component 21 generates a client stab 22 and a memory handler 23 from the interface definition 12. The client component 21 writes data to a shared memory 30, and supplies a shared memory identifier through the service stab 13 and the client stab 22 to the memory handler 23. The memory handler 23 utilizes the shared memory identifier and attaches the shared memory 30 inside its own process. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a software module linkage system and method for linking software modules of different standards.

  As a platform for constructing a distributed processing system, middleware called an application server is increasingly used. Software modules that operate on the application server are developed in a predetermined language such as Java (registered trademark). However, since it is necessary to use components developed in various languages in an actual system, it is difficult to construct a system with only one language. Therefore, techniques for linking software modules developed in different languages and standards have been proposed.

  Specifically, a coordination adapter that facilitates coordination between an application server and a CORBA server is disclosed (see Patent Document 1). In Patent Document 1, a coordination adapter is interposed between a J2EE-compliant application server and a CORBA server. The J2EE-compliant application server can perform processing, settings, and data type conversion required for cooperation with the CORBA server by accessing the cooperation adapter. That is, it is possible to easily link between components having different architectures such as between a J2EE-compliant application server and a CORBA server by creating a coordination adapter.

In addition, it is disclosed that a component that hides a complex interface through cooperation between components is created and used as an adapter (see Patent Document 2). In addition, a technique is disclosed in which routine processing of a communication part of an application module used for communication is generated to improve development efficiency, and work can be easily performed in maintenance and debugging of transaction format and screen program information (Patent Literature) 3). In Patent Document 3, a communication code necessary for transaction processing is automatically generated by designing a screen.
JP 2003-157242 A JP 2003-202984 A Japanese Patent Laid-Open No. 9-282152

  However, in a multi-model linkage framework such as CORBA or WSDL (Web Service), the source code automatically generated by the tool is only data binding. Even if there is a common process to handle that data, each client needs to do a similar process individually, which is not only cumbersome but can also cause unexpected behavior due to incorrect processing. is there.

  Further, in a collaboration framework between single languages such as Java (registered trademark) RMI, the server can send the code itself for handling data to the client, but there is a problem that transmission overhead is inevitable. . There is also a problem that it cannot be linked with software modules in other languages and environments.

  The present invention has been proposed in order to solve the above-described problems, and a software module linkage system and method capable of linking software modules without performing complicated processing even when the language used or the environment is different. The purpose is to provide.

  A software module linkage system according to the present invention includes a first software module that performs predetermined processing, an interface definition unit that defines information for accessing the first software module, and a first software module A second software module of a different standard from the first software module, the first software module generates a code for cooperating with the second software module based on the interface definition, and The second software module generates a code for cooperating with the first software module based on the interface definition, and the first and second software modules respectively use the generated code. It is characterized by performing a cooperation process with each other.

  The software module cooperation method according to the present invention is based on the interface definition in which the first software module that performs a predetermined process defines information for accessing the first software module. Code for cooperating with a second software module of a different standard from the software module of the second software module, and the second software module cooperates with the first software module based on the interface definition Code is generated, and the first and second software modules perform a cooperation process with each other using the generated code.

  The first and second software modules may be the same hardware or different hardware via a network as long as they perform predetermined services (data processing). The interface definition unit defines information for accessing the first software module, and based on this information, codes for linking with the first and second software modules are generated. Then, the first and second software modules perform cooperation processing with each other using the generated codes.

  Therefore, even if the language used and the environment are different, the above invention generates code for cooperating with the first and second software modules based on the interface definition unit without performing complicated processing. The first and second software modules can be linked.

  According to the present invention, software modules can be linked without performing complicated processing even when the language or environment is different.

  Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings.

  FIG. 1 is a diagram showing a configuration of a cooperation system according to an embodiment of the present invention.

  The cooperation system includes a server 10 that provides a predetermined service, a client 20 that requests the server 10 for a service, and a shared memory 30 that is used between the server 10 and the client 20. In the server 10, the client 20 and the shared memory 30 are connected to each other via a network.

  The server 10 and the client 20 are constituted by, for example, computers, input / output ports for inputting / outputting data via a network, storage devices for storing data, software components, etc., data generation / distribution, software components And an arithmetic circuit for performing arithmetic processing related to the control and the like. As a result, the server 10 and the client 20 have the following configuration functionally.

  The server 10 includes a service component 11 that performs a predetermined service and an interface definition 12 that is information for accessing the service component 11. The client 20 has a client component 21.

  FIG. 2 is a diagram showing the interface definition 12. The interface definition 12 is configured by an XML document. The interface definition 12 includes one access point information (information regarding an access destination that can be uniquely identified on the network) (one of the second to sixth lines) and one or more methods ( It includes a method definition part (lines 7 to 19) for defining service information) and a virtual code definition part (lines 20 to 39) for defining virtual codes. The service (service component 11) indicated by the interface definition 12 is a service that receives an image name and returns image data indicated by the name. This virtual code is a model-dependent virtual code for attaching the shared memory 30 to its own process.

  The access point information definition part is the information defined by <endPoint> ... </ endPoint>. The network address representation method and its address (<address type = “...”> ... </ adress >), Port number (<port> ... </ port>), and notes on using the interface (<restriction> ... </ restriction>). The communication method is “named pipe” (line 3), and the default port number is used. The precautions (constraints) in using the interface indicate whether or not information that is difficult to directly transmit is included in the data transmitted and received on the network. In FIG. 2, “sharedMemory” (line 5) is listed. This indicates that the shared memory can be used as a constraint condition. Others include "fileDescriptor" and "localFile".

  The method definition section is information defined by <method name = ”... >> to </ method>, and there is one or more for the above access point, and corresponds to the actual service entity. Specifically, each method definition part includes input information to the service (<input> ... </ input>), output information from the service (<output> ... </ output>), virtual code and its execution Contains the location (<wrapper type = ”…”>… </ wrapper>).

  Therefore, the method definition unit indicates the service name (GetImagePage) of the service component 11 and the data format (input information and output information) on the communication path between the service component 11 and the client component 21. . The input from the client component 21 to the service component 11 is the name of the image, and the type is a character string (line 9 in FIG. 2). On the other hand, the output is the image size (integer), width (integer), height (integer), depth (integer), identifier (integer), type (integer) (lines 12 to 17 in FIG. 2). ). Up to this point, the contents are almost the same as those of existing interface definitions such as CORBA and WSDL.

  The virtual code definition part is information defined from <wrapper type = “cliant”> to </ wrapper>, and defines a function entity.

  Specifically, the virtual code definition part is a function name (<method name = ”…”>), function definition (<transform>), service information and input / output information, and correspondence between variables in the function (mapping) ) (<Source>… </ source>), function type (compile language, script language), processing in case of abnormality, virtual code of the function to be executed (<pseudo type = ”…” exception = ”…” />) Is included.

  Note that the 20th line in FIG. 2 indicates that the virtual code operates on the client side. The 21st line shows a target service (GetImagePage).

  "Correspondence between service information and input / output information and variables in function" indicates from which location (category) what element (element) value is transferred to virtual code in what type (type) ). The last attribute (wrapped) indicates whether the referenced variable is disclosed to the user of the function. If it is not disclosed, it is not defined as the return value of the function. That is, it declares to use the size, identifier, and type of an image among the service address and service output information as input data for data conversion. Of these, the addresses and identifiers are also hidden and shown to be invisible to the client function.

  Note that the virtual code grammar uses a simplified specification of C, which is a general procedural language, and has a system call different from the system call provided by Unix (registered trademark), Windows (registered trademark), or the like. In the cooperation system, stubs and memory handlers are generated as follows.

  First, the service component 11 generates a service stub 13 which is a stub code on the service side, based on the interface definition 12 described above. At this time, since the interface definition 12 does not include the service-side code, the service component 11 generates the service stub 13 based on the service name and data format described in the interface definition 12. Then, the service component 11 starts the actual service by linking the generated code and the implemented code.

  Next, in order to use the service of the service component 11, the client component 21 uses the interface definition 12 issued by the service component 11, and the client stub 22 that is the client side stub code and the executable memory. A handler 23 is generated.

  Since the interface definition 12 includes client-side code, it includes code for handling the shared memory 30. Here, the client 20 is assumed to be created in the C language that runs on the NetBSD OS, and the code generated there is as follows.

  FIG. 3 is a diagram illustrating codes of the client stub 22 and the memory handler 23.

  According to the 23rd line of the interface definition 12 (FIG. 2), it is understood that the address of the service which is a global variable is used. The ninth line in FIG. 3 shows a declaration of service address usage. The client stub 22 is an interface that is above the service GetImagePage provided by the service component 11, and the type of the function on the 11th line is determined from the interface declaration.

  As a result, as shown in FIG. 4, the server 10 includes a service component 11, an interface definition 12, and a service stub 13. Further, the client 20 includes a client component 21, a client stub 22, and a memory handler 23.

  In the cooperation system configured as described above, cooperation between software modules is performed as follows.

  The service component 11 attaches the shared memory 30 to its own process using its own code (step S1), and starts the service.

  In the client 20, the client component 21 accesses the client stub 22 to request a service from the service component 11 (step S2). The client stub 22 transfers the request for the client component 21 to the server 10 to call the client component 21 based on the 19th line in FIG. 3 (step S3).

  In the server 10, the service stub 13 transfers the request sent from the memory handler 23 to the service component 11 (step S4). The service component 11 writes the data into the shared memory 30, attaches the shared memory identifier, and responds to the service stub 13 (step S5). The service stub 13 transfers the response to the client 20 (step S6).

  In the client 20, the client stub 22 transfers the shared memory identifier sent from the service stub 13 to the memory handler 23 (step S7).

  The memory handler 23 uses the code based on the algorithm defined from the virtual code from the 26th line to the 36th line of the interface definition 12 (FIG. 2) as the shared memory identifier received from the client stub 22 as follows. Process as follows.

  The memory handler 23 attaches the shared memory 30 in its own process using the shared memory identifier (step S8). Furthermore, the memory handler 23 adds the address of the attached shared memory 30 and responds to the client component 21 (step S9).

  Specifically, the memory handler 23 first converts the shared memory identifier into a local identifier (line 22 in FIG. 4), clears the flag (line 23), and attaches the shared memory 30 to its own address. (Line 24) Then, the memory handler 23 refers to the address at the rear end on the shared memory 30, compares it with the magic number, and confirms that it is page data (line 25). At this time, if the magic number is not correct, the memory handler 23 detaches the attached shared memory 30 and shifts to exception processing (lines 26 and 27). If it is normal, the memory handler 23 subtracts the size corresponding to the magic number from the size of the shared memory 30 (line 29) and supplies the address of the attached shared memory 30 to the client component 21 (line 30). Eye).

  The client component 21 can read the data written in the shared memory 30 by accessing the shared memory 30 based on the received memory address.

  Here, conventionally, the above client-side code must be designed and implemented by all clients. In this embodiment, it is not possible to use without knowing the method for attaching the shared memory 30 to the own process and the magic number. If it is a method of using the shared memory 30, it may be possible to create a code by obtaining knowledge from a general book or the like. This is very inefficient because all clients must implement it independently based on the specifications described in the diagram and figures. In particular, if the specification is changed, it becomes necessary to make it known and change the code implemented by all clients.

  On the other hand, the cooperation system according to the embodiment of the present invention prepares an interface definition 12 for accessing the service component 11, and based on the interface definition 12, the service stub 13, the client stub 22, and the memory A handler 23 is generated. The cooperation system transmits and receives data between the service component 11 and the client component 21 via the service stub 13, the client stub 22, and the memory handler 23.

  Thereby, even if the standard and environment of the service component 11 and the client component 21 are different, the cooperation system generates the stubs 13 and 23 and the memory handler 23 based on the interface definition 12, so that the cooperation is performed. Therefore, it is possible to omit duplication processing. Further, since the code generated by the cooperation system is an execution code that matches the architecture of each component, like the stub code, there is no need for transfer and the processing efficiency is high.

  Note that the present invention is not limited to the above-described embodiment, and it is needless to say that the present invention can also be applied to a design modified within the scope of the claims.

  For example, in the above-described embodiment, the code is generated on the assumption that the server 10 and the client 20 share the memory, but the present invention is not limited to this. In other words, when the memory is not shared, there is no problem in generating the code for transferring the memory contents based on the usage form of the memory.

  Furthermore, in the above-described embodiment, the case where the code is statically generated and combined with the client has been described. However, if this is dynamically combined at the time of execution, it is possible to flexibly cope with specification changes. . For example, in the above embodiment, the magic number is “0xa5a5”. However, if there is a dynamic link, the interface between the service component 11 and the client component 21 is not likely to be flawed, so the magic number is “0xfefe”. It is also possible to change to.

It is a figure which shows the structure of the cooperation system which concerns on embodiment of this invention. It is a figure which shows an interface definition. It is a figure which shows the code | symbol of the client stub 22 and the memory handler 23. FIG. It is a figure which shows the structure of the cooperation system of the state by which the service stub, the client component, and the client stub were produced | generated.

Explanation of symbols

10 Server 11 Service Component 12 Interface Definition 13 Service Stub 20 Client 21 Client Component 22 Client Stub 23 Memory Handler

Claims (2)

A first software module that performs predetermined processing;
An interface definition section defining information for accessing the first software module;
A second software module having a different standard from the first software module,
The first software module generates code for cooperating with the second software module based on the interface definition,
The second software module generates code for cooperating with the first software module based on the interface definition,
The software module linkage system, wherein the first and second software modules perform linkage processing with each other using generated codes. Based on the interface definition in which the first software module that performs predetermined processing defines information for accessing the first software module, the second software having a different standard from the first software module. Code for linking with the hardware module,
The second software module generates code for cooperating with the first software module based on the interface definition,
The software module cooperation method, wherein the first and second software modules perform cooperation processing with each other using generated codes.

Images