Using Binary Encoding in WCF

I recently had a question from someone on using Binary Encoding and how performance of their application relates to that. My answer was it depends...it depends on what is in your message body and if you are using message security or transport security.

Before talking about binary encoding, the first thing to understand is that it is not a interoperable encoding. If your clients and service are all built with WCF then go ahead and use Binary Encoding. Binary Encoding is great stuff if you are using Message level security. In message security 90% of the SOAP header is security! When you are working with Issued Tokens, like SAML, the size of these headers are even bigger. Using Binary Encoding in these cases really compacts the size of the message by substituting each text element with a equivalent integer. Now, when I say element it is only applicable to the set of know element and attributes in a SOAP message. Like the element name "Envelope", "Header", "EncryptedData", "Signature" will be encoded to a single integer. How well the Body contents will be compacted depends on what is in the contents. If the Body is encrypted, then the contents contain the well known "EncryptedData" element and this will be compacted. If the Body contents is not encrypted then it will appear in plain text. An exception to this rule would be the infrastructure messages like Request Security Token (RST) and Request Security Token Response (RSTR) which are all well-knows elements. If your body contents are not encrypted and have custom serialized objects or Data Sets or XML Documents then you will not see any compaction here. So consider your scenario carefully, check the size of your body to the rest of the SOAP message. The chances are you will see a Performance boost moving to Binary.