SAN MATEO (05/08/2000) - XML deepens the data content of e-business applications, but it also makes data management more complex largely because most companies store their XML documents in database management systems that aren't optimized for XML.
This leads to either poor access performance or programming hassles for developers, who have to reconcile data structure differences in their code to let XML documents flow through standard databases. The result? Longer, more costly development cycles and the need for additional hardware resources.
A recent release from Software AG promises to rectify these matters. Tamino, the company's new database management system, can store and deliver XML documents in native format and offers a set of tools for effectively managing XML data.
I tested the Developer Edition of Tamino 1.2.1 and was impressed with its strong data management capabilities. However, Tamino's awkward user interface prevented it from scoring higher than Good in my evaluation.
Installation was spotty; Tamino was very attentive to some elements but less helpful on others. For example, the program warned me to install a missing prerequisite Service Pack 5 for Windows NT but did not set up the ODBC environment, which I had to prepare afterward.
The product documentation, thankfully, clearly described all the steps in the process.
Cranking out XML data
Tamino's most innovative feature is its data engine, the X-Machine, which can efficiently store and retrieve XML data structures without altering the hierarchical structure or sequence.
You access the X-Machine via the Tamino Manager, a browser-based interface that simplifies the process of defining XML databases by creating links to relational data structures and managing access rights. The Tamino Manager is the main access point to the data engine and is similar in functionality to IBM DB2's Control Center or Microsoft SQL Server's Enterprise Manager.
Defining an XML database with the Tamino Manager was a no-brainer. A wizard guided my steps, suggesting default values for most options.
To improve performance the Manager's wizard lets you easily adjust the value, location, and size of data, indexes, and log files. For example, you can spread data or log files across different disk devices much as you would in a traditional DBMS.
Troublesome UI
With just a few keystrokes I had created my first XML database. My only complaint was with the interface itself. Other databases offer a consolidated user interface that facilitates administrative tasks, but Tamino's GUI isn't that friendly, which is the product's major downfall.
To create a schema from an XML document and load the actual data, you must invoke another browser-based interface, called the Inter-active Interface (II), by launching it from the Windows Start menu.
Because Tamino's communication protocol is HTTP, II operations must be integrated with your Web server. This involves pointing II to your database by providing it with the URL. Unfortunately, Tamino doesn't offer any memory for existing locations. Once you've done that, you can define, load, delete, or query XML data structures similar, for example, to the way SQL Server's Query Analyzer works in relational environments.
Although Tamino can work with popular Web server offerings from Netscape Communications Corp., Microsoft Corp., and Apache, it offers no help in configuration. You have to set up your Web server manually. This turned out to be a fairly involved process; I had to rely on both the product documentation and some phone support from Software AG before I could connect II to my new database.
In addition, Tamino requires closing and restarting your Web server to acknowledge a new XML database, which can create disturbances in production environments. A better solution, in my opinion, would be to let users invoke II directly from Tamino Manager. This would solve the database addressing issue automatically, thereby simplifying administrative tasks, especially when the number of databases grows.
Once I had settled my configuration woes it was easy to define the schema and load the database. I could browse the file system from II for my sample XML schema and documents.
Once my new schema was loaded I could also use II to query the database using XQL (XML Query Language). Tamino implements standard XQL with some additions, such as generic search capabilities, to retrieve data.
What surprised me was that I didn't have to log on to the database to perform these tasks, although I did have to connect to the database to work with Tamino Manager. I was obviously logged on to Windows NT, but most data management tools keep database and OS access rights separate. Creating separate access rights for the database is one tweak that Software AG could make to strengthen Tamino a bit and allay some security fears.
Tamino also provides a set of data management tools that lets you tune the configuration of each XML document according to specific load demands. For example, you can define indexes to boost data retrieval speed directly into the XML document definition.
Obviously, providing specific indexes of XML fields will make for a big performance advantage over XML documents stored in a relational database.
Pulling sources together
Another interesting feature is Tamino's capability of describing a composite data structure by assembling information from heterogeneous data sources. In fact, you can describe many different kinds of data content in XML notation, thus creating a uniform interface for various applications.
For example, you can create an XML structure using data from existing relational tables and XML documents. You can deepen the content of your relational data-bases, including such extras as multimedia data or transaction-spe-cific information, without changing the existing databases.
Your application will include only one data structure. But behind the scenes Tamino will retrieve the information from each data source and feed it to your code.
Another component, the X-Node, lets you map XML definitions to relational tables. From the Schema Editor interface, which you invoke from Tamino Manager or the Windows Program Menu, you can interactively modify XML data definitions and, when appropriate, link each field to a corresponding column in a relational table.
This process takes a bit of effort, but once done you can access all your data under the common XML paradigm. These features improve the overall usability of your data and make it easier and less expensive to develop e-business appli-cations.
Even though Tamino offers a general catalog to describe its data, you're not limited to the catalog formats. As long as your XML documents are well-formed you can add new field definitions, thereby giving yourself greater flexibility to manage changes.
Rough edges
I reached the end of my first experience with Tamino with mixed feelings. The product clearly has tremendous potential for making XML a viable solution for e-business applications, and it's an exciting new entry into the database arena that companies should evaluate.
Still, I was slightly disappointed by some rough edges that could be smoothed in future releases. With a better, more friendly interface, Tamino would rank as an excellent product despite its steep $25,000-per-CPU price tag, which can easily be offset by shortened development cycles and improved XML data retrieval.
But until then, Software AG's Tamino can still give your diversified data a common XML look and feel, and its XML-specific database management features are currently unmatched.
Mario Apicella, a senior analyst for the InfoWorld Test Center, is a former programmer and database administrator. You can reach him at mario_apicella@infoworld.com.
Reconciling diverse data structures
When it comes to managing information exchanges across different platforms and environments, XML is an irresistible option. It is an open, accepted standard that runs on multiple platforms. It's also the only data technology that clearly spells out data structures and content, and it doesn't burden applications with proprietary database technologies. As a result, XML makes data exchange easier and less expensive than most other data formats.
Traditionally, allowing programmatic access to a database has required that a developer be proficient with the underlying technical and semantic paradigms typical of whatever information repository is being used.
For example, relational databases hide data behind a proprietary format that is accessible only if you include the proper API for that database, such as an ODBC driver in your application. Furthermore, to access data, developers must provide the correct coordinates such as database, table, and field names.
Allowing coding access to multiple databases can complicate your application, which can add costs to your project.
In comparison, XML is an open book. An XML data structure goes hand in hand with an associated DTD (Document Type Definition), which spells out both the data content and its naming conventions. Each piece of data is thoroughly labeled according to the DTD and is therefore understandable to your application. Moreover, it's generally easy to convert data structures to XML, so your applications can rely on XML to retrieve data from multiple sources.
But adopting XML sometimes means trading one set of problems for another. One of the most serious limitations of XML is that it doesn't have a data engine of its own. As a result, XML documents are often stored in existing data repositories such as relational or object databases. Most major database vendors provide extensions that let you store and retrieve XML documents from their databases.
But this solution isn't perfect, either, because you suffer performance hits when you use different data structures.
Properly defined indexes can make or break the responsiveness of a relational database, but because XML organizes data in a hierarchical model that doesn't translate easily into the relational paradigm, such fine-tuning can be difficult when you're dealing with XML.
If this all sounds like de ja vu, you're right -- we've been down this road before, most notably during the object vs. relational database wars. The market produced some hybrids, such as the object-relational database that offered the irresistible appeal of preserving companies' investments in relational technology while adding object functionality.
Now a similar trend is developing in the XML world. Will relational databases survive XML as they did objects? Probably, but innovations such as the XML-specific DBMS present interesting options in reconciling varied data structures.
Stay tuned.
THE BOTTOM LINE: GOOD
Tamino 1.2.1 Developer Edition
Business Case: Tamino offers a unified interface for storing and retrieving both XML and relational data, letting you fully leverage the power of the XML standard while shortening development cycles and simplifying application deployment.
Technology Case: Using an XML-specific data engine, Tamino can store and retrieve XML data structure in its native format. The product lets you access multiple data sources, but its general lack of attentiveness -- ODBC and Web server configurations are left entirely to the user -- leaves room for improvement.
Pros:
+ Dedicated, XML-specific data engine
+ Integrated view of multiple data sources+ Flexible schema definition -- does not require DTDs (Document Type Definitions)+ Compatible with major Web serversCons:
- Requires manual configuration
- User interface not user-friendly
Cost: $25,000 per processor
Platform(s): Windows NT
Software AG Inc., Walnut Creek, Calif.; (925) 472-4900; www.softwareag.com