XML Data Binding Toolkit for Java

XML Data Binding with LDX– Sophisticated binding for complex Schemata

– Unlimited size of instance documents

http://www.dijkstra-ict.nl

Lolke B. Dijkstra, Dijkstra ICT Consulting, 2009, 2010, 2011

http://www.dijkstra-ict.nl

Challenges

Implementation Timelines

Budgetary Constraints

Staying in sink with new versions of the Standards

Meeting Quality Requirements

Managing Complexity

But..

Writing XML may be easy, Reading is an other ballgame..

Technology makes parsers complex to implement High volume data/Very large XML documents (out of

memory)! Complex Data formats

Example: The SEPA challenge..

Need to be able to process (large amounts of) data accurately and reliably

This thing is huge…

New versions of standard will keep us busy…

Limited time-to-market

We want to..

Increase Quality of our software Dependability Maintainability

Be lean and agile: be able to adapt easily to specific needs

Be in time, on budget

Focus on Business Needs, not technology

LDX Toolkit + Framework

Helps your team focus on business needs instead of technicalities

Generates code directly from the XML Schema files

Provides easy to use pluggable architecture

Separates Processing from Reading Fully encapsulates the Reading of XML data, without

sacrificing flexibility Your team implements the processing specific part of the

Parser and connects it to the Reader Component

LDX Generated Code:

Cost Effective, you maintain the model, not the code

Dependable, flexible, highly efficient

Generated code is fully documented

Highly Flexible: your application is runtime configurable

Generates 100% Java (1.5 or later), no high-cost third-party dependencies

High-level architecture

The Reader Component is generated by the toolkit

Your team concentrates on the business logic and processing of the data in the Application Processor Component

Framework and Generated code

Main java module SEPA sample..

Logging

Exceptions due to validation errors are simply handled (for instance for logging purposes) by catching the org.xml.sax.SAXException error, so you can log them

Errors during processing can be handled by implementing the org.xml.sax.ErrorHandler interface, from here you can do your logging

Exceptions due to processing errors are handled by catching the ProcessorException error in the main, and again you can hookup logging here

Processing Data: Java Interface

Configuring Runtime Behaviour

Ease of configuration, changing processing and memory usage per XML element at runtime without programming a single line (by editing an XML configuration file)

Use a configuration file per application to: Enable/Disable processing for XML elements (defaults to

disable) Detaching XML elements from their parent element, making

them short-lived (defaults to attaching items to parent)

Configuration – XML fragment

Example XML for SEPA/Pain.001.001.03 messages:

Configuration – Specifying options

Configuration – Java code

Your application’s Reader Component will automatically configure itself with the specified options.

In the example it means we’d like send GrpHdr, PmtInfo and CdtTrfTxInf to the processor.

And since there are potentially unlimited number of PmtInf and CdtTrfTxInf, we detach them, so we don’t keep them in memory once we’re done with them.

In your main just write:

Quality, Compliancy, Flexibility..

“The standard is huge, how do you guarantee consistency of your code and how do you maintain your code?”

“We do follow the standard, but there are exceptions..”

“Don't want to learn a new proprietary API..”

Model Driven Engineering!

The model (e.g. ISO 20022) drives our mapping and code..

Code and XML Schema are direcly related, you don’t have to learn a new API

MDE is especially beneficial for large models

Finally, code and model are consistent and in sync…

Use different schemata for certain channels? Generate code for each of them

MDE: Mapping Model to Code(Example: SEPA)

ISO 20022

Generated Code

Quality, Compliancy, Flexibility..

We wrote a common (small) framework in Java, which is extended by the generated code

The generated code is clean and not redundant, is heavily reuses the common framework

We maintain the code generator, and the framework not the generated Java code

Java reference documentation is generated and in sync with the code

We use automated unit tests

Quality, Compliancy, Flexibility..

What about validation? “Want to reject XML message when validation fails” “Just want to reject individual transaction when not valid but process the

valid ones”

First case: Pre-validation; the XML message is either valid or invalid Then process validated XML document

Second case: Document is well-formed, but some information may be missing You can optionally pre-validate with a relaxed XML Schema, specifying

your minimum requirements During processing decide what to do per transaction

Summary

Model and code are perfectly in sync. Guaranteed!

Your team focuses on the functionality of processing of data instead of dealing with the intricacies of the standard

Easy to use and highly flexible

Common foundation for all XML parsers, increasing maintainability, dependability and cost effectiveness

Increased productivity due to reuse of common reader components

More Information

Dijkstra ICT ConsultingLolke B. Dijkstra

It’s a Framework and a Toolkit

For more information navigate to: http://www.dijkstra-ict.nl

Lolke B. Dijkstra, Dijkstra ICT Consulting, 2009, 2010, 2011

http://www.dijkstra-ict.nl

Tel. +31 55 355 1607