transforming meta object facility specifications into relational data definition language structures and JAVA classes

A meta object facility file is parsed into a plurality of schema elements. For each schema element, it is determined that the definition of the schema element is complete. A computing artifact usable in a database description language database table or a JAVA class is created from the schema element. When the schema element is a meta object facility class, a modeling entity is created to store the computing artifacts derived from the meta object facility file wherein the modeling entity is a JAVA class. The meta object facility class is transformed into a JAVA class, and upon determining that an attribute of the meta object facility class has an array of values, an array table is created and identified in the modeling entity, and an array attribute is added to JAVABEAN information in the modeling entity.

FIELD OF THE INVENTION

This invention relates to databases and object-oriented programming, and more particularly relates to a computer-implemented method to generate manipulatable computing artifacts from a set of abstract and generic specifications described in Meta Object Facility (MOF) format.

BACKGROUND OF THE INVENTION

Meta Object Facility (MOF) metamodels define data structures for many system and computing application domains such as software modeling, data warehousing, component management, versioning, etc. MOF is a text-based specification that describes a set of objects, their attributes and their associations with other objects. MOF defines the semantics and content structure of metamodels but it does not define a concrete implementation. In order to use these MOF specifications in a business application, they need to be converted into artifacts or structures such as databases and JAVAlanguage classes that can be instantiated, manipulated either manually or programmatically, and that can store data in memory at runtime as well as maintain data in the databases.

Prior to the invention described herein, creating useful computing artifacts such as databases and JAVAclasses from a MOF format was a manual, cumbersome, multi-step process: first, the MOF format files were read and parsed using manual or automated processes; second, classes and attributes were converted into relational database data definition language statements through a series of manual and automated sub-steps. These sub-steps created a logical data model from the classes and attributes identifying entities and attributes, transformed the logical data model into a physical database design, and created the Database Description Language (DDL) from that physical database design. The third and final step created the necessary JAVAclasses that were used by an application to create in-memory representations of the data in the database.

Known methods that are both manual and cumbersome include using a combination of IBM's RATIONALROSEand CRM Tooling products in a three-step process that loads the MOF file using CRM tooling into RATIONALROSE, followed by two steps within RATIONALROSEto transform the object-oriented model into a database design, and then generate the database data definition language statements. This solution, however, does not generate JAVAclasses. Another solution is COMPUTERASSOCIATE'SERWIN: ERWINis a three-step process used only in the creation of the relational database but it does not support object-oriented classes and attributes and does not generate JAVAclasses. In both solutions above, moreover, the results must be manually fixed and enumerated lists are not generated.

SUNMICROSYSTEMSMOF compiler is an open-source product that parses MOF files and uses the resulting object model information to generate corresponding JAVABEANSthat are then stored in a binary repository. The JAVABEANSdefine interfaces but do not include any implementing code. The SUNMICROSYSTEMSMOF Compiler, moreover, does not translate the object model into a corresponding relational model. A WINDOWSMANAGEMENTINSTRUMENTATIONMOF Compiler is a proprietary product provided with the MICROSOFTWINDOWSoperating system starting with WINDOWSNT that compiles MOF files into corresponding classes and stores the classes in the WINDOWSMANAGEMENTINSTRUMENTATIONrepository. A PEGASUSMOF compiler is also an open-source product that compiles MOF files into corresponding classes and stores the classes in a file-based repository.

Despite the several products and their capabilities, there remains a need for an automated process of transforming a model defined using Meta Object Facility specifications into persistent data storage in a relational database and of generating object-oriented JAVAclasses used to create in-memory representations of the data in the data storage. There is a further need for a simplified and automated process to streamline the systems development effort of transforming a model defined using MOF specifications into persistent data storage in a relational database and of generating object-oriented JAVA classes used to create in-memory representations of the data in the data storage. These needs and other that will become apparent are solved by the invention as stated below:

SUMMARY OF THE INVENTION

These needs and others are met by a method to transform a meta object facility file wherein a computer parses the meta object facility file into a plurality of schema elements. For each schema element, the computer determines that a definition of a schema element is complete and processes the schema element to create a computing artifact usable in a database description language database table or a JAVAclass. The computer further determines that the schema element is a meta object facility class and creates a modeling entity that stores the computing artifacts derived from the meta object facility file wherein the modeling entity is a JAVAclass. The computer further transforms the meta object facility class into a JAVAclass, determines that an attribute of the meta object facility class has an array of values, creates an array table in the modeling entity, identifies the array table in the modeling entity and adds an array attribute to JAVABEANinformation in the modeling entity.

Also described herein is a data communication system including a transmitting data processing device that transmits data on a communication network and a receiving data processing device that receives the data transmitted from the transmitting data processing device. The transmitting data processing device comprises a transmitting portion which transmits a meta object facility data file. The receiving data processing device comprises a receiving portion that receives the meta object facility data file transmitted from the transmitting data processing device. The receiving data processing device has a processor that transforms the meta object facility data file into a database description language database and JAVAclasses for use on the data communication system. The processor parses the meta object facility file into a plurality of schema elements and for each schema element, the processor determines that a definition of a schema element is complete and creates a computing artifact usable in a database description language database table and/or a JAVAclass. The processor determines the schema element is a meta object facility class and creates a a modeling entity that stores the computing artifacts. The processor transforms the meta object facility class into a JAVAclass. The processor further determines that an attribute of the meta object facility class has an array of values and creates and identifies an array table in the modeling entity. The processor adds an array attribute to JAVABEANinformation in the modeling entity.

Also described herein is a computer program product to transform meta object facility files into computing artifacts usable in a database description language database and as JAVAclasses, the computer program product comprises a computer readable tangible storage device and has first program instructions to download a file in meta object facility format across a network. Second program instructions parse the meta object facility file into a plurality of meta object facility schema elements. Third program instructions create a plurality of meta object facility classes from at least one of the plurality of meta object facility schema elements that accurately reflect the object-oriented hierarchy of the meta object facility file. Fourth program instructions determine if each of the plurality of meta object facility classes has attributes. Fifth program instructions transform each of the plurality of meta object facility classes and its attributes into a database schema element wherein the database schema element is a table and has references to each attribute. Sixth program instructions create JAVABEANinformation of the database schema element and its respective attributes for use in at least one JAVAclass. Seventh program instructions determine that an attribute of at least one of the meta object facility classes has an array of values. Eighth program instructions create an array table in the modeling entity. Ninth program instructions identify the array table in the modeling entity. Tenth program instructions add an array attribute to JAVABEANinformation in the modeling entity. The first, second, third, fourth, fifth, sixth, seventh, eighth, ninth, and tenth program instructions are stored in the computer readable tangible storage device.

Also disclosed herein is a service for managing data transfer transactions between at least one microprocessor device and a servlet, both coupled to a communication network, the microprocessor device having processing hardware and/or software. The service comprises transferring a meta object facility formatted file to the microprocessor device. The microprocessor device parses the meta object facility formatted file into at least one class having at least one attribute and creates at least one schema element pertaining to each class wherein the schema element is capable of storing the attribute and value of the attribute. The microprocessor device creates JAVABEANinformation pertaining to the created database schema element. The microprocessor device determines that the schema element is a meta object facility class and creates a modeling entity that stores the computing artifacts. The microprocessor device transforms the meta object facility class into a JAVAclass and determines that the attribute of the meta object facility class has an array of values. The microprocessor device creates an array table in the modeling entity and identifies the array table in the modeling entity. The microprocessor device adds an array attribute to JAVABEANinformation in the modeling entity, and stores the schema element, the JAVAclass, and the JAVABEANinformation in a computer readable tangible storage device.

The invention is described with reference to the accompanying drawings; however, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather the illustrated embodiments are provided so that this disclosure is thorough and complete, and fully conveys the scope of the invention to those skilled in the art. Like numbers refer to the like elements throughout.

DETAILED DESCRIPTION OF THE INVENTION

Before proceeding with the detailed description of the invention, a summary of the terminology used herein is provided. An object is an abstract representation of a real-world concept or thing; for example, an object can represent a customer account in a banking application. An object may have an operation that defines an action that an object can perform, or an action that can be performed on the object or a property. For example, “make withdrawal” could be defined as an operation on a customer account object. Alternatively, an object may have a property that indicates the state of an object. Every property of an object has a value that defines the state of the object. A property can be either an attribute or a reference. An attribute defines a value that is stored within the object; for example, “current account balance” could be an attribute of the customer account object. The numeric value for the customer's account balance would be stored in the customer account object. A reference is a link or pointer to another object and implies a relationship to that other object. A reference is typically used when it is desired not to duplicate data; for example, the customer account object could store the customer's name and address as attributes. In the event that a customer has multiple accounts, the customer's name and address would appear in multiple account objects. Therefore, it is desirable to define a separate customer object and place the name and address as attributes of the customer object. The customer account object would then contain a reference to the customer object. The prefix meta as used herein shall describe a relationship. For example, metadata describes data; a metaobject is an object that represents metadata; and, metamodel an abstract language for expressing other models. The term model is generally used herein to denote a description of something in the real world.

The relational model is based on the mathematical theory of relations and was formally introduced by Dr. E. F. Codd in 1970 to describe how users perceive data. The relational model represents data in the form of two-dimension logical entities. Each logical entity represents some real-world person, place, thing, or event about which information is collected. A relational database is a database that is treated as a set of tables derived from logical entities and manipulated in accordance with the relational model of data. The relational database has a set of objects used to store, manage, and access data. The basic objects in the database are tables, columns, views, indexes, constraints (relationships), and triggers.

As will be appreciated by one of skill in the art, the present invention may be embodied as a method, data processing system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects, all generally referred to herein as a “module.” Furthermore, the present invention may take the form of a computer program product on a computer-readable tangible storage device having computer-usable program code embodied therein. Any suitable computer-readable tangible storage device may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.

Computer program source code for parsing, interpreting, and translating the MOF files and specifications may be written in an object oriented programming language such as JAVA, SMALLTALKor C++. The program object code may execute entirely on the software developer's computer, partly on the software developer's computer, as a stand-alone software package, partly on the software developer's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the software developer's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer via the Internet using an Internet Service Provider.

Referring toFIG. 1, a high-level block diagram of a computer network system8consistent with an embodiment of the invention is shown. Computer network system8may comprise any number of networked computers10, each of which may have a central processing unit (CPU)12, main memory14, and various digital and/or analog interfaces28-38. The various devices communicate with each other via an internal communications bus22. CPU12is a general-purpose programmable processor, executing instructions stored in memory14; while a single CPU is shown inFIG. 1, it should be understood that computer systems having multiple CPUs could be used. CPU12may be capable of executing the program instructions embodying the translation process, may be capable of generating the computer program or the instructions embodying the translation process, may be capable of receiving and transmitting the program instructions embodying the translation process, and is capable of storing the MOF file and the results generated by the translation process described herein. Communications bus22supports transfer of data, commands and other information between different devices, and while shown in simplified form as a single bus, it is typically structured as multiple buses including an internal bus24which may connect the CPU12directly with memory14.

Memory14is a random-access semiconductor memory for storing data and programs. Memory14is shown conceptually as a single monolithic entity but it is well known that memory is often arranged in a hierarchy of caches and other memory devices, some or all of which may be integrated into the same semiconductor substrate as the CPU12. Random access memory (RAM) devices comprising the main storage of computer, as well as any supplemental levels of memory, e.g., cache memories, nonvolatile or backup memories, programmable or flash memories, read-only memories, etc. In addition, memory14may be considered to include memory storage physically located elsewhere in computer, e.g., a cache memory in a processor or other storage capacity used as a virtual memory, e.g., as stored on a mass storage device or on another computer coupled to computer via network.

Operating system16and applications18,20reside in memory14. Operating system16provides, inter alia, functions such as device interfaces, management of memory pages, management of multiple tasks, etc. as is known in the art. Examples of such operating systems may include LINUX, AIX, UNIX, Windows-based, OS/400, an RTOS, a handheld operating system, etc. OnISERIES and AS/400 machines, OS/400 is the native operating system and object system and IFS is the UNIX object system complemented by the Qshell Unix command shell. These and other various applications, components, programs, objects, modules, etc. may also execute on one or more processors in another computer coupled to computer10via a network40,42, e.g., in a distributed or client-server computing environment, whereby the processing required to implement the functions of a computer program may be allocated to multiple computers10over a network40,42.

The invention is equally applicable to any microprocessor device10having an operating system16in which the microprocessor or processing device10is connected across a network40,42to devices having the same or different operating systems. In general, the routines18,20executed to implement the embodiments of the invention, whether implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions will be referred to herein as computer programs or simply programs. The computer programs typically comprise one or more instructions that are resident at various times in various memory and storage in a device and that, when read and executed by one or more processors in a device, cause that device to perform the steps necessary to execute steps or elements embodying the various aspects of the invention.

It should be appreciated that computer10typically includes suitable analog and/or digital interfaces28-38between CPU12and the attached components as is known in the art. For instance, computer10typically receives a number of inputs and outputs for communicating information externally. For interface with a software developer or operator, computer10typically includes one or more software developer input devices60-64, e.g., a keyboard, a mouse, a trackball, a joystick, a touchpad, and/or a microphone, among others, and a display such as a CRT monitor, an LCD display panel, and/or a speaker, among others. It should be appreciated, however, that some implementations of computer10, e.g., some server implementations, might not support direct software developer input and output. Terminal interface34may support the attachment of single or multiple terminals44and may be implemented as one or multiple electronic circuit cards or other units. Data storage50preferably comprises one or more rotating magnetic hard disk drive units, although other types of data storage, including a tape or optical driver, could be used. For additional storage, computer10may also include one or more mass storage devices50, e.g., a floppy or other removable disk drive, a hard disk drive, a direct access storage device (DASD), an optical drive e.g., a compact disk (CD) drive, a digital video disk (DVD) drive, etc., and/or a tape drive, among others. One of skill in the art will further anticipate that the interfaces28-38may also be wireless.

Furthermore, computer10may include an interface36,38with one or more networks40,42to permit the communication of information with other computers10coupled to the network(s)40,42. Network interface(s)36,38provides a physical and/or wireless connection for transmission of data to and from a network(s)40,42. Network(s)40,42may be the Internet, as well as any smaller self-contained network such as an Intranet, a wide area network (WAN), a local area network (LAN), or other internal or external network using, e.g., telephone transmissions lines, satellites, fiber optics, T1 lines, wireless, public cable, etc. and any various available technologies. One of ordinary skill in the art understands that computer system8may be connected to more than one network40,42simultaneously. Computer system and remote systems8may be desktop or personal computers, workstations, a minicomputer, a midrange computer, a mainframe computer. Any number of computers and other microprocessor devices, such as personal handheld computers, personal digital assistants, wireless telephones, etc., which may not necessarily have full information handling capacity as the large mainframe servers, may also be networked through network(s)40,42. Still yet, any of the components of the method and program products shown in the embodiments ofFIG. 1throughFIG. 9could be deployed, managed, serviced by a service provider who offers to receive MOF specifications over a computer network and then provide concrete and usable computing artifacts of the MOF formatted file in a usable DDL specified schema and/or usable JAVAclasses.

With respect toFIG. 2now, among the applications or routines that can be loaded onto the computing device is a translation engine120capable of translating a Meta Object Facility (MOF) specification or file110into useful computing artifacts and/or Java classes usable by a database description language (DDL) computer application. In fact, any computer data that is presented in a MOF format can be reformatted using the method described herein to be used in other object-oriented applications or and/or DDL applications, including but not limited to descriptions of an entire industry, or billing system, etc.FIG. 2provides a broad overview100of the major inputs, processes, and outputs of the translation engine in accordance with an embodiment of the invention. The MOF file110is an industry standard specifications file for defining objects; one or more MOF files are input to the translation engine120. The translation engine120first parses the MOF file and generates the database data definitions file180, the JAVAclasses130, and the XML object-to-relational (O/R) mapping file140and more.

The DDL files180created by the translation engine120and its processes accurately reflect the object-oriented hierarchy of the objects described in a MOF file. The MOF classes are transformed to database tables, the class attributes are transformed to columns within the table and prefix names may be used to create schema names. The translation engine preferably uses the schema name “enum” for all MOF enumerated lists tables generated. When creating table names and column names, the translation engine may remove all MOF prefixes from class names, e.g., CIM_, and remove all attribute names whether prefix, embedded or suffix when creating table names and column names. When no parent class exists, the translation engine and process described herein creates a unique generated primary key column for classes. If, however, a parent class does exist, the translation engine and process herein use the parent's primary key as the key of the class and creates a database constraint linking the child to the parent, e.g., Class classname: parent class name. The translator/process further creates database comment statements tables and columns using the description of the classes and the attributes and then transforms MOF attribute data types to database column data types.

By way of example only, IBM DB2 data types use the following translations to create the correct data type:

The translation engine also creates a single unique index using all attributes and/or columns identified with the keyword “Key”. The format for the name of the unique index may be: tablename_akn where “n” is an incremental number for additional unique indexes, for example: “employee_ak1”. For association classes the translation engine creates a table linking it to the parent classes/tables. Preferably, the “Ref” keyword role name and suffix “ID” are used as the column name. The translation engine further creates database constraint statements using the column names of the parent object class/database table using the column names of the parent's primary key column name. It uses the parent column data type for new column's data type. For example:

class CIM_Dependency {[Key, Description (“Antecedent represents the independent object in this ”“association.”)]CIM_ManagedElement REF Antecedent;[Key, Description (“Dependent represents the object dependent on the ”“Antecedent.”)]CIM_ManagedElement REF Dependent;
creates the following:Table name: DependencyPrimary key: DependencyID (see 4 above for explanation)Columns: AntecedentID and DependentIDUnique secondary index Dependency_AK1 on columnsConstraints on both columns to parent table ManagedElement andcolumn ManagedElementID.

Attributes with arrays can be identified either by the keyword “ArrayType” or by the trailing [ ] after the attribute name. The translation engine and process creates a child table moving the attribute to the child table, cascading the parent table primary key and adds a column, a SequenceNumber Integer, to the primary key. The table name is a combination of the parent table name and the array attribute name. The translation engine and the process described herein further creates a foreign key constraint from the new table back to the parent table.

Attributes with enumerated lists can be identified either by the keywords “ValueMap” and “Values”; both must be present. The translation engine creates a second enumerated list table using the enumerated list attribute as the primary key of the new table and a new “attribute name Description” column (varchar254). The new table name is a combination of “El” and the attribute name. It leaves the attribute on the existing table and creates a foreign key constraint from the parent table to the new table.

For attributes with arrays and enumerated lists, the translation engine creates a combination of both of the above where the child array table is an intersection table between the original table and the enumerated list table. Both parent tables' primary keys are cascaded into the intersection table. The name is a concatenation of the original table and the enumerated list table (minus the El prefix). It creates a constraint from the intersection table to each of the parent tables.

The translation engine further creates output files listing the old unabbreviated object name and the newly created abbreviated relational name. These are comma delimited files and include a list of tables, and a list of columns. The table names are unique within the generated DDL file generated, and the column names are unique with the table. The translation engine creates same name columns, i.e., foreign key columns on parent and child tables. The translation engine creates constraint names that support the convention of parent-tablename_cnn where “nn” is an incremental number within the table, e.g. “employee_c01”. The translation engine further creates index names that support the following conventions:tablename_pk for primary key statement, e.g., “employee_pk”;tablename_akn where “n” is an incremental number for additional unique indices, e.g., “employee_ak1”; andtablename_ien where “n” is an incremental number for additional non-unique secondary indices, e.g., “employee_ie1”.

The JAVAclasses130created by the translation engine120may be used by an application to create in-memory representations of the data in the database. The JAVAclasses represent each MOF class and correspond to the objects defined in MOF format. The translation engine120and its process as described herein further creates JAVAclass attributes that represent each MOF attribute and accessor methods for these Java class attributes.

The translation engine120and its method described herein further generates object-to-relational mapping files140that correlate the JAVAclasses and their attributes to the tables and columns in the created database. The translation engine may also create an object-to-relational mapping file, such as in XML, that maps the JAVAobject model to a relational database model. Each Java object is represented by a <class> element composed of attributes, a <map-to> element and <field> elements. The <map-to> element contains a reference to the relational table to which the Java object maps. Each <field> element represents a class variable and is composed of attributes and one <sql> element. The <sql> element represents the column in the relational table to which the <field> element maps. This O/R mapping file can be used to configure third-party object-to-relational persistence engine s, such as CASTORand HIBERNATE.

The translation engine120also generates enumerated list insert statements150used to load the data gathered from the MOF definitions for any enumerated list attributes. The MOF definitions contain explicit value sets, i.e., enumerated lists, that the translation engine120uses to build structured query language (SQL) insert statements for loading the enumerated list values into the database. These insert statements are written to a script file which is executed to insert the values into the corresponding tables. Additionally, import and export load statements along with the grant authorization SQL statements are created.

Object-to-relational name translation reference reports160comprise listings of each class name and its translated table name. Each class attribute name is also associated with its corresponding translated table column names. Translation reference reports160further comprise a file having lists of values assigned to specific class attributes for reference by users.

The database design reports170are also generated by the translation engine120and its method described herein; these reports170are used by development and testing to understand the database design and may include a data dictionary report containing the class/entity name, table name, attribute name, and column name; table and column report including datatype, size, whether nullable or not, and default values listing. The database design reports170may further include a referential integrity constraint report that maps to the associations defined in the MOF file.

The DDL File180comprises the create table, create index, create constraints, import and exports statements, and SQL grant authorizations statements.

FIG. 3is a simplified flow chart of the initial steps of the MOF translation process200. The process200starts at step210, then the translation engine reads the MOF classes to be translated from one or more input files at step212. Different sections of the class hierarchy may be defined in different files that are linked by “pragma include” statements. Within each file, classes are preferably defined starting with the highest class in the hierarchy and continuing downward. Class definitions preferably only refer to classes and qualifiers that have already been defined. In step214, the translation engine parses the MOF input file to discern the MOF schema element definitions. The parsing process214reads the input file and generates tokens representative of objects that are class definitions and class attribute definitions. A schema element may be considered as a subset of the object's total properties. Other properties, such as object methods, could also be generated in this step. Each definition includes a class or attribute declaration plus any qualifiers preceding the declaration. Parsing in step214further checks the token stream for valid parsing expressions and aggregates the expressions until they form a complete element definition. In step216, if the translation engine determines that it has read a complete element definition from the file, it exits the parsing process long enough to create representations of the corresponding JAVABEANand database definition at step222. At step218, the translation engine stops parsing when it reaches the end of the file and, at step230after exiting the parsing loop, the translation engine writes the completed JAVABEANS, database definition statements, and reference information to output files.

FIG. 4presents a simplified flow chart of the process steps300that processes a MOF schema element, such as in block222. In step302, the translation engine begins processing the MOF schema element by first checking to see if it defines a MOF class, as in step310. The parsing process of step214inFIG. 3separates the definitions of class attributes from the definition of the class itself so processing of class attributes is not included in the processing of the class definition here. In step312, to process a MOF class definition, the translation engine creates a corresponding modeling entity, e.g., a JAVAobject, that represents a multi-purpose modeling entity that will store information derived from the MOF class definition. While shown in this particular implementation as a JAVAobject, one of skill in the art will realize that other objects in other object-oriented programming languages could also be created. The modeling entity created includes components for representing the class as a JAVABEANand as one or more tables within a data model. In step314, the translation engine analyzes the MOF class definition to derive information needed to represent the modeling entity in a relational model and an object model. The information generated using the MOF class definition includes the names of the corresponding database table, the corresponding JAVABEAN, its parent class if there is any, the database schema and any table that supplies primary key values, i.e., the enumerated lists, for this entity's table. In step314, a table definition is initialized and a container for collecting information about the table, such as column names and types, is created within the entity-modeling object for the MOF class.

To comply with restrictions on the length of database table names, the translation engine uses a configurable utility to abbreviate table names as needed. An example of an abbreviation routine and rules that could be used by a translation engine is given herein. After each rule, the translation engine checks for table and column name length database limitations. By way of example only: all class prefixes may be removed; all extraneous words may be removed, e.g., “the” “and” “or”; all vowels may be removed except if a vowel begins a word or if there is a double vowel, then one of the vowels is removed, e.g., book to bok; double characters may be removed, e.g. support to suport; additional trailing abbreviation words may be removed; and extraneous special characters within the name to prevent database syntax errors are removed.

If the translation engine determines that a MOF schema element is not a class definition in step310, then in step320, the translation engine checks to see if the schema element is a class attribute definition. If so, then at step322, the translator's MOF parsing process at step214preferably returns class attribute definitions immediately after returning the definition of the owning class. Because of the nature of the standard structure of a MOF filed which identifies all the attributes of a class immediately after identifying the class itself, each class attribute encountered by the translation engine is processed as an attribute of the last class encountered.

If the translation engine determines that a MOF schema element is not a class definition in step310, nor a class attribute definition in step320, the process then checks in step330if the schema element is a class definition terminator. If so, then in step332, the translation engine finalizes the relational and object model information for the class and its attributes as described further inFIG. 9.

The schema element of the MOF file may have attributes which are determined and processed at400ofFIG. 5. At step410, the translation engine determines if the schema element has a key qualifier attribute. The key qualifier indicates that the attribute's value is part of the object name that uniquely identifies each instance of the class. If the class has a key qualifier attribute, then in step414, a unique key is created and the translation engine adds the unique key to a list of unique key columns for the corresponding table within the class's modeling entity. When DDL is generated for this MOF class, the translation engine uses this list to define a unique key constraint for the table. Then at step416, the translation engine inquires if the key has a propagated qualifier. A propagated qualifier identifies an attribute of a class that has already been defined and indicates that the current class attribute will have the same value as the attribute identified by the qualifier. If the key has a propagated qualifier at step416, then at step418, the translation engine creates a foreign key (FK) constraint on the propagation source. When a class attribute has the propagated qualifier, the translation engine adds the propagated qualifier constraint to a list of foreign key columns for the corresponding table within the class's modeling entity. When DDL is generated for this MOF class, the translation engine uses the list to define foreign key constraints for the table.

If, in step412, the schema element being processed does not have a key qualifier or, if in step416, the element does not have a propagated qualifier, the translation engine then inquires at step420, if the element has an association qualifier. Classes that contain association qualifiers associate two or more previously-defined classes and each association qualifier identifies a previously-defined class. If there is an association qualifier, then step422determines if the association qualifier is an “override” indicating that the attribute overrides the corresponding attribute of the parent class. When an attribute has an association qualifier and an override qualifier, the implication is that the parent of the current MOF class contains a duplicating attribute, so in this case, the translation engine does not add the attribute to the model entity for the current MOF class. The schema element is processed as in step460. If, however, in step422, the association qualifier does not have an override qualifier, then in step424, the association attribute is processed in accordance withFIG. 8.

If the attribute does not have an association qualifier in step420, then the translation engine inquires if the attribute has an array qualifier in step430. The presence of square brackets [ ] after an attribute's datatype indicates that the attribute contains an array of values rather than a single value. If there is an array, then in step432, the array attribute is processed.

If the attribute has neither an association qualifier in step420nor an array qualifier in step430, then the translation engine inquires if the MOF class attribute has Values or a ValueMap qualifier. If the MOF class attribute has a Values or ValueMap qualifier in addition to an array qualifier, the values in the array are enumerated, as in step442. Details of processing the Values or ValueMap qualifier are given inFIG. 7.

In step460, the translation engine has determined that MOF class attribute does not associate another class at step420, does not contain an array of values at step430, does not reference an enumerations at step440, so the translation engine adds a corresponding column to the table definition within the class's modeling entity at step450. The translation engine determines the correct datatype for the column using a configurable lookup table that maps MOF attribute types to datatypes for the database being used. At step452, in addition to defining the table columns and/or new tables needed to represent the attribute in the data model, the translation engine adds a corresponding attribute to the JAVABEANinformation stored in the current class's modeling entity.

How the translation engine processes enumeration attributes in step442is presented as the enumeration process500ofFIG. 6. An enumeration column is created in step514given that attributes510and array attributes512exist. The translation engine treats attributes that have Values or ValueMap qualifiers as references to enumerations. To represent the attribute in the data model, the translation engine adds a column for the attribute to the MOF class's corresponding table in the modeling entity and then creates a separate table to represent the enumeration that the attribute references. The translation engine can be configured to use a separate schema for tables that represent enumerations. In step520, if the attribute does not have a ValueMap qualifier, the translation engine defines a separate list enumeration table and represents the attribute as a simple list of values and creates an enumeration table in step522. The table will contain a column for the list values. In step524, for the list enumeration table created in step522, the translation engine places the values identified in the primary key column.

If in step520, the attribute has a ValueMap qualifier, then in step530, the translation engine determines if the attribute has a Values qualifier. An attribute that has a Values qualifier represents an indexed list of values, but if the attribute does not also have a ValueMap qualifier, the index of each list entry is equal to the position of the entry in the list, where the position of the first entry is zero. In step532, to represent an enumeration where the entries are indexed based on list position, the translation engine defines a separate indexed enumeration table. This table will include columns for an index and a value column. In step534, for indexed enumeration tables, the translation engine defines a primary key column to hold the index. The index value will be generated when the data load file for the enumeration tables is written at the conclusion of the translation process. Then at step536, the translation engine places the values identified by the ValueMap qualifier in the non-key column for indexed enumeration tables.

Step540ofFIG. 6represents the case where the attribute has a ValueMap qualifier in step520and has a Values qualifier in step530. An attribute that has a Values qualifier represents an indexed list of values. If the attribute also has a ValueMap qualifier, the index of each list entry is equal to the position of its value within the ValueMap, where the position of the first entry in the ValueMap is zero. To represent an enumeration where the entries are not indexed based on position, in step540, the translation engine defines a separate mapped enumeration table that includes columns for an index and a value column. In step542, for mapped enumeration tables, the translation engine places the values from the ValueMap qualifier in the key column; and in step544, the translation engine places the values from the Values qualifier in the non-key column.

After the appropriate enumeration table has been created and populated, the translator, at step550, creates a foreign key (FK) constraint on enumeration table key column. To link the separate enumeration table to the referencing attribute defined for the current MOF class's main table, the translation engine adds the primary key column for the separate enumeration table to the list of foreign key columns for the main table. When DDL is generated for this MOF class, the translation engine will use the list to write foreign key constraints for the table. Then at step560, the translation engine creates a JAVAclass having attributes for the enumeration table. In addition to defining the new table for the enumeration attributes, the translation engine also in step560adds a corresponding attribute to the JAVABEANinformation stored in the current class's modeling entity. Thus, the enumeration attributes562and the array attributes564have been processed in accordance with the embodiment described herein.

FIG. 7describes the process600by which the translation engine processes array attributes. In step610, when a class attribute contains an array of values, the translation engine represents the array within the data model using a separate table created in step610. This array table will include the primary key for the current class's main table. The translation engine stores information about the new table in a list of array tables for the current class's modeling entity. In step612, to represent each array element's index, the translation engine defines an “ID” column for the array table. The index stored in the ID column will be generated automatically when a record is added to the array table. In step614, if the MOF class attribute has a Values or ValueMap qualifier in addition to the Array qualifier, the values in the array will come from an enumeration and the process continues in step442.

If, however, the attribute does not have a Values or ValueMap qualifier in step614, each array element will contain a value of the type identified in the MOF for the class attribute. In this case, the translation engine simply adds a corresponding column to the array table in step450. The translation engine determines the correct datatype for the column using a configurable lookup table that is a compilation of industry standard and specific mappings that maps MOF attribute types to datatypes for the database being used.

At step620which follows from processing the enumeration attribute in step442, and also follows from defining a new table for the array attribute in step450, the translation engine adds a corresponding attribute to the JAVABEANinformation stored in the current class's modeling entity.

FIG. 8illustrates the process700whereby the translation engine processes an association attribute. When the current class associates other classes, the translator, in step710, reads the primary key columns for each associated class. In step720, the translation engine creates a column referencing the associated table whereby the translation engine adds the primary key columns for each associated class to the list of primary key columns in the appropriate table of the current class's modeling entity. The translation engine then creates the foreign key constraint on the enumeration table key column at step730. The translation engine also adds the primary key columns for each associated class to the list of foreign key columns for the corresponding table within the current class's modeling entity. When DDL is generated for this MOF class, the translation engine uses the list to write foreign key constraints for the table. In step740, the translation engine creates JAVAattributes that reference the associated class. In addition to defining a new table for the array attribute, the translation engine adds a corresponding attribute of the associated class to the JAVABEANinformation stored in the current class's modeling entity.

FIG. 9represents the process800by which the translation engine processes MOF schema elements that reference an enumeration. If the schema element has enumeration attributes, the definition of the separate enumeration table is stored in the class's modeling entity. Then when the translation engine finalizes the tables, it checks for enumeration attributes at step820. At step830, the translation engine finalizes the enumeration tables and defines a dummy non-key column for tables that only contain a key column. The dummy column is preferred to use the translator's output with an object-to-relational persistence service, such as CASTOR.

If at step820, the schema element does not have enumeration attributes, then the translation engine determines if the schema element has a parent class in step832. With the exception of enumeration tables, the translation engine defines each table's primary key, including adding the primary key columns to the class's modeling entity, when finalizing the table. The primary key includes at least one ID column and may also include other key columns. The translation engine determines what columns to add for the primary key depending on whether the table is for a MOF class that inherits from another MOF class. When the table the translation engine is finalizing is for a MOF class that has a parent class, it inherits its primary key columns from the table defined for the parent class. So, at step832, the translation engine determines if the schema element has a parent class. For tables that inherit their primary key columns, from a parent class, in step834, the translation engine reads the ID column and any other primary key columns from the parent table and defines a matching column for each within the child table.

For tables that do not inherit their primary key columns, the translation engine defines a generated ID column for each the child table at step836. In either case, the translation engine creates a primary key (PK) constraint at step840and adds each of the new columns to a primary key column list. The primary key constraint is used to write the DDL for the table's primary key constraint. When the translation engine processes an array attribute for a MOF class, it stores information about the attribute and the corresponding array table in the class's modeling entity. So that another step of finalizing the tables defined for a MOF class, step850, the translation engine checks for array attributes. If so then at step860the translation engine reads the information stored in the modeling entity for each and repeats the steps described above for the corresponding array table.

The benefits of this invention include: (1) a simplified single step process whereas all other known solutions are multiple step processes; (2) a single source MOF input that does not require separate object and/or data models; (3) the output is DDL that is ready for production, no modifications are required; (4) JAVA classes are generated; (5) the inheritence-based database design supports object inheritance in the MOF specification; and (6) direct control is allowed over translation between object and relational models. It will be appreciated that variations of some elements are possible to adapt the invention for specific conditions or functions. The concepts of the present invention can be further extended to a variety of other applications that are clearly within the scope of this invention. Having thus described the present invention with respect to preferred embodiments as implemented, it will be apparent to those skilled in the art that many modifications and enhancements are possible to the present invention without departing from the basic concepts as described in the preferred embodiment of the present invention. Therefore, what is intended to be protected by way of letters patent should be limited only by the scope of the following claims.

APPENDIX

Below is an Example of a Mof Specification that is Used as an Input to the process. The MOF specification describes the structure of a class and its attributes. There are other element types the describe the type of class such as whether it is a parent class or a sub-class.

Below is an example of an output DDL statement that is generated by the translation engine of the translator. This statement describes a CREATE statement for a table that corresponds to the MOF specification of the class.

Below is an example of an XML-based Object-to-Relational (O/R) mapping file that is generated by the Translation engine. This file defines mappings between Java classes and database tables.

Below is an example of a Java class that is generated by the Translation engine. This represents the MOF specification of the class. The Java class attributes correspond to the MOF specification as well. The class also contains accessor methods for these attributes.

/*** This file was auto-generated.*/package com.ibm.cim.bean;import javax.wbem.client.*;import javax.wbem.cim.*;import java.util.*;import java.lang.Exception;/*** This Class contains accessor and mutator methods for all properties defined in the CIM class* IBM_ManagedElementType as well as methods comparable to the invokeMethods defined for this* class. This Class implements the IBM_ManagedElementTypeBean Interface. The CIM class* IBM_ManagedElementType is described as follows:** This is the IBM extention and stores information about ManagedElementType.*/public class IBM_ManagedElementTypeBean extends CIMBean {private final static String[ ] keysArr = {“ManagedElementTypeCaption”};private final String versionStr = “2.7.0”;public static final String cimClassName = “IBM_ManagedElementType”;public IBM_ManagedElementTypeBean( ) {super( );init(cimClassName);} // constructor/*** This method returns the Version qualifier value of CIM class IBM_ManagedElementTypeor “−1” if the class does not have a Version qualifier.** @returnString Version qualifier value or “−1” if there isn't one*/public String getBeanVersion( ) {return versionStr;} // getBeanVersion/*** This method returns an array of Strings with the names of the key qualified properties* defined for the CIM class. This method is used to build the CIMObjectPath of the* CIMInstance managed by the Bean in the case that the key qualifiers are not included* in the CIMInstance.** @returnString[ ]array of the key qualified property names*/public String[ ] getBeanKeys( ) {return keysArr;} // getBeanKeys/*** This method returns the IBM_ManagedElementType.ManagedElementTypeAcronymproperty* value. This property is described as follows:** The ManagedElement Type Acronym.** @returnString current ManagedElementTypeAcronym property value* @exceptionException*/public String getManagedElementTypeAcronym( ) throws Exception {if (getProperty(“ManagedElementTypeAcronym”) != null) {return (String)getProperty(“ManagedElementTypeAcronym”);} else {return null;}} // getManagedElementTypeAcronym/*** This method sets the IBM_ManagedElementType.ManagedElementTypeAcronym propertyvalue.* This property is described as follows:** The ManagedElement Type Acronym.** @paramString new ManagedElementTypeAcronym property value* @exceptionException*/public void setManagedElementTypeAcronym(String managedElementTypeAcronym) throwsException {if (managedElementTypeAcronym != null) {setProperty(“ManagedElementTypeAcronym”,managedElementTypeAcronym);}} // setManagedElementTypeAcronym/*** This method returns the IBM_ManagedElementType.ManagedElementTypeCaptionproperty* value. This property is described as follows:** The ManagedElement Type Caption.** @returnString current ManagedElementTypeCaption property value* @exceptionException*/public String getManagedElementTypeCaption( ) throws Exception {if (getProperty(“ManagedElementTypeCaption”) != null) {return (String)getProperty(“ManagedElementTypeCaption”);} else {return null;}} // getManagedElementTypeCaption/*** This method sets the IBM_ManagedElementType.ManagedElementTypeCaption propertyvalue.* This property is described as follows:** The ManagedElement Type Caption.** @paramString new ManagedElementTypeCaption property value* @exceptionException*/public void setManagedElementTypeCaption(String managedElementTypeCaption) throwsException {if (managedElementTypeCaption != null) {setProperty(“ManagedElementTypeCaption”, managedElementTypeCaption);}} // setManagedElementTypeCaption/*** This method returns the IBM_ManagedElementType.ManagedElementTypeDescriptionproperty* value. This property is described as follows:** The ManagedElement Type Description.** @returnString current ManagedElementTypeDescription property value* @exceptionException*/public String getManagedElementTypeDescription( ) throws Exception {if (getProperty(“ManagedElementTypeDescription”) != null) {return (String)getProperty(“ManagedElementTypeDescription”);} else {return null;}} // getManagedElementTypeDescription/*** This method sets the IBM_ManagedElementType.ManagedElementTypeDescriptionproperty* value. This property is described as follows:** The ManagedElement Type Description.** @paramString new ManagedElementTypeDescription property value* @exceptionException*/public void setManagedElementTypeDescription(String managedElementTypeDescription)throwsException {if (managedElementTypeDescription != null) {setProperty(“ManagedElementTypeDescription”,managedElementTypeDescription);}} // setManagedElementTypeDescription} // Class IBM_ManagedElementTypeBean