JP4835313B2 - Software module linkage system - Google Patents

Description

The present invention relates to a software module linkage system to link 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 standard 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 to solve the problems described above, the software module linkage system that can be used languages and environments to work together software module without performing a complicated process even if different The purpose is to provide.

The software module linkage system according to the present invention includes a first software module that performs predetermined processing, an access point information defining unit that defines access point information for accessing the first software module, and the access point method definition part for defining a method that shows the entity of service corresponding to the information, and at least including interface defines the virtual code definition unit for defining a virtual code indicating the entity of the function, the first software module and different standards comprising a second software module, wherein the first software module, based on the description service name and the data format in the interface definition, service for cooperating with said second software module · generate stubs, the second soft Wear module, the first software module has issued based on the interface definition to generate a client stub and handlers to work with the first software module, the first and second soft The hardware module communicates with each other using the generated service stub and client stub, and performs processing using an execution code based on an algorithm defined in the virtual code included in the interface definition by the handler. It is characterized by realizing a cooperation process by performing .

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.
The software module linkage system according to claim 2 is the software module linkage system according to claim 1, wherein the access point information definition unit includes a network address expression method, the network address, a port number, and an interface usage precaution. The method definition unit includes input information and output information on a communication path between the first software module and the second software module, and the virtual code definition unit includes the entity of the function. Function name, function definition, information indicating from which location the value of which element is transferred in the virtual code, whether to disclose the referenced variable to the function user Attribute that is not defined as a function return value when it is not disclosed, function type, processing at the time of abnormality, and virtual code of function to be executed It is intended to include.
According to a third aspect of the present invention, there is provided the software module linkage system according to the first or second aspect, wherein the first software module and the interface definition are stored in the server and the second software. A client in which a module is stored; and a shared memory used between the server and the client. The server issues the interface definition to the client, and the first software module The interface definition is used to write image data to the shared memory in response to a service request from the client, send a shared memory identifier to the client, and the client issues an interface definition issued from the server. Based on whether the server Attach the shared memory in its own process using the sent shared memory identifier, and access the shared memory by the second software module based on the address of the attached supply memory. The data is read out.
The software module linkage system according to claim 4 is the software module linkage system according to claim 3, wherein the handler is code for handling the shared memory, and the client uses the client stub. Sending a request for the service to the server, the server receiving a request sent from the client using the service stub, and in response to the received request, the first software module Write the data to shared memory, send the shared memory identifier to the client using the service stub, and the client receives the shared memory identifier sent from the server using the client stub, Using the handler, the shared memory identifier is used based on the shared memory identifier. Attach the memory to its own process, based on the address of the shared memory attach is for reading the data from the shared memory to access the shared memory by said second software module.
According to a fifth aspect of the present invention, in the software module cooperation system according to the third or fourth aspect, the virtual code includes a magic number, and the client uses the handler to determine the shared memory identifier. Convert to a local identifier, attach the shared memory to its own address, refer to the address of the shared memory, compare with the magic number, and if the magic number is not correct, detach the shared memory If exception processing is performed and the magic number is correct, the address of the shared memory is supplied to the second software module.

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

A first software module that performs predetermined processing;
An access point information defining unit for defining access point information for accessing the first software module, a method defining unit for defining a method indicating the service entity corresponding to the access point information, and a function entity an interface definition that contains the virtual code definition unit for defining a virtual code at least,
A second software module having a different standard from the first software module,
The first software module generates a service stub for cooperation with the second software module based on the service name and data format described in the interface definition,
The second software module generates a client stub and a handler for cooperating with the first software module based on the interface definition issued by the first software module.
The first and second software modules communicate with each other using the generated service stub and client stub , respectively , and the handler defines an algorithm defined in the virtual code included in the interface definition. A software module linkage system characterized by realizing linkage processing by performing processing using the execution code based on it.   The access point information definition unit includes a network address expression method, the network address, a port number, and points to note when using an interface.
  The method definition unit includes input information and output information on a communication path between the first software module and the second software module,
  The virtual code definition unit includes the function name, function definition, information indicating which element value is transferred from which location into which virtual code, and the referenced variable as the function entity. 2. An attribute that is not defined as a return value of a function when it is not disclosed, a function type, a process at the time of abnormality, and a virtual code of a function to be executed is included. Software module linkage system.   A server storing the first software module and the interface definition;
  A client in which the second software module is stored;
  A shared memory used between the server and the client,
  The server issues the interface definition to the client, and writes image data to the shared memory in response to a service request from the client by using the interface definition by the first software module. Send a shared memory identifier to the client;
  Based on the interface definition issued from the server, the client attaches the shared memory in its own process using the shared memory identifier sent from the server, and based on the address of the attached supply memory, The software module linkage system according to claim 1 or 2, wherein the second software module accesses the shared memory and reads the data from the shared memory.   The handler is code for handling the shared memory;
  The client sends a request for the service to the server using the client stub,
  The server receives a request transmitted from the client using the service stub, and writes the data to the shared memory by the first software module in response to the received request. Sending the shared memory identifier to the client using a stub;
  The client receives the shared memory identifier sent from the server using the client stub, attaches the shared memory to its own process based on the shared memory identifier using the handler, and attaches the shared memory 4. The software module linkage system according to claim 3, wherein the second software module accesses the shared memory and reads the data from the shared memory based on a memory address.   The virtual code includes a magic number;
  The client uses the handler to convert the shared memory identifier to a local identifier, attach the shared memory to its own address, refer to the address of the shared memory, compare with the magic number, and 5. If the magic number is not correct, the shared memory is detached and exception processing is performed, and if the magic number is correct, the address of the shared memory is supplied to the second software module. The software module linkage system described.

Images