WO2000010096A1

WO2000010096A1 - Methods and apparatus for the distribution of data constructs, such as object-oriented objects, among processes

Info

Publication number: WO2000010096A1
Application number: PCT/US1999/017940
Authority: WO
Inventors: John Gage
Original assignee: Wonderware Solutions, Inc.
Priority date: 1998-08-14
Filing date: 1999-08-10
Publication date: 2000-02-24

Abstract

A method of distributing a data constructs, such as an object-oriented programming 'object', includes transmitting to the processes (12-16) a message that identifies the selected data construct and that identifies its type. That type can constitute the name of a data construct manager, or object manager (30), that can be executed within each process (1, 2, 3) to create, destroy or access and update (68, 70) a local copy of a corresponding data construct. The method further includes responding, e.g., within each of the processes (12-16), to the message by invoking a data construct manager (30) that corresponds to the 'type' identifier in the message. The data construct manager (30) is used to access a data construct that is associated with (e.g., local to) the respective process and that corresponds to the data construct identified in the message.

Description

METHODS AND APPARATUS FOR THE DISTRIBUTION OF DATA CONSTRUCTS, SUCH AS OBJECT-ORIENTED OBJECTS, AMONG

PROCESSES

Background of the Invention

This application claims the benefit of priority of U.S. Patent Application Serial No. 60/096,516, filed August 14, 1998, for "Method and Apparatus for the Distribution of Data Constructs, such as Object-Oriented Objects, Among

Processes," the teachings of which are incorporated herein by reference.

This invention pertains to digital data processing and, more particularly, to methods and apparatus for distribution of data constructs, such as object-oriented programming "objects," among a plurality of processes.

Difficulties in managing data have grown with the complexity of computer systems and their increased use in business and society as a whole. One area in which this is most evident is in enterprise-wide management information systems. As companies grow, they typically open offices at disparate locations around the country or around the world. Computer systems at those sites are linked to provide a constant flow of information to and from corporate headquarters.

In theory, data processing systems employed within a given enterprise would maintain and store data in identical formats and run the same production, analysis and reporting software. Thus, inventory management or accounting data, for example, generated by one site could be readily integrated with that generated at other sites. Enterprise-wide data, such as pricing information, could likewise be distributed by corporate headquarters and readily utilized at satellite offices.

Unfortunately, the theory of information management usually varies widely from practice. Thus, while two offices within an enterprise may use the same basic data formats, there may nevertheless be differences in the ordering and types of data. A corporate office in Britain, for example, may record sales in pounds, while an office in France records them in francs. Software versions may vary from office to office, as well. Thus, the Indian manufacturing site of a multinational corporation may utilize a different release of a database management package than the Taiwanese site.

One solution to this problem is provided in United States Patent No.

5,493,671, assigned to the assignee hereof. It discloses inter alia a data conversion apparatus and method that translates information in a first relational database for use by a first version of a computer program into information stored in a second relational database for use by a second version of that computer program. The conversion is performed as a function of the identities of the first and second versions, utilizing a table of procedures for translating individual records or fields of information as between the respective databases.

The increasing complexity of the software and data storage techniques, including those inherent to the new object-oriented technologies, demands still better systems for the distribution of data. That is an object of this invention.

More particularly, an object of the invention is to provide improved methods and apparatus for the distribution of data structures among processes. A related object is to provide such methods and apparatus for the distribution of updates, such as additions, deletions and changes, among processes that share copies of common data.

A further object of the invention is to provide such methods and apparatus as are adapted for use with both old and new technologies, such as object-oriented programming and their attendant data storage structures.

Still further objects of the invention are to provide such methods and apparatus that can utilize conventional communications media and techniques to transfer basic units of information among processes. Yet still further objects of the invention are to provide such methods and apparatus as are platform independent.

Summary of the Invention

These and other objects are attained by the invention which provides, in one aspect, a method of distributing a selected data construct, such as an object-oriented programming "object," to one or more processes. The method includes transmitting to the processes a message that identifies the selected data construct and that identifies its type. According to a preferred practice of the invention, the "type" constitutes the name of a data construct manager, or object manager, that can be executed within each process to create, destroy or access and update a local copy of a corresponding data construct. Names of the data construct, type and/or manager can be adapted from those used in a given one of the processes or can represent terms/symbols common to all of the processes.

The method further includes responding, e.g., within each of the processes, to the message by invoking a data construct manager that corresponds to the "type" identifier in the message. In a preferred practice, this constitutes instantiating an object of the class specified in the message. In alternate practices, it constitutes invoking a software function or object otherwise capable of creating, destroying or accessing and updating data constructs of the type specified in the message.

Regardless of how the data construct manager is designated or invoked, a method according to this aspect of the invention calls for use of the manager in accessing a data construct that is associated with (e.g., local to) the respective process and that corresponds to the data construct identified in the message. That data construct may be identically named with the construct identified in the message or it may bear a local name derived from or otherwise corresponding to the construct named in the message. According to further aspects of the invention, the message that is broadcast to the processes identifies a data construct (and its "type") that has been created, updated and destroyed by one of the processes. Software resident on each of the processes, for example, can detect whenever a local data construct is updated. That software can cause an message to be generated and transmitted to the other processes so that they can update their local copies as well. In this way, data coherence can be maintained among even remote systems.

Still further aspects of the invention provide methods as described above in which the message transmitted to the processes includes one or more attributes of the selected data construct, in addition to its name and "type." This attribute can include, for example, a value for the data construct or, in the more typical case of a data construct that constitutes many fields, the identities of one or more fields and their respective values. The data construct managers, according to this aspect of the invention, can use the attribute information to update their local copies of the corresponding data construct.

In yet still further aspects of the invention, a sequence number can be included in the message. This can be, for example, a count that reflects the number of times that the selected data construct has been updated. Receiving processes can check that count, before updating their local copies of the selected data construct, as a check of data integrity. Thus, for example, if the message indicates that the selected data construct has been updated five times, yet one of the receiving processes has only received three prior update message, an error can be signaled.

These and other aspects of the invention are evident in the drawings and in the description that follows. Brief Description of the Drawings

A more complete understanding of the invention may be attained by reference to the drawings, in which:

Figure 1 depicts the architecture and data flow of a system according to the invention;

Figure 2 depicts the operational flow of a system according to the invention; and

Figure 3 depicts the structure of an update message in a system according to the invention.

Detail Description of the Illustrated Embodiment

Figure 1 depicts a system 10 according to the invention. The system includes a plurality of processes 12, 14, 16 connected by a communications medium 18. In the illustrated embodiment, each of the processes 12 -16 resides on a separate digital data processor (not shown), though in other embodiments one or more of the processes may reside on the same digital data processor. Although only three processes are depicted, those skilled in the art will appreciate that the invention may be practiced with greater or fewer numbers of processes.

Communications medium 18 represents any medium that supports the transmission of information, such as the messages discussed below, between processes. This includes interprocess communications mechanisms, local area networks (LANs), wide area networks (WANs) and the Internet, among other media.

Processes 12 -16 are associated with respective data stores 20 -24, as illustrated. These represent any dynamic or static media capable of storing data constructs. Such media include microprocessor memory (e.g., RAM), tape drives, CDROMs and, more typically, disk drives. Disk drive stores are preferably configured as databases and include attendant database managers (not shown), though these and other stores may be arranged in any other manner as well.

The data constructs may constitute bits, bytes, words, long words, arrays, records, structs or other structures representing or storing values or other attributes. In a preferred embodiments, they constitute "objects," as that term is defined in object-oriented programming (OOP) contexts, comprising both data and method attributes. Many different types of data constructs (e.g., different "classes" of objects) may be associated with the processes 12 -16 and stored in their respective data stores 20 -24. A feature of the illustrated embodiment is its ability to distribute data constructs of different types among the processes.

A more particular feature of the illustrated embodiment is its ability to distribute information among the processes 12 -16 to maintain the coherence of information they have in common. Thus, though the data sets maintained by the processes may be substantially independent, for purposes of the discussion that follows it is assumed that they maintain (or are desired to maintain) at least some common information. It is further assumed that common information is maintained in data constructs that correspond to one another —regardless of whether those data constructs share identical names, types or formats.

By way of example, if processes 12 -16 represent resource tracking and allocation systems at respective manufacturing sites of a multinational automobile company, processes 12 and 16 may maintain parts information in a class of OOP objects referred to as AUTO PART whose data members include WEIGHT and COST, each of which is a floating point attribute or value. Runtime data constructs, or objects, created from this class and maintained in stores 20 and 24, respectively, may be named, for example, ENGINE, SEATS, and TRIM. Similar information maintained by process 14 may be represented by objects in the class CAR PART whose sole data member is ACCOUNTING UNITS, which is an integer. Runtime objects from that class maintained in store 22 may be named MOTOR, SEATING and SIDING.

Illustrated process 12 includes a user application 26 that updates and, more particularly, creates, destroys and changes data constructs in the respective data store 20. Application 26 may perform these functions directly or via other interface mechanisms, such as database management systems or object-oriented database management systems. Though not illustrated processes 14 and 16 may also include a user applications for accessing data constructs in their respective data stores 22, 24. Those skilled in the art will appreciate that the invention is not limited to embodiments in which a user application causes a data store to be updated but, rather, is more generally applicable to distribution of objects regardless of the instrumentality by which they are created, destroyed or changed.

As indicated by Step 60 of Figure 2, element 28 determines whether a data construct in data store 20 has been updated, i.e., created, destroyed or changed. This may be accomplished by monitoring information passed between user application 26 and its data store 20, or by any other technique such as checking time stamps associated with the data constructs, comparing old and new copies of them on the data store 20, and so forth. In the illustrated embodiment, element 28 is configured to intercept calls made by the user application to an OODBMS that interfaces with the data store 20.

Upon detecting that a data construct (or object) has been updated, update monitor 28 generates an update message for alerting the other processes 14, 16.

See Step 62 of Figure 2. That message identifies the data construct, its type, and at least the attributes of it which have changed. Though not shown in the drawing or discussed in the examples below, it will be appreciated that processes 14, 16 can include similar mechanisms for generating update messages for alerting the processes of changes. The data construct can be identified via the name by which it is known in a given one of the processes or via a terms/symbols common to all of the processes. Continuing the example above, if the object ENGINE were updated, the construct identifier might be chosen as "ENGINE," i.e., the name used by process 12 itself. Were a common enterprise-wide name assigned to the construct, that name could be used instead. It would even be possible (though less efficient) to generate several otherwise identical update messages, each using an identifier known to the message recipient, e.g., "ENGINE" for messages targeted to process 16 and "MOTOR" for messages targeted to process 14.

Likewise, the type identifier in the update message can be that by which the data construct is known in a given one of the processes or via a term common to all of the processes. Continuing the example above, the class identifier "AUTO PART" could be used as, perhaps, could a more common term, like "PART." Moreover, in the event multiple update messages were generated, each could use an identifier known to the targeted process.

According to a preferred practice of the invention, the type identifier used in the update message does not identify the type or OOP class of the data construct per se but, rather, identifies a data construct manager —i.e., a subroutine, function,

OOP object class or other such functionality —that can be executed within each of the recipient processes to create, destroy or otherwise access a respective local data construct corresponding to the data construct updated in process 12. Where the data constructs are objects, the data construct manager is referred to as an object manager.

In addition to the data construct and type identifiers, the update message identifies one or more attributes of data construct that were updated by process 12 (i.e., in addition to the name and type of that construct). Those attributes identify changes made to the data construct. Thus, for example, if the user application 26 changes the value of the attribute WEIGHT in the object ENGINE stored in data store 20, the update message lists the new value of that attribute, preferably, along with the name of the attribute (e.g., "WEIGHT" or another term associated with that attribute by the other processes). If the user application also changes the value of the attribute COST in the copy of object ENGINE associated with process 12, the update message can also list the new value of that attribute, again, preferably, along with the name of the attribute.

The attribute portion of the update message may explicitly or implicitly reflect the creation of a data construct. For example, if process 12 creates a new object FUEL NJECTORS in class AUTO_PART, the update message lists the values (and names) of all of the attributes of that new object. An optional flag or status field contained in the update message can identify it as pertaining to a newly created object.

Likewise, the update message can reflect the destruction or deletion of a data construct. For example, if process 12 were to delete an object

CARBURETORS in class AUTO_PART, the update message can list "null" values for all of the attributes of that object. Preferably, a status field is provided instead, identifying the object as having been deleted.

In addition to identifying the name, type and updates to the data construct modified by process 12, the update message can provide a sequence number of count reflecting the number of times that the construct has been changed. Processes receiving the update message can check that count, before updating their local copies of the selected data construct, to better insure data coherency. See Step 70 of Figure 2. For example, if the user application has updated the object

TRIM five times, the update monitor can include that count in the respective update message. Had the receiving process 14 only received three prior updates for that object, it could signal an error on receiving the update message. In response to such signaling, a message can be logged to the system administrator and the data construct in process 14 corresponding to the object TRIM in process 12 can be restored from "scratch." According to a one embodiment of the invention, update messages are comprised of a header portion and a detail portion as shown Figure 3. The header includes the Program ID a Reference Object, or "naming" object, that is instantiated by each receiving process 14, 16 to store the identity of the local data construct to be updated. In the illustration, this is set to "AUTO_PARTS.REF", indicating that the receiving processes are to instantiate objects of the class AUTO_PARTS.REF as naming objects.

The header also includes the Program ID of a Manager Object that is used by the receiving processes to access and update local copies of the data constructs identified in the update messages. In the illustration, this is set to "AUTO_PARTS". By convention, the Program ID of the Manager Object has a name similar, but not identical, to that of the class of the data construct to be updated. Specifically, a manager object of class AUTO_PARTS will be instantiated and used by the receiving processes to access and update a local data construct of type AUTO PART. In this regard, the illustrated a different manager object is supplied for each class of local data constructs that may specified in the update messages.

The detail portion of the update message includes detail records that specify, not only the name of the updated data construct, but also its attributes —or, at least, those attributes which were changed by the process that generated the update message. Each such attribute is defined by three fields: a DispID, which constitutes a unique, enterprise-wise identifier for the attribute; a Value, which defines the value of that attribute; and a Value Type, which defines the data type of the Value. The name of the data construct is specified in this manner, as well.

Thus, as shown at the bottom of Figure 3, the sample update message includes a DispID of 51 , indicating that the value that follows is the name of a data construct —in this case ENGINE. The designator "string" reflects that the name is supplied in the form of a text string. The update message also includes a DispID of 52, indicating that the value that follows pertains to the WEIGHT attribute of the ENGINE object. The value 355.22, in the example, is a floating point number, as further specified in the update message.

In the illustrated embodiment, the update message are sent or broadcast over communications medium 18 by communications manager, which encodes or otherwise formats the message appropriately for transmittal over that medium. See Step 64 of Figure 2.

Not all changes made by user application 26 or, more generally, by process 12 to data constructs in data store 12 necessarily result in generation of an update message by monitor 28. Nor do all update messages generated by monitor 28 result in messaging of the other processes 14, 16. Rather, data tables or other logic employed with the monitor 28 and communications manager 34 can identify specific data constructs (or types thereof) for which update message must be generated. Such tables or logic can additionally specify processes to which such message are to be routed.

Communication managers 36, 38 in processes 14, 16, respectively, receive update messages transmitted by process 12, decode those message, and commence action on them. Particularly, if an update message specifies a data construct manager in place of the type of the data construct, each of the communication managers 36, 38 instantiates or invokes the specified manager, passing to it the name of the local data construct to be updated. See Step 66 of Figure 2. Thus, in the case of an embodiment that utilizes an update message format as shown in Figure 3, object managers 30, 32 are instantiated from types corresponding to the

Program ID of Manager Object specified in the update message. Alternatively, if the update message directly specifies the type or class of the data construct, each communication managers 36, 38 instantiates or invokes a data construct manager appropriate for that type of data construct or object, again, passing to it the name of the data construct to be updated. In an embodiment that utilizes an update message format as shown in Figure 3, communication managers 36, 38 instantiate respective naming objects 40, 42 prior to invoking the object managers 30, 32. See Step 65 of Figure 2. As mentioned above, those naming objects are instantiated from classes corresponding to the Program ID of Reference Object included in the header of the update message. Upon instantiation, the dispatch methods of those naming objects are used to decode the name of the data construct from the update message. That name may be contained in a single detail record, e.g., as in the example shown in Figure 3, or it may comprise components in several detail records.

Upon invocation, each data construct manager 30, 32 accesses, in its local data store 22, 24 a data construct corresponding to that identified in the update message —or, where extant, in the naming objects 40, 42. See Step 68 of Figure 2.

Where convention permits, the data construct manager (or object manager

30, 32) can take the name of the corresponding data structure directory from that supplied in the update message (or naming object 40, 42). Thus, for example, if an update message generated by process 12 specifies updating an object ENGINE of class AUTO_PARTS, the data construct manager 32 of process 16 (which utilizes a like naming convention as process 12) can determine the identify of the corresponding entity directly. Otherwise, the data construct manager may utilize a table or naming algorithm to infer the identity of the corresponding data construct. Indeed, such inference may be necessary to determine the data construct' s type (or the data construct manager's) identity in the first place.

The data construct manager (or object manager 30, 32) of each process 14, 16 can access the corresponding data construct directly or through other means, such as a database management system. Where a corresponding data construct does not exist in the local data store, the data construct manager can create it, populating its data attributes null values or, preferably, with values specified in the update message. Once the corresponding data construct has been accessed, each data construct manager updates it in accord with the attributes specified in the update message. See Step 70. In embodiment that utilizes an update message format of the type shown in Figure 3, new values for the corresponding data construct can be set by using accessor method associated with the DispID fields specified in the update message. If an update message specifies deletion, of course, the data construct manager can instead delete the corresponding data construct.

Described above are methods and apparatus for distributing object meeting the goals set forth above. Those skilled in the art will appreciate that the embodiments shown in the drawings and discussed herein are merely examples of the invention. Other apparatus and methods incorporating changes to those shown herein fall within the scope of the invention, of which I claim:

Claims

1. A method of distributing a selected data construct to one or more processes, the method comprising:

A. transmitting to the processes a message including a first identifier and a second identifier,

B. invoking a data construct manager that is associated with each respective process and that corresponds to the second identifier,

C. using each data construct manager to access a data construct that is associated with the respective process and that corresponds to the first identifier.

A method according to claim 1 , wherein

step (A) comprises transmitting with the message one or more attributes of the selected data construct, and

step (C) comprises using each data construct manager to set attributes of the data construct accessed thereby in accord with the one or more attributes in the message.

3. A method according to claim 1, wherein step (C) comprises using a data construct manager to any of create and destroy the data construct that corresponds to the first identifier.

4. A method according to claim 1, wherein

step (A) comprises transmitting with the message a sequence number, step (C) comprises using each data construct manager to check the sequence number in the message.

5. A method according to claim 4, wherein

step (A) comprises generating as the sequence number a count indicating a number of times the selected data construct has been updated,

step (C) comprises using each data construct manager to compare an update count associated with the data construct accessed thereby with the sequence number in the message.

6. A method of according to claim 1, wherein step (A) comprises

identifying a data construct any of created, updated and destroyed by a first process, and

generating the message such that

the first identifier corresponds to an identity of that data construct, and

the second identifier corresponds to any of a type of that data construct and an identity of a data construct manager.

7. A method of distributing objects among processes, the method comprising:

A. identifying a selected object any of created, updated and destroyed by a first process, B. generating and transmitting to other processes a message that includes a first identifier corresponding to an identity of that object and a second identifier corresponding to any of a type of that object and an identity of an object manager,

C. invoking an object manager that is associated with each respective process and that corresponds to the second identifier in the message, and

D. using each object manager to access an object that is associated with the respective process and that corresponds to the first identifier in the message.

8. A method according to claim 7, wherein step (C) comprises creating a naming object that is associated with each respective process and that corresponds to the first identifier in the message.

9. A method according to claim 8, wherein step (C) comprises passing the naming object that is associated with each respective process to the object manager associated with that process.

10. A method according to claim 7, wherein

step (B) comprises transmitting with the message one or more attributes of the selected object, and

step (D) comprises using each object manager to set attributes of the object accessed thereby in accord with the one or more attributes in the message.

11. A method according to claim 10, wherein

step (A) comprises identifying one or more attributes of the selected object changed by the first process, and 10096 step (B) comprises generating the message to indicate those changed attributes.

12. A method according to claim 7, wherein step (C) comprises using an object manager to any of create and destroy the object that corresponds to the first identifier.

13. A method according to claim 7, wherein

step (B) comprises transmitting with the message a sequence number,

step (C) comprises using each object manager to check the sequence number in the message.

14. A method according to claim 13, wherein

step (A) comprises generating as the sequence number a count indicating a number of times the selected object has been changed,

step (C) comprises using each object manager to compare an update count associated with the object accessed thereby with the sequence number in the message.