Technology Preview: x-Persistence Utility

© ObjectCentric Solutions, Inc., 2000-2001

 

Technology Preview: x-Persistence Utility. 1

Narrative. 1

Why not 100% automation?. 1

Technicalities. 2

Applications. 2

 

Narrative

The software addresses the problem of effective automatic conversion of XML data onto relational database objects. Database vendors such as IBM, Microsoft and Oracle have developed tools to assist in XML documents conversion onto flat tables.

Oracle XML SQL Utility models XML document elements as a collection of “nested” tables. Enclosed elements are modeled by employing Oracle Object data-type. “SQL-XML” conversion constructs XML document by using one-to-one association between table, referenced by Object data-type, and nested element. Reversed conversion, “XML-SQL”, might require either to amend data model (convert it from relational into object-relational), or restructure original XML document. In either case Utility does not store XML attributes.

 IBM DB2 XML Extender allows storing XML documents either as BLOB-like objects, or as being decomposed into set of tables. The latter transformation, known as XML collection, is defined by utilizing XSLT/XPath notations.

In heterogeneous corporate database environment having a unified tool to perform the same task for different databases has obvious advantages. Some authors advocate XSLT technology as universal methodology for XML documents processing. Without any doubt, XSLT covers the broad category of text processing applications. We also have to acknowledge that under database-driven processing usually the next step of data transformation depends on the data previously extracted from database. For example, inserting records with reference data, such as foreign keys would require submitting an additional database query.  It can be predicted that XSLT as the data transformation language might co-exist with XML SQL query language in some XML- centric application.

In contrast we would like to promote more traditional approach: saving XML documents as normalized tree structures and provide tools similar to DOM APIs to navigate data by employing traditional SQL processing.

 

Why not 100% automation?

 

Theoretically document mapping onto database objects can be performed in two stages: (1) convert original document into DOM with subsequent saving in the database; (2) applying the additional transformation XML document for disassembling converted original document onto database tables. Note that the order of database insert/update operations can not be arbitrary. Variation of this approach is to embed information of "XML-SQL" mapping within element attributes. However, document producer and consumer often belong to different corporations, and therefore this variation has really limited usage. At any rate, database tables population is normally controlled by application logic distributed between "pure" application code, transaction processing, database layer, and stored procedures, not mentioning that some tables can reside in remote databases. If the full automation in many cases does not provide real benefits, what can be proposed? Solution: saving XML documents as normalized tree structures - raw tree data - for further application processing. Another advantage would be archiving various XML documents in a repository in a unified format.

Object-oriented and object persistence technologies could be choices in future for solving the problem discussed here.

 

 

Technicalities

 

(1)   Platforms:  Sybase, MS SQL Server.

(2)   Future platform coverage: Oracle, DB2, and PostgreSQL.

(3)   Utility is built on top of Xerces XML Parser.

(4)   Database installation: just a few tables, and stored procedures to navigate via database tables as tree structures.

(5)   Tables can be substantially re-used for OLAP processing and reporting.

 

Applications

 

Utility is used as a core of XML-based data acquisition agents in Open Finance Laboratory, customizable integration platform for a range of financial applications such as portfolio management, asset-liability management, risk management, liquidity/cash management, etc. Open Finance Laboratory adopted FpML as a description of Interest Rate Derivatives products. Utility is currently used as FpML/FRA data acquisition agent.