JP3238788B2 - Object communication method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a communication system for objects in a computer system operating on an object basis.

[0002]

2. Description of the Related Art A computer system operating on an object basis can encapsulate data and procedures handled in the system.
The safety of the system can be dramatically improved. Also, in the process of application development, extremely efficient system development is enabled by the inheritance function and polymorphism of the object.

In such a computer system, as shown in FIG. 14, for example, the system is executed on a single CPU, or different systems connected by a local area network (LAN) or the like. Functions in the computer layer that define, for example, whether they are executed on CPUs (nodes), and how processes (or tasks) on these CPUs
All the functions in the process layer that define whether or not are executed are concealed by the abstract function of the configuration of objects in the object layer and the exchange of messages between objects. Therefore, the user can construct a required application only by defining the configuration of the objects and the messages exchanged between the objects.

[0004] Here, for example, when a large number of users develop applications in a distributed manner, it is often necessary to communicate data between tasks distributed for each user. For example, in a database system development application, the definition of an individual database may be performed in a client task executed on a client terminal, and the construction of a database based on those definitions may be performed in a server task executed on a server terminal. is there. In such a case, between the client task and the server task,
Communication of various data is required.

[0005] In a computer system that operates in units of objects, when data is communicated between different distributed tasks, it is naturally necessary to communicate in units of objects.

FIG. 15 shows a conventional technique of the object communication system. When one task wants to perform communication, the task issues a transmission request to a dedicated communication processing program that performs communication processing.

As a result, the communication processing program analyzes the structure of the transmission object that the task wants to transmit, and then assembles it into a data packet. Then, the communication processing program secures a transmission buffer of an amount necessary for transmitting the data packet, and copies the data packet to the transmission buffer.

After that, the communication processing program issues a transmission buffer transmission request to the lower layer communication processing program. On the other hand, in the task on the receiving side, although not particularly shown, the communication processing program also generates a structure of an object represented by data stored in the transmission buffer after receiving the transmission buffer, and shares the object in a predetermined order. The data stored in the memory is stored in the generated object.

[0009]

However, in the above-mentioned conventional example, the communication processing program must be able to recognize the structure of the object to be communicated. Therefore, when an object or a group of objects having a complicated structure is communicated, the communication processing program becomes complicated. Conversely, in order to make the communication processing program versatile, the structure of objects to be communicated is limited to a certain structure, and the types of objects that can be communicated are extremely limited. Have.

Further, in the above-mentioned conventional example, a communication error such as a communication buffer access error due to inconsistency between the communication processing program and the object to be communicated is likely to occur. Since the possibility of being communicated cannot be completely excluded, the communication processing program cannot properly transmit the object (for example, cannot be developed in the communication buffer), or the communication processing program appropriately receives the content (for example, the content of the communication buffer). There is also a problem that a state in which the object cannot be returned to the object is likely to occur, and the reliability during communication cannot be increased.

An object of the present invention is to realize object communication which is highly reliable and can support various types.

[0012]

SUMMARY OF THE INVENTION The present invention is based on an object communication system for communicating objects between different tasks.

[0013] First, there is a communication object having a transmission function and a reception function of communication data corresponding to the own object. The communication objects are, for example, objects forming a group having a client-supplier relationship, and each of the objects has a function of transmitting and receiving communication data corresponding to each object. Alternatively, the communication object is an object of a class derived from the base class, and has a function of transmitting and receiving members of the communication object corresponding to each of the classes related to the communication object, for example, a member function defined in each class. As

Next, the task on the receiving side has a communication object generation object (corresponding to a Receiver object) for generating a communication object corresponding to the received communication data. The communication object generation object generates a communication object corresponding to the communication data based on, for example, an identifier set in the received communication data. The communication object generation object owns a list object. The list object corresponds to a communication object generation routine object that generates communication objects of a predetermined group by determining communication data and corresponds to a plurality of groups. Can be configured to own multiple items. In this case, the communication object generation object determines any of the communication data received by each communication object generation routine object via the list object by, for example, an identifier added to the communication data. The communication object generation routine causes the communication object to generate a communication object corresponding to the communication data. Alternatively, the communication object generation object can be configured to own a database management object that owns a plurality of instances of the communication object as a database. In this case, the communication object generation object makes the instance of the communication object via the database management object determine the communication data received, for example, by the identifier attached thereto,
By causing the instance of any communication object corresponding to the communication data to copy the instance itself, a communication object corresponding to the communication data is generated.

With the above configuration, the transmission function of the communication object in the task on the transmitting side stores the communication object in, for example, a shared memory. On the other hand, the object for generating a communication object in the task on the receiving side is
Generate a communication object corresponding to the received communication data.

Then, the receiving function of the generated communication object receives, for example, communication data received as a shared memory as the communication object itself.

In the configuration of the invention described above, a communication protocol control means (Send) for controlling a communication protocol during a transmission operation by a communication object in a task on the transmission side and a reception operation by a communication object in a task on the reception side.
er object and Receiver object)
Can be further provided. Note that these controls may be performed by the communication object itself.

[0018]

In the present invention, taking advantage of the fact that the communication target is an object, each communication object has a transmission function and a reception function of communication data corresponding to its own object. As a result, the communication object itself performs its transmission and reception, for example, writing (unpackaging) to a shared memory, which is a communication buffer, and reading (packaging) from the shared memory. It is no longer necessary to consider the versatility of the object, and as a result, it is possible to remove restrictions on objects to be communicated and to communicate with various objects.

Further, as a result of the object itself transmitting and receiving the object, the possibility of occurrence of a communication error such as a communication buffer access error is drastically reduced, and the reliability during communication can be greatly improved.

Further, when the communication object itself has the communication function of the object, the communication function of the message is previously provided to the base class, and the communication object is defined as a class derived from the base class and included in the base class. By generating an object of a derived class that inherits the communication function of the object, the object of the application can easily have the communication function of the object.

In the task on the receiving side, the object for generating a communication object generates a communication object corresponding to the received communication data. In this case, by generating a communication object corresponding to the communication data based on the identifier set in the received communication data, the corresponding communication object can be generated by a simple control process. In addition, the communication object generation object owns a list object that owns a plurality of communication object generation routine objects that generate a predetermined group of communication objects corresponding to the plurality of groups, and thereby the type of the group of the received object is obtained. Is changed without modifying the communication object generation object for such a change.
It is possible to respond flexibly only by adding, deleting, or changing the communication object generation routine object to the list object. Alternatively, the communication object generation object owns a database management object that owns a plurality of instances of the communication object as a database, so that even if the received object is changed, the communication object generation is performed in response to such a change. It is possible to respond flexibly by simply adding, deleting, or changing the instance of the communication object with respect to the database management object without modifying the object for use.

On the other hand, when the object transmitted / received by the object itself is communicated according to a predetermined communication protocol, a function for performing control based on the communication protocol is provided as communication protocol control means, so that a control function based on the communication protocol is provided. Can be assigned to the communication protocol control means, and the application performing communication can realize communication in accordance with a predetermined communication protocol only by sending a message to the communication protocol control means. The possibility of occurrence can be reduced.

[0023]

Embodiments of the present invention will be described below in detail with reference to the drawings. <Structure of Embodiment> FIG. 1 is a diagram showing the structure of an embodiment of the present invention.

The present embodiment is realized as a client-server type Windows application system executed on a Windows system which is a window system for a personal computer. Further, the object in the present embodiment is realized by a computer system executing a program created based on the C ++ programming language.

The client task and the server task that communicate with each other are executed on one computer system or on different computer systems (nodes) (see FIG. 14) connected by a network. Further, a plurality of processes (tasks) exist in each node. However, since these relationships are hidden by the object, the application does not need to be aware of the computer system on which the task that is the object of the object communication is being executed. You only need to be aware of

The application object of the client task first generates a transmission object section 101 to be transmitted, and then transmits a transmission request message to the Sender object 102.

As will be described later, the Sender object unit 102 does not directly control writing to the transmission / reception buffer of the transmission object unit 101, but only controls overall transmission and reception of messages in the transmission process.

Upon receiving the transmission request message, the Sender object unit 102 transmits a buffer write request message 107 to the transmission object unit 101. Upon receiving this message, the transmission object unit 101 autonomously writes (unpackages) the members in the object into the transmission / reception buffer object unit 103. In addition, ostrstream described later
The object and the shared memory correspond to the transmission / reception buffer object unit 103.

Thereafter, the Sender object 102 requests the communication protocol control unit 104 to transmit the transmission / reception buffer object unit 103 to the server task.
As a result, the communication protocol control unit 104 transfers the above-mentioned transmission / reception buffer object unit 103 to the server task along a preset path. In addition, Wi described later
The ndows system corresponds to the communication protocol control unit 104.

Receiver object 10 of server task
5 receives the reception notification of the transmission / reception buffer object unit 103 from the communication protocol control unit 104, determines the identifier in the transmission / reception buffer object unit 103, and generates the reception object unit 106 which is the object to be received. In response, a buffer read request message 108 is transmitted.

Upon receiving this message, the receiving object unit 106 autonomously reads (packages) the data in the transmission / reception buffer object unit 103 into the members in the own object. The istrstream object described later is a part of the transmission / reception buffer object unit 103.

The detailed operation of this embodiment based on the above basic configuration will be described below. <Basic Configuration of Object> When starting an application, first, as shown in FIGS. 2 and 3, an application object NdbApp is used as a client task.
But also server object Serv as a server task
er are activated respectively. These objects are objects that define functions other than the functions related to the application or server interface.

Next, as shown in FIGS. 2 and 3, an application main user window object MainUserWindow (hereinafter, referred to as an application MainUserWindow object) and a server main user window are respectively set by an application object NdbApp and a server object Server. An object MainUserWindow (hereinafter referred to as a server MainUserWindow object) is generated one by one, and each is owned by the application object NdbApp and the server object Server. These objects are
Functions related to the interface between the application object NdbApp and the server object Server, for example, a function for displaying data on windows related to client tasks and server tasks displayed on the display device, a function for inputting commands on these windows, and a function for responding to the commands. An object that defines a display function and a DDE (Dynamic Data Exchange) function for realizing object communication related to the present invention. The application object NdbApp and server object Server
MainUs for application generated by pointer stored in each data member MainWindow
Access the erWindow object and the MainUserWindow object for the server.

Also, MainUserWindow for application
When the object and the MainUserWindow object for the server are generated, the sender object Sender (hereinafter, referred to as Sender object) and the receiver object Receiver (hereinafter, referred to as Sender object)
Receiver objects) are generated and owned by the MainUserWindow object for the application and the MainUserWindow object for the server.
Note that the MainUserWindow object for the application uses the pointers stored in its data members aReceiver and aSender to generate the Receive
Access er object and Sender object.

FIG. 6 shows MainUserWind for an application.
FIG. 3 is a diagram showing a class structure of an ow object and a MainUserWindow object for a server. Ma for application
Main user window class for application, which is the class of the inUserWindow object, and Main for server
The server main user window class, which is a class of the UserWindow object, is a class derived from a common DDE processing class that defines the DDE processing. The DDE processing class is a class derived from a common window processing class that is a base class that defines a basic interface of window processing.

Therefore, the main user window class for the application and the main user window class for the server inherit the function of the DDE processing class and the function of the window processing class by the inheritance (inheritance) function of the class. When the constructor of the application main user window class and the server main user window class is executed when the application MainUserWindow object and the server MainUserWindow object are generated, the constructor of the DDE processing class is called, and the constructor of the DDE processing class is called. By
As shown in Figure 6, Sender object and Receiver
An object is created.

These server objects Server and Receive
Under the control of the iver object, the communication target object generated by the application object NdbApp or the server object Server independently performs self-packaging to the shared memory or packaging from the shared memory for itself. Thereby, object communication between the client task and the server task is realized. <Path setting operation between client task and server task> Next, prior to the object communication operation between the client task and the server task, a path is set between the client task and the server task according to the DDE protocol. You. This operation will be described with reference to FIGS.

First, the user selects a path setting command on the window screen of the client task. As a result, the path setting member function of the application object NdbApp transmits a message SetTarget requesting the path setting to the Sender object (S in FIG. 2).
1). This message contains the name of the application to which the object communication is to be performed. For example, when a path from a client task to a server task is set, the application name is the name of the server task.

The Sender object executes a member function SetTarget corresponding to this message. Member functions
SetTarget is a Windows system function (hereafter, Window
s function), and calls a path setting request function InitiateDDE including the application name (S2 in FIG. 2).

The Windows function InitiateDDE calls the callback function WMDDEInitiate, which is a member function defined for the main user window object for the server of the server task, for the server.
It is inquired whether or not the topic name specified by the member function SetTarget of the nder object is supported by the Receiver object owned by the server MainUserWindow object (S3 in FIG. 3). In this case, the Windows system will use the Main
Maintains a handle that is the identifier of the UserWindow object, and this handle allows the server to use MainUserWind
Identify the ow object.

First, the callback function WMDDEInitiate is executed by the server's MainUserWindow object.
Message SetReturnTarget for setting the handle of the MainUserWindow object for the application, which is the handle of the return path, to the nder object
Is transmitted (S4 in FIG. 3). By executing the member function SetReturnTarget corresponding to this message, the Sender object sets the handle of the application MainUserWindow object in the data member of the Sender object.

Next, the callback function WMDDEInitiate
Responds to the above query by searching for a topic name preset in the Receiver object.
If the iver object determines that the queried topic name is supported, the Windows function SendMe
MainUserWind for application of client task that requested path setting by calling ssage
The handle of the server MainUserWindow object is notified to the ow object (S5 in FIG. 3).

The Windows function SendMessage notifies the handle of the server MainUserWindow object to the client task application MainUserWindow object by calling a callback function WMDDDEAck which is a member function defined in the client task application MainUserWindow object. 2 S6).

In response, the callback function WMDDEA
ck is a message SetTargetWindowHan for setting the handle of the server MainUserWindow object, which is the handle of the transmission path, to the Sender object owned by the application MainUserWindow object.
dle is transmitted (S7 in FIG. 3). The Sender object uses the member function SetTargetWin corresponding to this message
By executing dowHandle, the handle of the MainUserWindow object for the server is set to the data member in the self object.

Thus, the path setting operation is completed. <Overall operation of object communication between client task and server task> By using the path set between the client task and the server task by the above-described operation, an actual communication between the client task and the server task is performed. Object communication takes place. This operation will be described with reference to FIGS.

Here, for the sake of simplicity, the operation in the case of communicating a character string object will be described. Of course, any type of object may be used. First, the application object NdbApp creates an object ExString to be sent and a pointer aExS
Tring is held (S1 in FIG. 4).

Next, the application object NdbA
The pp object transmission member function is a message SetExData for linking the transmission target object ExString to the Sender object for the Sender object.
Is transmitted (S2 in FIG. 4). A pointer aExString to the transmission target object ExString is added to this message.

The Sender object executes a member function SetExData corresponding to this message. As a result,
The transmission target object ExString is owned by the Sender object (S3 in FIG. 4).

Subsequently, the application object Nd
The bApp object transmission member function transmits a transmission start message ExSend to the Sender object (S4 in FIG. 4).

The Sender object executes the member function ExSend corresponding to this message. As a result, a stream object ostrstream (hereinafter, referred to as an ostrstream object) for outputting a string on the memory is generated, and a pointer ogs to the stream object is held by the Sender object (S5 in FIG. 4). Furthermore, the pointer to the transmission target object ExString owned by the Sender object by the member function ExSend
An output message printOn to the ostrstream object specified by ogs is transmitted (S6 in FIG. 4).

In response to this, the transmission target object ExSt
ring is the member function printOn corresponding to this message
Execute As a result, the transmission target object ExString
Is autonomously output to the ostrstream object (S7 in FIG. 4). Thus, instead of the Sender object outputting the transmission target object ExString to the ostrstream object, the transmission target object ExStri
One of the most important features of the present invention is that the object is autonomously output by the member function printOn defined in ng and the transmission is executed.

Next, the member function Ex of the Sender object
Send sends a message pcount to the ostrstream object to query the length of the character string stored therein. The ostrstream object executes the member function pcount corresponding to this message. As a result, os
The length of the string stored in the trstream object is
The Sender object is notified (S8 in FIG. 4).

Further, the member function Ex of the Sender object
Send secures a shared memory having a size that can store the length of the character string notified from the ostrstream object, and then copies the character string stored in the ostrstream object to the shared memory (S9 in FIG. 4).

Note that the shared memory is implemented as a shared memory object, and the contents of the transmission target object ExString are not passed through the ostrstream object, and the member function prin is used.
It may be output directly to the shared memory object by tOn.

Member function ExSend of Sender object
Does a Windows function after copying to shared memory
By calling PostMessage, the Windows system is requested to transmit a shared memory based on the DDE protocol (S10 in FIG. 4). As a result, the shared memory becomes
posted to the main system queue of the ndows system,
Hereinafter, along the path previously set between the client task and the server task by the above-described setting operation,
Transmission of shared memory is performed under control of the ows system.

The Windows function PostMessage calls the callback function WMDDEData, which is a member function defined for the MainUserWindow object for the server of the server task, on the server's MainUserWindow object, so that the DDE message with the pointer to the shared memory added. To the server MainUserWindow object (S in FIG. 5).
11).

First, the callback function WMDDEData is executed by the Receiver owned by the MainUserWindow object for the server.
Message TakeoutO for requesting packaging of object from shared memory to object
bject is transmitted (S12 in FIG. 5).

The Receiver object owned by the server MainUserWindow object executes the member function TakeoutObject corresponding to the above message. This member function TakeoutObject is a stream object istrstream (hereinafter, istrst) for inputting a string to memory.
A ream object is generated, and a pointer st to the object is held (S13 in FIG. 5). The member function TakeoutObject sends a message to the operator "<<" of the istrstream object, and causes the operator to read the data in the shared memory into the istrstream object (S14 in FIG. 5).

Next, the Receiver object is
By determining the identifier set in the data read in the am object, it is determined that the object to be received is an ExString object. Then, the Receiver object creates an ExString object and holds a pointer aExString to the ExString object. Here, when the ExString object is generated, the data stored in the istrstream object is read into the ExString object autonomously by the constructor, which is a member function that is automatically executed at the time of generation. S15). The most important feature of the present invention is that the Receiver object does not read the contents of the istrstream object into the ExString object, but the ExString constructor independently reads data into the object and performs reception. This is one of the related major features.

Further, as described above, when the shared memory is realized as a shared memory object, the contents of the shared memory are stored in ExStri
ExString directly by constructor of ng object
It may be stored in the object. Next, Main for server
The Receiver object owned by the UserWindow object is Queue, which is the receive queue owned by it in advance.
Sends a queue connection message put to the object. By executing the member function put corresponding to this message, the Queue object connects the pointer aExString to the ExString object to the reception queue in the object itself (S16 in FIG. 5).

Then, at an appropriate timing, the object fetching member function of the server object Server
Receiv owned by MainUserWindow object for server
For the er object, a message Receiv to retrieve the received ExString object from the receive queue
The eData is transmitted (S17 in FIG. 5).

The Receiver object executes a member function ReceiveData corresponding to this message. This member function ReceiveData sends a queue fetch message get to the Queue object owned by the Receiver object. The Queue object connects the pointer aExString to the ExString object to the server object Server by executing the member function get corresponding to this message (S18 in FIG. 5).

As described above, the ExString object transmitted by the application object NdbApp shown in FIG. 4 is replaced with the server object Server shown in FIG.
Is received. <Details of Input / Output Processing of Object to / from Shared Memory> In the overall operation of object communication between the client task and the server task described above, the case where a simple character string object called an ExString object is communicated has been described.

Here, actually, as a first case, an object may form a group having a mutual client-supplier relationship with another object by a pointer to the other object. Many. In such a case, while the objects in the group maintain the relationship between the objects, the members included therein need to be communicated collectively.

In the second case, the object is often an object of a class derived from another parent class. In such a case, one object includes, in addition to members defined in a derived class that directly generates the object, members defined in a parent class of the derived class. Therefore, even when one object is communicated, members corresponding to each class included in the object need to be communicated while maintaining the inheritance relationship between the classes related to the object.

Further, as a third case, each object forming a group having a client-supplier relationship as in the first case is an object of a class derived from another parent class as in the second case. In many cases. In such a case, it is necessary for the objects in the group to be communicated collectively while maintaining the relationship between the objects and maintaining the inheritance relationship between the classes related to the objects. .

The details of the input / output processing of the object to the shared memory via the ostrstream object or the istrstream object in each of the first to third cases will be described. Object I / O to / from shared memory in first case
Processing First, as a first case, an ostrstream object or istrstre of a member included in each object forming a group having a client-supplier relationship.
Input / output processing to / from the shared memory via the am object will be described with reference to FIGS.

In the example of FIG. 7, an object called ShSchema having four data members (variables) owns two objects called ShArray having three and one data members, respectively, and further has three data members. ShArray objects with
A client-supplier relationship is shown that owns two objects called ShRecord with one data member.

First, on the client task side, the above-mentioned group of objects automatically shares members included in each group via the ostrstream object by the following processing corresponding to FIGS. 4S7 to S9 described above. Output to memory.

First, as a process corresponding to S1 of FIG. 4 described above, the application object NdbApp is a group of objects to be transmitted as a group of ShSchema objects, ShArray objects, and
And a group of ShRecord objects.

Next, as a process corresponding to S3 in FIG. 4 described above, a pointer to the ShSchema object is owned by the Sender object. Subsequently, FIG.
As a process corresponding to, MainUserWi for application
The member function ExSend (Sender.ExSend) of the Sender object owned by the ndow object is for the transmission target object ShSchema owned by the Sender object.
Send the message printOn.

In response to this, the ShSchema object becomes
The member function printOn (ShSche
ma.printOn) (S1 in FIGS. 7 and 8). The member function ShSchema.printOn firstly receives the address A of the shared memory shown in FIG. 8 through the ostrstream object.
After writing the identifier “ShSchema” to 0, the first and second non-set variables of the ShSchema object (FIG. 7) are written to the addresses A1 and A2 of the shared memory. Subsequently, the member function ShSchema.printOn recognizes that the third data member of the ShSchema object is an object pointer which is a set variable, and then, for the # 1 ShArray object indicated by the pointer,
Send the message printOn.

In response to this, the ShArray object # 1 sets the member function printOn (Sh
Array.printOn) is executed (S2 in FIGS. 7 and 8).
The member function ShArray.printOn is transmitted via the ostrstream object to the address A3 of the shared memory shown in FIG.
After the identifier “ShArray” is written into the array, the number of arrays (= 2) (FIG. 7) is written into the address A4 of the shared memory as the first non-set variable of the ShArray object # 1.
Next, the member function ShArray.printOn
By recognizing that the second data member of the object is an object pointer which is a set variable, a message printOn is transmitted to the # 1 ShRecord object indicated by the pointer.

In response to this, the ShRecord object # 1 sets the member function printOn (Sh
Record.printOn) (S3 in FIGS. 7 and 8).
The member function ShRecord.printOn is transmitted via the ostrstream object to the address A5 of the shared memory shown in FIG.
After writing the identifier “ShRecord” into the shared memory, the address of the ShRecord object # 1
One data member (FIG. 7) is written, and the process ends. As a result, member function prin of # 1 ShArray object that sent the message to # 1 ShRecord object
At tOn, control returns.

Member function pr of # 1 ShArray object
intOn is the # 1 ShArray object in the # 1 ShArray object.
By recognizing that the third data member next to the data member when sending the message to the Record object is an object pointer which is a set variable, the message is sent to the # 2 ShRecord object indicated by the pointer. Send printOn.

In response to this, the ShRecord object of # 2 sets the member function printOn (Sh
Record.printOn) (S4 in FIGS. 7 and 8).
The member function ShRecord.printOn is transmitted via the ostrstream object to the address A9 of the shared memory shown in FIG.
After writing the identifier “ShRecord” into the shared memory, the three data members (FIG. 7) of the # 2 ShRecord object are written to the addresses A10 to A12 of the shared memory, and the process ends. As a result, the member function pr of the ShArray object # 1 that sent the message to the ShRecord object # 2
Control returns to intOn.

The member function pr of the ShArray object # 1
intOn is the ShArray object of # 2 in the ShArray object of # 1.
By recognizing that there is no data member to be processed next to the data member at the time when the message was transmitted to the Record object, the processing ends as it is. As a result, a message was sent to the ShArray object # 1
Control returns to the ShSchema object member function printOn.

The member function printO of the ShSchema object
n is indicated by the pointer in the ShSchema object by recognizing that the fourth data member following the data member when the message is transmitted to the ShArray object # 1 is an object pointer that is a set variable. Send message printOn to # 2 ShArray object.

In response to this, the ShArray object of # 2 sets the member function printOn (Sh
Array.printOn) is executed (S5 in FIGS. 7 and 8).
The member function ShArray.printOn is transmitted via the ostrstream object to the address A1 of the shared memory shown in FIG.
After writing the identifier "ShArray" in No. 3, the array number (= 0) (FIG. 7) is written as the first non-set variable of the ShArray object # 2 at address A14 of the shared memory. Next, the member function ShArray.printOn
The process ends by recognizing that the ray object has no more data members. As a result, # 2
ShSche that sent a message to the ShArray object of
Control returns to the member function printOn of the ma object.

The member function printO of the ShSchema object
n recognizes that there is no data member to be processed next to the data member when the message is transmitted to the ShArray object of # 2 in the ShSchema object, and ends the processing as it is. As a result, ShSche
Control returns to the member function ExSend of the Sender object that sent the message to the ma object.

As described above, in the client task, the autonomous output to the shared memory via the ostrstream object of the group of objects including the ShSchema object, the two ShArray objects, and the two ShRecord objects is completed.

Next, on the server task side, after the contents of the above-mentioned shared memory are read into the istrstream object by the processing corresponding to the above-described S14 of FIG. 5, the following contents corresponding to the above-described S15 of FIG. Objects that should store the contents of the istrstream object are automatically generated, and the data stored in the istrstream object is automatically read into those objects by the constructor of those objects. As processing corresponding to S15 in FIG. 5, a Receiver owned by the server MainUserWindow object
The object has the identifier “ShSchema” set at the beginning of the data read into the istrstream object.
, It is determined that the object to be received first is a ShSchema object. As a result, the Receiver object generates a ShSchema object shown in FIG.

When the ShSchema object is generated, the constructor, which is a member function automatically executed at the time of generation, generates the non-set variables stored at the addresses A1 and A2 of the istrstream object. The first and second data members are stored in the created ShSchema object (see FIG. 7). This process is a process in which the direction of data is opposite to the process of S1 in FIG. Subsequently, the constructor recognizes that the identifier “ShArray” is stored at the address A3 of the istrstream object, and thereby, as shown in FIG.
Create ShArray object of # 1.

When the # 1 ShArray object is generated, the constructor first executes the ShSc
The object pointer to the generated # 1 ShArray object is stored as the third data member of the hema object (see FIG. 7). Next, this constructor stores the number of arrays (= 2) which is a non-set variable stored at the address A4 of the istrstream object as the first data member in the generated # 1 ShArray object ( (See FIG. 7). This processing is shown in FIG.
Is a process in which the direction of data is opposite to the process of S2. Subsequently, the above-described constructor recognizes that the identifier “ShRecord” is stored at the address A5 of the istrstream object, and thereby executes the ShRe of # 1 shown in FIG.
Create a cord object.

When the # 1 ShRecord object is generated, the constructor first
As the second data member of the ShArray object,
The object pointer to the generated # 1 ShRecord object is stored (see FIG. 7). Next, this constructor calculates the addresses A6 to A of the istrstream object.
8 is replaced with the generated # 1 Sh
The first to third data members are stored in the Record object (see FIG. 7). This process is a process in which the direction of data is opposite to the process of S3 in FIG. And
The constructor ends the process by recognizing that the identifier "ShRecord" indicating the object of the same class as the class of the self object is stored in the address A9 of the istrstream object. As a result,
Control returns to the constructor of the # 1 ShArray object that generated the # 1 ShRecord object.

The # 1 ShArray object constructor generates the # 2 ShRecord object shown in FIG. 7 by recognizing that the identifier "ShRecord" is stored at the address A9 of the istrstream object.

When the # 2 ShRecord object is generated, the constructor first
As the third data member of the ShArray object,
The object pointer to the generated # 2 ShRecord object is stored (see FIG. 7). Next, this constructor generates the address A10 of the istrstream object.
The data member stored in A12 is changed to the generated # 2
Is stored as the first to third data members in the ShRecord object (see FIG. 7). This process is a process in which the direction of data is opposite to the process of S4 in FIG. Then, the constructor recognizes that the address "A13" of the istrstream object stores the identifier "ShArray" indicating the object of the class above the class of the own object, and ends the process. As a result, the # 2 ShRecord object was created
Control returns to the constructor of the # 1 ShArray object.

The # 1 ShArray object constructor recognizes that the address "A13" of the istrstream object stores an identifier "ShArray" indicating an object of the same class as the own object, and terminates the processing as it is. As a result, # 1 ShAr
Control returns to the constructor of the ShSchema object that created the ray object.

The constructor of the ShSchema object recognizes that the identifier "ShArray" is stored at the address A13 of the istrstream object, and generates the # 2 ShArray object shown in FIG.

When the # 2 ShArray object is generated, the constructor first executes the ShSc
The object pointer to the generated # 2 ShArray object is stored as the fourth data member of the hema object (see FIG. 7). Next, this constructor stores the number of arrays (= 0) which is a non-set variable stored at the address A14 of the istrstream object as the first data member in the generated # 2 ShArray object ( (See FIG. 7). This process is a process in which the direction of the data is opposite to the process of S5 in FIG. Then, the constructor recognizes that there is no data after the address A14 of the istrstream object, and ends the processing. As a result, control returns to the constructor of the ShSchema object that generated the ShArray object # 2.

The constructor of the ShSchema object recognizes that there is no data after the address A14 of the istrstream object, and ends the processing as it is. As a result, control returns to the Receiver object that generated the ShSchema object.

As described above, in the server task, the reception of the group of objects including the ShSchema object, the two ShArray objects, and the two ShRecord objects ends. Object I / O to / from shared memory in second case
Processing Next, as a second case, the input / output processing to / from the shared memory via the ostrstream object or the istrstream object of the member corresponding to each class included in the object of the class derived from another parent class will be described with reference to FIGS. 11 will be described.

In the example of FIG. 9, the ShSchema class for generating an object called ShSchema is derived from a parent class called ShObject, and the ShObject class is TObjec
It derives from a parent class called t. That is, ShSc
The hema and ShObject classes are derived classes, and TObj
The ect class is a base class. At this time, the member functions printOn of the ShSchema class, ShObject class, and TObject class are overloaded, and a function suitable for each class is defined.

Under the class hierarchy shown in FIG.
When a ShSchema object, which is an object of the Schema class, is generated, the ShSchema object includes, as shown in FIG.
0, members defined in the TObject class, members defined in the ShObject class,
Includes members defined in ShSchema class.

ShSc having the data structure shown in FIG.
The operation when hema object communication is performed will be described below with reference to FIG. First, on the client task side, the ShSchema object is converted into a TObject class, a ShObject class, and a ShSchema object by the following processing corresponding to S7 to S9 in FIG.
The members in the ShSchema object corresponding to each class of the class are independently output to the shared memory via the ostrstream object.

First, as a process corresponding to FIG. 4S1 described above, the application object NdbApp is used as an object to be transmitted, as shown in FIG.
Create a hema object.

Next, as a process corresponding to S3 in FIG. 4, the pointer to the ShSchema object is owned by the Sender object. Subsequently, FIG.
As a process corresponding to, MainUserWi for application
The member function ExSend (Sender.ExSend) of the Sender object owned by the ndow object is for the transmission target object ShSchema owned by the Sender object.
Send the message printOn.

In response, the ShSchema object sets the member function printOn (ShSchem
a.printOn) (S1 in FIGS. 9 and 11). As shown in S1 of FIG. 11, the member function ShSchema.printOn first writes the identifier “ShSchema” at the address A0 of the shared memory via the ostrstream object, and then generates the ShSchema object.
By recognizing that the class is derived from the ShObject class, it calls the member function printOn (ShObject.printOn) defined in the ShObject class (S2 in FIGS. 9 and 11).

The member function ShObject.printOn is shown in FIG.
As shown in FIG. 2, first, the identifier “ShObje” is added to the address A1 of the shared memory via the ostrstream object.
After writing “ct”, it recognizes that the ShObject class is derived from the TObject class, so the member function printOn (TObject.pr
intOn) (S3 in FIGS. 9 and 11).

The member function TObject.printOn is shown in FIG. 11S
As shown in FIG. 3, first, the identifier “TObjec” is added to the address A2 of the shared memory via the ostrstream object.
After writing "t", the member in the ShSchema object corresponding to the TObject class is written after address A3. After that, the processing of the member function TObject.printOn is completed, and the member function ShObje which called this member function is called.
Control returns to ct.printOn (S in FIGS. 9 and 11).
4).

The member function ShObject.printOn writes the member in the ShSchema object corresponding to the ShObject class after the address Ai of the shared memory via the ostrstream object, as shown in S4 of FIG. After that, the processing of the member function ShObject.printOn ends, and the member function ShSchem that called this member function
The control returns to a.printOn (S in FIGS. 9 and 11).
5).

The member function ShSchema.printOn is shown in FIG.
As shown in FIG. 5, a member in the ShSchema object corresponding to the ShSchema class is written via the ostrstream object after the address Aj of the shared memory. After that, the processing of the member function ShSchema.printOn ends, and Send that sends the message to the ShSchema object
Control returns to the member function ExSend of the er object.

As described above, in the client task, the independent output of the ShSchema object generated from the derived class ShSchema to the shared memory via the ostrstream object ends.

Next, on the server task side, after the contents of the above-mentioned shared memory are read into the istrstream object by the processing corresponding to S14 of FIG. 5, the following processing corresponding to S15 of FIG. ShSche to store the contents of the istrstream object
The ma object is automatically created and the TObject class, ShObject class, and ShSc contained in the object
The data stored in the istrstream object is autonomously converted by ShSche by each constructor of the hema class.
First, as a process corresponding to FIG. 5S15 described above, the receiver object owned by the server MainUserWindow object has the identifier “ShSchema” set at the head of the data read into the istrstream object. Is determined, the object to be received is a ShSchema object.
As a result, the Receiver object is shown in FIG.
Create ShSchema object.

When the ShSchema object is generated, a constructor which is a member function automatically executed at the time of the generation is started. This constructor uses the address A1 of the istrstream object.
Data stored in derive ShSchema class
By recognizing that the identifier is "ShObject" indicating the ShObject class, the constructor defined by the ShObject class is called.

The constructor defined in the ShObject class is that the data stored in the address A2 of the istrstream object is the TObj derived from the ShObject class.
By recognizing the identifier "TObject" indicating the ect class, the constructor defined in the TObject class is called as it is.

The constructor defined by the TObject class includes a member corresponding to the TObject class stored after the address A3 of the istrstream object.
It is stored in the generated ShSchema object (see FIG. 10). This process is a process in which the direction of the data is opposite to the process of S3 in FIG. After that, the processing of the constructor defined in the TObject class ends, and control returns to the constructor defined in the ShObject class that called the constructor.

The constructor defined by the ShObject class includes a member corresponding to the ShObject class stored after the address Ai of the istrstream object,
It is stored in the generated ShSchema object (see FIG. 10). This process is a process in which the direction of data is opposite to the process of S4 in FIG. Thereafter, the processing of the constructor defined in the ShObject class ends, and control returns to the constructor defined in the ShSchema class that called the constructor.

The constructor defined in the ShSchema class includes a member corresponding to the ShSchema class stored after the address Aj of the istrstream object.
It is stored in the generated ShSchema object (see FIG. 10). This process is a process in which the data direction is opposite to the process of S5 in FIG. After that, the processing of the constructor defined in the ShSchema class ends, and control returns to the Receiver object that generated the ShSchema object.

As described above, in the server task, the TObject class included in the ShSchema object,
The reception of the members corresponding to each of the ShObject class and the ShSchema class ends.

In the example described above, as shown in FIG. 9, the ShSchema class and the ShObject class are each one.
Although derived from one parent class, these classes may be derived from more than one parent class. In this case, the member function printOn and constructor of each parent class are sequentially executed, so that members defined in those parent classes are input / output to / from the shared memory. Object I / O to / from shared memory in third case
Processing Finally, as in the third, the members included in each object includes object classes derived from another parent class form a group having a client supplier relationship, ostrstream object or istr
The input / output processing for the shared memory via the stream object will be described.

For example, a case where a ShSchema object is generated from a derived class ShSchema class shown in FIG. 9 in a group of objects having a client-supplier relationship shown in FIG. 7 will be described.

First, on the client task side, the above-mentioned group of objects automatically shares members included in each group via the ostrstream object by the following processing corresponding to the above-described FIGS. 4S7 to S9. Output to memory.

In this case, when the member function printOn of the ShSchema object is executed as a process corresponding to S1 in FIG. 8 in the first case described above, it is defined by the ShObject class as described with reference to FIG. Member function printOn and the member function printOn defined in the TObject class are called sequentially. As a result, ostr
The data corresponding to the storage contents of the addresses A1 to (Aj-1) in FIG. 11 is stored in the storage area corresponding to the addresses A0 and A1 in the shared memory in FIG. The data corresponding to the storage contents after the address A1 of the shared memory in FIG.

Next, on the server task side, the contents of the above-mentioned shared memory are read into the istrstream object by the processing corresponding to S14 of FIG. 5 described above, and are shown below corresponding to S15 of FIG. Objects that should store the contents of the istrstream object are automatically generated by the processing that is performed, and the data stored in the istrstream object is automatically read into those objects by the constructor of those objects. In this case, When the constructor of the ShSchema object is executed as a process corresponding to S1 in FIG. 8 in the first case described above, the constructor defined in the ShObject class and TO
Constructors defined in bject class are called sequentially. As a result, the address A of the shared memory in FIG.
FIG. 1 stored in a storage area corresponding to between 0 and A1
FIG. 8 shows that data corresponding to the storage contents of the addresses A1 to (Aj -1) of FIG.
As described in the first case, the data corresponding to the storage content after the address A1 of the shared memory is a ShSchema object, a ShArray object of # 1, a ShRecord object of # 1 and # 2, and a ShRecord object of # 2. ShArra
will be stored in the y object. <Details of Object Assembling Process by Receiver Object> As described above in S15 of FIG.
The iver object determines the object to be received by determining the identifier set in the data read into the istrstream object,
A receiving object is generated using a class corresponding to the determined object among the classes defined in the er class object. Thus, Receiver object needs to know whether advance what objects are received. Here, when the type of the received object is changed in the middle,
Modifying the member function of the ceiver object is cumbersome and lacks versatility.

The following describes two methods of assembling an object by a Receiver object that can flexibly respond to a change in the type of the received object.

First, FIG. 12 is a diagram showing details of the first method of assembling an object by a Receiver object. In FIG. 12, the processing for assembling a specific group of objects is summarized as an Exit routine object, which is owned and managed by a List object, and the List object is
Owned by the object.

Then, the Receiver object reads the identifier set in the data read in the istrstream object in the process corresponding to S15 of FIG. 5 described above, and sends a request message including the identifier to the List object.
Send to object.

The List object transmits a message including the above identifier to each Exit routine object registered in the list, and each Exit routine object determines the identifier, and the Exit routine object corresponding to the identifier is transmitted. Constructs an object corresponding to the identifier. For example, if the identifier is “F”, the conditional statement “ca
A condition is satisfied in "se F", and an F object is assembled as a process corresponding to the conditional statement.

When a group of objects to be received is added by the configuration shown in FIG. 12, an Exit routine object for assembling the group of objects to be added is prepared, and the Exit routine object is prepared by the List object. Should be added. When a group of received objects is deleted, the Exit routine for assembling the group of objects to be deleted may be deleted, and may be deleted from the list managed by the List object.

Therefore, even if the group of objects to be received is changed, the receiver cannot receive such a change.
It is possible to respond flexibly without modifying the member function of the object. Note that the List object is an object that performs well-known list processing, and has an interface that can easily add, delete, or change a list.

Next, FIG. 13 is a diagram showing details of a second method of assembling an object by a Receiver object. In FIG. 13, instances (models) of objects to be received are registered in advance as databases such as objects A to F, and they manage a list of instances of those objects as a database and perform a query function for them. The List / Dictionary object has the List / Dictionary object, and the List / Dictionary object is owned by the Receiver object.

Then, the Receiver object reads the identifier set in the data read into the istrstream object in the process corresponding to S15 of FIG. 5 described above, and sends a request message including the identifier to the List object.
Send to / Dictionary object.

The List / Dictionary object sequentially transmits a message including the above identifier to each object registered as a database in a list of the List / Dictionary object, and inquires whether each object corresponds to the identifier. As a result, the object corresponding to the identifier copies its own object, thereby generating a cloned object as a received object. For example, if the identifier is “C”, the object C corresponds to the identifier “C”. Then, the object C generates a new object C and passes it to the Receiver object as a reception object.

Here, as described above with reference to FIGS. 7 and 8, when a group of objects is received, the constructor of the object received at a certain point in time may or may not be passed through the Receiver object. By directly sending a query message to the List / Dictionary object, a new clone object is created for the object corresponding to the message in the database, and this is set as a new received object in the group. .

As described above, when a group of objects to be received is added by the configuration shown in FIG. 13, an instance of the added object may be added to the database. When a group of received objects is deleted, an instance of the deleted object may be deleted from the database.

Therefore, even if the group of the received objects is changed, the receiver is not affected by such a change.
It is possible to respond flexibly without modifying the member function of the object. Note that the List / Dictionary object is an object that performs a well-known database access process, and has an interface that can easily add, delete, or change an instance of each object that is a component of the database. <Other Embodiments> In the above-described embodiments, the operation in the case where an object is transmitted from a client task to a server task has been described. However, the same applies to the case where an object is transmitted from a server task to a client task. . In this case, a Sender object is generated by the server task, and a Receiver object is generated by the client task.

Although the embodiment described above is for an application operating under a window system, the present invention can be applied to various types of systems as long as the system operates in an object-oriented manner.

Further, the objects in the embodiments described above are realized by a computer system executing a program created based on the C ++ programming language, but any object processing system can be used. May be realized on a simple system.

[0130] In addition, the function of the Sender object in the above-described embodiment may be encapsulated in a communicated object.

[0131]

According to the present invention, since the communication object itself transmits and receives its members, it is not necessary to consider the versatility of the communication data, and as a result, the restriction on the communication target object is eliminated. And various objects can be communicated.

Further, as a result of the object itself transmitting and receiving its members, the possibility of occurrence of a communication error such as a communication buffer active error is drastically reduced, and the reliability at the time of communication can be greatly improved.

Further, when the communication object itself has the communication function of its members, the base class is provided with the communication function of the message in advance, and the communication object is defined as a class derived from the base class. By generating as a derived class object that inherits the communication function of the member in the above, the object of the application can easily have the communication function of the member.

On the other hand, when the communication object generation object generates a communication object corresponding to the received communication data in the task on the reception side, the communication object corresponding to the communication data is identified by the identifier set in the received communication data. By generating a communication object to execute, a corresponding communication object can be generated by a simple control process.

The communication object generation object owns a plurality of list objects corresponding to a plurality of communication object generation routine objects for generating a predetermined group of communication objects. Even if the type of the group is changed, the communication object generation object is not modified for such a change,
Only by adding, deleting, or changing the communication object generation routine object to the list object, it is possible to flexibly cope with the list object.

Alternatively, even if the received object is changed by the communication object generation object owning a database management object which owns a plurality of instances of the communication object as a database, such an object is not affected. It is possible to respond flexibly by simply adding, deleting, or changing the instance of the communication object to the database management object without modifying the communication object generation object.

On the other hand, when members transmitted and received by the object itself are communicated according to a predetermined communication protocol, the function of performing control based on this communication protocol is made into an object as a communication protocol control object, so that control based on the communication protocol is performed. The function can be encapsulated in the communication protocol control object, and the communication application can realize communication according to the predetermined communication protocol only by sending a message to the communication protocol control object, and the load on the communication of the object in the application can be realized. Further, the possibility of occurrence of an error can be reduced.

[Brief description of the drawings]

FIG. 1 is a configuration diagram of an embodiment of the present invention.

FIG. 2 is an explanatory diagram (a client task side) of a path setting operation.

FIG. 3 is an explanatory diagram (a server task side) of a path setting operation.

FIG. 4 is an explanatory diagram (a client task side) of an object communication operation.

FIG. 5 is an explanatory diagram (a server task side) of an object communication operation.

FIG. 6 is a diagram showing a class structure of a main user window object.

FIG. 7 is a diagram illustrating an example of a group of objects.

FIG. 8 is a diagram showing a storage form of a group of objects in a shared memory.

FIG. 9 is a diagram illustrating an example of an inheritance relationship of a derived class.

FIG. 10 is a diagram showing an example of an object of a derived class.

FIG. 11 is a diagram showing a storage form of an object of a derived class in a shared memory.

FIG. 12 is a diagram showing details (No. 1) of an object assembling process by a Receiver object.

FIG. 13 is a diagram showing details (No. 2) of an object assembling process by a Receiver object.

FIG. 14 is a configuration diagram of a computer system having an object as a basic element.

FIG. 15 is a configuration diagram of conventional object communication.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 101 Transmission object part 102 Sender object 103 Transmission / reception buffer object part 104 Communication protocol control part 105 Receiver object 106 Reception object part 107 Buffer write request message 108 Buffer read request message

────────────────────────────────────────────────── ─── Continuation of the front page (56) References JP-A-5-20090 (JP, A) JP-A-5-225012 (JP, A) JP-A-6-149600 (JP, A) Interface September 1991 No. (Vol. 17, No. 9), CQ Publishing Co., pp. 219-233 (Patent Office CSDB literature number: CSNW199800205006) (58) Fields investigated (Int. Cl. ⁷ , DB name) G06F 9/44 G06F 9/46 G06F 13/00 G06F 15/16 JICST file (JOIS) CSDB (Japan Patent Office)

Claims (6)

(57) [Claims] In an object communication system between different tasks , a communication object which is an object communicated between the tasks.
The project, and transmit and receive functions of the communication data corresponding to the contents of its own object to the receiving side of said tasks, and objects communication objects generated to generate the communication object corresponding to the received the communication data have the transmission function with the communication objects in said task sender writes the communication data corresponding to the content of the free-object in the sending and receiving buffer object, the communication written in the reception buffer object
The communication data is transmitted to a receiving task, the communication object generating object in the receiving task generates the communication object corresponding to the received communication data, and the generated communication object has The receiving function reads the communication data of the transmission / reception buffer object into the own object when the own object is generated. 2. A communication protocol control means for controlling a communication protocol during a transmission operation by the communication object in the task on the transmission side and a reception operation by the communication object in the reception task. 2. The object communication method according to claim 1, wherein: 3. The communication object is an object forming a group having a client-supplier relationship, and each of the objects has a function of transmitting and receiving communication data corresponding to each object. The object communication method according to claim 1, wherein the object communication method includes: 4. The communication object according to claim 1, wherein the communication object is an object of a class derived from a base class, and has a function of transmitting and receiving members of the communication object corresponding to each of the classes related to the communication object. Item 4. The object communication method according to any one of Items 1 to 3. 5. The communication object generating object generates the communication object corresponding to the communication data according to an identifier set in the received communication data. The object communication method according to any one of claims 1 to 4. Wherein said communication object generation object owns a list object, the list object, a communication object generation routine object that generates a communication object of Jo Tokoro group own multiple corresponding to the plurality of groups The list object generates the communication object.
Transmitting the communication data to a routine object, wherein each of the communication object generation routine objects includes:
Based on the identifier included in the received communication data,
The object communication method according to any one of claims 1 to 5 , wherein a communication object to be set up is determined, and the communication object corresponding to the communication data is generated.