Generic data centric object structure and implementation

[0002] The present invention is in the general field of data processing, and provides a technique for accessing relational and other structured data from an object based application model.

[0003] An object based application model is an application model in an object oriented (OO) programming environment. Data stored statically, such as in a relational data base, can be presented in an object based application model and manipulated at run time, encapsulated in a self-contained entity called an object. In addition to data, the object contains its own instructions to perform operations on the data.

[0004] OO programming in general is based on the notion of inheritance; the attributes and methods invocable in an object are defined through a class hierarchy that permits functionality to be reused from one object to another when active objects are instantiated. The active objects are constructed in dynamic memory according to a set of constructors defined through class inheritance.

[0005] The manner in which access to the stored data is made through an active object must be specifically programmed, particularly if the data is stored in a structured format such as a relational database. As discussed in European Patent Application 0 690 375 A2 of International Business Machines Corporation for “Persistent Object-Mapping In An Object-Oriented Environment”, published on Jan. 3, 1996, an object called a schema mapper can be employed to generate all of the database access code in the object. A sample of code to map an object with a single database table is provided in the published application. In order to map the object with data in multiple discrete tables, databases and/or memories, similar code would have to be generated in the object for each data access location.

[0006] The present invention is directed to structuring an object that can be used for simple and complex mappings to data, as well as various forms of data resource management. The object structure of the invention can be used for wrapping legacy code, as well as newly written object-based code.

[0007] The invention is also directed to structuring an object so that both vertical and horizontal slicing techniques on the inheritance hierarchies can be used.

[0008] Accordingly, the present invention provides a system for giving program data objects access to stored data, implemented in an object oriented programming environment. The system provides at least one object wrapper isolating access code for the stored data into reusable modules, and means for invoking said access code from the program data objects. Preferably, the object wrappers consist of a plurality of access code modules, each of which contains access code for a unique view of data accessed from multiple storage locations.

[0009] The present invention also provides an object builder tool implemented in software for mapping program data objects with stored data. The object tool includes means for wrapping blocks of access code to the stored data in reusable code modules, and means for inlining access code to the reusable code modules in the program data objects. Preferably, the means for wrapping blocks of access code to the stored data in reusable code modules consists of means for isolating attributes from methods in a given program data object, means for defining each of a set of attributes and methods for the given program data object in one or more one wrapper objects and sequentially mapping each attribute and method in the given data object to, respectively, at least one attribute and method in the one or more wrapper objects, and then means for generating the reusable code modules in the wrapper object(s) according to the defined attributes and methods. Also, preferably, the means for wrapping blocks of access code to the stored data in reusable code modules consists of means for wrapping blocks of access code to unique views of the stored data, with at least some views representing data accessed from multiple storage locations.

[0010] Additionally, the invention provides a method for creating wrappers for reusable code blocks for access to stored data. For each selected data object, the method consists of defining at least one persistent object instance, defining the attribute mapping from the data object to said at least one persistent object instance, defining the method mapping from the data object to said at least one persistent object instance, generating code to define said at least one persistent object according to the defined associations of data object attributes and methods, and generating inline code in the data object to invoke methods in said at least one persistent object to access the stored data.

[0011] The invention is also directed to a program storage device readable by a machine, that tangibly embodies a program of instructions executable by the machine for performing the above recited method steps.

[0012] Embodiments of the invention will be described in detail below in conjunction with the accompanying drawings in which;

[0013] FIG. 1 schematically illustrates the relationship between an active object and a single data location, according to the prior art;

[0014] FIG. 2 schematically illustrates the relationship between an active object and multiple data locations, according to the prior art;

[0015] FIG. 3 is a view similar to the views in FIGS. 1 and 2, schematically illustrating the relationship between a data object and multiple data locations, according to the invention;

[0016] FIG. 4 is a flow diagram showing the steps for creating data access through persistent objects, according to the invention; and

[0017] FIGS. 5 through 13 are views from a computer display illustrating, by way of screen captures, the operation of a tool that can be used to automate the creation of data objects of the structure of the invention, according to a preferred embodiment of the invention.

[0018] FIGS. 1 and 2 schematically illustrate the access relationship between an active data object (DO) and stored data, according to the prior art. To discuss this access relationship, the example of a document having a set of properties or state data is used. The properties or state data of the document object are the aspects of the object or its components that the user may want to access and manipulate.

[0019] Taking the simple case first in reference to FIG. 1, documents are defined as having three properties, size, heading and body. The data on “documents” is stored in a traditional relational database 1a, in a document table 2, organized in columns 3, 4, 5, for data on each of the three document properties.

[0020] Each instance of a document in the document table 2 can be represented by an active data object represented generally by reference numeral 6, instantiated when a user reads, writes or gets the document. The document object 6 includes access code for each of the three properties to target the relevant column in the document table 2. In traditional programming, this access code is placed in the document data object 6aat the point at which access to the data on that property is required. An example of data access code is that generated by the schema mapper described in the above-referenced European Patent Application No. 0 690 375 A2. Repeated access requests result in a data object with large inter-related blocks of code.

[0021] The preferred embodiment of the present invention has been implemented in IBM's Component Broker series (CBSeries), a data model defined by the C++language mapping of the Object Management Group's Common Object Request Broker Architecture (OMG CORBA) Version 2.0.

[0022] One aspect of CBSeries/CORBA is that it does not permit direct reference to object properties. The properties or state of an object are isolated from its behaviour, and also from the transactional and operational aspects of the object by defining the document's Interface Definition Language or IDL and stating its attributes. A set of “get” and “set” method are used to get the document size get the document's heading and get the documents body in order to access these properties, and to set the documents size, set the document heading and set the document body in order to create these properties in a new document. The set methods are also used to modify an existing document.

[0023] It is very rare that all data is found in only one table in a single data base. FIG. 2 illustrates a situation that is more complex, but more likely to be closer to reality. In addition to the three properties of size, heading and body, the document may have other properties such as serial number and author name, used for indexing. In the illustrated example, this additional data is stored in columns 8, 9, in document index table 7, possibly located in a separate relational data base 1b. Because tables 2 and 7 contain data on properties for the same documents, there must be some relationship between them. Usually the serial number (generally designated as column 8 in the tables) is a common element. In relational data base terminology, this common element is referred to as the “foreign key”.

[0024] Reference to multiple tables is common in relational data base technology. To handle this, relational space includes mechanisms called “views” for linking the tables to permit users to extract subsets of information from across them.

[0025] In current implementations, in order to access (“get” a view of a document from its data object, serial access code segments, for each table referenced, is written in the data object. The identity of the document is likely to be its foreign key (its serial number in the example illustrated in FIG. 2), and the data for this is found in multiple databases. So, in addition to providing the access code for all tables referenced in the document view, the data object must include functionality to relate the document identity to all of the code segments for accessing the database tables. Each access code segment causes the data from that table to be stored locally, so that the desired information is available to the object. This may result in the local storage of multiple copies of the data.

[0026] If the name or data storage location of a property changes, there are complex problems associated with mapping the change into the code written in the data object. In particular, all of the access code must be checked to reset the value of all references to the modified property, to avoid data access errors. Similarly, when the user is creating or adding to a document, the order of table access is determined by the data base implementation. This order must be strictly followed, particularly where changes are made to a foreign key, to maintain consistency across the tables. (In the case of setting a foreign key, checkpoints must be maintained in the data object to ensure that the foreign key has been set in all the tables containing information for the data object.) Where the access code is managed sequentially, as in the prior art, there are more and more issues to take care of in manipulating the stored data, and the code in the data object becomes longer and more complex.

[0027] The present invention provides a data object structure for mapping the data object to one or more database tables, or other data locations, in a manner that simplifies these access and access coding requirements. This is illustrated schematically in FIG. 3.

[0028] A data object 10 is divided into one or more modules called persistent object wrappers (PO) 11, 12, 13. The role of the PO is purely to isolate the raw data access and management code of the smallest meaningful units of state.

[0029] In the simple case, a data object has one PO and delegates all of its “get” and “set” methods, as well as its state associated behaviour to the PO. The data object could also provide type mapping, but in the preferred embodiment, the DO is designed to provide nothing more than attribute name. As discussed in detail below, type mapping is also delegated to another pure helper class that has no state of its own. Then, when the user wants to “get” a property, instead of having the data object execute the “get” method itself and obtain its local copy of the data, the data object simply invokes the “get” method on its PO. Providing a DO with type mapping as well as attribute name, according to the invention, would be an obvious modification to the following description, to the person skilled in the art.

[0030] Where, as in the preferred embodiment, the DO provides only the attribute name, then depending on the implementation environment, the getter method inlined in the DO could constitute a simple statement, such as:

[0031] All of the code for accessing the document data, including the docSize property, is found in the PO, instead of being inlined in the DO. The code generated in a PO for “getting” a particular attribute is reusable by any user of the PO.

[0032] In the same way, entering changes to the stored data is also modularized. A brief method invocation, often a single statement, in the body of the DO invokes the appropriate update methods in one or more persistent objects, in the order required for effectively updating the stored data. This is described in detail below in conjunction with FIG. 13 illustrating an aspect of the preferred embodiment.

[0033] This approach enables the user to minimise the amount of code by creating PO interfaces to the data source(s) for frequently accessed views of the data. However, the basic structure of the DO remains unchanged, and direct mapping, with inlined code, or using a mapping helper class outside the builder tool, is still possible, particularly for complex attributes in the DO that require mapping that is unique to the particular DO and isolated from the reusable PO. This could include infrequently accessed document views, or views that include data requiring special approvals or security to access.

[0034] The example shown in FIG. 3 illustrates a relatively complex situation. For an instance of a document, the data object (DO) 100 has at least three persistent objects (PO), a PO 102 representing the data in a document table 114 in a first data base 108, a PO 104 representing the data in a document view table 116 in a GUI (graphical user interface) data base 110, and a PO 106 representing the data in the document index table 118 in a third data base 112. When the user wants access to author information, the DO 100 will invoke “get author” on PO 106 representing document index table 112, rather than having its own copy of the access code. Similarly, to access the document body, the DO 100 will delegate, and invoke the “get body” method on PO 102 representing document table 114. In both cases, the “get” method invocation represents a single line of code in the body of the DO, rather than a copy of the data from the data base table.

[0035] The invention has been implemented in an object builder tool that automates the above-described modularization of data base access code in persistent object (PO) wrappers in a data object (DO). The tool operates to generate the code to create one or more PO wrappers containing the attributes and methods of the DO. FIG. 4 is a flow diagram setting forth the steps and decisions taken in the tool to map and then generate this PO wrapper code. FIGS. 5 through 12 are a series of views or windows from a computer display of the user interface in the object builder tool. These views illustrate the manner in which the steps for setting parameters for the get and set methods for the PO's are presented to the user and information is elicited for code generation to achieve the PO wrapping.

[0036] Although the parameters for the get and set methods are defined by the programmer, they are a reflection of the rules in the database. In the case of relational databases, these are strict rules. For example, referring back to FIG. 3 where the serial number in the document index table 118 is the foreign key for the document table 114, proper sequencing requires that a new serial number is indexed before it is added (set) in the document table.

[0037] Particularly in the case of multiple PO's, the data object has the responsibility of dealing with how the PO's relate to each other. By isolating out the PO's, the data object deals purely with the relationship of the PO's to each other in the context of the data object. This is similar to the modularizations done when data schema are made of various configurations over a set of tables.

[0038] In FIG. 4, the user must first select the PO wrapper to be used for the simple access code (block 200). The user can select as many instances of POs as needed (block 202), typically one PO instance for each database table being accessed. Each PO instance must have a unique name relative to the other PO instances, although instances of the same PO type can be multiplied, if needed.

[0039] FIG. 5 illustrates a user interface in the builder tool. The illustrated window 300 for defining persistent objects associated with a specific data object, includes an instance name field 302 which is automatically defined when the user makes a selection from the list in the type field 304, and a tree view window 306, called Persistent Object Instances, that presents a current hierarchy as the persistant objects associated with the data object are built by the user. The type field list 304 contains a scrollable list of PO types that the builder tool knows about. The user can also input an override type name into field 304 that is not found in the tool's list. In that case, the builder tool will check that the user override name is unique before generating the PO. A PO is generated when the user imports a data base table definition (as in the example discussed and illustrated herein). This is supported as an import for tables, views (SQL types) or from a JavaBean.

[0040] The windows 300, 310, 340 illustrated in FIGS. 5 through 12 include other common windowing features, such as size and close icons, and buttons to move forward and backward, and to end the window or access help, but as these form no part of the invention, they have not been separately referenced.

[0041] Returning to FIG. 4, once the persistent object instance(s) for a data object have been specified (blocks 200, 202), each DO attribute must be associated with a PO attribute (block 204). In the builder tool view shown in FIG. 6, the Attributes Mapping window 310 (which is similar in appearance to the Associated Persistent Objects window 300 shown in FIG. 5) includes the field 312 in which a single mapped persistent object attribute is shown, field 314 defining the mapped attribute's type, and tree view 316 showing the attribute hierarchy as it is constructed.

[0042] This mapping can be a one-to-one mapping, as shown in FIG. 6, or one DO attribute can be mapped to many PO attributes, as shown in FIG. 7. Consequently, the type (shown in field 314) may vary. In FIG. 6, the DO attribute name, drawn from the type field 314, is identical to the PO attribute name 312. In FIG. 7, the attribute type 312 is simply described as “long”, and the attribute of “customer name” maps to two “customer” PO attributes shown in the tree view 316, “customer name” and “agent”.

[0043] For each attribute mapping set, the user selects the type of mapping to be done as the value moves from the DO interface to the PO interface (block 206 in FIG. 4). The tool of the preferred embodiment queries the user input to provide the appropriate mapping. Currently, three options are provided as illustrated in the screen captures of FIGS. 8 through 10. The user can select default values provided by the tool (blocks 208, 210, in FIG. 4), or can input parameters for a pattern recognised by the tool, such as map as a key or as an object reference (blocks 212, 214). If the pattern is not a recognised pattern or default mapping, the user must provide a helper class to provide definitions for the class and its methods (block 216).

[0044] As shown in FIG. 8, the default mapping option 322 equates to a simple assignment statement. As shown in FIG. 9, Mapping as a Key is a type of mapping pattern completely automated within the tool of the preferred embodiment. The tool queries for further details by providing a list of the recognised patterns 326, so that the appropriate code can be inserted into the DO and PO interfaces. The provision, in the tool, of this selection list of known patterns again leads the user to a simple assignment statement.

[0045] If the user does not want to map using the automatic mapping values provided by the tool, then the user selects Map using a Helper Class (button 328 in FIG. 10). The user must provide a class to do the mapping in field 330 and identify which method to use for each directional movement of the values from the DO to the PO in field 332, and from the PO to the DO in field 334. The tool will not generate inline code in the DO to do the mapping; instead, a method invocation on the specified helper class will be used for the mapping. If the user changes the mapping required between the DO and the PO attribute using a helper class, the only required change is in the mapping helper called in the DO methods.

[0046] Once all of the attribute sets for each attribute in the data object are mapped (blocks 218, 220 in FIG. 4), the methods must be mapped (block 222). For the tool of the preferred embodiment, this is illustrated in the screen captures of FIGS. 11 and 12.

[0047] In this tool, the methods of the DO, called “framework methods” 344, can be mapped to one or more PO method. This, in FIG. 11, the DO method insert listed in the tree in field 344 can be mapped to a single PO insert method (entry in field 342 is added to the tree in field 344). If more than one PO method is needed, then the user can simply select them. Thus, in FIG. 12, a PO delete method selected in field 342 has been added to the mapping of the DO's insert function in the tree displayed in field 344. As with the attributes, if the sequence of the accessing the methods is important, the user can specify the sequence by the order in which the PO methods are listed in the mapping tree 344, adjusting that sequence by selecting the move up/down button for the field.

[0048] By providing the two sets of UI specifications to separately define attribute and method mapping, the tool can gather enough information from the user to generate all the DO and PO code involved in DO to PO mapping according to the invention.

[0049] When all of the mapping is complete in the tool of the preferred embodiment, the code can be emitted. As a result of following the invention, the DO getter method could look as simple as:

[0050] In the case of the implementation environment of the preferred environment, CBSeries, the code would be generated as:

[0051] The additional code required to handle conversions to CORBA and other program model issues are inlined in the DO. Thus, these DO unique issues are handled without touching the PO.

[0052] As discussed above, updating changes in the data base is accomplished by invoking an update method in the PO. A simple statement in the DO, such as:

[0053] invokes the method defined in the following code segment, an update method in the DO that has been mapped to a single PO, as illustrated in FIG. 13.

[0054] The above code for the update method in the PO is all that is generated and can be reused by any user of the PO.

[0055] A more complex mapping of one DO attribute to different PO attributes simply adds one line to the DO update method. If the same PO is being used, no additional PO code is required.

[0056] While the present invention may be implemented in any object oriented programming environment, it is particularly useful in an interpreted environment such as Java or Smalltalk. Productive use of the invention in a compiled OO environment such as C++can be made, provided (specifically in the case of C++) that indirect references are minimised.

[0057] Modifications of the invention that would be obvious to the person skilled in the art are intended to be covered by the scope of the appended claims.