Message encoding
As time goes on, perhaps we will be conditioned to think that XML (SOAP) is a structural literal. After all, text is human-readable, and each computer system can process text. The general commonality of text-based XML resonates with our idea of interacting with other systems. text-based XML, which can be easily interpreted, is inherently larger in size. It is understandable that using XML can result in performance losses. It takes a bit of effort to put the letter in the envelope, it needs some processing time to interact with the XML. In some cases, the text-based XML data size limits its application, especially when we are sending an XML message over the network.
In addition, if we limit ourselves to using text-based XML, how can we send binary data (like music or video) into an XML document? If you have read the standard XmlSchema data type, you will find 2 binary data types:: Xs:base64binary and Xs:hexbinary. Essentially, two data types represent a set of ordered 8-bit bytes. Using these XML data types may solve some of the problems embedded in binary data into the document, but in fact this has made the performance problem worse. The well-known problem is that the base64 encoding increases the size of the data 30%. This is worse for xs:hexbinary because it increases the original twice-fold size. All two of the data are based on UTF-8 coding assumptions. If we use UTF-16 encoding, these multiplier factors will multiply.
XML information set (XML Infoset)
To find the answer to the bottleneck of performance, let's look at the structure of the XML document in detail. If we look at the specification, XML is a precise syntax for composing structured data (defined in http://www.w3.org/TR/REC-xml/). It requires that a well-formed XML document must contain a start and end element, a root node, and so on. Oddly, the XML specification has been published, prompting the need for an abstract definition of an XML document. The XML information set (defined in http://www.w3.org/TR/xml-infoset/) provides this abstract definition.
In fact, the definition of an XML information set is a relationship between projects that does not define any specific syntax, and we are able to interpret many different message encodings, including some higher-school coding formats than text, without having to modify our programs.
Soap and XML Information set
Remember that soap is built on XML. This creates a problem: In the end, is the SOAP message based on an earlier XML syntax or an XML information set? The answer is 2 of them. 2 SOAP Specifications Coexist: SOAP 1.1 and SOAP 1.2. SOAP1.1 is built on the old XML syntax, and SOAP1.2 is built on the XML information set. With such a fact, it can be assumed that SOAP1.2 created a message that the SOAP1.1 parser might not be able to read. WCF is built on the SOAP1.2 (XML information set), but it can handle both SOAP 1.1 and SOAP 1.2 messages at the same time.
WCF can be used and customized to work with other actual message encodings, as long as the message is in accordance with SOAP1.1 or SOAP1.2 (it can work with not SOAP messages). As you will see in the next chapters, WCF is a flexible access and portfolio architecture. So a custom encoder can be easily installed on a WCF pipeline. When a new encoder is developed, Microsoft or a third party can create and insert it in the message stack. I will be in the 6th chapter: "Channel" in detail to introduce the message encoder. Now let's look at the encoders in WCF. At the time of writing, WCF provided three encoders: text, (binary) binary, messaging optimization (message transmission optimization mechanism, MTOM).
Text encoder
As you guessed from its name, the output of the text editor is a text-encoded message. Each system that understands Unicode text can read and process messages from this encoder, which is a helpful choice when interoperating with other non-WCF systems. Binary data can be incorporated into text-based messages through Xs:base64binary extended style definition (XSD) data types. This is a message encoded using a WCF Text encoder (to remove part of the element for clarity).
<s:envelope xmlns:s= "Http://www.w3.org/2003/05/soap-envelope"
<s:header></s:header
<s:body>
<submitorder xmlns= "http://wintellect.com/OrderProcess"
<or Der Xmlns:i= "Http://www.w3.org/2001/XMLSchema-instance"
<orderbyte xmlns= "Http://wintellect.com/Order"
mktjxwyxkr/9ow/jo48ihuwrzvnodyuuquzeaicy08aa+hxkt3dnmve/
+ zi96q91a9zb17htrcigtbwmbsk4ys2psemaizxv3cwcd3z4ccdwzpwx1/
wuretsxjtaji3hbzblk6dmw0eghvnl652lkejcuj6uh/ Lrlzz3x1+aereeogdlkt4gcnno efecl8ctrjty/tapm4a+k/
4e1jpnbgtcrrgwwpvko0uqrxahz2xbshrdqnzgdwahdf/
FHDXFZGPFWOGPF1IG88KQZO0JNCSYKIP5I8OPYTEQD0YVHB8QST9SWW59YZLHVU65UKOYF xa7rvoqzkjgtv6wzaggca=
=
</Or Derbyte>
<ordernumber xmlns= "Http://wintellect.com/Order"
12345
;/ordernumber>
</order>
</submitorder>
</s:body>
</S:envelope>