Chapter 14. Content Syndication

14.1.1. Evaluating the Requirements

All too often, good solutions to a problem are not appropriate solutions for the company with the problem. The Foobar Library is a perfect example of this: certainly a Java servlet that could communicate with servlets built by mytechbooks.com could quickly solve the two organizations' problems. However, this ignores the library's requirements. Before creating a solution, the library detailed its requirements:

• The solution must be Perl-based; no Java engineers are on staff.

• The solution must not involve new software or library installations.

• The solution must not impact the existing order-entry system (no interface changes).

While these are not extremely stringent requirements, they force a solution other than Java servlets. You must avoid using Java as a solution. Of course, as this is a book on XML, you should be thinking that storing the data about new books in an XML format could allow the library to then supply that XML to clients through an HTTP request, thus enabling those clients to use the data in any way they wish. In fact, this is a much better solution than servlet-to-servlet communication, as the XML can be used by any company or client in its applications, rather than tying the library (and its books) to a specific company. This then defines the goal for updating the Foobar Public Library's system: save the entered information as XML data, and then provide HTTP access to that XML data for clients and customers.

14.1.2. Entering the Books

We need to examine the existing HTML interface for suppliers entering new books into the system. Example 14-1 shows the static HTML used to generate this form.

This file, saved as addBooks.html, provides the portion of the library application allowing suppliers to add new books they are sending to the library.

NOTE: In Example 14-1 and throughout the rest of the chapter, complete code and HTML listings are given so that you can create the example applications and walk through the process of enabling XML communication across the applications. Additionally, the code examples in this chapter assume you are using the filenames supplied in the text; you will need to change the code and examples if you use your own filenames. Code that may need to be changed to reference different filenames or scripts is emphasized in the listings to help you walk through the examples.

The HTML in Example 14-1, when accessed through a web server, results in the output shown in Figure 14-1. Although we do not look at the other menu options, the supplier can also view the library's catalog, go to the application's main menu, and log out of the application by using the menu on the left of the screen.

Figure 14-1. HTML user interface for Foobar Public Library

This form allows the supplier to enter the details about each book it is sending to the library. The supplier enters the book's essentials (title, author, publisher, pages, and a description), as well as a subject to categorize the book, and sales details, which include the price and ISBN number.

Once this information has been entered, it is submitted to a Perl CGI script:

<form method="POST" action="/cgi/addBook.pl">

This script, then, must produce XML output. The easiest solution would be to download a Perl library that handled XML parsing, such as Xerces-Perl; however, remember that one requirement of the library was that no libraries or software could be added. While this may seem silly and frustrating, keep in mind that many companies have very strict lock-downs on their production systems. In this case, the Foobar Public Library is just beginning to introduce applications on the Internet, and it does not have resources to support additional software.

Luckily, the code only has to output XML; this is done fairly easily by generating a file with information on the entered books by brute force. Things would be much trickier if parsing incoming XML were required. Because the library needs to keep any existing books, each new entry is appended to an existing file, instead of creating a new file upon a new request. Writing the Perl is almost trivial, and the complete Perl program to read the request parameters and append the information to an existing file is shown in Example 14-2.

This program, saved as addBook.pl, is invoked by a form submitted when the supplier enters a new book. The script defines the file to write to, and then assigns the request parameter values to local variables:

$title = $query->param('title');
$author = $query->param('author');
$subject = $query->param('subject');
$publisher = $query->param('publisher');
$isbn = $query->param('isbn');
$price = $query->param('price');
$numPages = $query->param('numPages');
$description = $query->param('description');

Once these values are easily accessible, the script opens the file defined earlier in append mode (signified by >> preceding the filename) and writes raw XML-formatted information about the entered book to the end of the file:

  print FILE "<book subject=\"" . $subject . "\">\n";
  print FILE " <title><![CDATA[" . $title . "]]></title>\n";
  print FILE " <author><![CDATA[" . $author . "]]></author>\n";
  print FILE " <publisher><![CDATA[" . $publisher . "]]></publisher>\n";
  print FILE " <numPages>" . $numPages . "</numPages>\n";
  print FILE " <saleDetails>\n";
  print FILE "  <isbn>" . $isbn . "</isbn>\n";
  print FILE "  <price>" . $price . "</price>\n";
  print FILE " </saleDetails>\n";
  print FILE " <description>";
  print FILE "<![CDATA[" . $description . "]]>";
  print FILE "</description>\n";
  print FILE "</book>\n\n";

The subject is used as an attribute on the enclosing element, book, and the rest of the information is entered in as elements. Because a book's title, author, description, and publisher may include quotation marks, apostrophes, ampersands, and other characters that would have to be escaped, the code encloses that data within a CDATA section so as not to have to worry about escaping the data.

Additionally, you should notice that no XML declaration or root element is created, as multiple books will exist in a single file. Because it is a bit difficult to check if the file exists, write the declaration and root element if the file is new, and then write out the ending element (which has to be overwritten at each new entry), the file is left as an XML document fragment. For example, here is what the file might look like after two books have been entered:

<book subject="Computers">
 <title><![CDATA[Java Servlet Programming]]></title>
 <author><![CDATA[Jason Hunter]]></author>
 <publisher><![CDATA[O'Reilly & Associates]]></publisher>
 <numPages>753</numPages>
 <saleDetails>
  <isbn>0596000405</isbn>
  <price>44.95</price>
 </saleDetails>
 <description><![CDATA[This book is a superb introduction to Java 
  servlets and their various communications mechanisms.]]></description>
</book>

<book subject="Fiction">
 <title><![CDATA[Second Foundation]]></title>
 <author><![CDATA[Isaac Asimov]]></author>
 <publisher><![CDATA[Bantam Books]]></publisher>
 <numPages>279</numPages>
 <saleDetails>
  <isbn>0553293362</isbn>
  <price>5.59</price>
 </saleDetails>
 <description><![CDATA[fter the First Foundation was taken over by the 
  Mule, only the Second Foundation stood between order and the utter 
  destruction the Mule would bring.]]></description>
</book>

Although not a complete XML document, this fragment is well-formed and could be inserted into an XML document with the header and root element already set. In fact, when I look at providing a listing of books in the next section, that is precisely how I'll handle output of the fragment.

The rest of the script outputs HTML indicating whether the book was successfully added or if errors occurred. Once a book has been added to the XML storage, the supplier receives the simple confirmation message shown in Figure 14-2.

Figure 14-2. Confirmation message when a book is added

Now that there is an XML document fragment with information about new books, you'll need to take that file and provide it to requestors.

14.1.3. Providing a Listing of Available Books

We again can use Perl as a mechanism to provide clients and customers with an XML listing of new books. I'm making the assumption that some other portion of the library's application periodically reads the XML data and updates the library's catalog; at this point, that application component is responsible for removing the entries within the file (or the file itself) so that the books within it are no longer regarded as new entries. With this assumption, all a second Perl script has to do is read the XML fragment and add the data within it to an XML document that is output to the screen. As I already mentioned, the script also needs to add an XML declaration and a root element to surround the content within the new books file. This new script, shown in Example 14-3, reads the file created by the addBook.pl script and outputs the content within an XML document when it is requested over HTTP.

This script, saved as supplyBooks.pl, accepts a request, reads the file created by addBook.pl, and outputs XML upon an HTTP request. The result of requesting this script in a web browser (with several books added) is shown in Figure 14-3.

Figure 14-3. XML output from supplyBooks.pl

As you can see, this easily turned the library's simple Perl-based application into a component capable of supplying useful information to its clients, including the mytechbooks.com technical bookstore. Additionally, we were able to accomplish this without installing new software, changing the architecture of the library's system or application, or even writing a line of Java!