Rant: Don't return XML in string variables!

OK, I admit...

markorangel.com — Wed, 12 May 2004 21:57:00 GMT

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

Jeff Perrin — Wed, 12 May 2004 19:03:00 GMT

What happens when you're accessing the service with another technology, like PHP or ASP? (I really don't know this...) I've created a few XML-RPC based web services that return xml documents as strings, which is exactly what an xml document is... If a PHP client, for example, is accessing a .NET webservice with a return type of XmlDocument, can it easily process it?

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

brady gaster — Wed, 12 May 2004 19:33:00 GMT

AMEN (to the post, not the comment)

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

David Barnhill — Wed, 12 May 2004 19:54:00 GMT

Returning XmlDocument from a web server serializes itself to xml, so if you are accessing the web server from a non-.Net environment it still works OK. What you save is the XmlDocument->String and String->XmlDocument conversions.

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

Matt Powell — Wed, 12 May 2004 20:57:00 GMT

As for interop, As David points out, XmlDocument basically just sticks XML in the body of the envelope so it should definitely be x-platform goodness.

And by the way, I've done this too ... back in the early SOAP Toolkit days when a change in toolkit versions changed the wire protocol and we had to live with it until the next revision of our app. But we fixed it as soon as we could - and appropriately repented.

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

Mike Julier — Wed, 12 May 2004 21:21:00 GMT

So is this a question of changing the type of object that gets wrapped around the bytes? It sounds like the bytes don't change but that perhaps they get copied. Is this what the rant is about?

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

Matt Powell — Wed, 12 May 2004 21:28:00 GMT

The bytes do change. Sending the string sends this:

<envelope>
<body>
<a>blah<c>blah</c></a>
</body>
</envelope>

Sending the XML sends this:

<envelope>
<body>
<a>
blah
<c>blah</c>
</a>
</body>
</envelope>

(I hope this formats okay in my comments.)

-Matt

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

Serban Florea — Wed, 12 May 2004 21:38:00 GMT

Well, it is somewhat cleaner (and safer), but it's not that we dispensed with serialization altogether...

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

David Taylor — Thu, 13 May 2004 00:50:00 GMT

Hi Matt,

I have been working with the new MS CRM and note that it sends XML between the client and server as strings, which I also found frustrating!

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

Christoph Schittko — Thu, 13 May 2004 02:23:00 GMT

The office team is defined interfaces with stings containing XML for their research and translation web services as well. It would help if service interfaces published by Microsoft Web would follow best practices.

I am sure many developers new to Web services will follow practices the see in interfaces published by the big guys.

Christoph

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

Simon Fell — Thu, 13 May 2004 02:24:00 GMT

All you need to do now is make the same fix in your products!, seriously go checkout the SOAP interface for MS-CRM, it blows chunks.

Rant continued: Some reasons...that don't usually apply

Matt Powell — Thu, 13 May 2004 06:37:00 GMT

Take Outs for 12 May 2004

Enjoy Every Sandwich — Thu, 13 May 2004 08:04:00 GMT

Take Outs for 12 May 2004

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

kevin — Thu, 13 May 2004 13:33:00 GMT

Does this also apply to SignedXML objects? Can they be returned directly as well?

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

chadbr — Thu, 13 May 2004 15:46:00 GMT

What if you don't want the overhead of creating the DOM on the server in the 1st place?

If you look @ a typical "read" stack it's:

client request => server => some object(s) => database (or data store) request

(unwinding stack)
data results => some data format => soap serializer => client

Why would I want to take on the server overhead of "some data format" being a DOM?

If I want to process the data from a database before it's sent back to the client, I probably want to process it in the form of a dataset or datareader -- neither returns a DOM –

So are you suggesting the overhead of creating a DOM so it can be returned in native XML is worth the server overhead?

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.

Rant Continued: Avoiding the DOM?

Matt Powell — Thu, 13 May 2004 22:55: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:


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


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 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!

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

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!

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);

National Weather (Web) Service

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

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

Matt Powell Rant Don t return XML in string variables | work from home

Matt Powell Rant Don t return XML in string variables | work from home — Tue, 16 Jun 2009 15:09:19 GMT

PingBack from http://workfromhomecareer.info/story.php?id=31774