Post on 06-Aug-2015
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
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
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 – 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
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