Are you scalable as you could be?
If you’re pulling a lot of your content from a database, don’t count on it.
Here’s a secret – if you want scalability – check out XML, XSL and XSLT Processors. What’s a XSLT Processor? It’s an idea that makes rendering XML and XSL a breeze. And guess what? Microsoft’s .NET provides a class, XSLTransform, that’s going to make your life a breeze. Pretty sweet, eh? What’s fantastic about XSL Transform is that you can output all of your content (data, links, frequencies, etc.) into XML, then transform it into whatever you desire (text, html, xml, aspx) using XSL.
What really makes XSL Processing work well is that you can forget browser incompatibilities and old browsers that don’t have the facilities to render XML. XSL Transform along with CSS will format your website so well, even your mother can’t tell the difference between the transformed web page and one painfully hacked out in HTML. Seriously, though, the real money is in the speed and scalability of your system – that’s why, if you can do it, you should move all ‘static’ content from the database to XML documents. When I say ‘static’, I mean the data in your database that won’t change, or is very unlikely to be changed.
This ‘static’ data can be stored as XML – releiving pressure from an expensive database query that could be used for something more useful, like a dynamic search against an author column. By moving the burden from SQL and network traffic to mere I/O, you’ve bought yourself some real scalability.
But, uh, ok. I’ve got all this data in XML, and it looks like crap. I can’t make sense out of it and the guys in marketing are going to be screaming bloody murder…Relax. This is where XSL comes in. XSL stands for eXtensible stylesheet language – you can just think of it as a script that formats XML into a nice looking page. XSL can take any XML document and make it into anything you want – whether that’s another XML document, a text file or an ASPX page. The key here is that XML is your content and XSL is your presentation layer – and XSLTransform is the glue that binds them together.
Here’s some code I’ve used on my site tiberi.us
public string TransformXML(string
strXMLURL, string strXSLURL)
{
//Create a IO Stream
System.IO.StringWriter oSW = new System.IO.StringWriter();
try
{
System.Xml.XmlTextReader oXR = new
System.Xml.XmlTextReader(strXMLURL);
System.Xml.Xsl.XslTransform
oXSLT = new
System.Xml.Xsl.XslTransform();
oXSLT.Load(strXSLURL);
System.Xml.XPath.XPathDocument
oXPath = new
System.Xml.XPath.XPathDocument(oXR);
oXSLT.Transform(oXPath,null,oSW);
}
catch (System.Exception e)
{
//Put in custom error
handler here…
string x = e.ToString();
}
return oSW.ToString();
}
A quick walk-through of the code will show the power of the XSL Processor.
public
string TransformXML(string
strXMLURL, string strXSLURL)
{
//Create a IO Stream
System.IO.StringWriter oSW = new System.IO.StringWriter();
try
{
System.Xml.XmlTextReader oXR = new
System.Xml.XmlTextReader(strXMLURL);
Our two parameters that we pass to this method are the URL of the XML file and the URL of the XSL file. After we have both of these parameters, we can transform our two files into something useful. Notice that we’ve created a StringWriter object and have fired up an XMLTextReader and passed in the URL for our XML file.
Now, here’s the real meat of our method…
System.Xml.Xsl.XslTransform
oXSLT = new
System.Xml.Xsl.XslTransform();
oXSLT.Load(strXSLURL);
The XSLTransform object that we’ve instantiated will do the pack-mule amount of the work here. Once we let it know where our XSL file is, and passed it an XPathDocument, we can do the Transform.
System.Xml.XPath.XPathDocument
oXPath = new
System.Xml.XPath.XPathDocument(oXR);
oXSLT.Transform(oXPath,null,oSW);
}
catch (System.Exception e)
{
//Put in custom error
handler here…
string x = e.ToString();
}
return oSW.ToString();
}
Notice that the oXSLT.Transform method takes three arguments, an ‘input’, an args list for XSLT, and an ‘output’. We’re passing in an XPath Document for our input, NULL for our arguments and we’re dumping the transformed XML into a StringWriter. Although you could use an overloaded method of the Transform method that directly references the URL of the XML and XSL files, I’ve decided to walk you through the long way of doing the Transform so you’ll learn what this object is capable of.
Although we are passing in NULL for our XSLT arguments, we are taking advantage of something very cool – the ability to render portions of our XML based on parameters provided in our XSLT args. We could write our XSL in such a way that it refers to parameters we’ve set up – such as the current time.
//Create an XsltArgumentList.
System.Xml.Xsl.XsltArgumentList xslArg =
new System.Xml.Xsl.XsltArgumentList();
TimeSpan oTime = DateTime.Now.TimeOfDay;
xslArg.AddParam(“cur_time”, “”,
oTime.ToString());
And in our XSL sheet, we’ll refer to our parameter we’ve passed in, rather than rely on a script embedded in the XSL.
<xsl:stylesheet
version=”1.0″
xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”>
<xsl:param name=”cur_time”/>
<xsl:template match=”/”>
Current Time: <xsl:value-of select=”$cur_time”/>
</xsl:template>
</xsl:stylesheet>
To take the XsltArgumentList to the next step, we could render off of the <xsl:if> conditional statement based on the parameters you’ve passed in via the XsltArgumentList.
Now that we’ve got a good grounding of how XSLTransform works, let’s talk a bit more about scalability and how we can push the envelope even more.
There are three strategies that most businesses would use when applying the power of XSL Transformation.
Strategies for XML and XSLT
1. Transformation on Demand
2. Transformation Factory
3. Cached Transformation Factory
Transformation on Demand
When using the Transformation on Demand strategy, HTML or ASPX pages are created dynamically by applying a XSL style-sheet to an XML document and using a transformation object to create the output. When a user requests a resource on your website, an XSL Transformation object is used to format the resource according to the layout in the XSL document. You may wish to pursue this strategy if you’re creating an XML document by using the System.Data.SqlClient.WriteXML() method based on a dynamic query from your end user, if your XML or XSL documents are created on the fly, or if you need absolute dynamic information pushed to your end user.
Transformation Factory
In a Transformation Factory, HTML or ASPX pages are created from the XML and XSLT and saved as ‘static’ pages. By using a Transformation Factory, you can create hundreds of static pages from dynamic sources and save the overhead of creating these pages on demand. You could set up a Transformation Factory to whip through thousands of XML files, apply the XSL and save the output as HTML, ASPX or any other format you desire. End users would connect to these ‘static’ pages without the overhead of the ‘on-demand’ XSL Transformation. You may wish to use this strategy if you don’t anticipate the ‘look and feel’ of your website or the information to change. There is no need to apply an XSL to the XML every time an end user requests a resource on your site.
Cached Transformations
A cached transformation is simply a transformation that takes places on a given schedule, say 24 hours. The result of the XSL Transformation is cached for a day or until needed and dished up to the end user. This is the strategy most ‘dynamic’ sites should take unless you need to dish out dynamic information that is up to the minute – like the information needed in a stock market application. Most business needs are met with a daily or twice daily caching of information.
Simply cache each page with a cache time expiration of 24 hours. You can also create a dependency to any file (in this case, an XML file), so if the file changes, your cache is updated with the information in the updated file.
To conclude, XSL Transformation is a very slick and needed technology. This powerful tool allows you to scale upward rather than outward – giving a needed break to your corporate pocketbook.
Tiberius OsBurn is a freelance technology author and speaker based in Omaha,
Nebraska. His book, “Hardcore Development”, will be released in the summer
of 2003. Mr. OsBurn has extensive experience in VB, VB.NET, C#, SQL Server,
ASP.NET and various other web technologies. Be sure to visit his site,
http://www.tiberi.us, for his latest articles of interest to .NET developers.
