Rant: Don't return XML in string variables!

High-Performance Web Services: Avoid XmlNode, Use IXmlSerializable

Kirk Allen Evans' Blog — Thu, 06 Apr 2006 22:45:19 GMT

Avoid returning XmlNode from a web service method at all costs. In this post, I show why you should avoid returning XmlNode in web services, and demonstrate how to use the IXmlSerializable interface in .NET 2.0 web services for high performance XML serialization

National Weather (Web) Service

Matt Powell — Tue, 07 Dec 2004 02:35:00 GMT

re: Rant: Don't return XML in string variables!

yn — Sun, 11 Jul 2004 17:00:00 GMT

Why go through the trouble of instantiating an XmlDocument, XmlReader or even an XPathNavigator if you already have the XML as a string to begin with and have no interest in interacting with it in that context?

Let's take Oracle's (9i+) xmltype for example. It holds and returns XML as CLOB, which you normally cast to string. Assuming I simply want to forward this record from Oracle to my client, without interacting with it at all, why waste time and space over deserialization?

In the client I can simply (assuming client is the browser in this sample and 'result' is callService's callback argument):

var xmlDoc=document.createElement("xml");
xmlDoc.loadXML(result.value);

How to return well-formed XML from WebServices without the DOM: from XmlReader and XPathNavigator

TrackBack — Mon, 31 May 2004 19:34:00 GMT

re: Rant: Don't return XML in string variables!

Daniel Cazzulino — Mon, 31 May 2004 16:38:00 GMT

It's not necessary at all to load a DOM to return well-formed XML from a webservice. And as the DOM will be the "legacy-deprecated-dying" API in .NET, it only makes sense to move to XmlReader and XPathNavigator-based processing.
Here's how you can return well-formed XML without wasting server resources in loading DOMs you don't need: http://weblogs.asp.net/cazzu/archive/2004/05/31/144922.aspx (How to return well-formed XML from WebServices without the DOM: from XmlReader and XPathNavigator)

re: Rant: Don't return XML in string variables!

Tim Huffam — Wed, 26 May 2004 21:52:00 GMT

What about loose coupling?

Bundling various parameters into an primitive type like a string (like the MSCRM APIs do)provides a simple way to acheive loose coupling does it not?

Tim

Rant continued again: Don't put XML in Strings

Matt Powell — Fri, 14 May 2004 23:56:00 GMT

re: Rant: Don't return XML in string variables!

Shaun McDonnell — Fri, 14 May 2004 18:09:00 GMT

What about Classic ASP object incompatability?

For example, if I have an "Account" object on my .NET side of things and decide make that object a return value in my .NET Web Service, will ASP know how to handle the object? I don't think so.

In order to keep my .NET apps object-oriented, we just serialize our objects into Xml like this:

<I>
Account asq = new Account()
StringWriter swQuery = new StringWriter();
XmlSerializer xsQuery = new XmlSerializer(typeof(Account));
xsQuery.Serialize(swQuery, asq);
return swQuery.ToString();
</I>

Is there a better way to do this in order to avoid returning a string of Xml? I know the overhead is enormous and would love to know the answer. Thanks!

Shaun McDonnell
Citigroup

Rant Continued: Avoiding the DOM?

Matt Powell — Thu, 13 May 2004 22:55:00 GMT

re: Rant: Don't return XML in string variables!

Michaeljon Miller — Thu, 13 May 2004 17:55:00 GMT

Yup, agreed about the MS-CRM interfaces. There's a lot of history around why they're shaped the way they are, but that doesn't really matter any more. We (that is, the MS-CRM team) are looking at a bunch of approaches to make this all better in upcoming releases and I'll try to post some information as I can.

The problem was really one of timing and a requirement to handle type extensibility in the field. The timing problem is simple - the only tool available when we started MS-CRM was ATL server (and only in beta). Sure, we ended up slipping way past the VS.Net release date, but that's a different story. The type extensibility problem is that customers want to and need to change the shape of their entities on the fly. There were no types available for ATL server that we could leverage that could automatically extend (struct would never work, it's hard-coded in the type system), so we ended up choosing strings.

XML strings as parameters suck. They suck at the programming model level for both the client and the service. Building XML strings is error prone to say the least. But they also suck for type safety reasons on the wire. Trust me, I've stared at enough netmon traces of our stuff to get dizzy - it would be tremendously better if we had objects.

We're getting there. Slowly, but we're getting there. All I can recommend right now, and it's a short term hack, is to look at Dan Roger's <a href="http://www.microsoft.com/downloads/details.aspx?FamilyID=de0cc46b-4dea-4786-9eb0-8733e41bf5a8&DisplayLang=en">XSDObjectGen</a> tool and build classes from the XSD (it's what I do when I'm programming against the CRM SOAP interfaces). Although, on that topic, the V1.0 XSD were buggy out of the box. I think v1.2 fixed it and if not I might be persuaded to hand out the right fix.