New York University

Computer Science Department

Courant Institute of Mathematical Sciences

 

Homework #4 – Page-Based Script-Oriented XML Application Server Technology

 

Due Date: 11/14/11

 

Course Title: Application Servers                                            Course Number: g22.3033-005

Instructor: Jean-Claude Franchitti                                            Session: 6

 

 

1. Ongoing Project Background

 

This homework follows the course on-going project approach described in the homework #1 specification. You should keep enriching your framework-based enterprise application design, and take advantage of the application server platforms used to implement/deploy your application. Your application should be developed in such a way as to be shielded as much as possible from the underlying software infrastructure. For that reason, it is a good idea to build your applications around a portable application framework. As portability issues arise, you will learn how to improve the design of your applications to make them more portable across application server platforms.

 

2. Introduction to Page-Based Script-Oriented XML Application Server Technology

 

Any technology that is static is probably dead. Like everything else, the HTML content description language has undergone and will continue to undergo evolutionary changes. The introduction of Dynamic HTML is just one example . The Extensible Markup Language (XML) is another. Along the evolutionary path, page-based application server technology seeked to improve the limitations of traditional dynamic HTML approaches that characterized first generation application servers. The quest for a flexible and extensible approach led to extensions of HTML that would support special server-side tags to be processed by the web/application server. Two categories of tags were developed to support either custom HTML tags with pre-defined semantics and user defined scripts. Microsoft IIS with COM+ and ASP  is an example of a script-oriented page-based application server. For rich user experiences, there needs to be a flexible method of exchanging data between the client and server. Exchanging data like this within the HTML framework can be a cumbersome task, and this is where XML and XML application servers help out.

 

XML was developed to separate data from the user interface. Both HTML and XML have roots in SGML, an early data description language that preceded the Web. XML could be considered "SGML Lite" since it has fewer syntactic requirements than SGML, but shares a number of common features such as opening and closing tags, attributes, and Document Type Definitions (DTDs), which describe the structure of a document. The real power of XML is that a document that employs it can describe its own format. This, coupled with Dynamic HTML, allows for flexible client applications. DTDs describe the format of a document by defining data tags, their order, and the nested structure of the tags. Since the XML document author gets to define the tags, they can have mnemonic names like <AUTHORS>. Any XML-compatible parser can read any document assuming it is well formed—meaning that every opening tag has a matching closing tag. A validating parser uses the DTD to verify that every required tag is present in the specified order.

 

XML makes for a powerful way to create industry-standard methods of data exchange. A number of industries are working on creating standard DTDs for interchangeable data. These vertical market standards will allow the industries to exchange data using either off-the-shelf software or homegrown solutions. Open Financial Exchange (OFX) is one such standard. Even though OFX does not meet the requirements of XML, it gives financial institutions a standard method of connecting customers to their internal data, using Microsoft Money or Quicken to pay bills and check account balances. Because there is a common specification, banks and brokerage houses can offer this integration into their environments without having to develop multiple solutions for each software client. This is a huge cost and time savings, and it empowers their customers.

 

To illustrate the development of applications that use XML as their data exchange format, you will study a simple three-tier sample application server as part of this homework. The goal of the  homework is to deploy the framework-based application developed as part of homework #1 on top of a script-oriented page-based application server, and extend it to make use of XML configuration and processing capabilities. The suite of applications presented in this homework illustrates how to receive XML data from a client via HTTP or FTP, and how to return data to the client as an XML document. This rather simplistic client/server implementation will show how easy it is to build more involved systems.

 

The overall project objectives can be summarized as follows:

 

·         Help you practice your understanding of XML technology to support presentation-oriented publishing and message oriented middleware

·         Understand the use of XML to serve up an application's data

·         Produce and refine components for a complete working three-tier XML application

 

2.1. Software Infrastructure Provided:

 

Programming environment

 

1.       Environment used for homework #1 (as needed)

2.       Microsoft IIS with COM+ and ASP

3.       Other development tools best suited for page-based application server development environments

 

Programs

 

1.       All the software needed for this homework is contained in an archive posted on the course Web site under demos. The distribution archive contains the following directories for the various software components described in the previous section.

 

·         Xml_asp

·         XMLDBService

·         XmlIsapiConfig

 

Additional Sample Applications

 

1.       No additional sample applications are provided for this homework

 

2.2. Installing and Running the Homework Software Infrastructure:

 

1.       Install the Microsoft IIS with COM+ and ASP server (or similar technology), and any other development tool judged useful

2.        Deploy the sample application described in part 3 below using the information contained in the Readme files provided along with the distribution.

 

3.      Sample Application

 

XML-Based Application Server Overview:

 

The sample XML-based application server, XmlDbService, consists of two HTML pages on the client tier and three elements on the server tier. In its base configuration, the software uses Microsoft SQL Server and the Windows NT/2000 registry for the data tier (see Figure 1 below). The application allows you to bulk load a database via an FTP file drop and view the data in the database from a Web browser. On the server side there is a Windows service that watches for files to appear in a specified FTP directory (or any directory for that matter). If a user uploads an XML file to the monitored directory, the service parses the document and converts the items within it to database records. The client can view the data in the database by connecting to an Active Server Page, which converts the stored records into an XML file.

 

 

 

Figure 1: Three-tier Sample XML-based Application Server

 

Since the service waits for files to land in a specific directory, there must be a way to configure it to know where to look. This is done with an HTML file on the client side and an ISAPI DLL on the server side. The configuration data is stored in the Windows registry. Both the client and server applications use the Microsoft COM-based XML parser, MSXML, to process the XML documents.

 

The Client Tier:

 

Before you start testing the database bulk loading, you'll need to configure XmlDbService. You do this by reading the current configuration from the remote server, using an ISAPI DLL as the intermediary. The ISAPI command reads the server's settings and returns them as an XML document. The following code is an example of an XML configuration document:

 

 <?xml version="1.0" encoding="utf-8"?>

 <DBBULKCFG>

     <FTPDIR>C:\TEMP\XML_APP</FTPDIR>

     <INEXT>.XML</INEXT>

     <PROCEXT>.PRC</PROCEXT>

                        </DBBULKCFG>

 

Using the MSXML COM component and JScript, you can parse the XML document and copy the data into the form within the HTML. When the user commits the new settings, the form gets POSTed to the ISAPI DLL, where it saves the settings via the server's COM interface. There are four elements to the XML document. The  <DBBULKCFG> element is the parent wrapper for all of the other elements. It contains no data itself because its main purpose is to act as the root node of the XML tree. The root node of the tree has special meaning for the MSXML parser; all other children are accessed through this node. The remaining three elements contain the configuration data. <FTPDIR> is the directory that the service is meant to watch, <INEXT> is the file extension given to the file name once the processing is done. If the server has not yet been configured, these  values will be c:\, .XML, and .PRC respectively.

 

The sample application is organized around an interface layer and a back-office processing layer. While the interface layer focuses on the use of XML between the client and the web server, the back-office layer focuses on the use of XML between the web server and the data tier. The interface layer handles the configuration portion of the XML-based application., which is performed by reading the current configuration from the remote server, using an ISAPI DLL as the intermediary. The ISAPI command reads the server's settings and returns them as an XML document. Using the MSXML COM component and Jscript, the XML document is parsed and the data is copied into the form within the HTML page. When the user commits the new settings, the form gets POSTed to the ISAPI DLL, where it saves the settings via the server's COM interface.

 

The back-office layer of the sample application handle the XML data storage. As far as the XML data storage is concerned, the automated bulk population of the database occurs on the server tier using a Windows service (XmlDbService.exe) that watches for files to appear in a specified directory. The client does not interact with the service directly; the user interacts with it by dropping XML files into the watched FTP directory and through the configuration utility's HTML page. This HTML page communicates with an ISAPI DLL (XmlIsapiConfig.dll) that is the intermediary for the XmlDbService. XmlDbService.exe is a Windows service that uses Win32 file notification events to watch a directory for new files. When a file lands in the specified directory, an event is fired and the service scans for new files. XmlIsapiConfig.dll uses a COM interface to read and save the service's configuration data, which tells the server to reconfigure upon change. XmlDbService.exe writes the configuration information to the Windows registry but could write it to a file or database instead. As seen in the first part, the default ISAPI command returns the configuration data as an XML file. Clearly, XmlDbConfig.dll does not manipulate the registry directly, which maintains a good abstraction between the ISAPI DLL and the Windows service.

 

After you are done experimenting with the configuration logic, you will need to focus on the loading and parsing of an XML document previously stored in the underlying database. For the purpose of this assignment, we assume that the sample user data corresponds to a list of product items for a pet store encoded in XML as follows:

 

      <?xml version="1.0" encoding="utf-8"?>

      <ITEMLIST>

            <ITEM>

                  <PRODID>4</PRODID>

                  <NAME>Super duper bird feeder</NAME>

                  <PRICE>23.95</PRICE>

                  <QTYONHAND>1</QTYONHAND>

                  <COLOR>Green</COLOR>

                  <SHIPOPTS>0</SHIPOPTS>

            </ITEM>

            <ITEM>

                  <PRODID>5</PRODID>

                  <NAME>Average bird feeder</NAME>

                  <PRICE>3.95</PRICE>

                  <QTYONHAND>100</QTYONHAND>

                  <COLOR>White</COLOR>

                  <SHIPOPTS>0</SHIPOPTS>

            </ITEM>

            <ITEM>

                  <PRODID>3</PRODID>

                  <NAME>Thistle Bird Feed</NAME>

                  <PRICE>5.95</PRICE>

                  <QTYONHAND>1000</QTYONHAND>

                  <COLOR>Black</COLOR>

                  <SHIPOPTS>0</SHIPOPTS>

            </ITEM>

      </ITEMLIST>

 

Assuming that a user uploads the above listed XML file to the monitored directory, XmlDbService will parse the XML document and convert the items within it to database records.

 

4. Questions

 

1.       Preparation phase:

 

  1. Select a technology infrastructure that is compatible with the application infrastructure components provided for this homework.
  2. Install the application infrastructure software, and experiment with it.
  3. Experiment with the sample application
  4. Refine your framework-based enterprise application and extend it to make use of the XML configuration and processing capabilities, which are part of the software infrastructure presented in this homework. If your application is well designed you should simply have to create separate XML-based services to extend the semantics of your application possibly using a combination of infrastructure frameworks.

 

2.       Prepare a short report documenting your refined framework-based enterprise application (using software engineering standards), and explaining its motivation.

 

3.       Prepare a short report including functional diagrams and screenshots (as needed) to demonstrate your understanding of the infrastructure software. Explain the infrastructure software differences between the application you developed in homework #1 and #2 and the one you are developing for this homework. You should follow the following steps a-h to piece apart the sample application architecture, and you should be able to answer the various questions raised along the way:

 

  1. Using the overall description of the application architecture presented in the above, study the  page called EditCfg.htm which implements the configuration form on the client side. The page contains an embedded JavaScript and accesses the MSXML COM component.  You should be able to explain your understanding of the configuration functionality.

 

  1. What is the XML document returned by the ISAPI DLL to interface with clients interacting with the configuration function via EditCfg.htm? Your answer should provide an XML document containing a few lines.

 

  1. How would you go at replacing EditCfg.htm by a combination of EditCfg.xml and EditCfg.xsl files so that XML can be used for two purposes: (a) to generate client pages dynamically and (b) to exchange data between the client and the business logic tier of the sample application?

 

  1. Using the overall description of the application architecture presented in the above, study the page ReadDB.htm, which currently implements the loading of XML data on the client side. Assuming that ReadDB.htm uses the same XML schema (DTD) as the XmlDbService that runs in the middle tier and gets its data from the business logic tier via ReadDB.asp, explain your understanding of the client side XML data loading functionality.

 

  1. Study the active server page ReadDB.asp, and note that each XML <ITEM> maps to a record in an underlying Product table, each XML element within the <ITEM> is mapped to a field in the Product table of the same name, and only one field, SHIPOPTS, is converted from a string to an integer. You should be able to explain your understanding of the server side XML data loading functionality. In particular, why is it important that the XML schema closely resembles the database schema, and can you assume that it will always be the case when dealing with general purpose applications?

 

  1. Assume that the various components are operational, and that the XML user data is as given in the project overview section. What is the expected client output obtained via browsing of ReadDB.htm[1]?

 

  1. In this particular application, what shows that the data tier may not forcibly be a database and may target any type of persistent storage?

 

  1. How would you go at replacing ReadDB.htm by a combination of ReadDB.xml and ReadDB.xsl files so that XML can be used for two purposes: (a) to generate client pages dynamically and (b) to exchange data between the client and the business logic tier of the sample application?

 

4.       Develop and deploy your framework-based enterprise application on top of the software infrastructure presented in this homework. Document the benefits and deficiencies of the approach on which the sample XML-Based application is based, and explain (as needed) how it limits your ability to develop the various application components you have envisioned for your enterprise application. Note that you do not need to provide a complete implementation of your application in this homework. You should restrict yourself to what you feel is feasible based on time and the level of support provided by the infrastructure software. Your application should be tuned for efficiency as allowed by the underlying infrastructure software, and you should document your performance engineering approach. You should conclude your report by suggesting, and implementing (as time allows) an improved Application Server model.

 

5.       Explain how you would refine the “analyzer” tool you started designing in homework #1 and #2 to  capture information about the new version of your application deployed on top of Microsoft IIS with COM+ and ASP, and re-deploy it as an XML-based web application such as: (a) the “SpyWeb” application provided as support material under demo programs on the course website, and (b) the Cocoon 2 XSP framework. Note that the target application should again maintain a strict separation between content, style, and logic. As for homework #1 and #2, your analyzer should strive to extract and represent a generic model of your application using a suitable markup language.

 

6.       Extra Credit: Implement a prototype of the analyzer tool described in question 5.

 

5. Deliverables

Please provide an electronic copy of your homework submission as one zip archive by sending it to the course TA by the beginning of next class. The archive should include your application software, any modified infrastructure software, a readme file describing the environment setup required to run your application, and your homework report (in word or text format). You should name your archive using the following convention for all homework archives: name_hw?_fa08.zip, where name may include additional underscore characters as needed. You are also required to provide a hard copy of your homework reports at the beginning of each session or according to the homework submission scheduled spelled out in the homework specification.

 

6. Grading

 

All assignments are graded on a maximum scale of 10 points. Your grade will be based equally on:

 

a.       The overall quality of your documentation.

b.       The understanding and appropriate use of application server related technologies.

c.       Your ability to submit working and well-commented code.

d.       Extra credit may be granted for solutions that are particularly creative.

 

7. Additional Information

 

Please let the TA know as soon as possible about teaming arrangements. You will need to stay with the same team for the duration of the course. You should only submit one report/archive per team for each assignment. To balance things out, the final grading in the course will take into account the fact that you are working as a team instead of individually, so you should feel free to work individually as well. Note that the final take home examination will require individual work.



[1] XmlDbService.exe, and XmlIsapiConfig.dll are provided as part of an archive in the demos/project directory on the course web site. The archive also includes an SQL script, which can be used to properly configure Microsoft SQL Server as the underlying database.