XSQL rules – CDM RuleFrame business rules classification application


1. Intro

In this article I will explain how easy it is to
create a web application based on XML and XSL-T/XPath techniques and
using the Oracle XSQL Servlet for server side parsing. I will
demonstrate this by explaining the on-line business rules
classification application I build some time ago.
The application is a questionnaire that helps in classifying your
business rules according the Oracle CDM RuleFrame method of business
rule classification. The application consists of two web pages: the
main page is a dynamic questionaire where the user can classify his/her
business rule(s). Depending the given answer the application searches
the appropriate next question to answer, until the business rule is
classified. The second page is more a reference page or help page that
shows a (static) list of defined business rule classes. Figure 1 shows
a screen shot of the questionnaire. The questionnaire consists if a
number of questions the user should answer with YES or NO (using the
radio buttons). Depending on the given answer, the application searches
the next question to ask, using XPath, and presents that question to
the user. This goes on until the business rule is classified. Figure 2
shows a screen shot of the list of defined business rule classes.

Figure 1: screen shot questionaire page
figure 1


Figure 2: Screen shot business rule classes
figure 2


2. Under the hood

The questionaire page consists of the following building blocks. You will find all files in this war file
(I changed the extension to zip, because .war was not allowed, but you
do not need to unzip it, just rename the file). You can deploy the war
file on your web container or application server. I deployed it on a
Tomcat 5.1, but it should work on any J2EE web container.


  • One XSQL file (cdmruleframe.xsql) for server
    side XML parsing. This file is picked up by the XSQL Servlet engine.
    The file includes both a parameter named choice and the
    classification.xml file into it’s own XML file (): see figure 3. The parameter "choice" gets it’s value via the URL.

    Figure 3: result XSQL file without transformation
    figure 3

  • One XML file (classification.xml) describing the business rule
    classes. Each rule consists of unique number, a title, a statement and
    two pointers for the answer (yes and no), pointing to the next
    question. To keep things simple, I have chosen to store these rules in
    an XML file; if you like you could store the rules inside a database
    table, and query the table into the application. Also, without a
    database you can run this as a stand-alone application.
  • One XSL-T file (cdmruleframe.xsl) that transforms the
    classification.xml file to the web page. This file holds all
    application logic and hence is the heart of the application. I will
    talk you through this file. The file’s output is html. To render page
    in the "portlet like" look-and-feel shown in figures 1 and 2, an
    external style sheet (tmp-amisLAF.xsl) is included. The rendering of
    the look-and-feel is deliberately performed via an external style
    sheet, because I wanted to decouple the application-specific
    transformation code from the general look-and-feel transformations and
    functionality. By doing so I can alter the look-and-feel of the
    application without changing the application-specific transformation
    code and, also important, I can very easily reuse the look-and-feel
    file in other applications that I want to render with the portlet
    look-and-feel without any changes or copying of code. Just copy the
    tpl-amisLAF.xsl to the new application, and it’s done.
    Next a parameter named rule is defined. The purpose of this parameter
    is to extract the value of the URL parameter choice, if it exsists! The
    first call to the application is always performed without a choice
    parameter: the node does not exsist. If the node does not exsist $rule
    is given the value 1 so the questionaire starts with question 1.
    The style sheet uses two named templates to render either a
    questionnaire with radio buttons (template questionnaire) or the final
    rule class (template showResult). The questionnaire template renders a
    html-form that posts the answer back to the same XSQL-page using
    parameter choice.
    Next, the neccessary matched templates are coded. The match on the root
    node adds the required html-head tags with help from the external style
    sheet. To fill the html-body the template for authorisationrules is
    applied. The match on authorisationrules node renders only the rule
    number defined in parameter $rule, not all the other rule nodes. The
    match on the rule makes a choice between rendering the questionaire and
    rendering the final business rule class, by using the follwoing XPath:
    in file classification.xml only rule nodes do have a child node
    statement and business rule classes do not, when the XPath results to
    the boolean value true(), the questionaire is rendered.
    Finally, the match on the yes and no nodes renders radio buttons and
    the corresponding choice URL parameter.

3. Listing of business rule classes

The other web page is a static list of all the defined business rule
classes. The page is rendered by simply including the
classification.xml into the XSQL-page (listclasses.xsql) and
transforming the authorisation rules to the html-table
(listclasses.xsl). The result is shown in figure 2. The web page is
called via the hyperlink "show defined rules" on the main page.


4. Deploying the war file

The war file includes all required
sources to run the application. You can download the file to your
favorite web container without making any changes to the file. Two jar
files are included in the WEB-INF/lib directory. oraclexsql.jar for
runnning the XSQL Servlet engine and xmlparserv2.jar for XML parsing.
File web.xml is adapted so files with mime-type *.xsql are mapped to
the XSQL Servlet. File XSQLConfig.xml, located in WEB-INF/classes, is
the configuration file for the XSQL Servlet. In respect to the default
config file, I’ve removed/invalidated the database connections.
If you do not want users to see your XML nodes or more important if you
want to disable users hacking your XSQL-pages by overriding your style
sheets, change the following node in XSQLConfig.xml:
noFigure 3 shows how you
override the transformation by extending the URL with parameter
xml-stylesheet=none or xml-stylesheet=myhack.xsl.


  1. Harm Verschuren November 26, 2005
  2. Svein Hansen November 23, 2005
  3. Jan Kettenis May 19, 2005
  4. Gert-Jan Paulissen May 18, 2005