Abstract:
A system and method to synchronize and reconcile objects are described. The system includes a memory device storing a first baseline including a set of first objects associated with a respective set of first identifiers and a second baseline including a set of second objects associated with a respective set of second identifiers. The system also includes a processor configured to determine a kinship among the set of first objects and the set of second objects based on the set of first identifiers and the set of second identifiers and to create a new baseline based on reconciling any conflict identified by the kinship.

Description:
BACKGROUND 
       [0001]    Synchronization and reconciliation of multiple versions is a necessary process in many contexts. For example, object-oriented programming involves the interaction among a plurality of objects to implement a computer application. Each object includes data fields and associated procedures (methods). Distributed objects are spread over multiple computers or multiple processors within a computer. Different objects may be managed by different users on different systems. For example, an object may be edited by one user to create a new object while the object is modified by another user. More than one editor may modify the same object. Ultimately, synchronization and reconciliation are needed to clarify the hierarchy and most recent version that should be used when the objects interact with each other. 
         [0002]    One of the current approaches to managing multi-version environments is by maintaining a single-version-of-truth. In a distributed object system, for example, this involves a single server managing all the objects and permitting only one client to work with the same object at a time. Changes made and committed at the client are reflected in the version maintained by the server. An object check-out and check-in process may be used to implement the single-version-of-truth approach. 
       SUMMARY 
       [0003]    According to an aspect of the invention, a system to synchronize and reconcile objects includes a memory device storing a first baseline including a set of first objects associated with a respective set of first identifiers and a second baseline including a set of second objects associated with a respective set of second identifiers; and a processor configured to determine a kinship among the set of first objects and the set of second objects based on the set of first identifiers and the set of second identifiers and to create a new baseline based on reconciling any conflict identified by the kinship. 
         [0004]    According to another aspect of the invention, a method of synchronizing and reconciling objects includes storing, in a memory device, a first baseline including a set of first objects associated with a respective set of first identifiers and a second baseline including a set of second objects associated with a respective set of second identifiers; determining, using a processor, a kinship among the set of first objects and the set of second objects based on the set of first identifiers and the set of second identifiers; and creating, using the processor, a new baseline based on reconciling any conflict identified by the kinship. 
         [0005]    According to yet another aspect of the invention, a non-transitory computer readable storage medium stores instructions which, when processed by a processor, cause the processor to implement a method of synchronizing and reconciling objects. The method includes storing a first baseline including a set of first objects associated with a respective set of first identifiers and a second baseline including a set of second objects associated with a respective set of second identifiers; determining a kinship among the set of first objects and the set of second objects based on the set of first identifiers and the set of second identifiers; and creating a new baseline based on reconciling any conflict identified by the kinship. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]    Referring now to the drawings wherein like elements are numbered alike in the several Figures: 
           [0007]      FIG. 1  is a block diagram of a distributed object system according to an embodiment of the invention; 
           [0008]      FIG. 2  illustrates the identifiers associated with an object according to embodiments of the invention; 
           [0009]      FIG. 3  illustrates a correspondence that may be stored in the memory device of one or more processing devices; 
           [0010]      FIG. 4  outlines a process of reconciliation implemented by a processor of one or more processing devices; 
           [0011]      FIG. 5  illustrates an example of merging baselines according to an embodiment of the invention; and 
           [0012]      FIG. 6  is a process flow of a method of merging baselines of objects according to embodiments of the invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0013]    As noted above, synchronization and reconciliation are necessary in a multi-version environment. The single-version-of-truth approach to maintaining synchronization limits all clients and users to keeping in contact with the server and making edits in turn. Embodiments of the system and method described herein facilitate synchronization and reconciliation through identification of objects. As a result, the objects may be edited, simultaneously or in turn, by clients and users that are not in contact with a single server acting as a repository for the objects. While embodiments are detailed below with specific reference to distributed objects for explanatory purposes, alternate embodiments apply, as well, to other multi-version environments. 
         [0014]    In a distributed object system, some objects are transitory, derivative of other objects, or are otherwise of secondary importance to this discussion. Exemplary objects of interest with respect to embodiments of the invention are objects that map to real world objects, both physical and abstract, and together model the domain of interest. These objects are designated as domain objects. Exemplary domain objects in the oil and gas domain include fields, reservoirs, wells, geological grids, faults, horizons, and fluid contacts. Exemplary domain objects in the email domain include email messages and address book entries. For explanatory purposes, address book entries are discussed below. 
         [0015]      FIG. 1  is a block diagram of a distributed object system according to an embodiment of the invention. Any number of processing devices  110  may communicate with each other over a network  120 . Each processing device  110  has one or more processors  112 , one or more memory devices  114 , an input interface  116 , and an output interface  118 . Each processing device  110  may be used to edit a distributed object (object  210 ,  FIG. 2 ). A baseline  510  (see e.g.,  FIG. 5 ) refers to a snapshot or reference list of (domain) objects  210  at a given time. Each user and/or processing device  110  may maintain a baseline  510 , and, when a user runs the program generated with the distributed objects  210 , baselines  510  must be merged and reconciled. The object identification process used according to embodiments of the invention to achieve the reconciliation is detailed below. 
         [0016]      FIG. 2  illustrates the identifiers associated with an object  210  according to embodiments of the invention. Each object  210  may be imprecisely identified by a tuple (Name, Version Number), where Name is the object name  220 , which may not be unique to the particular domain object  210 , and Version Number may also not be unique to the domain object  210 . Each object  210  may also be precisely identified by a tuple (Oid, Vid), where Oid  230  is an object identifier and Vid  240  is a version identifier. Each of the identifiers (Oid  230  and Vid  240 ) is universally unique such that, regardless of which user is editing an object  210  or the processing device  110  used for the edits, unrelated objects  210  will not have the same Oid  230  and two different edits of the same Oid  230  object  210  will not have the same Vid  240 . All objects  210  resulting from the same initial object  210  will have the same Oid  230 . However, when one object  210  stems from another, the two objects  210  will have a different Vid  240 . Thus, the tuple (Oid, Vid) is unique for each non-identical object  210 . Each object  210  also maintains a list of all Vid  240  associated with that object  210  as the VidList  250 . That is, an object  210   a  that had two previous Vid  240  associated with it may be copied and edited to create an object  210   b  that now has three versions (Vid  240 ) associated with it. The two objects  210   a,    210   b  would have the same Oid  230  but different Vid  240 , and the first two Vid  240  would be in common in their VidLists  250 , while the object  210   b  has a third Vid  240  that the original object  201   a  does not have in its VidList  250 . By using the Oid  230 , Vid  240 , and VidList  250  of any two objects, their relationship (kinship) to each other, if any, may be determined, and reconciliation to create a baseline  510  is accomplished, as detailed below. 
         [0017]      FIG. 3  illustrates a correspondence that may be stored in the memory device  114  of one or more processing devices  110 . A comparison of the Oid  230 , Vid  240 , and VidList  250  of two different objects  210  (shown in column  310 ) is used to determine their corresponding kinship (column  320 ), which is described in column  330 . As shown in row  310 - 1 , two objects  210   a  and  210   b  that share the same Oid  230  and Vid  240  are identical, because the tuple (Oid, Vid) is unique to a given object  210 . Row  310 - 2  illustrates that when the Oid  230  of two objects  210   m  and  210   n  is not the same, then the two objects  210  could not have had the same origin and are unrelated. Both rows  310 - 3  and  310 - 4  illustrate ancestry. When objects  210   x  and  210   y  have the same Oid  230 , and when the Vid  240  of one of the objects  210   x  appears in the VidList  250  of the other object  210   y,  then the object  210   x  whose Vid  240  appears in the VidList  250  of the other object  210   y  must be an ancestor of the other object  210   y  (and the other object  210   y  must be a descendent of the object  210   x ). Similarly, when objects  210   s  and  210   t  have the same Oid  230 , and when the Vid  240  of one of the objects  210   t  appears in the VidList  250  of the other object  210   s,  then the object  210   s  with the VidList  250  in which the Vid  240  of the other object  210   t  appears must be a descendent of the other object  210   t  (and the other object  210   t  must be an ancestor of the object  210   s ). Objects  210   g,    210   h  that originated from the same object (and thus have the same Oid  230 ) are illustrated in row  310 - 5 . In this case, the objects  210   g,    210   h  do not have an ancestor-descendent relationship (one object  210  Vid  240  does not appear in the VidList  250  of the other object  210 ). However, the common Vid  240  in the VidList  250  of each object  210   g,    210   h  relates to their common ancestor and indicates the kinship of the objects  210   g,    210   h  as cousins. 
         [0018]      FIG. 4  outlines a process of reconciliation implemented by a processor  112  of one or more processing devices  110 . Based on the kinship (column  410 ) identified according to the correspondence discussed with reference to  FIG. 3 , the contents of the new baseline (column  420 ) are determined as explained in column  430 . As illustrated in row  410 - 1 , when the objects  210  are found to be identical (e.g., objects  210   a,    210   b  in row  310 - 1  of  FIG. 3 ), then there is no conflict, and a reference to either (e.g., object  210   a  or  210   b ) may be used. As illustrated in row  410 - 2 , when the objects  210  are unrelated (e.g., objects  210   m  and  210   n  in row  310 - 2  of  FIG. 3 ), then there is no conflict and each object (e.g.,  210   m,    210   n ) should be referenced as it is invoked. As illustrated in row  410 - 3 , when the objects  210  are directly related (e.g., object  210   x  is an ancestor of object  210   y  and object  210   t  is an ancestor of object  210   s  in rows  310 - 3  and  310 - 4 , respectively, of  FIG. 3 ), then the descendent object (e.g.,  210   y,    210   s ) is referenced in the baseline because it represents the latest modifications to the object  210 . As illustrated in row  410 - 4 , when objects  210  are cousins (e.g., objects  210   g,    210   h  in row  310 - 5  of  FIG. 3 ), then there is a conflict that must be reconciled. The reconciliation may be achieved through the selection of one of the cousin objects (e.g.,  210   g,    210   h ). This selection may be automatic based on pre-defined criteria in the processing device  110 . In alternate embodiments, the user may be alerted to the conflict and asked to input a selection. According to another embodiment, the reconciliation may involve creating a new version of one of the objects (e.g.,  210   g  or  210   h ) that includes differences that are part of the other object (e.g.,  210   h  or  210   g ). This embodiment may also include user intervention to varying degrees. 
         [0019]      FIG. 5  illustrates an example of merging baselines according to an embodiment of the invention. As noted above, exemplary domain objects  210  in the oil and gas domain include fields, reservoirs, wells, geological grids, faults, horizons, and fluid contacts. In  FIG. 5 , the example relates to address book entries in a mobile communication domain. In this example, each object  210  having a given Oid  230  (address book entry) has multiple elements (Name, Address, Phone). Baseline  1   510   a  represents an initial state of the system that may have been stored in a repository and copied by one or more users onto two different mobile devices. Baseline 1.1  510   b  represents edits to baseline 1  510   a  in one of the mobile devices, and baseline 1.2  510   c  represents edits to baseline 1  510   a  in the other of the mobile devices. The edits done to create baseline 1.1  510   b  and baseline 1.2  510   c  were done when the mobile devices were not in contact with the repository (from which baseline 1  510   a  was initially copied). When the mobile devices restore connectivity to the repository, the reconciliation or merge of baseline 1.1  510   b  and baseline 1.2  510   c  is reflected in baseline 2  510   d.  Specifically, in baseline 1.1  510   b,  an address is changed ( 520   a - 1 ), resulting in an update to the corresponding version number (VersionNo)  501  to 2 and Vid  240  for Oid  230  O1 of V1.2. A phone number is changed ( 520   b ) for Oid  230  O3, resulting in an updated VersionNo  501  of 2 and Vid  240  of V3.2. A new entry with Oid  230  “O4” is added ( 520   c ) with an initial VersionNo  501  of 1 and Vid  240  of V4.1. In baseline 1.2  510   c,  an address change ( 520   a - 2 ) is made that happens to be the same as the address change ( 520   a - 1 ) made in baseline 1.1  510   b.  In addition, a phone number ( 530   a ) change is also made for Oid  230  O1 to result in an updated VersionNo  501  of 2 and Vid  240  of V1.3. A phone number ( 530   b ) is added (where there was no number before) for Oid  230  O2 to result in an updated VersionNo  501  of 2 and Vid  240  of V2.2. The new entry ( 520   c ) with Oid  230  O4 is not part of the baseline 1.2  510   c  but only part of the baseline 1.1  510   b  and has VersionNo  501  of 1 and Vid  240  V4.1. Baseline 2  510   d,  resulting from a merge of baseline 1.1  510   b  and baseline 1.2  510   c,  results from the process described with reference to  FIGS. 3 and 4 , as discussed below. 
         [0020]    Both baseline 1.1  510   b  and baseline 1.2  510   c  include Oids  230  O1, O2, and O3. With respect to Oid  230  O1, both baseline 1.1  510   b  and baseline 1.2  510   c  have the same Oid  230  O1 but different Vid  240 . Because neither baseline 1.1  510   b  nor baseline 1.2  510   c  stemmed from the other (none of the elements of one of those baselines is a descendant or ancestor of elements of the other baseline), the elements of Oid  230  O1 in baseline 1.1  510   b  and baseline 1.2  510   c  are cousins (see  310 - 5  of  FIG. 3 ). With respect to the address element, the cousins (changes  520   a - 1  and  520   a - 2 ) are identical. Thus, the reconciliation for the address element of Oid  230  O1 is trivial, and the new address ( 520   a - 1  and  520   a - 2 ) is incorporated into baseline 2  510   d.  The phone number element change ( 530   a ) is only in baseline 1.2  510   c  (not in baseline 1.1  510   b ), so, with respect to the “Phone” element of Oid  230  O1, the conflict between the two entries must be reconciled. As discussed above, one of the ways to reconcile a conflict is to create a new version  540  that incorporates the differences between baseline 1.1  510   b  and baseline 1.2  510   c.  With regard to Oid  230  O2, both baseline 1.1  510   b  and baseline 1.2  510   c  have the same Oid  230  O2 but the Vid  240  in baseline 1.1  510   b  is V2.1 while the Vid  240  in baseline 1.2  510   c  is V2.2. Thus, for Oid  230  O2, the phone number element in baseline 1.1  510   b  is an ancestor of the phone number element in baseline 1.2  510   c.  Accordingly, the more recent version (V2.2 in baseline 1.2  510   c ) is used and the phone number  530   b  added in baseline 1.2  510   c  is included in Oid  230  O2 of baseline 2  510   d.  With regard to Oid  230  O3, both baseline 1.1  510   b  and baseline 1.2  510   c  have the same Oid  230  O3 but the Vid  240  in baseline 1.1  510   b  is V3.2 while the Vid  240  in baseline 1.2  510   c  is V3.1. Thus, for Oid  230  O3, the phone number element in baseline 1.2  510   c  is an ancestor of the phone number element in baseline 1.1  510   b.  Accordingly, the more recent version (V3.2 in baseline 1.1  510   b ) is used and the phone number  520   b  from baseline 1.1  510   b  is used in baseline 2  510   d.  Finally, with regard to the new entry  520   c  included as Oid  230  O4 in baseline 1.1  510   b,  there is no Oid  230  O4 in baseline 1.2  510   c.  Thus, the entry (Oid  230  O4) is included in baseline 2  510   d  because it is unrelated to (and, therefore, does not conflict with) any entry in baseline 1.2  510   c.    
         [0021]      FIG. 6  is a process flow of a method of merging baselines of objects  210  according to embodiments of the invention. At block  610 , obtaining identifiers associated with each object  210  includes obtaining the Oid  230 , Vid  240 , and VidList  250 . At block  620 , using the identifiers to determine kinship among objects is done by a processor  112  of a processing device  110  according to the process described with reference to  FIGS. 3 and 4 . At block  630 , reconciling as needed includes determining when two objects  210  are cousins and, therefore, in conflict. As noted above, several different approaches, with and without user intervention, may be used to resolve the conflict. Creating a new baseline at block  640  includes creating a snapshot of the objects  210  with any conflicts reconciled as illustrated by the example discussed with reference to  FIG. 5 . 
         [0022]    While one or more embodiments have been shown and described, modifications and substitutions may be made thereto without departing from the spirit and scope of the invention. Accordingly, it is to be understood that the present invention has been described by way of illustrations and not limitation.