New York
University
Computer
Science Department
Courant
Institute of Mathematical Sciences
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:
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
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:
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:
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
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.
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.