By Maggie Biggs
Extensible Markup Language (XML) is quickly becoming the de facto standard for exchanging corporate data via structured documents, whether internally with business partners or via public applications across the Internet. However, the data you need to exchange will likely be stored today in a relational database or some other data format rather than in an XML document. Therefore, you need to implement a process to translate data from its current format into XML and from XML back to the formats you use internally to process data.
You could use some of the tools that are available with relational databases such as Oracle9i or IBM’s DB2. These tools can translate structured and even unstructured data to and from XML. However, if you use these tools to translate data on-the-fly when an XML exchange is requested, you may actually increase the processing time of XML-based transactions as well as potentially slow other applications that might be accessing the relational database.
Alternatively, you might consider another approach—native XML databases. These databases, which are relatively new to the marketplace, do not replace your relational databases. Rather, they act as an intermediate cache between your Web applications and your back-end data sources (e.g., relational databases, data stored in file systems) to speed up application performance.
Beyond speed, native XML databases are useful because they provide a standard way to let you translate data from multiple back-end data sources into XML and vice versa. This is an improvement over implementing XML translation techniques for each data source you might have. Thus, all of your applications that need to exchange XML data can use one native XML database to cache XML documents. This will reduce the overall effort needed to manage XML translations.
Are they right for you?
To determine whether your company should implement a native XML database, consider which data sources you have that might require XML translation. If you have more than one data source that you will use for XML-based applications, a native XML database might be in order. And if you have large groups of data that require XML translation, a native XML database is an attractive option to minimize the impact of translation processing. XML databases include application programming interfaces (APIs) that you can use to integrate XML data with applications.
For example, suppose you need to exchange data with other companies using XML to support your billing and payment processes. This data might be stored in one database. At the same time, you might need to exchange XML data with other companies to support online ordering and product shipments. These applications might use an entirely different database or even data stored in your file system.
A native XML database—implemented on the middle tier, usually alongside an application server—would allow you to process XML translations for billing, payment, ordering, and product shipment on-the-fly or in batch mode without affecting either of your back-end databases, your file system performance, or the speed of your Web applications.
As with any technology, native XML databases do have a few drawbacks. For starters, the technology is rather new and not yet widely proven via successful implementations. In addition, commercial native XML databases can be costly to implement. Some are priced at $40,000 and higher per CPU. However, some less-costly native XML databases are beginning to arrive. Many of the more budget-minded native XML databases were developed in the open source community and are now available as commercial products. These lower-priced products are worth examining, as their functionality is nearly the same as their more expensive rivals (see this chart).
Native XML databases are fairly easy to install. However, you’ll need some technical resources on hand to implement the integration among the native XML database, your back-end data sources, and your applications. An experienced software developer can complete the integration work in short order, but he or she will need to be experienced with APIs and database connectivity. You might need an additional technical expert who understands database administration and tuning to get the most out of your native XML database.
However, if your company plans to use XML to any great extent over the longer term, these drawbacks are not that great when compared with the benefits you’ll gain by increasing processing speeds, standardizing on XML, and automating business processes in a standard manner.
Looking ahead to Web services
Native XML databases can give your company an edge right now when they’re used as an intermediate cache in transaction-processing environments. This is particularly true if you exchange dissimilar data with a large number of other companies. By shifting to data exchange that uses a single format (XML), you’ll reduce the amount of work needed to process data while also gaining the performance boost that comes with a native XML database.
Native XML databases will also play a key role when you implement Web services. As you begin to consider your Web services strategy and the use of technologies such as SOAP, UDDI, and ebXML, you’ll want to consider using native XML databases. XML is a key part of Web services technology and those using native XML databases will find it easier to implement Web services in the future.
Before investing in native XML database technologies, test the XML capabilities of your existing databases. It’s likely that your database will be able to translate from its relational form into XML document structures. You’ll need to measure how quickly that translation is performed.
Perhaps more important, if you use multiple back-end data sources, such as multiple relational databases from different vendors, object-oriented databases, or data stored in file systems, you’ll need to see if one of your existing databases can accept and translate data from other data sources into XML. You want to avoid having multiple databases doing XML translations, as this will only add to processing time.
Most native XML databases can be downloaded (or ordered on CD) in a trial form. You’ll definitely want to evaluate several native XML databases before deciding which approach is best for your company.
Maggie Biggs has more than 15 years of business and IT experience in the financial sector. She has implemented multiple integration projects that leverage Java and XML.
How do you see native XML databases helping your company?
We look forward to getting your input and hearing about your experiences regarding this topic. Post a comment or a question about this article.