Callout B in Listing 3 shows standard ADO code for accessing the database. In the production application, this script (including the ADO code) will be a COM object that provides all the database support for the application. The CheckCustomer function at callout C verifies that a CustomerID is valid. If either the CustomerID or password is invalid, the function returns a value of false and the application doesn't return the XML stream. The code at callout D dimensions the main variables for the application and opens the Recordset. This code is generic for ASP and ADO.
The real work starts at callout E in Listing 3. For reasons that I address later, I chose to create the XML in script rather than use ADO or SQL Server XML features. The first step in generating the XML is to output the XML tag, which is the first line in callout E. The rest of the code in callout E loops through the Recordset and builds the resulting XML stream by concatenating the XML tags and the values from the Recordset.
The first line of code at callout F in Listing 3 stores the XML stream in the sourceFile variable. Then, the code creates the path for the XSLT file to use for the current CustomerID. The server object's MapPath method returns a physical path to the XSLT file, then instantiates the XML parser that will handle the XML stream. Next, the code sets the async property of the parser object to false to force synchronous processing of the XML document. (With synchronous processing, the parser processes the request completely before returning control to the program.) Finally, the code loads the XML stream into the parser object.
The next step is loading the XSLT file. First, the code instantiates another instance of the parser and sets the async property to false. Different naming conventions clearly separate the XML and the XSLT objects.
The code loads the XSLT file exactly like the XML stream, except that this time it uses the Load method because the XSLT code is in a file instead of a variable. The next line does the bulk of the work in the application by calling the transformNode method of the XML parser object (the instance containing the XML) and passing in a reference to the StyleSheet object. The variable sOutPut now contains the new XML stream.
To complete the XML output stream, the next line of ASP code prefixes the XML declaration to sOutPut. First, the encoding parameter specifies the character-set encoding of the XML to let the parser know how to interpret the data. Finally, the vbCrLf constant adds a line break in the XML output for readability.
The code at callout G in Listing 3 is the main body of the application. First, it retrieves the incoming CustomerID and passwords from the Request object. Then, the If statement calls the CheckCustomer() function to check whether the customer is valid and authorized to use the service. If CheckCustomer() is true, the code calls ProcessXML to extract the data from the database and generate the XML. Then, the code uses Response.Write to write the output. Listing 4 shows the HTML code of a simple test page I used during development to execute the Web service.
Custom Made
Let me point out two things about this article's example. First, because it doesn't use ADO or SQL Server to generate the XML, you can use this code with any version of SQL Server and with versions of ADO that don't have XML-generation features. Also, I've found that the database server is often the bottleneck in an application. Although SQL Server 2000 could generate the XML, putting the XML in the ASP code lets you run the service in a farm of servers without dragging down the database server. And, this code can generate data in many XML formats and even non-XML formats, which is a criteria of one of our clients.
Second, although the ASP/ADO code isn't the fastest way to do things, not every application needs to run the fastest. You can optimize the ASP/ADO code by placing it in a COM object, using stored procedures rather than SQL, and not returning Recordsets when you don't need them. Of course, with any application you must perform real-world testing.
XML and XSLT are powerful and easy to use in a data-exchange environment, and you don't need to be an XML or XSLT guru to use them. This solution isn't designed to handle large data streams for thousands of users, but it works well for smaller data streams and hundreds of users. And if you need to add a layer of security to the application, you can place the ASP file in a directory secured with Secure Sockets Layer (SSL). Using SSL encrypts the ASP code's output, so the receiver of the output must also use SSL when retrieving the data from the service.
End of Article
Prev. page
1
2
[3]
next page -->
