The Web has given us an easy-to-use, easy-to-market, and easy-to-navigate medium for conducting business. We've come to a stage where mainstream people are comfortable shopping on the Web. What it lacks is the ability to ensure that what the end user has browsed or accepted is the same as what was processed on the back end. In other words, how do you make sure the confirmation of a transaction is the same as the transaction itself?

This article discusses how XML and Formatting Objects Processor (FOP) technology can be used to address this problem.

The FOP initiative is a part of the Apache organization and is a subproject of the XML project ( http://xml.apache.org/fop/index.html). It is a Java application that enables rendering of XML input data to various output formats such as PDF, PCL, SVG, XML, Print, AWT, TXT, and RTF (not yet supported). Among these formats, PDF is the most popular option. The latest version of FOP supports the XSL-FO version 1.0 W3C recommendation ( www.w3.org/TR/2001/REC-xsl-20011015/).

FOP is a Java rendering engine invoked at runtime that applies an XSL-FO stylesheet to XML data and produces an output format based on properties that the runtime engine was initialized with. For example, you can fetch data from the database, represent it in XML format, and then apply an XSL-FO stylesheet to generate a PDF report. This process executes within the server tier. The resulting PDF stream can be presented to the end user in the same way that a PDF document can be set up for download from the Web.

Why XML and FOP?
Several rendering mechanisms are available today. HTML, TEXT, Microsoft Word, and other reporting mechanisms such as Crystal Reports are widely used. Most of them can also be used on the Web. Web pages are built mainly using HTML, the most common of the mechanisms. HTML is a primary language for building Web navigations with Web forms to capture user input, and also for displaying results to the end user.

It makes perfect sense to follow this approach until you capture data and navigate from page to page, but not after the input data has been processed and you're ready to show the results. The main flaw with rendering end results in HTML format is that the result page is easily editable. For example, you can get a final receipt from Amazon.com for a purchase in HTML, save it on a local machine, and then edit it to look like a completely different purchase. Or you can get an insurance quote for a car, change its premium by editing the HTML, print it, and fax it back to the company to claim lower premiums. You probably don't stand a chance of actually grabbing that phony deal, but just imagine how much time a sales representative would have to spend to disprove it!

The solution to this problem is that whenever you want to present to a customer what he or she is going to pay - a final receipt or a quote - you probably want to present it in a noneditable form close to the printed receipt you get at the checkout counter, something like a receipt presented as a PDF document. Therefore, it would be more accurate to show a final receipt within a browser as a PDF page instead of an HTML page. You can advise your customer to print that receipt as a proof of purchase.

Another advantage of using XML and FOP: if FOP solves your problem at the client tier, then XML solves it at the server tier. The XSL-FO stylesheet is applied to XML data, and XML data at that instance depends on many parameters a customer must have chosen to finally select that product. For example, a customer may get some discounts that may be applicable for that purchase. Another example: when highly configurable products, such as PCs, are sold on the Web, they vary from customer to customer. Granted, you have information about all the parts in your database, but you don't have information about a particular configuration. That configuration is already represented in the XML data. When the customer actually clicks that final buy button and the response is sent back to the server, your systems can easily work from XML data for that purchase instead of going all the way back to the database.

The main idea here is to make the final proof of purchase noneditable and also keep it in sync with the back-end processes. It makes the hard copy and the electronic copy virtually the same.

Putting it to real use
Before we jump to building a demo application, take a look at Table 1, which describes applications of XML-FOP to various industries.

Case Study: Insurance Quote Processing
Various applications of XML and FOP have already been discussed. Now let's explore how we can apply XML and FOP to a sample auto insurance quote application. I won't delve into how a quote is actually generated from the object tier. That would fall under the J2EE and JDBC areas. We'll assume here that we have all the data needed in the form of XML to process the quote, and will discuss how we can generate a PDF report from the XML data and process the data to complete the transaction.

Figure 1 shows the QuoteSessionBean that's responsible for collecting user-specific data to generate the quote in XML form. The QuoteSessionBean can interact with various business objects or get data straight from the database to generate the XML file (code not provided). Once the XML file is ready, something like a Reporter object that wraps the FOP calls can apply the XSL-FO stylesheet to the XML data and stream an auto policy quote as a PDF report to the user. Once the user accepts the quote and clicks the submit button, the application-tier object, such as QuoteProcessor, can work from the Quote XML file to finalize the quote.

Quote in XML form
The business logic tier generates the QuoteXML. The data needed to generate the report is embedded in the <quotedata> tag in Listing 1. Our report prints a simple auto policy quote that has customer, coverage, and summary data. The customer data has address and contact data within itself. The coverage data has the type of auto defined as an attribute and policy-related information as options. Many option tags appear in the options data definition. Each defines a type of coverage added in the policy. The summary data is just the total amount for the policy. As you can see, the XML data definition is quite simple and can be easily generated using something like Xerces libraries.

XSL-FO stylesheet
At first look the XSL-FO stylesheet looks a little complicated, but with a little experience it becomes as easy as coding HTML manually. Coding HTML or XSLT manually can sometimes get complicated, of course, but tools such as XML Spy help you autofill <fo> tags when you start coding the stylesheet. Also, coding the <fo:root> section becomes a repetitive task that can be copied from one stylesheet to another. Even better, you can have a set of formatting stylesheet libraries that define various styles and flows of PDF documents. Once this section is coded, all you do is match templates (XML node names) from the XML to the XSLT file and apply whatever formats you want in the rest of the section.

In Listing 2 the FOP root section has the simple definition and flow of a PDF document with a title and three sections, one each for Customer, Coverage, and Summary. Following this definition there are matching templates for Customer, Address, Contact, Coverage, Options, and Summary tags.

Note: The code in Listing 2 illustrates only FOP-specific items. See the "Resources" section at the end of this article for directions on obtaining the full stylesheet.

Generating dynamic PDF reports
You can also make the PDF reports dynamic by controlling what section of the report you want to hide at runtime. You can pass a flag to the stylesheet that's defined in another XML file. For example, you can code a common stylesheet for your "preferred" and "new" customers and generate different reports at runtime based on the value of the flag.

Say you have a flag called "showdiscount" defined in discount.xml as:

<discounts>
<policy showdiscount="true"/>
</ discounts >

and a variable displayControl defined in stylesheet as:

<xsl:variable name="displayControl" select="document(discount.xml')"/>

You can have the following statement around any <fo> block to control the display of that block only to your preferred customers:

<xsl:if test="$displayControl@showdiscount = 'true'"> <fo:block> Preferred Customer Discount Details </fo:block> </xsl:if>

PDF Output
To get the PDF output, you must have the Apache FOP ( http://xml.apache.org/fop/download.html) installed on your computer. Use the following command once you have FOP installed:

<<install_dir>>\fop-0.20.3>
fop -xml <<xmlj_files_dir>>\QuoteXML.xml -xsl
<<xmlj_files_dir>>\QuoteXslFopXslt.xslt -pdf
<<xmlj_files_dir>>\QuoteUsingApache.pdf

You can also invoke the FOP rendering engine from within any Java application or any application server (see Figure 2).

Back-end processing components
If you decide to keep the Quote XML data in memory until the response is obtained or the session is invalidated, you can process the quote from the Quote XML rather than querying for the same data again. This would save several DB calls. Moreover, as described earlier, the presentation layer and the processing layer would be in sync.

Conclusion
The use of XML and FOP together offers two main advantages for industrial applications:

GNU Ghostscript: www.cs.wisc.edu/~ghost/

Published Sep. 27, 2002— Reads 9,769 — Feedback 3
Copyright © 2002 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

Related Links

▪ Figure 1

▪ Figure 2

▪ Source Code

▪ Figure 3

About Rajesh Zade
Rajesh Zade has more than 13 years of experience in the computing field and has been working in various Java and e-Commerce technologies since 1996. He is currently chief technical architect for NetCliff, Inc., based in Santa Clara, CA.