I am building a web application which will generate XML from a database based on a specific schema and depending on certain input parameters (such as dates or search terms) carried on a querystring.
Is the best approach to write a web service which returns the required XML or to write an ashx handler that outputs the XML?
Am I able to specify the XML exactly as I want it in each instance?
Consider writing a REST-style WCF service using WebHttpBinding.
I've found the fastest way to get started with doing this sort of thing, particularly if its a simple REST type service - eg. using a simple HTTP GET - is to use ASP.MVC. As I'm sure you've read, this gives you complete control over the HTML, but it also means you get complete control over whether its even HTML you return. You don't even need a view, you can just return a ContentResult.
Its a bit of a "waste" of MVC, but its a very fast way to get the ball rolling. I used a similar approach, but in the end formalized it with my own HttpHandler and RouteHandler, which basically allow me to basically map a URL to a chunk of code, with almost no extra setup.
Leading on from Ch00k's answer the following blog (no it's not mine :-)) has his findings on using ASP.MVC and making a Restful web service to return XML, JSON etc. Maybe this would be a useful read for you ... Blog link.
The main thing to remember is that you want to return the xml string not an actual .net XmlDocument type (I may have mis understood the point in the question) as otherwise it's harder to consume it from other platforms.
Hope this helps :-)
I would do ashx in a situation like this. From your description, it sounds like a single search facility, a single table (or limited group of tables in a single database) and a relatively limited scope. All the MVC stuff is probably overkill. Don't over-engineer it.
Just create a class that implements IHttpHandler (or just do a generic handler if you're in Visual Studio 2005 or higher), parse the query string, either create a dynamic SQL string or pass the parameters to a stored procedure, and then use an XmlTextWriter to create the output. You can point the XmlTextWriter either to the output stream of the response or to a memory stream. I use the memory stream approach because it gives me better error handling options. Then set the content type to application/xml and stream the results.
I like this approach because it's easy to understand, easy to implement, easy to maintain, and gives you complete control. The downsides are that it's tightly bound to the database and may be less flexible than one of the web service framework based approaches if your application's scope increases over time.