KR101398959B1 - Interface method and apparatus by using plug-in - Google Patents

Abstract

The present invention discloses a plug-in interface method and apparatus using an abstract interface in implementing a plug-in interface system. An interface method according to the present invention comprises the steps of creating an abstract interface defined in a message exchange bus (MEB), creating a dynamic link library (DLL) of a message exchange component (MEC) using the abstract interface created, Connecting the DLL and the MEB, and transmitting and receiving data using the data stored in the MEB. According to the present invention, even if there is no separate plug-in provider, it is possible to solve the dependency problem due to the reference of the framework object that may occur at compile time by referring to the abstract interface.

Description

[0001] INTERFACE METHOD AND APPARATUS BY USING PLUG-IN [0002]

The present invention relates to an interface method and apparatus using a plug-in when developing a simulation framework using modeling and simulation technology.

In order to successfully build a development system, it is necessary to develop a software architecture design and a framework that provides a common execution environment. The development system is required to be easy to change user requirements, to increase the reliability and reusability of components .

Therefore, in the development of a large-scale system, there is a need to solve the problem of system integration when modifying or modifying some of the system modules. To solve these problems, a plug-and-play architecture has been proposed.

However, conventional plug-in frameworks have a coupling between a plug-in target and a plug-in provider. That is, there is a problem that the plug-in target needs to know the object of the plug-in provider. Thus, there is a problem that the interface implementation of the framework that provides the plug-in function can not be accessed at the time of developing the plug-in module.

In consideration of the problems of the prior art, the present invention provides a method for managing a null object of a module providing a plug-in function in the implementation of an executable file (DLL) of a plug-in target person without the operation of a framework or a loader as a plug- The purpose of this paper is to propose an interface method of message objects to provide a plug-in framework independent implementation environment. It also aims to exchange the exchange data even if the other party's information is not exchanged by dynamically generating the routing table for the exchange information between the DLLs.

According to another aspect of the present invention, there is provided a plug-in interface method comprising: generating an abstract interface for generating an executable file; Generating a dynamic linking library (DLL) of a message exchange component (MEC) by referring to the abstract interface; Connecting a DLL of the MEC with a message exchange bus (MEB); And transmitting and receiving data between the DLL and the MEB of the MEC.

According to another aspect of the present invention, there is provided a plug-in interface device including an abstract interface for generating an executable file of a plug-in component; A message exchange component (MEC) for generating a dynamic library (DLL: Dynamic Linking Library) of a plug-in component with reference to the abstract interface and connected to a plug-in framework to transmit / Exchanging Component) module; And an interface device including a Message Exchange Bus (MEB) module for transmitting and receiving data to and from the MEC module.

According to the present invention, when implementing a plug-in target object (DLL), an abstract interface is referred to even if there is no separate plug-in provider such as a framework or a loader. In this way, you can solve dependency problems caused by references to framework objects that can occur at compile time. Also, according to the present invention, it is possible to implement only the function module of the DLL module regardless of whether the DLL module is created or not.

1 is a flowchart illustrating a plug-in interface method according to an embodiment of the present invention.
2 is a reference diagram showing an example of an abstract interface.
3 is a block diagram illustrating a plug-in interface device according to an embodiment of the present invention.
4 is a block diagram illustrating a configuration of a message exchange component (MEC).

Hereinafter, a plug-in interface method and apparatus using the abstract interface of the present invention will be described in detail with reference to the drawings and embodiments.

FIG. 1 illustrates a plug-in interface method using an abstract interface according to an embodiment of the present invention.

In the plug-in system, step (S100) of creating an abstract interface for generating an executable file is a step of creating an abstract interface for compiling executable code to generate an executable file.

An execution code is a command readable by a computer, which is prepared in advance by a user. Executable code can be written using the same programming language as C ++, JAVA, etc.

Executable files include dynamic library files. Dynamic library files can also be classified as static link library files and dynamic link library files in the * .DLL extension format.

In the case of a dynamic link library file, only a minimum amount of information required for a link is inserted into an execution code, and the operation code is referred to at execution time. Therefore, in order to implement and compile a dynamic library in general, you need to insert the minimum information needed for the inter-system link into the executable binary or executable code.

However, in the case of the dynamic link library, since it is necessary to prevent an error in linking, the present invention can prevent link time error when compiling an executable file by generating an abstract interface and determining a reference when a DLL is compiled.

Referring to FIG. 2, a function for interacting with a message exchange component (MEC: Message Exchanging Component), which is an executable file of a plug-in framework client or a plug-in framework, is implemented by implementing an abstract interface of a Null MEB module can do. As an implementation of the abstract interface, the same function as the MEB can be declared by referring to the plugin framework implemented in the Message Exchange Bus (MEB).

The plug-in framework is a program development and execution environment. It can encapsulate many tasks such as network operations and interfaces, and can operate on virtual machines. The plug-in framework may include a system that allows a plug-in program to run a program in conjunction with the framework, without any action being taken, by connecting the plug-in program to the framework.

Interaction refers to the function of the MEC and the MEB to exchange data with each other using a function and to perform processing according to mutual data exchange. Data can have handle values, and MEC and MEB can be implemented to manage data by referring to handle values.

Step S200 of creating a dynamic linking library (DLL) of a message exchange component (MEC) by referring to the abstract interface is a step of generating an executable file by compiling the MEC. The executable file contains a file in the form of a dynamic link library (DLL).

An implementation of a dynamic link library can be implemented by creating a DLL by referencing a function of an abstract interface by inserting it into the executable code. When you want to create a DLL for the MEC, you refer to the abstract interface, not to the functions of the MEB. That is, the dependency on the framework can be reduced by not referring to the MEB until the link time for execution.

A step S300 of connecting the DLL of the MEC and a message exchange bus (MEB) implements the system to connect the DLL of the MEB and the MEC. The DLL of the MEC sends a message to the MEB, which receives the message sent by the DLL of the MEC. MEB can extract routing information and object model by parsing the message received from MEC's DLL.

Parsing is the parsing of a sentence by analyzing the received message to distinguish the information such as the sender of the message, the message receiver, and the object model.

Among the information extracted through sentence analysis, routing information that can identify the sender / receiver in relation to message transmission is stored in the routing table. In the plug-in system, since the DLL is created by referring to the abstract interface without referring to the MEB, the MEB needs to store the sender / receiver of the message.

Yet another example may include creating an object model composed of XML corresponding to an object model. Independently developing a DLL has a problem that the relative DLL is not known. When the MEC is plugged in the plug-in framework MEB using the XML object model, that is, the exchange information classified as XML, To be exchanged.

 For example, the object model has Sharing information and can display Publish or Subscribe. For example, <Objectclass messageName = "Missile" sharing "publish"> means to send Missile information and <Objectclass messageName = "Missile" sharing "subscribe"> means to receive Missile information .

In step S400 of transmitting and receiving data between the DLL and MEB of the MEC, information for identifying a transmitting object is stored in the message transmitting object, and the routing information for the receiving object is retrieved and stored in the message routing table.

The routing information stored in the message routing table can be used to transmit data from the message transmission object to the message reception object. The information that can be identified is not limited to any particular form as long as it is information that can identify the DLL and MEB of the MEC.

FIG. 3 illustrates a plug-in interface device using an abstract interface according to an embodiment of the present invention. The plug-in interface device may include an abstract interface 100, a message exchange component 200, and a message exchange bus 300.

The Abstract Interface 100 may be preconfigured by the user and may declare the same function name as the function of the MEB 300. The MEB module 300 and the MEC module 300 may be interfaced with each other by referring to a function of the MEB module 300.

The message exchange component 200 uses the abstract interface 100 to generate an executable file of the MEC module 200, which is a plug-in component. That is, instead of directly referring to the MEB 300 as a plug-in framework, an executable file is generated using an abstract interface. The executable file contains dynamic libraries, and dynamic libraries include static link libraries and dynamic link libraries.

A message exchange component (MEC) 200, which is a plug-in execution module, is connected to the MEB 300, which is a plug-in framework, to transmit and receive data.

Referring to FIG. 4, the MEC 200 may generate a message notification module 230 and an MEC agent (Surrogate) 250 through a user defined management module 210.

A message informer 230 receives a message from the MEB module and sends a message to the MEC's DLL based on the received message.

MEC agent (Surrogte) 250 performs data transmission in communication with the MEB and other MECs. For example, in the case of a sender, a module called MEC Publisher can be set up to transmit data, and in the case of a receiver, a module called MEC Subscriber can be set to transmit data.

A message exchange bus (MEB) 300 manages sub-modules of the MEB module, interacts with the MEC module, processes meta information of a message received by the MEC managing the MEC module and the DLL, defines the message, Creates a wrapper class.

Meta information refers to data such as sender information and recipient information extracted by message exchange bus parsing a message.

The MEB module 300 may include a MEB component, a MEB message distribution module, a MEB processing management module, a MEB message processing module, and a MEB message processing module.

The MEB component (MEB Component) manages the submodules included in the MEB module, and allows the DLL of the MEC to be plugged in.

The MEB message dispatching module analyzes a message received from the MEC module to generate a message routing table, provides a message exchange service with reference to the message routing table, and interacts with the MEC module.

The MEB Handle Manager manages the memory to create and delete DLL objects that implements the Message Informer interface. When the MEC DLL is plugged in, a notification service (Notification Service).

The Notification Service can provide a service to notify the user that the MEB and the MEC DLL are connected.

If the DLL object of the MEC is plugged in, the identification number of the MEC can be given to the DLL and the identification number can be referred to when the plug is released.

When registering the message notification service, the sender and receiver can be stored separately. For example, a sender can have a table value called Publisher, and a recipient can have a table value called Subscriber.

The MEB Message Processor creates a storage class that parses the XML message created to interact with other DLLs and manages the meta information of each message. The DLL creates an object from the storage class to use the message. .

The MEB message processing module implements a wrapper class for a basic type and a complex type that can define a message.

A wrapper class is a class that allows basic data to be processed on an object-by-object basis. It is a class that creates basic data as objects.

The present invention has been described above with reference to preferred embodiments. It will be understood by those skilled in the art that the present invention may be embodied in various other forms without departing from the spirit or essential characteristics thereof. Therefore, the above-described embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is indicated by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

Claims (15)

In a plug-in system,
An abstract interface that determines a reference of the DLL to prevent a link error of a dynamic link library (DLL) to be included in an executable file generated by compiling executable code that is a command readable by a computer, &Lt; / RTI &gt;
Generating the DLL to be included in a message exchange component (MEC), which is the executable file of the plug-in framework, with reference to the abstract interface;
The message exchange bus (MEB), which is a plug-in framework, receives a message from the DLL of the MEC, extracts routing information and an object model for the message transmission object and the message reception object from the received message, Connecting the DLL and the MEB to transmit the mutual message; And
And receiving, by the MEB, data required by the MEC, which is the message receiving object, from the DLL of the MEC, which is the message transmitting object, using the routing information and the object model, and transmitting the received data to the MEC Way. 2. The method of claim 1, wherein generating the abstract interface comprises:
And declaring a function capable of interacting between the MEB and the MEC as a function identical to a function set in the MEB based on the MEB. 2. The method of claim 1, wherein generating the DLL comprises:
And a function defined in the abstract interface is referred to an executable code of the MEC to prevent a link error of the DLL at compile time. 2. The method of claim 1,
The MEB receiving a message from a DLL of the MEC;
Extracting the routing information and the object model for each of the message transmission object and the message reception object by parsing a message received by the MEB; And
Storing the routing information in a routing table;
Lt; / RTI &gt; 5. The method of claim 4, wherein the connecting step
And generating an object model composed of XML corresponding to the extracted object model. delete delete delete delete delete delete delete delete delete delete

Images