DEC 12, 2008 11:09am ET

Related Links

IBM to Buy Green Hat
January 4, 2012
Is BOA the New SOA?
December 8, 2011
How Should Government Build IT for the Future?
October 27, 2011

Web Seminars

Data Discovery for Big Insights
May 17, 2012
The Big Deal About Big Data Governance
May 22, 2012
Treating Big Data Performance Woes with the Data Replication Cure
May 23, 2012

Improve Your XML Applications

Print
Reprints
Email

XML is everywhere. It is unrivalled both as a data exchange format for industry standards and a data interchange format for application developers. It’s taken just 10 years for XML to reach ubiquity.

 

XML could even be considered the new language of business data. Most industries are developing standards for data interchange in XML. And some XML standards, like XBRL, are transcending across all industries. XML has experienced rapid rates of adoption because it solves some big issues with exchanging information, including:

 

  • It is platform independent, which means that any two computer systems, regardless of the hardware or software that the system uses, can utilize XML to exchange information.
  • It is self-documenting, allowing people to understand the structure of the data simply by reading the XML.
  • The hierarchical nature of the XML data format can be easily used to represent common data structures like records, trees, lists and more.

During the past decade, many organizations developed software applications that store or retrieve XML data. For the most part, these applications used existing infrastructure, including the file system and relational databases, to store the XML. They used workarounds that incurred significant processing overhead and required expensive transformations. This had a significant impact on the complexity and performance of the applications.

 

Initially, a new breed of XML-only databases emerged to address the needs of these applications. However, XML data is isolated in these databases - it lives in a different repository than other data. In this era of business optimization, organizations are increasingly looking to optimize the use of information assets. Placing XML data in an isolated XML-only database hinders business optimization efforts. The major relational database vendors addressed this issue by building native XML support into the database environments. By doing so, they have shortened development time, lowered maintenance costs and improved application performance when storing and retrieving XML data.

 

As more business information is cast in XML, the ability to efficiently and effectively handle XML data in a transactional environment is essential.

Transactional environments put a premium on programming ease, high performance, high availability and cost effectiveness. Providing these characteristics to XML-oriented applications requires unique innovation.

But that hasn’t always been the case.

 

The Old XML Ways

 

Clumsy and complicated are two words often used to describe the way developers first handled XML data. Many companies were already using relational databases when XML came along. A relational database stores data in a tabular format with columns for each piece of information and then rows for each record. With the development of XML, professionals wanted to figure out how to store this information in a database. The question became, “How can we get XML data into a tabular format for efficiency?” But the problem is that XML data is inherently hierarchical. In other words, it is more apt for representation using a tree structure rather than a tabular one.

 

Programmers responded by creating two workarounds. One method called shredding takes XML and tries to map it into a tabular format. A second approach called stuffing puts all the XML data into a single large object (LOB) cell in the table. Both approaches work, but there are significant drawbacks, especially as the amount of XML data has grown.

           

With LOB storage, a database cannot natively work with the information in the cell. A developer has to retrieve the large object and create code to process it. As a result, there is a performance impact every time you need to work with the information in the database.

 

Filed under:
SOA

Advertisement

Twitter
Facebook
LinkedIn
Login  |  My Account  |  White Papers  |  Web Seminars  |  Events |  Newsletters |  eBooks
FOLLOW US
Please note you must now log in with your email address and password.