Vienna Knowledge Net Framework

Software Framework written in Java based on a XML Metadata Repository. Designed to support easy development of scaleable, highly customized database-centric web applications of arbitrary complexity.

• Targets
• XML-Repository
• Business Objects
• Database Independence
• Search Engine
• Utilities
  • SQLDialect
  • SelectStmt
  • DbTable
• Flaws / To do's
• Credits
  • Programming
  • Technologies
  • Supported Databases

Targets 

Custom database application often have many things in common. You'll always want to load, modify and store some sort of Business Objects or search for them by entering some of their properties, list them, look at their details etc. In more complex systems like they frequently appear in daily business or scientific applications you'll often have a network (graph) of connected objects, where the connections (paths) between the objects (nodes) are as important as the objects and their properties themself. For example, in a project database you might want to get a list of people who worked on a specific project together with the roles they played in that project.

So our target was to create a software framework which automates as many of this tasks as possible while reducing the developer's work to entering just the data that is specific for a given application. That led us to the approach of using a Metadata Repository, which holds all the schema information about the Business Objects, their connections, the possible search criteria etc. Based on that information many tasks can be abstracted, e. g. generating database tables, loading, modifying, storing of and searching for business objects.

XML-Repository 

• package: Defines a name space.
• class: A Business Object comprised of a set of fields and some references, which define relations to other classes, e.g. foreign key fields. There are several stereotypes of classes, like base, extension, rel, lookup etc. which affect saving and loading strategies. The stereotypes base and extension provide automated handling of property inheritance. Every class is identified by a unique name comprised of the package name and the class name, or by a short type, which is just another unique name of up to 5 characters.
• field: has an abstract data type, a length, some flags like it is a key field or should it be indexed, a caption, a corresponding lookup definition which provides the possible values, a default value and so on.
  Some field templates like &lock_field and &changeTrackingFields; are available.
• enum: A definition to look up the possible values for a field. Can be either static, like an enum in C, or dynamic, which means there is a SQL definition to retrieve a DB result set containing the values.
• selection: DB search definition, comprised of selection fields, result fields and order fields. Selection fields define the fields that can be searched in, result fields define the possible set of fields in the result set and order fields define the fields and direction the result set is sorted.
One class is declared as the return type of the selection. All fields of other classes must be associated with a DB path, which defines the relation between the field's class and the return type.
• boview: Defines a view for one specific class, e.g. the SQL statements used to list the object's properties and related objects.

Given that metadata, recurring tasks can be abstracted and separated from the application specific code.

Business Objects 

Business Objects (BOs) are the central concept for storing and retrieving data and provide routines to load fields from inherited classes and save incomplete data, which means just the required fields have to be specified. One BO can correspond to several DB tables. Every BO is identified by and Object ID (OID) which is a String containing the class' Short Type and the values of the key field(s), for example wrk:12345.

Here's a JSP snippet which adds a dot to a work's title:

// standard code for every user request
Environment env = (Environment)application.getAttribute("env");
String username = (String)session.getAttribute("username");
Locale loc = (Locale)application.getAttribute("locale");
Request req = new Request(env, username, loc);

// load 
String oid = "wrk" + Oid.OID_DELIM + request.getParameter("id");
BO wrk = env.getRepository().createBo(oid, req);
wrk.load();
wrk.set("wrk_title", wrk.get("wrk_title") + ".");
wrk.store();

req.close();

Database Independence 

All functionality of the framework is working on top of an extensible software layer that abstracts the differences in behaviour and syntax of various RDBMS vendors. A small sentence for a major feature!

Search Engine 

Based on the metadata defined in the XML-Repository and implemented with a JSP/HTML GUI the framework's search engine allows some brief search words to be translated into complex SQL statements with joins, nested SELECTs and so on.

Search words can be combined with logical operators (AND, OR, NOT), with comparison operators (=, <, > etc.), they may eventually contain a wildcard character (*) and be grouped by parentheses.

Utilities 

SQLDialect 

SelectStmt 

DbTable 

Set of Java classes to "page" a result set. Customizable output, variable page length by specifying the number of rows per page, scroll back and forth, to first and last page while being safe of changing result sets.

Flaws / To do's 

The framework was designed and developed as a necessarity which arose from the requirements from various database-centric projects we worked on. Because of that, time to spend on additional work like abstraction, research and implementation of the framework on cost of the current project itself was always verrrry short. That's why the software is almost undocumented despite some strategic papers, some micro-how-to's buried in our mailbox archives and the comments in the source code.

Second, while reducing the developer's work to mainly creating the XML Metadata, some of the definitions still are quite verbose and you'll have to have thorough understanding of relational databases, the XML language, the framework and so on. Some kind of GUI to enter the metadata would eliminate most of the quirks and push the framework to a higher level of usability as much less knowledge of the underlying technologies would be necessary to create an application.

Credits 

Programming 

Technologies 

Resin Servlet Engine
CUP Parser Generator
JLex Lexical Analyzer Generator
Oracle XML Parser

Supported Databases 

Microsoft SQL Server
Oracle
Postgres Open Source DB
More can be easily added.