|Publication number||US7401340 B2|
|Application number||US 10/970,454|
|Publication date||Jul 15, 2008|
|Filing date||Oct 21, 2004|
|Priority date||Oct 21, 2004|
|Also published as||US20060090170|
|Publication number||10970454, 970454, US 7401340 B2, US 7401340B2, US-B2-7401340, US7401340 B2, US7401340B2|
|Inventors||John W. Leigh|
|Original Assignee||Oracle International Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (11), Non-Patent Citations (7), Referenced by (5), Classifications (11), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
The present invention relates to systems that facilitate manipulating objects within an object-oriented programming system. More specifically, the present invention provides a method and an apparatus for supporting cross-component references within an object-oriented programming system.
2. Related Art
Object-oriented programming systems enable programmers to create, modify and manipulate objects, which contain both code and data. These objects are often organized into related groups, which are referred to as “components”.
To facilitate the use of components, object-oriented programming systems often provide mechanisms to ensure that objects within components remain consistent with each other as they are updated.
Additionally, many object-oriented programming systems support “loose coupling”, which enables programmers to concurrently modify related components. Moreover, loose coupling allows applications to be developed by larger development teams. However, loose coupling also makes it harder to manage consistency between components.
For example, a problem can arise when a referenced object is deleted and re-imported. Suppose there exists a database table (component) called “EMP”, with columns “ID” and “DEPT_ID”. Also suppose that the column EMP.DEPT_ID contains a foreign-key which refers to the column “ID” in another database table (component) “DEPT”. Furthermore, suppose that the column ID is the unique-key for database table (component) DEPT. Note that if DEPT is deleted, its unique-key will also be deleted. However, because of loose coupling, the foreign-key contained in column EMP.DEPT_ID may not be updated to reflect this deletion. Moreover, if DEPT is subsequently re-imported, the foreign-key may still not be updated. Consequently, even after re-importing DEPT, the foreign-key contained in column EMP.DEPT_ID may continue to refer to a non-existent object.
Upon subsequent validation of the EMP object, the database may report an error because the foreign-key in column EMP.DEPT_ID does not refer to a valid unique-key. Consequently, the user may have to either delete the foreign key or change it to refer a new unique-key.
Similarly, problems can arise when a component is updated. For example, an update can cause information within a referencing component to be inconsistent with associated information in a referenced component.
Unfortunately, existing loosely coupled systems do not check for such inconsistencies, which can cause the system to fail. As a result, such inconsistencies are typically detected when it is too late, e.g., after a system failure.
Hence, what is needed is a method and an apparatus for managing consistency between components thereby avoiding the problems described above.
One embodiment of the present invention provides a system that supports cross-component references in an object-oriented programming system. During operation, the system makes a first attempt to obtain a name for a referenced object through a cross-component reference between a referencing object and the referenced object. This first attempt involves attempting to obtain the name for the referenced object from the referenced object, which involves attempting access the referenced object through an identifier for the referenced object within the cross-component reference. If this first attempt fails, the system makes a second attempt to obtain the name for the referenced object, which involves obtaining a pathname for the referenced object from the cross-component reference.
In a variation on this embodiment, the second attempt also involves obtaining the name for the referenced object from the pathname for the referenced object.
In a variation on this embodiment, while importing an object into a repository, the system first determines if the referenced objects are to be imported along with the object. If so, the system ensures that cross-component references between the object and the referenced objects include both identifiers for the referenced objects and pathnames for the referenced objects. Otherwise, the system ensures that cross-component references between the object and the referenced objects include pathnames for the referenced objects.
In a variation on this embodiment, the system maintains a first aggregate signature within the cross-component reference, which reflects the structure of the referenced object. The system also maintains a second aggregate signature within the cross-component reference, which reflects the structure of the referencing object. The system uses the first aggregate signature and the second aggregate signature to determine whether or not the referenced object is synchronized with the referencing object.
In a variation on this embodiment, the system maintains a first time stamp, within the cross-component reference, indicating the time of the last inbound synchronization from the referenced object to the referencing object. The system also maintains a second time stamp, within the cross-component reference, indicating the time of the last outbound synchronization from the referencing object to the referenced object. The system uses the first time stamp and the second time stamp to determine whether or not the referenced object is synchronized with the referencing object.
In a variation on this embodiment, if the referenced object is not synchronized with the referencing object, the system performs an inbound or an outbound synchronization operation between the referenced object and the referencing object.
In a variation on this embodiment, the system subsequently uses the name obtained for the referenced object while generating code that manipulates the referenced object.
In a variation on this embodiment, the system uses the cross-component reference to access the referenced object from the referencing object.
The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DYDs (digital versatile discs or digital video discs), and does not include computer instruction signals embodied in a transmission medium (with or without a carrier wave upon which the signals are modulated).
Components within a Programming System
In one embodiment of the present invention, objects are classified into folders, first class objects (FCOs) and second class objects (SCOs). A folder is a special FCO which acts as a container for other FCOs. FCOs act as containers for second class objects (SCO). An FCO together with its associated SCOs is referred to as a “component”. For example, an FCO can be a database table, and corresponding SCOs can be columns and constraints for the database table. In another example, an FCO can be a mapping that specifies a transformation associated with one or more database tables, and corresponding SCOs can be operators involved in the transformation.
An association between objects can be within a component (an intra-association) or across components (an inter-association). Inter-component associations can be between FCO-FCO, FCO-SCO, and SCO-SCO objects, which exist in different components. The term “cross-component reference” (CCR) refers to inter-component association, and the terms “referencing object” and “referenced object” refer to objects at the ends of the cross-component reference. One embodiment of the present invention guarantees the consistency of intra-associations but not inter-associations.
In one embodiment of the present invention, the programming system supports a decoupling paradigm, which allows only one user to modify a given component at a time. Within this system, changes in a given component are not transparent to its inter-associations with other components. This lack of transparency can give rise to a number of problems, which are described in more detail below with reference to
Exemplary Foreign-Key Constraint
In this example, the system provides a cross-component reference (CCR) 202 to represent the association between the foreign key in table EMP and the corresponding unique key in the table DEPT. Cross-component reference 202 includes a primary reference in the form of an identifier (ID)=101 for the unique key of table DEPT. Cross-component reference 202 also includes a secondary reference in the form of a fully qualified pathname,
In addition to ID 302 and pathname 304, cross-component reference 300 also includes an aggregate signature for the referenced object 306 and an aggregate signature for the referencing object 308. These aggregate signatures 306 and 308 are used to maintain consistency between the referencing object and the referenced object as is described in more detail below with reference to
Process of Obtaining a Name for a Referenced Object
Next, the system examines a cross-component reference (CCR) 300 from the FCO (step 404). The system then attempts to obtain a name for the referenced object through the ID for the referenced object 302 in cross-component reference 300 (step 406). The system then determines if the attempt was successful (step 408).
If the attempt was not successful, the system attempts to obtain the name for the referenced object from within the pathname for the referenced object 304 (step 410). This can involve reading the name of the referenced object from the pathname for the referenced object. The system then determines if the second attempt was successful (step 412). If not, the system takes a remedial action (step 414).
Otherwise, the second attempt was successful (or if the first attempt was successful in step 408), the system determines if there are any more cross-component references associated with the FCO (step 416). If so, the system returns to step 404 to obtain the name for the corresponding referenced object.
Otherwise, the system uses the names for referenced objects while generating code that manipulates the referenced objects (step 418).
Note that when code generation is invoked on a table, a foreign-key to unique-key reference is traversed to generate a constraint statement. If this reference is broken in a prior art system, no foreign-key constraint is generated; in fact, generation will not get invoked at all. With the secondary references provided by the present invention, the system can continue with generation in most cases, even when the primary reference is broken or non-existent.
Note that the above-described process for obtaining a name for an object (component) can also be used to during the process of displaying objects (components) within an UI for an editor, which allows objects to be manipulated.
Process of Importing an Object
The system starts by obtaining an object (component) to be imported into repository 100 (step 502). Next, the system determines if referenced objects are to be imported along with the object (step 504). If so, the system imports the object along with the associated referenced objects in the repository 100 (step 506). In doing so, the system ensures that cross-component references between the object and the referenced objects include both identifiers (primary references) and pathnames (secondary references) for the referenced objects (step 508).
Otherwise, if referenced objects are not to be imported at step 504, the system imports only the object (step 510). In doing so, the system ensures that the cross-component references include pathnames for the referenced objects (step 512). Note that identifiers are generally not available for objects which do not reside within repository 100.
Process of Maintaining Consistency Between Objects
Note that a mapping component needs to maintain a copy of a referenced object in order to be able to generate independent of the referenced object. For example, a table T1, with a column C3 which is typed by TYP1 is not required to understand TYP1 in order to generate itself. Although metadata-wise this is true, from a user's perspective, when TYP1 is changed it does have an impact on T1 and the users of T1.
To support this need, the referencing object needs to be able to determine when a referenced object has changed since it was referenced. This implies that some additional metadata needs to be stored on the referencing object to keep track of consistency between the referenced object and the referencing object. To this end, one embodiment of the present invention maintains signatures of the referenced object and the referencing object within a cross-component reference to facilitate maintaining consistency between the referenced object and the referencing object.
Note that the aggregate signature can be computed based on the metadata signature of every child object using the following technique.
If the referenced object is not the aggregate parent,
aggregate signature = metadata signature.
get all aggregated children recursively;
sort the children;
compute metadata signatures for each child in the sorted list; and
concatenate the signatures.
Note that the system can alternatively maintain a time stamp for the referenced object, which can for example be obtained from the last inbound synchronization operation from the referenced object. The system similarly maintains an aggregate signature 308 (or time stamp) for the referencing object within the cross-component reference 300 (step 604).
Next, the system uses the aggregate signatures (or time stamps) 306 and 308 to determine if the referenced object is synchronized with the referencing object (step 606). For example, the system can compare the aggregate signature of the referenced object 306 (from within the cross-component reference) against the current structure (or current aggregate signature) of the referenced object. If these differ, the referenced object may not be synchronized with the referenced object. The system can also can compare the aggregate signature of the referencing object 308 against the current structure (or current aggregate signature) of the referencing object to determine if they differ.
If the referenced object is not synchronized with the referencing object, the system performs with an inbound or outbound synchronization operation between the referenced object and the referencing object (step 608).
In some situations, a component or a subcomponent is derived from another component or a subcomponent, or copy of a component/subcomponent is maintained in other component/subcomponent. The derived component (or copy acts) as the referencing object and the derivation/original acts as the referenced object and the inter-component association between the copy and the original represents a binding.
In this case, one embodiment of the present invention provides a synchronization mechanism, which synchronizes the copy from the master (inbound synchronization) and vice-versa (outbound synchronization). Note that the copy and the original are not aware of changes to each other and reconciliation needs to be invoked to ensure that they are synchronized, irrespective of whether it is required or not.
In this example, a change to the table EMP resets its aggregate signature, which is then out-of-synch with the aggregate signature for EMP contained in the cross-component reference. In this case, an inbound synchronization is required to make the EMP operator within mapping 700 consistent with the EMP table 708. (This inbound synchronization can be automatically performed by the system, or alternatively, the user can be given the responsibility of initiation the inbound synchronization.)
Similarly, a change to the EMP operator with mapping 700 (such as adding the CHANGE_DATE column) resets its aggregate signature, which is then out-of-synch with the aggregate signature for the referencing object contained in the cross-component reference. In this case, an outbound synchronization is required to make the EMP table consistent with the EMP operator within mapping 700.
The foregoing descriptions of embodiments of the present invention have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5819091 *||Dec 22, 1994||Oct 6, 1998||Arendt; James Wendell||User level control of degree of client-side processing|
|US5842018 *||Jun 6, 1995||Nov 24, 1998||Microsoft Corporation||Method and system for referring to and binding to objects using identifier objects|
|US6012085 *||Oct 22, 1997||Jan 4, 2000||Stampede Technolgies, Inc.||Apparatus and method for increased data access in a network file object oriented caching system|
|US6016478 *||Aug 13, 1996||Jan 18, 2000||Starfish Software, Inc.||Scheduling system with methods for peer-to-peer scheduling of remote users|
|US6105072 *||Apr 2, 1997||Aug 15, 2000||Fischer; Addison M.||Method and apparatus for validating travelling object-oriented programs with digital signatures|
|US6185733 *||Jan 20, 1998||Feb 6, 2001||International Business Machines Corporation||Method and apparatus for remote object code inclusion|
|US6253257 *||Jul 31, 1997||Jun 26, 2001||Bea Systems, Inc.||Software Interface for dynamic API mapping|
|US6571388 *||Mar 9, 1999||May 27, 2003||Hewlett-Packard Development Company, L.P.||Building a custom software environment including pre-loaded classes|
|US20040003007 *||Jan 16, 2003||Jan 1, 2004||Prall John M.||Windows management instrument synchronized repository provider|
|US20050050084 *||Aug 29, 2003||Mar 3, 2005||Atm Shafiqul Khalid||Dynamic registry partitioning|
|US20050066303 *||Sep 21, 2004||Mar 24, 2005||Trigence Corp.||Computing system having user mode critical system elements as shared libraries|
|1||*||De Sutter, Bjorn; De Bus, Bruno; and De Bosschere, Koen. "Sifting Out The Mud: Low Level C++ Code Reuse." Conference on Object Oriented Programming Systems and Applications; Proceedings of the 17<SUP>th </SUP>ACM SIGPLAN Conference on Object-Oriented Programming, Systems, and Applications, 2002.|
|2||*||Duggan, Dominic. "Type-Safe Linking With Recursive DLLs and Shared Libraries." ACM Transactions on Programming Languages and Systems: vol. 24, Issue 6, Nov. 2002.|
|3||*||Fong, Philip W. L. and Cameron, Robert D. . "Proof Linking: An Architecture for Modular Verification of Dynamically-Linked Mobile Code." Prceedings of the 6<SUP>th </SUP>ACM SIGSOFT Internation Symposium on Foundations of Software Engineering, 1998.|
|4||*||Fong, Philip W. L. and Cameron, Ronbert D.. "Proof Linking: Modular Verification of Mobile Programs in the Presense of Lazy, Dynamic Linking." ACM Transactions on Software Engineering and Methodology: vol. 9, Issue 4, Oct. 2000.|
|5||*||Janson, Philippe A.. "Dynamic Linking and Environment Initialization in a Multi-Domain Process." Proceedings of the 5 <SUP>th </SUP>ACM Symposium on Operating Systems Principles, 1975.|
|6||*||Kessler, Kempf J.. "Cross-Address Space Dynamic Linking." Proceedings of the Second Inernational Workshop on Object Orientation in Operating Systems, 1992.|
|7||*||Levine, John R.. Linkers and Loaders. San Diego: Academic Press, 2000.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8049316 *||Nov 1, 2011||Kabushiki Kaisha Toshiba||Semiconductor package|
|US8352913 *||Jan 8, 2013||Adobe Systems Incorporated||Generating and resolving component names in an integrated development environment|
|US20090205806 *||Feb 26, 2009||Aug 20, 2009||Tsuyoshi Hasegawa||Semiconductor package|
|US20090319567 *||Dec 24, 2009||Apple Inc.||System and method of data management using a structure to propagate changes to referenced objects|
|US20110035729 *||Aug 7, 2009||Feb 10, 2011||Kiran Sakhare||Generating and resolving component names in an integrated development environment|
|U.S. Classification||719/332, 717/165, 707/999.106, 707/999.103|
|International Classification||G06F7/20, G06F9/44, G06F3/00|
|Cooperative Classification||G06F9/4428, Y10S707/99944, Y10S707/99947|
|Oct 21, 2004||AS||Assignment|
Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LEIGH, JOHN W.;REEL/FRAME:015924/0603
Effective date: 20041020
|Dec 22, 2009||CC||Certificate of correction|
|Sep 21, 2011||FPAY||Fee payment|
Year of fee payment: 4
|Dec 30, 2015||FPAY||Fee payment|
Year of fee payment: 8