I know the title of this post is a little tongue in cheek but actually who cares?
Just to put this in context in SL3, Microsoft have added support for binary encoding of soap messages for communication between Silverlight 3 applications and WCF Services.
Binary encoding means that the server can process messages faster, meaning higher throughput and the ability to handle more clients than the SL2 text encoding for SOAP.
The downside that the binary encoding is a proprietary Microsoft format (not MTOM), infact its the same one used by NetTCPBinding.
Since performance doesn't seem to be worse than text encoding in any situation, Microsoft have made this the default encoding for building Silverlight enabled WCF Services.
Does it matter if the default encoding is not interoperable? No, because you can always set it back to a text encoding if you need interoperability.
Also, Silverlight by default does not encourage interoperability. To allow other browser clients to connect to your webservice you need to set you cross domain policy file. By default cross domain browser clients are shut out.
Finally if you are building a truly public interoperable api, you probably wouldn't make it SOAP based anyways, you would be likely to build a REST api
Good Move Microsoft, Binary Encoding Rocks!
5 comments:
"Since performance doesn't seem to be worse than text encoding in any situation"
Implying that it is not any better either. Why use a non-interoperable, opaque (binary) encoding if there is no benefit. Sure performance is the only reason to favour it, and if it is only 'no worse' then what does it have going for it?
"Binary encoding means that the server can process messages faster, meaning higher throughput and the ability to handle more clients than the SL2 text encoding for SOAP."
Binary Encoding is much more performant than text encoding in most situations, particularly numbers, objects and arrays. There is no performance gain with strings.
My point with the earlier quote is that even in situations where it isn't optimized, performance is never worse.
There is a huge benefit in using binary encoding over text encoding
Hope that makes things a little clearer, and yes you are correct performance is the only reason to favor binary over text
i would like the msft binary encoding to be documented in some way that others could interop with it. For example AMF for flex is the equivalent to binary encoding for silverlight (ok not technically but in practical terms it is)... and amf is an open format (http://osflash.org/documentation/amf) ... would be nice to see the same thing happen here... but not a deal breaker by any means...
Mike,
I understand where you are coming from, as this was my gut reaction.
Howeever since then, |I have been thinking about things, and I just don't think you would interop with it.
I truly believe you will use binary soap for your own silverlight clients, and will use REST for any public api's. So I don't think interop is a big thing.
I agree, but playing devils advocate, I'm sure adobe thought the same thing and then flourinefx showed up
http://www.fluorinefx.com/
and now silverlight for amf
http://blog.fluorinefx.com/?p=15
Post a Comment