Perl Cd Bookshelf [Electronic resources] نسخه متنی

Best Practices

Before you start to explore the technical details of your XML application implementation, it is important to ask yourself the following questions:

What information do I need to deliver?

What is the format for the XML document?

Are there any limits to the size of the XML document?

Which tier can be used to create, process, and deliver the XML content?

The answers to these questions will help you to make your design decisions.

First, for point-to-point communications, where individual pairs of applications exchange data through their private tunnels, encapsulating the data in XML is not a good choice because it introduces processing overhead from the metadata. Without this need to share data in public, the proprietary data formats, such as the binary format, are much more efficient and provide better security for the data transmission over the network.

Second, when using XML, always make sure to pick the right data format. Also, avoid including presentation data in XML. It is a good practice to keep presentation data in the XSLT stylesheets.

Even though many people perceive the capability to create highly descriptive tag names as an advantage of XML, you should not forget that, in most cases, XML documents are used for application processing and the size of the XML can greatly impact on the scalability of XML applications. XML documents need to be designed for efficient application processing. For example, the human-readable element name Employee_Salary could be replaced by EmpSal, and certain empty XML elements that describe properties or context for the data can be replaced by XML attributes to simplify the data access and reduce document size.

As discussed earlier, whitespaces are used to format an XML document as human-readable. This creates additional overhead for most XML processing. Removing whitespaces in XML documents sometimes can reduce the DOM object size 50 to 70 percent!

Third, in addition to creating a compact data format, you should also avoid generating large XML documents from SQL queries. Just as databases utilize partitions to deal with large tables, you should also split large XML documents containing repeating subtrees or row sets into sets of smaller XML documents. Otherwise, your application may end up running out of memory or not being able to scale when deployed in production systems with high volumes of data and transactions.

Fourth, you should avoid overloading any application tier with XML processing. For example, sometimes XSL transformations are required before delivering the XML data. Depending on the nature of the XSL stylesheets and the size of the input documents, you can perform the XSL transformation in database tier, in mid-tier application servers or on the client side.

If the XSL process transforms large amounts of data from the database, it is a good practice to run them in database. This is because you can easily leverage the high-performance data management in database, such as the lazy DOM support in the Oracle XML DB. Additionally, transforming in database can facilitate sharing the transformed results between database applications.

If the XML documents are small but intensive processing is required, such as processing SOAP or other types of XML messages, the middle tier provides the advantage of scalability by offloading the database server and hence improving the overall system performance.

To further offload the servers, some XML processing can even be performed on the client side. Now, through their support for Java, PDAs and cell phones also provide XML support.

Caching XML is another way to save processing resources in servers. The Oracle database will cache the query results in its the shared pool. However, you can also simply store the result XML documents in CLOB tables for further use.

Fifth, if certain XML SQL queries are frequently used, XML views can be used to eliminate retyping and parsing the SQL statements, thus saving time.

Finally, though the built-in XML functions give you broad functionality in generating XML, you could implement customized solutions with Oracle XML Developer’s Kit (Oracle XDK) APIs in C, C++, and Java when the built-in XML functionality cannot meet your business requirements. For example, since the SAX parsing is not available in the SQL/XML functions or any of the PL/SQL packages, you can create mid-tier applications using SAX APIs from the Oracle XDK to generate large XML documents as follows:

Connection conn;
String username = "sh";
String password = "sh";
String thinConn = "jdbc:oracle:thin:@localhost:1521:ORCLX";
try
{
//Open a File and JDBC Connection
OutputStream out = new FileOutputStream("out.xml");
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
conn= DriverManager.getConnection(thinConn,username,password); 
// Create SAX Print Driver
XMLSAXSerializer sample = new XMLSAXSerializer(out);
// Using the OracleXMLQuery with SAX Output
OracleXMLQuery qry = new OracleXMLQuery(conn,"select * from sales");
qry.getXMLSAX(sample);
sample.flush();
}
catch(Exception ex)
{
ex.printStackTrace();
}

The XMLSAXSerializer is a SAX Content Handler in Oracle XDK that provides SAX output serialization with many options to customize the output such as specifying “pretty” or “compact” formats, setting the encoding attribute in the <?XML?> prolog and so on. In this example, the XMLSAXSerializer is registered to the OracleXMLQuery.getXMLSAX() interface to receive SAX events for the XML created by the XML SQL Utility. It then serializes the output out.xml.