A year ago developers were just learning that XML stands for eXtensible Markup Language. Six months ago CIOs started taking an interest in XML and smart developers started buying "Introduction to XML" books. Now "XML for Managers" books are becoming popular and it seems like everyone is trying to figure out what they can do with XML and what infrastructure they'll need to support it.
There are many reasons to use XML as an enabling data format and many potential applications have been suggested, from improved Internet searching to defining configuration files. However, the two uses of XML that appeal most to both CIOs and developers are the exchange of business data between applications and customized presentation of data.
- Exchanging business data between applications: Application developers need to tie enterprise systems from different vendors together within an organization to enable, for example, order-processing applications to pass information to inventory management and for both systems to access the customer database. Using XML, a loose integration is possible at a fraction of the effort of traditional EDI. With XML, businesses don't need to replace or rebuild their applications; rather they will simply begin to XML-enable the data and systems they already have.
- Customized presentation of data: Different browsers and devices, such as PDAs (personal digital assistants), cell phones or pagers, have unique display formats. Using an XSL processor, on either the client or server, XML data can be transformed into the appropriate format for display on any client, completely insulating the business application from the constraints of the output device. This separation of form from content is key to building any flexible and extensible information system.
How Do Databases Fit In?
For a short while in the rapid evolution of XML there was a notion that specialized XML servers and object databases would be the natural storage point for XML documents and data. But then a question arose: "So where does all this XML data come from?" The answer, of course, is: "From the relational databases that underpin the majority of business applications in use today." For most XML applications, the creation and ongoing maintenance of a separate "XML repository" is an unnecessary development expense. Instead, all most companies need to do is take information from existing databases and render it as XML so it may be shared and consumed more easily. Of course, if the relational database in question has object capabilities, such as Oracle8i, then the task of rendering and updating data as XML is greatly simplified.
If the key requirement is to be able to efficiently read and write XML to and from the database, developers should look hard at Oracle8i. Designed from the ground up to be the database for the Internet, it includes native support for Internet standards such as Java and XML. In fact, at the heart of the Oracle8i database is a highly scalable Java engine tuned for server-side Java application development, giving Java the ability to scale to thousands of heavy-duty concurrent connections. In addition, Oracle's XML capabilities are so much a part of the database that Oracle8i can run its XML components for Java completely within the database to deliver the scalability required by today's Internet applications.
Let's look at the tools and techniques used to read and write XML in Oracle8i.
Reading XML from the Database
The ability to model or materialize a database object, such as an insurance claim form, in XML requires infrastructure components that can use SQL to request the object and transform it into an XML-formatted document or datagram. In the example in Figure 1, a claim form is defined as an object in the database using the relational tables shown.
This object can be materialized in XML as follows:
<STREET>123 Cherry Lane</STREET>
The driver lost control of the vehicle.
This was due to <CAUSE>faulty brakes</CAUSE>.
This XML document preserves the data relationships set up by the database schema for the insurance claim object. The following illustration was built using the Oracle XML Utilities and shows how a simple Java servlet (the XSQL Servlet, available for download on the Oracle Technology Network) can create this output.
The XSQL Java servlet can be loaded into a database that supports Java, such as Oracle8i shown in Figure 2 or a middle-tier server such as Oracle Application Server or other Web servers that support servlets. Let's take a look at the XSQL Servlet structure in detail.
Oracle XSQL Servlet for Java
The XSQL Servlet is a Java program that leverages the capabilities of Oracle8i to assist in producing dynamic XML documents from one or more SQL queries of data objects. It does this by processing a .xsql file, which is simply an XML file with a specific structure. The following is an example of a .xsql file that searches for insurance claims submitted by Mr. Doe. Note that the query may be written as regular SQL or, as in this case, using object dot notation.
<?xml-stylesheet type="text/xsl" href="claim.xsl"?>
select value(c) as Claim from insurance_claim_view c
where c.claimpolicy.primaryinsured.lastname = 'Doe'
The servlet uses Oracle's XML Parser to process this file and pass any XSL processing statements to its internal XSLT Processor (which performs transformations according to an XML stylesheet) while passing the parameters and SQL statements between the <query> tags to the XML SQL Utilities. Results from those queries are then received as either XML-formatted text or a JDBC ResultSet object. If necessary, the query results may be further transformed into any desired format using the built-in XSLT processor.
The XML Parser is used by the XSQL Servlet to parse the .xsql files as well as to receive and render as necessary the output from the XML SQL Utilities. As with the servlet, the Parser can be loaded into the Java VM (virtual machine) in Oracle8i, run from a middle-tier server such as Oracle Application Server, or run on the client as a JavaBean. Through its DOM and SAX support, it can accept the ResultSet from the XML SQL classes and provide an XML object tree or text stream to the servlet for output.
The XML Parser's XSLT support isn't limited to transforming one XML document into another. These XML documents can also be used as data messages between heterogeneous databases, with XSLT providing the translation from one message format to the other. While this capability is useful for electronic data interchange, it can also be used to render documents in HTML and other text-based formats. Creating a stylesheet that is simply an HTML page with the appropriate XSL processor statements at the locations where the XML data is to be displayed can dynamically create very effective HTML pages.
For example, using the insurance claim XML document, we can create an HTML page to render selected data elements, initially using dummy data as page-formatting placeholders. Once the HTML is satisfactorily formatted, the static data may be replaced with XSL processor statements, as below:
Writing XML into the Database
Its self-describing object capability makes XML a compelling technology for e-business and other data interchange applications. Using application generation utilities such as Oracle's XML Class Generator for Java, Web-based applications can create XML documents or datagrams to be stored in databases.
There are two ways to store XML-tagged data as a single object in a CLOB or BLOB with its tags intact or distributed across a set of tables. Distributing across tables maps XML data into the relational schema. Oracle8i can accept an XML document as a single object and, through its interMedia text option, can actually search for and return data based on its XML tags. Using our insurance example, the following SQL statement searches for all settlements approved by JCOX and uses the CONTAINS SQL function to find those where "faulty brakes" were the cause.
FROM Claim_Header ch, Claim_Settlements cs,
WHERE csp.Approver = 'JCOX'
AND CONTAINS(DamageReport,'faulty brakes WITHIN cause')>0;
While this is quite useful for unstructured data such as the accident description on our claim form, structured data is better served by storing it in tables without tags where it can be easily updated and queried. Oracle's XML Parser with its XSLT transformation component can parse an XML document submitted to the database and, based on an XSL stylesheet, create the appropriate SQL INSERT and UPDATE statements to store the XML-tagged data in the database.
Referring back to our insurance claim document, the following stylesheet fragment could create the Payment table entry after XSLT processing:
insert into PAYMENT values
Alternatively, the OracleXMLSave class within the XML SQL Utilities is able to put back the XML document into any database table or view. It maps the tag names to the column names and handles structured types, collections and references appropriately.
Essential XML Building Blocks
Applications such as the XSQL Servlet described above make use of lower-level XML components including the Oracle XML Parser, Class Generator and Utilities. The Java versions of these components can be loaded into the Oracle8i server, run from a Java VM on a middle tier such as Oracle Application Server or on the client. They are available along with working code samples through the Oracle Technology Network to all registered members. Registration is free (
- Oracle XML Parser: Available in Java, C, C++ and PL/SQL. These parsers are available on Windows, Linux, all flavors of UNIX, and all the other platforms on which Oracle runs. The XML Parser for Java is fully compliant with the DOM Level 1 specification supporting validating and nonvalidating modes with an integrated SAX interface and support for Namespaces. Performance has been optimized through various strategies, such as caching DTDs and incorporating internally the XSLT processor for transforming XML documents based on CSS and XSL stylesheets.
- Oracle XML SQL Utilities for Java: These utilities take a SQL or SQLJ query and return the results in XML as text or DOM trees. SQL queries from the XQSL Servlet, Java stored procedures or even the command line can be sent to the database and will generate the results formatted as XML based on the internal structure of the schema.
- Oracle XML Class Generator for Java: The XML Class Generator for Java is a utility that creates Java classes from DTDs to enable the programmatic construction of XML documents. The Class Generator works in conjunction with the Oracle XML Parser, and boasts complete character set support and optional validation mode for ease of debugging. Documents created by these classes are fully compliant with the XML 1.0 W3C standard.
There's a lot of confusion and hype in the market. With all the current interest in XML, many vendors claim to be developing the "next XML standard" for any number of different applications or business types. Whether focused on the XML language itself or its DTD data standards, these efforts do little to promote clarity and only spread F.U.D. fear, uncertainty and doubt among decision makers. Regardless of the shakeout from the definition game, Oracle is committed to supporting open, vendor-neutral standards for XML. As an active representative on many W3C working groups and a founding member of XML.org, a vendor-neutral organization working to define the data standards, Oracle is working hand in hand with vendors and customers to ensure that, whatever that standard, customers will have the best technology platform to seamlessly integrate and run their applications.
Martin Boyd is a principal product marketing manager in Oracle's Worldwide Marketing organization, where he is responsible for XML and content management technologies. He can be reached at [email protected]