Browse Prior Art Database

Java OO Methodology for applications which must support multiple vendors Disclosure Number: IPCOM000031258D
Original Publication Date: 2004-Sep-20
Included in the Prior Art Database: 2004-Sep-20
Document File: 1 page(s) / 27K

Publishing Venue



This invention is a Methodology which involves abstracting common attributes from multiple vendors/languages (database table creation, SQL), and using sound OO Design principles to harvest those commonalities and minimize differences when programming. The methodology involves using a java class to pull together the commonalities and using java subclasses to handle any different vendor dialects. Below is an example of this Methodology, applicable to different database vendors and database table creation. Typically, Database Table definitions are stored in executable database scripts. These scripts are executed and the database tables are created. If an IBM product needed to support multiple database vendors, then a separate table creation script would be required for each database vendor. This violates sound OO Design principles. For example, if a Table name needed to be changed, the change would need to be made in each script, instead of in one central location. This is extremely problematic and could lead to unforeseen errors. The change could be made in one vendor's script but not in another, typos could occur when editing multiple scripts etc....

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 100% of the total text.

Page 1 of 1

Java OO Methodology for applications which must support multiple vendors

The example would store database table definitions in one central location, as opposed to many scripts. This single constant will leverage the common table attributes of any database vendor. This proposal uses established OO Design principles. If a common table attribute such as table name needs to be changed, the change would be made in one place (the constant), as opposed to many places if traditional database scripts are used. This greatly reduces the risk of errors.

This example would use a Java Constant to store the database table definitions. The Constant would essentially be a properly formatted XML page. We would take advantage of the XML Parser API (getChildNode(), getAttribute() etc....). This is how we can translate the XML to properly formatted SQL calls. A "column" is a child of "table" etc... A Java abstract class would handle parsing the XML constant and then would properly format the SQL call. Next, Java's JDBC Api would be used to execute the SQL call. If there are specific database vendor attributes which must be addressed, those would be handled by Java subclasses supporting that database vendor.