Silverlight 3 and Binary XML vs. CompressedProxy

Silverlight 3 and Binary XML vs. CompressedProxy

Old forum URL: forums.lhotka.net/forums/t/7258.aspx


Jaans posted on Friday, July 10, 2009

We are using the CompressionProxy to reduce the WCF Payload for CSLA Business Objects and its very impressive to see how much can be compressed.

It is my understanding that Compression is "applied" to the WCF XML itself. With Silverlight 3 now supporting Binary XML, I'm wondering how much of an improvement might be possible using Binary XML and whether the Binary XML offers a beneficial compression ratio.

We have a project that is very sensitive to the size of the data sent over the links (remote links to mining sites so no ADSL) and would consider any improvement over the current compressed XML as very valuable.

Has anyone tried this?

sergeyb replied on Friday, July 10, 2009

I would be curios as well. My gut feeling is that native binary protocol is not going to do anything with the message size because CSLA object data in message contract is already byte[].

Sergey Barskiy
Principal Consultant
office: 678.405.0687 | mobile: 404.388.1899

Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

-----Original Message-----
From: Jaans [mailto:cslanet@lhotka.net]
Sent: Friday, July 10, 2009 4:59 PM
To: Sergey Barskiy
Subject: [CSLA .NET] Silverlight 3 and Binary XML vs. CompressedProxy

We are using the CompressionProxy to reduce the WCF Payload for CSLA Business Objects and its very impressive to see how much can be compressed.

It is my understanding that Compression is "applied" to the WCF XML itself. With Silverlight 3 now supporting Binary XML, I'm wondering how much of an improvement might be possible using Binary XML and whether the Binary XML offers a beneficial compression ratio.

We have a project that is very sensitive to the size of the data sent over the links (remote links to mining sites so no ADSL) and would consider any improvement over the current compressed XML as very valuable.

Has anyone tried this?

RockfordLhotka replied on Friday, July 10, 2009

It is possible you could see a 50% improvement (give or take). I say this, because in SL2 WCF uses XML on the wire, and a byte array would be Base64 encoded so it becomes text - and that effectively doubles the size of the data.

So in SL3 you might see that the binary xml support in WCF is able to actually move the byte array without encoding it into text - and that would save nearly half the byte size, and a bunch of wasted processing to encode/decode the array into text on either side of the wire.

What I haven't had time to explore, is whether the DataContractSerializer has a simple switch to make it use binary XML, because if it does, then I can change MobileFormatter to use the DCS in that mode and that'd shrink the original data size pretty substantially as well - pre-compression.

Jack replied on Thursday, July 16, 2009

Some more info... its related to the beta though.

http://www.biztalkgurus.com/blogs/biztalksyn/archive/2009/06/07/improving-the-performance-of-web-services-in-silverlight-3-beta.aspx

Justin replied on Friday, July 17, 2009

Also remember most binary xml representations do not store the tag name in both the beginning and end tag construct, in fact most normalize unique tag names to a string list and reference by id in the tag structure. Also they do things like under stand data types so that a int only takes up 32bits not however many utf8 characters are needed. Same with date/times and of course binary is not base64 encoded.

I believe the BXML format MS uses does these things, so for documents with lots of tags with larger tag names and smaller amounts of data in the tags you can see good reductions in size.

The W3C draft binary format even supports gzip compression of the data in the tags, so that you can get all the processing speed improvements while still getting the ability to compress the content vs the silly situation we are in now which is to serialize data to text then run it through a compressor back to binary then back to text then de-serialize back to binary on the other end.

IMO Some form of standard binary XML is the future if all parties involved can just agree on which one, which seems to have stalled at this point, JSON contributing to the stall.

RockfordLhotka replied on Friday, July 17, 2009

Sadly, I don't see a way to fully leverage binary XML.

 

The MobileFormatter is a CSLA .NET construct that takes the data from the business object graph and puts it into another object graph. This other object graph is basically a DTO graph that contains the data from the business object graph, but in a form where it can be serialized by the DataContractSerializer. The DTO graph contains information about the original object types, field values and references - information necessary to rehydrate a clone of the original business object graph, and information the DCS doesn't grab by itself.

 

http://www.lhotka.net/weblog/CSLALightObjectSerialization.aspx

 

And that’s all good in my view, because it (within limits) replicates the behavior of the BinaryFormatter and NetDataContractSerializer from .NET.

 

I spent some time looking for the “binary DataContractSerializer”, but haven’t found it yet. Nor have I found a switch where I can tell the DCS to use binary XML. I’m a bit puzzled about exactly where/how the binary XML serialization is occurring – I’d have expected there to be a “binary XML serializer” or switch on the DCS for this purpose…

 

Anyway, the data portal calls MobileFormatter and gets a byte array as a result. That byte array contains the XML created by the DCS. That’s what is sent over the wire. So WCF is passing a byte array, not XML (even though the byte array contains XML). And this means using the binary XML option in WCF simply means it uses binary to pass the byte array, not XML.

 

It is possible (but not guaranteed) that this will save a lot of bytes on the wire. It is very likely that the byte array is base 64 encoded to ensure it is valid XML. Base 64 encoding nearly doubles the size of data. So if the binary XML serialization doesn’t base 64 encode the byte array, it would have a pretty big impact (perhaps almost 50% less) on the size of the data on the wire.

 

But it won’t actually serialize the object data into binary XML, because that happens before WCF gets the data…

 

If anyone is aware of, or runs across, the serializer or serializer option that is used for binary XML please let me know.

 

Rocky

Justin replied on Friday, July 24, 2009

Not sure if this helps but,

The WCF binary xml serializer is created by System.Xml.XmlDictionaryWriter.CreateBinaryWriter: http://msdn.microsoft.com/en-us/library/system.xml.xmldictionarywriter.createbinarywriter.aspx

It conform the the MS Proprietary MC-NBFX stadard: http://msdn.microsoft.com/en-us/library/cc219210(PROT.10).aspx

Blog showing examples of using the MS binary serializer: http://www.wintellect.com/CS/blogs/jsmith/archive/2006/03/28/wcf-xmldictionaries.aspx

Agile Delta's EFX format that the wc3 is currently supporting for the standard that has a WCF SDK(not free): http://www.agiledelta.com/product_efx.html

 

 

RockfordLhotka replied on Monday, July 27, 2009

Thanks, I'll take a look at those.

Jack replied on Monday, August 03, 2009

some more info:

 

http://msdn.microsoft.com/en-us/magazine/ee294456.aspx

 

 

From: RockfordLhotka [mailto:cslanet@lhotka.net]
Sent: July-27-09 10:28 AM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] RE: RE: Silverlight 3 and Binary XML vs. CompressedProxy

 

Thanks, I'll take a look at those.

RockfordLhotka replied on Monday, August 31, 2009

Btw, this was very useful information as I changed the code in 3.8 to enable (by default) the use of binary XML. Thanks!

 

Rocky

 

From: Justin [mailto:cslanet@lhotka.net]
Sent: Friday, July 24, 2009 10:26 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: RE: Silverlight 3 and Binary XML vs. CompressedProxy

 

Not sure if this helps but,

The WCF binary xml serializer is created by System.Xml.XmlDictionaryWriter.CreateBinaryWriter: http://msdn.microsoft.com/en-us/library/system.xml.xmldictionarywriter.createbinarywriter.aspx

It conform the the MS Proprietary MC-NBFX stadard: http://msdn.microsoft.com/en-us/library/cc219210(PROT.10).aspx

Blog showing examples of using the MS binary serializer: http://www.wintellect.com/CS/blogs/jsmith/archive/2006/03/28/wcf-xmldictionaries.aspx

Agile Delta's EFX format that the wc3 is currently supporting for the standard that has a WCF SDK(not free): http://www.agiledelta.com/product_efx.html

 

 



decius replied on Thursday, October 22, 2009

RockfordLhotka:

Btw, this was very useful information as I changed the code in 3.8 to enable (by default) the use of binary XML. Thanks!

Awesome! Do you have any estimations or benchmarks of what this new feature will save over the wire? Do you still recommend using compression alongside this?

RockfordLhotka replied on Thursday, October 22, 2009

See this thread for more info:

http://forums.lhotka.net/forums/thread/37377.aspx

Copyright (c) Marimer LLC