XML System Design Principles

Mark Norton  11 October 2011 10:41:52 AM

This post highlights the benefits of using XML as the core of a systems design philosophy.

XML

Idiom promotes XML centric design approaches. These approaches underlay the Idiom Decision Manager and Idiom Forms.

The design impact of an XML centric approach can be significant and positive.

What do we mean by an XML centric approach?

An important characteristic of an XML document is that with an appropriately designed schema (that is, an xsd) it can carry a complete and substantial (hundreds of thousands of nodes is not uncommon) transaction context within a single document. This means one data artifact for the transaction – not tens, hundreds or thousands of tuples that might need to be designed, captured, and otherwise managed in a traditional relational database representation of the same transaction.

In an XML centric approach, this transaction XML becomes a single data artifact that can be stored in a database. Contrary to popular belief, this blending of XML and relational technologies is not necessarily detrimental to database search performance. Modern databases like SQL Server allow for database supported XML datatypes and blended XPath and SQL queries. Performance is enhanced by the huge reduction in database reads required to acquire the transaction data. Similarly, bloat that is sometimes presumed to occur with XML syntax is more than compensated for by the reduction in the number of tables, and their associated indexes, that are otherwise required to hold the transaction data.

The database

The bottom line is that for a business with complex transactional data (Idiom customer examples of this sort of transactional data include: finance, insurance, logistics, health admin, clinical health, Telco servicing and billing, government policy) an XML based approach can reduce the number of tables in the database by an order of magnitude. A rule of thumb suggests that 10 dependent entities are required to support each primary transaction entity – it is these dependent entities that are being collapsed into the XML transaction document.

It is important to recognize the no denormalization is implied here – the XML schema should be fully normalized, and the document that complies with the schema will be placed in its proper context in the database. The entire fabric of normalization is maintained.

The data that remains explicitly declared in the database includes the full set of reference data, and all other data that lives outside of and supports the core business transactions. For an extended discussion regarding the primacy of this transactional data, please see our article on Modern Analyst  or our original 2006 decisioning article published by the Business Rules Journal.

On the database tables which store the transaction XML we should retain sufficient database defined attributes to support the following:

·        Locating and identifying the transaction;

·        Managing transaction state;

·        Workflow.

We will assume that supporting activities such as accounting and reporting will be managed by subsidiary systems, and that transaction data will be transformed into appropriate views for these systems as required. This clear separation of function leads to clean system boundaries with well defined and transaction agnostic interfaces.

Transaction Components

The discussion above has outlined a design philosophy that isolates the business transaction inside an appropriate database – the transaction itself (e.g. an insurance policy, an airline reservation, a loan, a patient episode, etc) is a payload. We can now think of it as CONTENT.

The benefits of this design approach are already significant. By designing systems that treat the transactions as ‘black box’ content we simplify system design, which in turn encourages better engineered, faster and more robust systems at lower cost. These systems are more agile because we can introduce new and different types of content, potentially even repurpose the system, without changes to the underlying system.

We now need to turn our attention to managing this transaction ‘content’. By using declarative, XML aware tools we can significantly extend the benefits already outlined.

There are typically three types of functions that need to be ‘content aware’ – that is, to manage the internal state of the transaction content, and to manage the interaction of this content with the outside world.

1.        Decisioning: for managing internal state and for transforming the content to meet the needs of external system consumers.

2.        Forms: for managing interactive human involvement.

3.        Documents: for managing passive human involvement.

All non human users can be supported by XML that is generated by decision models, so that (1) above can be used to provide interfaces for multiple external system consumers.

Idiom has built a suite of tools and capabilities that support the management and operation of XML based content within XML centric systems as described above.

These tools provide a comprehensive capability to declaratively define the processes that are required to manage a transaction. For the sake of clarity, this means that we can now build a host system and plug in new transaction types by defining new decision models, and if required, forms and/or documents. By way of example, a new transaction type might be a new insurance product, a new billing regime for a hospital, a new loyalty points calculation for a new business partner, etc.

Idiom Decision Models

Idiom Decision Manager is the heart of the capability. It provides an easy to use tool for analysts or SME’s to define the various transformations that create value for the business transactions. For example, approving and rating insurance policies, approving claims, calculating health billing, calculating loyalty points, etc.

This includes decisions regarding validation, acceptance, value (cost and/or price), state, and workflow.

Decision models can also act as proxies for external consumers. For instance, generating accounting records that comply with the rules of the accounting system; or transforming data for use in generic reporting systems; or generating transaction updates for business partners that comply with partner system requirements.

The Decision Models can also be used to drive webforms and human readable document generation.

Idiom Forms

Idiom Forms is not a universal forms development tool. It is targeted at a specific design goal – that is, the integration of ‘full strength’ decision models into dynamic webforms. Note the use of the word ‘dynamic’ in the preceding sentence – if the decision model is only applied on submission of the form, then use of Idiom Forms is not mandated. Idiom Forms provides significant development advantages when binding is required between server side and browser side data images – the decision models execute against the server side images, and the webform interacts with the browser side image. Idiom Forms automatically manages the synchronization of this effort.

That being said, Idiom Forms does allow rapid forms development (faster than equivalent native forms) and it does support a wide range of events and custom controls.

The downside is that extending beyond the available events, controls, and other forms components already supplied by Idiom Forms is a programmer task.

Therefore, when integrated decisioning is not required and/or there is a significant degree of bespoke programming required in the form, then native forms development is indicated. Things that would indicate the use of native forms include sustained interaction with a database (use of one or more cursers to manage search results for instance), sustained interaction with external services, or maintaining multiple transaction contexts within one session.

Idiom has recently developed and used a hybrid forms model, which allows Idiom Forms to be managed within native coded WebPages. This hybrid approach means that native code development can be used to manage workflow, orchestration, database interaction, and other complex transaction requirements, while Idiom Forms can be plugged in to manage the decision intense transactions within the workflow.

Documents

The Idiom Decision Manager provides a range of capabilities that can be used to help produce documents for human consumption within an otherwise generic document generator.

In this context Decision Models can be used to:

·        Calculate new variables;

·        Transform calculated variables into print substitution variables - i.e. strings for printing;

·        Calculate the presence of circumstances that control the inclusion of text into the document:

·        Create the actual text to be included in response to the presence of circumstances.

When the above are applied to a pre-written document template, a transaction specific document can be produced with relative ease using a generic reporting program.

Summary

The use of XML centric design and development supported by appropriate tools leads to more agile systems at lower cost, time, and risk. Idiom is currently developing systems using these techniques and tools for multiple insurers, financial intermediaries, airlines, billing systems and Telcos.

Call us for a discussion on whether we can help you too.

Mark Norton

+64 21 434669

mark.norton@idiomsoftware.com

• Comments [0]