[go: up one dir, main page]

WO2000010096A1 - Procedes et appareil permettant de distribuer des structures de donnees, telles que des objets orientes objets, dans des traitements - Google Patents

Procedes et appareil permettant de distribuer des structures de donnees, telles que des objets orientes objets, dans des traitements Download PDF

Info

Publication number
WO2000010096A1
WO2000010096A1 PCT/US1999/017940 US9917940W WO0010096A1 WO 2000010096 A1 WO2000010096 A1 WO 2000010096A1 US 9917940 W US9917940 W US 9917940W WO 0010096 A1 WO0010096 A1 WO 0010096A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
data construct
manager
data
processes
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US1999/017940
Other languages
English (en)
Inventor
John Gage
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wonderware Solutions Inc
Marcam Solutions Inc
Original Assignee
Wonderware Solutions Inc
Marcam Solutions Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wonderware Solutions Inc, Marcam Solutions Inc filed Critical Wonderware Solutions Inc
Publication of WO2000010096A1 publication Critical patent/WO2000010096A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488—Object-oriented
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/289—Object oriented databases

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • the invention 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.
  • 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.
  • a data construct manager that corresponds to the "type" identifier in the message.
  • this constitutes instantiating an object of the class specified in the message.
  • 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.
  • a method 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.
  • 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 can use the attribute information to update their local copies of the corresponding data construct.
  • 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.
  • 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.
  • Figure 3 depicts the structure of an update message in a system according to the invention.
  • FIG. 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.
  • 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.
  • FIG. 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.
  • 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.
  • FIG. 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.
  • 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.
  • FIG. 1 depicts a system 10 according to the invention.
  • 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.
  • LANs local area networks
  • WANs wide area networks
  • Internet Internet
  • 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.
  • microprocessor memory e.g., RAM
  • 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.
  • they constitute "objects," as that term is defined in object-oriented programming (OOP) contexts, comprising both data and method attributes.
  • OOP object-oriented programming
  • 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.
  • 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.
  • 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.
  • processes 14 and 16 may also include a user applications for accessing data constructs in their respective data stores 22, 24.
  • 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.
  • 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.
  • element 28 is configured to intercept calls made by the user application to an OODBMS that interfaces with the data store 20.
  • update monitor 28 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.
  • That message identifies the data construct, its type, and at least the attributes of it which have changed.
  • 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.
  • 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.
  • 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.
  • the class identifier "AUTO PART” could be used as, perhaps, could a more common term, like "PART.”
  • each could use an identifier known to the targeted process.
  • 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.
  • the data construct manager is referred to as an object manager.
  • 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.
  • 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).
  • 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.
  • the update message can reflect the destruction or deletion of a data construct. For example, if process 12 were to delete an object
  • the update message can list "null" values for all of the attributes of that object.
  • a status field is provided instead, identifying the object as having been deleted.
  • 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
  • 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.
  • this is set to "AUTO_PARTS”.
  • 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.
  • 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.
  • 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.
  • a DispID which constitutes a unique, enterprise-wise identifier for the attribute
  • Value which defines the value of that attribute
  • Value Type which defines the data type of the Value.
  • the name of the data construct is specified in this manner, as well.
  • 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.
  • 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.
  • object managers 30, 32 are instantiated from types corresponding to the
  • 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.
  • communication managers 36, 38 instantiate respective naming objects 40, 42 prior to invoking the object managers 30, 32. See Step 65 of Figure 2.
  • those naming objects are instantiated from classes corresponding to the Program ID of Reference Object included in the header of the update message.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé de distribution de structures de données, telles qu'un objet de programmation orienté objet, consistant à émettre un message, qui identifie la structure de données sélectionnée et son type. Ce type peut constituer le nom d'un gestionnaire de structure de données, ou un gestionnaire objet (30) pouvant être exécuté dans chacun des traitements (1, 2, 3), afin de créer, détruire, accéder ou mettre à jour (68, (70) une copie locale d'une structure de données correspondante. Le procédé consiste également à répondre, par exemple dans chaque traitement (12, 16), au message en demandant un gestionnaire de structure de données (30) correspondant à l'identificateur de type dans ledit message. Le gestionnaire de structure de données (30) permet d'accéder à une structure de données qui est associée (locale) au traitement respectif et qui correspond aux structures de données identifiées dans le message.
PCT/US1999/017940 1998-08-14 1999-08-10 Procedes et appareil permettant de distribuer des structures de donnees, telles que des objets orientes objets, dans des traitements Ceased WO2000010096A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US9651598P 1998-08-14 1998-08-14
US60/096,515 1998-08-14
US37132399A 1999-08-10 1999-08-10
US09/371,323 1999-08-10

Publications (1)

Publication Number Publication Date
WO2000010096A1 true WO2000010096A1 (fr) 2000-02-24

Family

ID=26791773

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/017940 Ceased WO2000010096A1 (fr) 1998-08-14 1999-08-10 Procedes et appareil permettant de distribuer des structures de donnees, telles que des objets orientes objets, dans des traitements

Country Status (1)

Country Link
WO (1) WO2000010096A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5566349A (en) * 1994-05-16 1996-10-15 Trout; Ray C. Complementary concurrent cooperative multi-processing multi-tasking processing system using shared memories with a minimum of four complementary processors
US5724575A (en) * 1994-02-25 1998-03-03 Actamed Corp. Method and system for object-based relational distributed databases
US5819255A (en) * 1996-08-23 1998-10-06 Tandem Computers, Inc. System and method for database query optimization

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5724575A (en) * 1994-02-25 1998-03-03 Actamed Corp. Method and system for object-based relational distributed databases
US5566349A (en) * 1994-05-16 1996-10-15 Trout; Ray C. Complementary concurrent cooperative multi-processing multi-tasking processing system using shared memories with a minimum of four complementary processors
US5819255A (en) * 1996-08-23 1998-10-06 Tandem Computers, Inc. System and method for database query optimization

Similar Documents

Publication Publication Date Title
US7194480B2 (en) System and method for invoking methods on place objects in a distributed environment
US7167874B2 (en) System and method for command line administration of project spaces using XML objects
US6751797B1 (en) System and method for managing the persistence of EJB components in a directory accessed via LDAP
US6061692A (en) System and method for administering a meta database as an integral component of an information server
US6829639B1 (en) Method and system for intelligent global event notification and control within a distributed computing environment
AU760999B2 (en) System and method for dynamic correlation of events
US5832275A (en) System for dynamically replacing operating software which provides distributed directory service after verifying that versions of new software and the operating software are compatible
JP4197753B2 (ja) 多数ディレクトリサービスに一様にアクセスするための方法及びシステム
EP0629960B1 (fr) Système de fichiers extensibles
US6032153A (en) Method and system for maintaining persistence in a shared object system
US6606627B1 (en) Techniques for managing resources for multiple exclusive groups
US6163802A (en) Message tracking system
US7284005B1 (en) Data transfer method and system
US20030093470A1 (en) System and method for implementing a service adapter
WO2000039673A1 (fr) Procede et appareil de filtrage et d'acheminement dynamique d'evenements
US6820136B1 (en) System and method for replicating monitored registry keys
US6941309B2 (en) Object integrated management system
US5991766A (en) Method and system for managing redundant objects in a distributed object system
US7107594B1 (en) Method and system for providing a version-independent interface to a computer resource
US7539672B2 (en) Apparatus, system, and method for direct retrieval of hierarchical data from SAP using dynamic queries
US20010039549A1 (en) Object-oriented interface to LDAP directory
WO2002037336A2 (fr) Abstraction orientee objet de base de donnees et production d'instructions
US7181462B2 (en) System and method for multi server place data representation
WO2000010096A1 (fr) Procedes et appareil permettant de distribuer des structures de donnees, telles que des objets orientes objets, dans des traitements
AU775155B2 (en) Method and apparatus for a user extensible event structure

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA JP

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase