Chapter 17: Developing XML-Based Reusable Components
In this chapter we begin to look at higher-order XML functionality. In previous chapters you have been introduced to the components that make up an XML infrastructure—XML parser, XSLT processor, XML Schema validator, etc. Now you will use this functionality in an XML-powered framework that supports building whole application processing blocks that can be easily configured by XML files instead of compiled code. This configuration not only covers the logic flow of your application but its schema as well. This functionality allows for the creation of reusable software components that reduce development time and improve application reliability. In the past such a framework would have had performance disadvantages; however, the design we will be discussing uses SAX streaming to mitigate these disadvantages and allow form-managed scalability.
Designing the Framework
Consider a fictitious book reseller, Big Barrel Books (BBB), who does business over the Internet with a wide variety of suppliers. However, BBB is not the size of Amazon.com and thus cannot dictate to its suppliers the particular book listing XML format that they use. Under these conditions, BBB needs to validate each entry against each partner’s XML schema before accepting the entry. To improve the system performance, these schemas are stored locally. However, this opens up a potential problem area because BBB may not be informed of a change or update to these schemas and thus could reject valid listings. Therefore, the system must include the capability to check for this condition without the overhead of always fetching the XSD file from the partner.The block diagram in Figure 17-1 illustrates such a system organized as a streaming pipeline. The strategy is to parse and validate incoming XML book listings using the SAX validation capabilities in Oracle XDK 10g against the local copies of partners’ schemas. If the listing validates, then it is passed through the pipeline to the output. However, if it fails validation, then the listing may be invalid, its associated schema may need updating, or both. You need to evaluate this condition and validate the listing against the new schema; then, you need to decide whether schema changes have occurred and whether the listing is truly invalid.
Figure 17-1: Book listing streaming pipeline
To perform this processing, you could custom design an application from scratch; however, you need a number of generic XML processing components, which means that you could design this in a modular form using a pipeline strategy. This is exactly how we will proceed, using the new XML Pipeline Processor in Oracle XDK 10g. (See Chapter 7 for an introduction to the XML Pipeline Processor.) The following components constitute the required functionality, as shown in Figure 17-1:
SAXParserProcess Parses incoming XML and outputs SAX events
XSDValProcess Validates against the local schema, analyzes the results, and reports any errors if necessary
XSDSchemaBuilder Parses an XML schema and outputs a schema object for validation
XSDConditionalValProcess Receives the SAX stream as well as the isCheck from which it either passes on the stream or compares and revalidates against the remote schema
XMLDiffProcess Compares two XML schemas, checking for differences, and returns an XSL stylesheet to convert one to the other if one or more differences are found
SAXPrintProcess Writes the SAX event output stream to a file
These components and processes can be connected together through a combination of the Pipeline Processor and an XML pipeline control file. Before we build this application, let’s start with a couple simple pipeline processes.