Jump to ID:
  Project: xmlprocess  [Show Path]

Project Home

Tracker

Documents

Source Code

Discussions

Reports

File Releases

Wiki

Project Info
xmlprocess

XML tools from CFH
Project Created: 02/27/2008
Project Categorization
forge
Project Members
Total Project Members: 12
Project Administrators:
adam.flinton
Site Administrator
XMLProcess Architecture
XMLProcess Architecture

Table of Contents:

Overview


XML ( eXtensible Markup Language ) is a standard method for marking up text so as to carry structured information.

It can be seen as the Whitworth screw thread of IT.  

The Whitworth screw thread in many ways enabled the industrial revolution as "His promotion of standard measures and interchangeability brought about an engineering revolution."

In essence XML allows any Information System/Computing language which can handle text files to talk to any other while carrying just about any information.

XML can be used to :
  • Carry structured data from machine to machine for example any of the many XML based messaging systems being used in just about every industry.
  • Carry rich text for reading by humans (for example this Document is written in (X)HTML which is the XML version of HTML).
  • Carry information for rendering into pictures/graphics for example Scalable Vector Graphics (SVG)
  • Carry model information for example via the OMG XMI or the HL7 MIF formats.

XML Process seeks to ensure that:
  • Every file is an XML file. No more Word Documents, Excel xls files etc.
  • Information from one file at one stage in a the process can/will/should be used to drive or check subsequent stages in the process.
  • No information is lost or trapped at any one stage or requires rekeying.

Design Goals

  1. Easy to create applications :
    • It is easy for people to create editors and viewers for any XML document.
    • Only requires editing XML Files in order to create an application.
    • Uses standard XML technologies such as XPath, XSLT and XForms.
    • Does not require any Java knowledge except in certain very specific cases.
    • Gives the designer the largest set of choices in terms of how the user interacts with the XML.
  2. Easy to use :
    • Standardized ways of displaying/accesing XML in lists or trees
    • Makes it easy for the user to choose just the small part he is interested in quickly and efficiently
    • Uses standard XML technologies such as XPath, XSLT and XForms
    • Does not require any Java knowledge except in certain very specific cases
  3. Easy to integrate :
    • Can be hooked into anything which can deliver and persist an XML file (e.g. Message Queue System, Database etc)
    • Uses standard web technologies (http, web browser)
    • Can be used locally for one user or to provide forms to the entire enterprise
    • All the application and configuration files can be loaded from a local folder or an http url (e.g. from a subversion server)
    • Can interact with any string/XML capable system, e.g. Servlets, ASP.net, JMS, Webservices, BPML engine etc.
  4. Easy to install / administer :
    • Only requires that the user have a javascript capable browser (preferably Firefox)
    • A single self contained War file which can be deployed into an Java web application server
    • If the application/configuration files are loaded from a central URL, many instances can be deployed
      and thus controlled from a single point.
    • XForms rendered as HTML so no need for an XForms plugin
  5. Flexible :
    • Can handle any XML document
    • Can be deployed locally or remotely
    • Can hook into any file source or sink
    • Can use a range of technologies to display and edit the XML document

Technologies used

Configuration Files

There are 2 XML Configuration files :
  1. The Server/Layout File
  2. The Application specific file

WebApp Architecture


The basic Web application flow of control is:

  1. index.jsp called with a type set e.g. http://localhost:8080/xmlprocess/index.jsp?type=Mif
  2. This then forwards to login.jsp if you are using a remote server and have not logged in yet, which then upon sucessful login sends you back to index.jsp
  3. If you are logged in etc. then index.jsp forwards to filecheck.jsp which checks that the file is OK, is of the right type etc.
  4. If so then it forwards to XFormMain.jsp

XFormMain.jsp is the main page and acts as composer/layout engine where the JSF pages are loaded as panels.

The 2 main web app libraries used are:

Apache Myfaces JSF implementation - This is setup by a combination of entries in the web.xml and the faces-config.xml

Chiba XForms rendering engine - This is set up via the standard web.xml

Java Architecture



The main class is: org.xmlprocess.DomElementBean

The basic way in which the application works is:

  1. The XML File is loaded and is checked against it's backing file.
  2. Those parts which are identified as text elements are CDATA'ed.
  3. The remaining "live" elements are then assigned a secret GUID in an Attribute so that that exact element can always be located quickly and easily.
  4. Web Pages then load with the root element as the first element chosen and this element (as a DOM Element) becomes held in the DomElementBean
  5. When the user click on a list or tree or other navigational device or link to chose a different node/element, the GUID for that element as detailed in (3) is posted
  6. This GUID is then used to locate the relevant node which is loaded into the DOMElementBean & is then then compared to any definitions in the backing file for that sort of element and the relevant forms are loaded.
  7. Changes are made etc & then when a docuument is saved to disk the XML persisted has all these "secret" GUID's stripped off. 


If you wanted to add specfic things to an application at a java level then the DomElementBean is designed to be extended though you may then have to editi the faces-config.xml to either set up your new implementation or to change the default one to your special extension.

Everything that can be cached is cached for perfomance reasons e.g. compiled XSLT sheets, loaded documents the backing objects etc. etc.

A brief guide to the Class Heirarchy:

I will briefly detail the packages and pull out the main classes of interest.

The assumption is that for the sake of brevity everything has a root of xmlprocess e.g. a package of cache is actually org.xmlprocess.cache.

Package Name: Classname Description
cache ObjectCache The cache for all compiled objects including DOM representations of XML Document
common CommonProps The Common Static strings
config A collection of classes controlling the configuration of the system including the settigns contained within the Config xml file and the backing files
domComparators The classes used to sort a DOM is that is required. The example of an OIDComparator is there.
dto A collection of DTO'es used to hold values in the system.
io A collection of classes dealing with IO i.e. loading and persisting files
jsf DisplayController Used by XFormMainHelper to control the Display i.e. what gets shown, what JSF pages are loaded etc.
DomElementBean The central class
XFormCreator The class which combines XForms with DOM Content to return a complete XForm as a Dom Document
jsf.tree A collection of classes which give the JSF tree navigator.
pagehelpers A collection of classes which provide most of the functionality for their relevant page (e.g. FileCheckHelper provides the functionality for FileCheck.jsp)
servlet A Collection of Servlets and ServletUtilities
ServletUtil A class of utility methods for Servlets
XFormEndPoint The Servlet which handles all the XForm postings and applies them to the XML Document being edited.
XFormHTMLProcessor A Servlet which extends ChibaServlet and performs the translation from an XForm into an HTML rendering.
XSLTEndPoint The servlet which handles all the XSLT generated postings (form instance from the MIF tabular view editor and applies them to the XML Document being edited.
uuid A collection of Apache sourced classes which generate the UUID/GUID used by the application
xml XMLHandler The main XML Handling Class
xml.util BasicXMLParser A simple Non DOM/Sax based stirng parser for quick parsing
ProcessXSLT A class which handles all the XSLT jobs.
XMLUtil A utility class containing many XML utility methods


Deployment Considerations


Any read only file can be loaded via a URL.

As such a central repository of such files can be held on a single server and then loaded by different instances of XMLProcess via http.
This can extend to holding files in a subversion reposiory should such a repository be set up to serve files via http.

If the File handler for documents being edited is written to allow for remote load/save operations (for instance FTP, JMS, SQL database,  webservice, repository (Subversion, cvs etc) then that too can be held on one server but edited/viewed by many instance of xmlprocess.

NB: The remote file implementation would then have to handle the file concurrency/locking as xmlprocess only cares if the fileIO tell it that the file is editable/not editable.