JPH10214196A - Software linking processor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To catch and process events asynchronously generated from connected other software components, by receiving event input informing from plural threads and executing the main processing of an application. SOLUTION: The software components 1 and 2 provided with different event drive type paradigms for turning a Java component 1 to the calling side and turning a window object component 2 to the called side are connected through a message gateway 5. Also, the side of the Java component 1 is constituted of the threads 3-1-3-3 and a queue 3-5 to be an interface to the thread 3-3. The thread 3-1 processes the processing of a GUI event, the thread 3-2 processes the processing of the event from the message gateway 5 and the thread 3-3 processes the main processing respectively parallelly. Thus, processing efficiency is improved and also the development efficiency of a program is improved.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software cooperative processing device that connects software having two different types of event-driven programming paradigms to enable cooperative operation.

[0002]

2. Description of the Related Art The event-driven programming paradigm has been widely used as a framework for constructing an application program linked to a GUI (graphical user interface). Examples of event-driven programming paradigms include, for example, callback programming of the X Window System,
Windows (trademark of Microsoft corporation) Window programming in OS (operation system), Java (trademark of Sun Miscrosystem Inc.) programming environment, and the like. In particular, Java programming is a technology that is currently attracting attention, and expresses event-driven programming using AWT (abstract window toolkit) in an object-oriented framework.
It offers a flexible paradigm. It also provides a mechanism for coupling / calling with software developed in other programming languages.

[0003] This other programming language coupling mechanism of Java is implemented as a native method mechanism of Java, and can be coupled with C language or C ++ language.
With this, if you implement the internal processing of the method that processes the event from the window as a native method,
Can be combined with software components developed in other programming languages. (Reference: "The
Java Tutorial: Integrating Native Methods into Ja
va Programs ")

[0004]

However, when an event-driven software component developed in another programming language is combined with the above-described conventional apparatus, there are the following problems to be solved. . In order to request processing from another combined event-driven software component and receive an end notification (end event) generated from the component, an end method must be included in the method (native method) that started the software component. It is necessary to describe wait synchronization processing. However, in this case, a method cannot be described only by asynchronous processing which is an event-driven characteristic. Further, during the synchronous processing, there is a problem that an event (attention) generated asynchronously from another coupled software component cannot be captured and processed.

[0005]

The present invention employs the following structure to solve the above problems. <Structure 1> Consisting of software components having different event-driven paradigms and a message gateway connecting these software components, the message gateway converts an event issued from any of the software components into
It has a conversion mechanism that converts the event into an event in accordance with the other party's event-driven paradigm and issues the event to the other party's software component.One software component stores the event in the software component's process. A software cooperation processing device comprising: a thread for processing; a thread for processing a mediation event from a message gateway; and a thread for receiving an event input notification from the two threads and executing a main process of an application.

<Structure 2> A software cooperation processing apparatus according to Structure 1, wherein one of the software components is provided with a queue for holding an event in a processing waiting state.

<Structure 3> Consisting of software components having different event-driven paradigms and a message gateway connecting these software components, one of the software components is incorporated in the message gateway and the other is installed in the message gateway. A software cooperation processing device comprising a conversion mechanism for converting an event issued from a software component into an event according to an event-driven paradigm of a built-in software component.

<Structure 4> In structure 3, the other software component includes a sub-window for processing an event in the process of the software component, a sub-window for processing a mediation event from the message gateway, and the above two software components. A software cooperation processing device, comprising: a sub window that receives an event input notification from a thread and executes a main process of an application.

[0009]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments of the present invention will be described below using specific examples. <Summary> This software cooperation processing apparatus can be connected to a network (TCP (Tran
smission Control Protocol) / IP (Internet Proto
col) Event-driven software components operating in a plurality of computer environments connected via a network or the like) are connected and cooperatively operate. To this end, both components are configured to be connected via a message gateway. The difference in the protocol between the event-driven processes using different methods is implemented by message mediation / conversion by the message gateway.

For example, consider a case where a software component B is connected to a software component A as a center. In this case, a thread for receiving a message from the message gateway is set for realizing the software component A,
It manages event processing other than the window event from the connected software component B.

Consider the case where an event-driven software component A is combined with an event-driven software component B. In this case, a message gateway for exchanging events between the software components A and B, a thread for processing a window event in the software component A process, a thread for processing a mediation event from the message gateway, A thread that receives an event input notification from the two threads and executes the main processing of the application is provided.

With this configuration, when the software component A issues an event to the software component B, the software component A sends a message to the message gateway, and the message gateway performs an event according to the event driven paradigm processed by the software component B. And issues the event to software component B. The message transmission from the software component A to the message gateway is an asynchronous process,
The software component A can execute another process after transmission. Software component B receives the event notification from software component A,
After the event processing is completed, an end event is transmitted to the message gateway. Next, the message gateway converts the end event into an event according to an event driven paradigm processed by the software component A, and issues the event to the software component A. The same processing sequence applies to notifying the software component A of an attention event that occurs independently in the software component B as well as the end event for the event from the software component A.

[0013] As described above, since the message gateway mechanism of the software cooperative processing device and the thread configuration of the software component enable parallel processing of the software component, the component can be described as an asynchronous process, and a different event-driven type can be described. Asynchronous coupling of software components with a paradigm is possible.

<First Embodiment> FIG. 1 is a block diagram of a software cooperation processing apparatus according to a first embodiment. For example, in this example, there are two event driven software components, and component 1 implemented in Java
And the component 2 implemented by the window object of the Windows OS. The Java component 1 has three threads 3-1, 3-2, 3-3.
It consists of. The thread 3-1 is a GUI for mouse input, keyboard input, and the like generated by interactive processing with the user.
A thread that processes I events. Thread 3-2
Is a thread that processes events from the message gateway described later. The thread 3-3 is a thread for executing a main process. API (Function Module) 4
Is an application program interface provided to the Java component 1. This API4
Is called from the thread 3-3, a message is transmitted to the message gateway 5 using the TCP / IP socket 6.

Window object component 2
Is a window object that processes events issued from the Java component 1. here,
A message reply unit 2-1 and a message receiving unit 2-2 for the API are provided, and registration of a window message corresponding to the API 4 and definition 2-3 of the main processing are performed. The message gateway 5 converts the TCP / IP socket message transmitted through the API 4
It becomes a broker that converts it into a window message, which is the basic communication mechanism of ndows, and sends it to the window object component 2. Further, the message gateway 5 receives the reply message (window message) of the message transmitted to the window object component 2, and returns the message to the socket 3-4 of the thread 3-2, contrary to the above example. For these operations, the message gateway 5 is provided with a TCP / IP socket message conversion mechanism 5-1 and a window message conversion mechanism 5-2.

In the present invention, a software cooperative processing mechanism that performs communication between the two event-driven software components 1 and 2 having such a configuration via the message gateway 5 to realize cooperative operation is realized.

FIGS. 2 and 3 show operation flowcharts of the software cooperation processing apparatus. In step S1,
It is assumed that a GUI event that needs to call the window object component 2 has occurred in the thread 3-1 in the Java component 1 and has been captured.
Thus, in step S2, the thread 3-1 notifies the thread 3-3 of the content of the event input as a message together with the change of the window display content. The communication between the threads includes a FIFO used to manage the order of messages processed by the thread 3-3.
An O (First In First Out) type queue 3-5 is used. This queue 3-5 is for supplying an event to the thread 3-5, and may be arranged anywhere in the Java component 1. The thread 3-1 inserts a message into the queue 3-5.

The thread 3-3 is in a state of waiting for an input to the queue 3-5. When a message is input to the queue 3-5, the message is taken out of the queue 3-5 in step S3, and processing corresponding to the message is performed. Execute That is, this queue mechanism becomes an interface (entrance) of the message sent to the thread 3-3. In the case of this example, this message corresponds to a message that calls the API 4 provided by the window object component 2. Therefore, the API 4 is called from the thread 3-3, and as a process of the API 4, a message is transmitted to the message receiving socket 6 held by the message gateway 5 in step S4. Then thread 3
-3 again transitions to the state of waiting for input from the queue 3-5.

Next, in step S5, the message gateway 5 extracts the message from the socket 6, converts the message into a window message which is a basic communication mechanism of Windows, and transmits the window message to the window object component 2. Next, proceeding to step S6, when the window object component 2 receives the window message,
The function corresponding to the message is executed in the main processing, and a window message indicating the end is returned to the message gateway 5 when the execution is completed. Thereafter, the window object component 2 transits to the window message reception waiting state again.

In step S7, when the message gateway 5 receives the reply message, the thread 3-2 in the Java component reverses the procedure described above.
Is transmitted to the message receiving socket 3-4 held by the server. In step S8, thread 3
-2, upon receiving the end message, inserts its contents into the queue 3-5 shown above. In step S9, the thread 3-3 is released from the waiting state, executes a process corresponding to the end message, and transitions to the state of waiting for input from the queue 3-5 again.

<Effect of Specific Example 1> Specific Example 1 described above.
According to the software cooperation processing device of the above, a software having a different event-driven paradigm such that a Java component is a calling side and a window object component is a calling side by a message gateway mechanism and a thread / queue mechanism of a software component. A coupling process between components can be realized. In this specific example, Ja
The va component side has three threads 3-1 and 3-
2, 3-3 and a queue 3-5 serving as an interface to the thread 3-3.
The process of the event, 3-2 processes the event from the message gateway, and 3-3 processes the main process in parallel. Therefore, the specified processing can be described independently of other thread processing, as well as the processing efficiency, so that the program development efficiency is improved.

<Embodiment 2> FIG. 4 is a block diagram of a software cooperation processing apparatus according to Embodiment 2. In this example, there are two event-driven software components, one of which is implemented with a Windows OS window object. Component 1 is
Implemented by Java. The window object component 2 includes three sub-windows 2-5, 2-
6, 2-7. The subwindow 2-5 is a window function for processing a GUI event such as a mouse input or a keyboard input generated by an interactive process with the user. The subwindow 2-6 is a window function for processing an event from the message gateway 5 having a Java execution environment described later. Subwindow 2
Reference numeral -7 denotes a window for executing the main processing. It is connected to a message gateway 5 via an API (function module) 4.

The Java component 1 includes a Java applet that processes an event issued from the window object component 2.
Is defined. Here also
An event processing thread 1-1 for receiving an event and selecting an applet is provided. The API 4 is an application program interface provided to the window object component 2. This API
When 4 is called from the subwindow 2-7, a message is transmitted to the message gateway 5 by a window message.

The message gateway 5 has a Java execution environment, receives a message transmitted through the API 4, converts the message into a method call method of Java, and calls a Java applet in the corresponding Java component 1. For this purpose, a conversion mechanism 5-4 for converting to a Java method call format is provided. When the execution of the Java applet ends, the message gateway 5 returns the result to the window object component 2 as a window message. For this purpose, an end message reply mechanism 5-3 is provided.

In the present invention, between the two event-driven software components having such a configuration,
Message gateway 5 with Java runtime environment
And implements a software cooperation processing mechanism that performs cooperative operation through communication.

FIGS. 5 and 6 show operation flowcharts of the software cooperation processing apparatus. First, in step S1, it is assumed that a GUI event that needs to call the Java component 1 has occurred in the subwindow 2-5 in the window object component 2 and has been captured. Accordingly, in step S2, the subwindow 2-5 notifies the subwindow 2-7 of the content of the event input as a message together with the change of the window display content. This subwindow 2-5
The window message is used for communication between
The subwindow 2-5 inserts a message into the window message queue 2-8 of its own window object.

The subwindow 2-7 is in a state of waiting for input to the window message queue 2-8, and is activated when a message is input to the queue 2-8.
In step S3, a process corresponding to the message is executed. In the case of this example, this message corresponds to a message that calls the API 4 provided by the Java component 1. Therefore, the API 4 is called from the subwindow 2-7, and a message is transmitted to the message gateway 5 as the processing of the API 4. Thereafter, the subwindow 2-7 is again in the subwindow message queue 2-8.
Transitions to the state of waiting for input from.

Next, proceeding to step S5, the message gateway 5 sets the window message queue 2-8.
Extract the message from
Change the Java applet in the ava component 1 to an executable state. In step S6, the Java component 1 executes the Java applet. When the execution of the Java applet is completed in step S7, the message gateway 5 transmits a window message indicating the completion of the execution to the window object component 2. Note that the end message is in step S
8 is processed by the subwindow 2-6. After the post-processing, a message is inserted into the window message queue 2-8 of the own window object as a window message to the sub-window 2-7 for executing the main processing. In step S9, the sub window 2-7 executes a process corresponding to the message.

<Effect of Specific Example 2> Specific Example 2 described above
According to the document, a message gateway mechanism having a built-in Java execution environment realizes a coupling process between software components having different event-driven paradigms such that a window object component is a caller and a Java component is a caller. can do. In addition, by incorporating a Java execution environment in the message gateway, Java
There is an effect that the va applet can be started up remotely. In both the first and second embodiments, when software components are operated in cooperation via a network, the message gateway may be arranged on either the transmitting side or the receiving side.

[Brief description of the drawings]

FIG. 1 is a block diagram of a software cooperation processing device of a specific example 1.

FIG. 2 is an operation flowchart (part 1) of the software cooperation processing apparatus;

FIG. 3 is an operation flowchart (part 2) of the software cooperation processing apparatus;

FIG. 4 is a block diagram of a software cooperation processing device of a specific example 2;

FIG. 5 is an operation flowchart (part 1) of the software cooperation processing apparatus;

FIG. 6 is an operation flowchart (part 2) of the software cooperation processing apparatus;

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 Java component 2 Window object component 3-1-3-3 Thread 3-4 Socket 4 API 5 Message gateway 6 Socket

Claims (4)

[Claims] The present invention comprises a software component having a different event-driven paradigm and a message gateway connecting these software components. The message gateway converts an event issued by any of the software components into an event of a partner. It has a conversion mechanism that converts events into events in accordance with the driving paradigm and issues the events to the other software component. One of the software components has a thread that processes an event in the process of the software component. A thread that processes the mediation event from the message gateway; and a thread that receives the event input notification from the two threads and executes the main processing of the application. Software cooperative processing apparatus characterized by comprising a de. 2. The software cooperation processing apparatus according to claim 1, wherein one of the software components is provided with a queue for holding an event in a process waiting state. 3. A software component having a different event-driven paradigm and a message gateway connecting these software components. The message gateway includes one software component and the other software component. A software cooperation processing device, comprising: a conversion mechanism configured to convert an event issued from an application into an event according to an event-driven paradigm of a built-in software component. 4. The two threads according to claim 3, wherein the other software component includes a subwindow that processes an event in a process of the software component, a subwindow that processes an intermediary event from a message gateway, and the two threads. And a sub-window for receiving an event input notification from the client and executing a main process of the application.