A family of Java interfaces defines methods to provide common information about a property, such as data type and editing capabilities. The interfaces identify the methods used to get generic metadata. Implementers may extend these classes, as needed, to provide the metadata for their specific properties. The common metadata description interface of the present invention allows multiple metadata sources to be used interchangeably within the same software product without the software code being specifically written for each metadata source.
|
1. A method for providing metadata, comprising:
providing an object descriptor interface;
creating an object descriptor class for an object using the object descriptor interface;
using methods defined by the object descriptor interface to identify a property of the object;
providing a property descriptor interface;
creating a property descriptor class using the property descriptor interface; and
using methods defined by the property descriptor interface to obtain metadata associated with the identified property.
21. A computer readable medium, for defining metadata, having stored thereon:
instructions for providing an object descriptor interface;
instructions for creating an object descriptor class for an object using the object descriptor interface;
instructions for using methods defined by the object descriptor interface to identify a property of the object;
instructions for providing a property descriptor interface;
instructions for creating a property descriptor class using the property descriptor interface; and
instructions for using methods defined by the property descriptor interface to obtain metadata associated with the identified property.
12. An apparatus for providing metadata comprising:
a processor;
first implementation means for providing an object descriptor interface;
first creation means for creating a object descriptor class for an object using the object descriptor interface;
first exposing means for using methods defined by the object descriptor interface to identify a property of the object;
second implementation means for providing a property descriptor interface;
second creation means for creating a property descriptor class using the property descriptor interface; and
second exposing means for using methods defined by the property descriptor interface to obtain metadata associated with the identified property.
2. The method of
3. The method of
4. The method of
5. The method of
7. The method of
9. The method of
13. The apparatus of
14. The apparatus of
15. The apparatus of
16. The apparatus of
18. The apparatus of
20. The apparatus of
|
|||||||||||||||||||||||||
1. Technical Field
The present invention relates to data processing and, in particular, to the definition of metadata in the Java programming language. Still more particularly, the present invention provides an open framework for the definition of metadata.
2. Description of Related Art
Java is a programming language designed to generate applications that can run on all hardware platforms without modification. Java is an interpreted language. The source code of a Java program is compiled into an intermediate language called “bytecode,” which cannot run by itself. The bytecode must be converted (interpreted) into machine code at runtime. Upon finding a Java applet, e.g., in a Web page, a Web browser invokes a Java interpreter (Java Virtual Machine (JVM)) which translates the bytecode into machine code and runs it. JVMs are available for most hardware platforms. Thus, Java programs are not dependent on any specific hardware and will run in any computer with the Java Virtual Machine software. On the server side, Java programs can also be compiled into machine language for fastest performance, but they lose their hardware independence as a result.
JavaBeans are a component software architecture that runs in the Java environment. JavaBeans are independent Java program modules that are called for and executed. They have been used primarily for developing user interfaces at the client side. The server-side counterpart is Enterprise JavaBeans (EJBs). Java programs may also reference data sources other than JavaBeans and EJBs. For example, a Java program may reference a database made up of tables. Each source of data may have a different associated metadata. Metadata is data that describes other data. Data dictionaries and repositories are examples of metadata.
With different metadata sources, programmers must anticipate every possible metadata source and write code to communicate properly with each metadata source. If code is written for a plurality of metadata sources, the code may become very complicated. Furthermore, it is impossible to anticipate new metadata formats in the future. If an enterprise wishes to add a new data type and, thus, a new metadata source, the code must be completely rewritten. Therefore, it would be advantageous to provide an open framework for the definition of metadata.
The present invention provides a family of Java interfaces that define methods to provide common information about a property, such as data type and editing capabilities. The interfaces identify the methods used to get generic metadata. Implementers may extend these interfaces, as needed, to provide the metadata for their specific properties. For example, when a relational database is added, a programmer may write an object descriptor and a property descriptor classes that extend the interfaces. The common metadata description interface of the present invention allows multiple metadata sources to be used interchangeably within the same software product without the software code being specifically written for each metadata source.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
With reference now to the figures,
In the depicted example, a server 104 is connected to network 102 along with storage unit 106. In addition, clients 108, 110, and 112 also are connected to network example, personal computers or network computers. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108–112. Clients 108, 110, and 112 are clients to server 104. Network data processing system 100 may include additional servers, clients, and other devices not shown. In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the TCP/IP suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN).
In accordance with a preferred embodiment of the present invention, Java programs may be called from within HTML documents or launched stand alone within network data processing system 100. When a Java program runs on a client, such as clients 108, 110, 112, it is often called a “Java applet.” When it is run on a server, such as server 104, it is called a “servlet.”
The present invention provides a family of Java interfaces that define methods to provide common information about a property, such as data type and editing capabilities. Implementers may extend these classes as needed to provide the metadata for their specific properties. For example, one embodiment of the present invention is an implementation that provides metadata descriptions of columns in a database table could be realized using Java DataBase Connectivity. Another example may be an implementation that uses Java introspection to glean metadata information about any bean object. The common metadata description interface of the present invention allows these two implementations to be used interchangeably within the same software product.
Referring to
Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to network computers 108–112 in
Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, data processing system 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.
Those of ordinary skill in the art will appreciate that the hardware depicted in
The data processing system depicted in
With reference now to
An operating system runs on processor 302 and is used to coordinate and provide control of various components within data processing system 300 in
Those of ordinary skill in the art will appreciate that the hardware in
As another example, data processing system 300 may be a stand-alone system configured to be bootable without relying on some type of network communication interface, whether or not data processing system 300 comprises some type of network communication interface. As a further example, data processing system 300 may be a Personal Digital Assistant (PDA) device, which is configured with ROM and/or flash ROM in order to provide nonvolatile memory for storing operating system files and/or user-generated data.
The depicted example in
With reference to
The interface IMetaPropertySetDescriptor 404 describes a set of properties, such as a group of columns in a database. The IMetaObjectDescriptor interface 406 extends IMetaPropertySetDescriptor to collect multiple associated property descriptions into a single object description. Interface 404 is a subclass of interface 406. The arrow between interface 402 and 404 represents association. The arrow indicates that an object that implements interface 404 has a one-way association with objects that implement interface 402. Besides inheritance and association, relationships may include aggregation, using, instantiation, and meta-class. The “1 . . . *” indicates the cardinality of the association; a property set is associated with one or more properties. This is a one-to-many association. Other cardinalities may include one-to-one or many-to-many.
The methods of the IMetaProperty Descriptor are as follows:
The methods of the IMetaPropertySetDescriptor interface are as follows:
The methods of the IMetaObjectDescriptor interface are as follows:
With reference now to
An ObjectDescriptor class 510 that implements the interface IMetaObjectDescriptor is created. For example, if an enterprise uses a relational database, a programmer may create an ObjectDescriptor specifically for the relational database. The ObjectDescriptor includes the actual code for the methods identified in interface 506 and may glean information about an object. Next, a PropertyDescriptor class 508 that implements interface IMetaPropertyDescriptor 502 is created to expose information about each property in the object. In other words, the PropertyDescriptor class includes the actual code for the methods that are identified in the IMetaPropertyDescriptor interface. These methods may be called to return metadata for a property. For example, for a relational database, each property may be represented by a column and the PropertyDescriptor may be written to provide the actual code for the methods identified in interface 502.
Interfaces 502, 504, 506 are universal. ObjectDescriptor and PropertyDescriptor classes are specific to a metadata source. An enterprise may create an OjbectDescriptor and one or more PropertyDescriptors when a metadata source is added. ObjectDescriptor and PropertyDescriptor classes may also be shared between enterprises. In fact, a developer of a data source, such as a database, may write an ObjectDescriptor and appropriate PropertyDescriptors to ship with the product. Once this framework is in place, software may be written as if all the programmer knows is that there is an object that has properties. This simplifies the programming significantly when multiple metadata sources are being used. Furthermore, software written for this open framework may be used even after new data sources are added.
Turning to
A DBTableObjectDescriptor class 612 that implements the interface IMetaObjectDescriptor is created. The DBTableObjectDescriptor class may glean information about the appropriate database table using APIs that talk to the backend database and use the methods defined in interface IMetaObjectDescriptor 606 to expose that information. Next, a DBColumnPropertyDescriptor class 608 that implements the IMetaPropertyDescriptor interface 602 is created to expose information about each appropriate database table column (again using APIs that talk to the backend database) and use the methods defined in interface IMetaPropertyDescriptor 602 to expose that information.
Similarly, a JavaBeanObjectDescriptor class 614 that implements the interface IMetaObjectDescriptor is created. The JavaBeanObjectDescriptor class may glean information about the JavaBean using Java's built-in object introspection mechanism and use the methods defined in interface IMetaObjectDescriptor 606 to expose that information. Next, JavaBeanPropertyDescriptor class 610 that implements the IMetaPropertyDescriptor interface 602 is created to expose information about each property in the JavaBean using Java's built-in method introspection mechanism. Thus, the family of Java interfaces that make up the common interface may be implemented to expose information from multiple metadata sources, in this example one source being a relational database and the other being a Java Bean object.
An example Java program for a property sheet editor written using the open framework of the present invention follows:
// This is an example of a property sheet editor that uses
// Java interfaces for describing property metadata in a
// generic way.
1000
public class Example
{
// This method loads a set of text field editor GUIs with
// the values of properties contained within an object
// whose metadata is described using the
// “IMetaObjectDescriptor ”interface.
1005
public void load(IMetaObjectDescriptor objDesc, Object
objValue)
{
// Loop through all the property descriptors contained
// within the object descriptor.
1010
for (int i=0; i < objDesc.getPropertyDescriptorcount( );
i++)
{
// Get a property descriptor from the object
// descriptor.
1015
IMetaPropertyDescriptor propDesc =
objDesc.getPropertyDescriptor (i);
// Get the programmatic name of the property
// descriptor.
1020
String propName = propDesc.getName( );
// Extract from the object's value the value of the
// property named by the property descriptor.
1025
Object propValue =
objDesc.getPropertyValue(propName, objValue);
// Get a property editor for the property's value
// from the property descriptor.
1030
PropertyEditor propEditor =
propDesc.getPropertyEditor( );
// Set the property editor to the value of the
// property.
propEditor.setValue(propValue);
// Create a text field editor GUI for the property.
JTextField textField = new JTextField( );
// Set the text field editor GUI's display text to
// the textual representation of the property's
// value. (The “getAsText” method of the property
// editor performs the conversion to textual
// representation.)
textField.setText(propEditor.getAsText( ));
// Associate the programmatic name of the property
// descriptor with the text field editor GUI and
// store it in the lookup table so that it can be
// accessed later.
1035
textEditors.put(propName, textField);
}
}
// This method saves a set of property values contained
// within text field editor GUIs to an object whose
// metadata is described using the “IMetaObjectDescriptor”
// interface.
1050
public void save(IMetaObjectDescriptor objDesc, Object
objValue)
{
// Loop through all the property descriptors contained
// within the object descriptor.
1055
for (int i=0; i < objDesc.getpropertyDescriptorCount( );
i++)
{
// Get a property descriptor from the object
// descriptor.
1060
IMetaPropertyDescriptor propDesc =
objDesc.getPropertyDescriptor(i);
// Get the programmatic name of the property
// descriptor.
1065
String propName = propDesc.getName( );
// Get a property editor for the property's value
// from the property descriptor.
PropertyEditor propEditor =
propDesc.getPropertyEditor( );
// Access the text field editor GUI for the
// property descriptor from the lookup table using
// the property's programmatic name.
JTextField textField =
(JTextField)textEditors.get(propName);
// Set the property editor to the textual
// representation of the property's value from the
// text field editor GUI. (The “setAsText” method
// of the property editor performs the conversion
// from textual representation.)
1070
propEditor.setAsText(textField.getText( ));
// Get the new value of the property from the
// property editor.
1075
Object propValue = propEditor.getValue( );
// Insert the new value of the property named by
// the property descriptor into the object's value.
1080
objDesc.setPropertyValue(propName, objValue,
propValue);
}
}
// Lookup table structure for storing text field GUIs used
// to edit property values.
private HashMap textEditors = new HashMap( );
}
In the example program, line 1000 defines a class. Then, line 1005 defines a method called “load” that takes an ObjectDescriptor and an object as values. In the example shown in
Next, in line 1010, the program uses the methods in the framework to get the number of properties and loops through the properties. Line 1015 gets the property descriptor from the object descriptor. Line 1020 gets the property name and line 1025 gets the property value. Next, line 1030 gets a property editor from the property descriptor. (For a description of property editors see SUN Java Bean specification, Java Platform Second Edition, version 1.1 API.) This is used to populate a text field user interface widget with a textual representation of the property's value. In line 1035, this text field widget is associated with the property's name and is saved to a lookup table.
Thereafter, line 1050 defines a method called “save” that takes an ObjectDescriptor and an object as values. Next, in line 1055, the program uses the methods in the framework to get the number of properties and loops through the properties. Line 1060 gets the property descriptor from the object descriptor. Line 1065 gets the property name. Next, line 1070 extracts the textual representation of the edited property value from the text field widget that was previously saved to a lookup table and converts it to the property value object using the property editor. Line 1075 gets the property value object from the property editor. Thereafter, in line 1080, the property's new value is saved back into the containing object. This completes the editing process.
As can be seen in the above example, a program may be written without identifying an object type or a metadata source. The example property sheet program may be used for multiple data sources and may be reused in any environment taking advantage of the open framework of the present invention. While the example program is written in Java, other programming languages may be used, such as C++.
With reference now to
Thus, the present invention solves the disadvantages of the prior art by providing a family of Java interfaces that makes up a common interface for multiple metadata sources. Classes that implement these interfaces may extend these classes as needed to provide the metadata for their specific properties. Multiple implementations may be used interchangeably within an application because of the common metadata description provided by the interfaces. This technique is useful in cases in which properties are dynamically created at runtime and, therefore, cannot be described using a concrete bean object defined at compile time.
It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
LeBlanc, Karalee Brown, Hartel, John Mark, Sanchez, John Conrad
| Patent | Priority | Assignee | Title |
| 10782943, | Oct 29 2009 | STENSAL, INC. | Encoding data and metadata for run-time checking of computer code and data serialization |
| 7685571, | Aug 27 2003 | Microsoft Technology Licensing, LLC | Interactive domain configuration |
| 7861250, | Apr 25 2003 | Microsoft Technology Licensing, LLC | Runtime polymorphism |
| 8195707, | Sep 30 2008 | Adobe Inc | Identifying and reacting to changes in an extensible automatic runtime object management system |
| 8448153, | Oct 29 2009 | STENSAL, INC | Encoding data and metadata for run-time checking of computer code and data serialization |
| 8918433, | Sep 30 2008 | Adobe Inc | Identifying and reacting to changes in an extensible automatic runtime object management system |
| 9971575, | Oct 29 2009 | STENSAL, INC | Encoding data and metadata for run-time checking of computer code and data serialization |
| Patent | Priority | Assignee | Title |
| 5758348, | Jul 25 1995 | Unisys Corp. | Method for generically manipulating properties of objects in an object oriented repository |
| 5848273, | Oct 27 1995 | Unisys Corporation | Method for generating OLE automation and IDL interfaces from metadata information |
| 6108664, | Oct 31 1997 | Oracle International Corporation | Object views for relational data |
| 6112207, | Oct 31 1997 | Oracle International Corporation | Apparatus and method which features linearizing attributes of an information object into a string of bytes for object representation and storage in a database system |
| 6128621, | Oct 31 1997 | Oracle International Corporation | Apparatus and method for pickling data |
| 6134559, | Apr 27 1998 | Oracle International Corporation | Uniform object model having methods and additional features for integrating objects defined by different foreign object type systems into a single type system |
| 6477701, | Sep 30 1999 | Seiko Epson Corporation | Version-adaptive serialization and deserialization of program objects in an object-oriented environment |
| 20030050932, | |||
| 20030140090, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Jul 09 2001 | HARTEL, JOHN MARK | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 011994 | /0490 | |
| Jul 09 2001 | LEBLANC, KARALEE BROWN | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 011994 | /0490 | |
| Jul 09 2001 | SANCHEZ, JOHN CONRAD | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 011994 | /0490 | |
| Jul 12 2001 | International Business Machines Corporation | (assignment on the face of the patent) | / |
| Date | Maintenance Fee Events |
| Oct 06 2005 | ASPN: Payor Number Assigned. |
| Apr 17 2009 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Aug 16 2013 | REM: Maintenance Fee Reminder Mailed. |
| Oct 11 2013 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Oct 11 2013 | M1555: 7.5 yr surcharge - late pmt w/in 6 mo, Large Entity. |
| Aug 11 2017 | REM: Maintenance Fee Reminder Mailed. |
| Jan 29 2018 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
| Date | Maintenance Schedule |
| Jan 03 2009 | 4 years fee payment window open |
| Jul 03 2009 | 6 months grace period start (w surcharge) |
| Jan 03 2010 | patent expiry (for year 4) |
| Jan 03 2012 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Jan 03 2013 | 8 years fee payment window open |
| Jul 03 2013 | 6 months grace period start (w surcharge) |
| Jan 03 2014 | patent expiry (for year 8) |
| Jan 03 2016 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Jan 03 2017 | 12 years fee payment window open |
| Jul 03 2017 | 6 months grace period start (w surcharge) |
| Jan 03 2018 | patent expiry (for year 12) |
| Jan 03 2020 | 2 years to revive unintentionally abandoned end. (for year 12) |