5th Chapter: News
The System.ServiceModel.Channels.Message abstract type is the basic unit of communication in Microsoft Windows Communication Foundation (WCF). Although the message type is used in WCF programs, WCF developers do not need to contact the message directly. As a result, you can write a rich WCF program without interacting with an instance of any message. However, while your code does not directly interact with the message object, remember that the WCF infrastructure is also busy creating, sending, accepting, or otherwise working with the message object.
Note that the words used in this chapter, when I use the message, refer to the System.ServiceModel.Channels.Message type. When I use message, I mean the abstract concept of sending and receiving data. (When Lao Xu translates this book, all the message is translated as: message type, as it is.) NET's built-in type. Messages are translated as: message. There is no confusion here. )
If the WCF infrastructure has done the message type for us, why do we have to spend so much time and effort to figure out the message type? In my opinion, there are 2 important reasons. First, many WCF public customization functions (like behaviors and encoders encoders) need to interact directly with the message type. If you don't know the message type, it will take more time and you may have very serious consequences for the WCF infrastructure. Secondly, I found that a solid grasp of the message type will effectively improve your overall understanding of WCF. At some levels, the WCF infrastructure is generating, sending, accepting, or processing a message object, so understanding the message type is the basis for understanding the internal work mechanism of WCF. To enable you to extend WCF knowledge and enhance your understanding of WCF, this chapter explains the core functions of the message type and other types of interaction with the message object.
Message Type Introduction
The message reference type is an abstraction of the SOAP messages that WCF applies. Because of the close relationship with SOAP messages, the message type defines members that represent SOAP versions, envelopes, message headers, message header blocks, and message body elements. Like other XML-centric WCF types, the message type is built on top of the XML Infoset. In effect, the message type is actually a wrapper over the data store, and the data store is an XML infoset.
Image from book
Message type and SOAP
The relationship between the message type and soap needs to be explained here. When Microsoft Architects designed WCF, they expected that XML and SOAP would become standard constructs for all messaging applications. And the industry as a whole is moving in this direction. Most, if not all, the message platform now supports sending and receiving XML messages. Many platforms use SOAP as the primary message structure. Aware of these problems, Microsoft's architects conclude that soap and XML are the preferred message structures, that the type of messages fully supports SOAP and encapsulates soap semantics in the object model.
The structure of the message type can easily satisfy a non-SOAP type of XML application system. The message type can simply remove the SOAP messaging structure and send plain old XML messages (Plain OID XML (POX) messages). When the message type must adapt to a non-XML platform application system, there will be problems arise. One of the most notable exceptions is JavaScript Object notation (JSON). Like your name says, JSON is a way for JavaScript to represent objects and is completely compatible with AJAX-enabled technologies, like Microsoft asp.net ajax.
Consider the following scenario: A Web program needs to asynchronously update a drop-down list with the value of an array. Suppose the value of this array is controlled by another control on the page. Use Microsoft ASP. NET and ASP.net AJAX, we can easily implement information retrieval and local refresh page content. So what if you need to get data from WCF? In this case, the answer message needs to use an array in JSON format, not XML. For this type of application, it is very difficult and complex for browsers to process XML. Object renders as JSON, in other words, it is very easy to pass the value of the Drop-down list through JavaScript.
At first glance, JSON seems to be another encoder applied to the message type instance, much like the messaging optimization mechanism (MTOM). Close observation, you will find a few problems. For starters, JSON does not have any XML namespaces and attributes. Our fictitious JSON encoder needs to extract the XML information. To be exact, the order of strings in JSON is very important. In XML, schemas define the order of elements. If the schema does not require the order of XML messages, it may be difficult to convert to an equivalent JSON object. To solve this problem, the WCF team will publish several additional types of Help message types for serialization.
Image from book
Throughout the lifecycle, the message object must be converted several times before it is transmitted to other messaging participants. From the sender's point of view, this transformation consists of 2 steps: Serialization and encoding. Message serialization Converts a message instance to an XML Infoset encoding that converts an XML infoset to a specific data format. From the recipient's point of view, this conversion is exactly the opposite of the sender. In other words, the recipient must deserialize the received data bit infoset and then deserialize Infoset as a message instance.
The Message object model focuses more on message serialization and deserialization, and most of them affect other types in the WCF Application Programming interface (API). Therefore, before studying the message type, it is necessary to know the type of serialization and encoding. We'll take a look at the next one. The basic type responsible for message serialization and encoding. Thereafter, we will continue to learn the message type in detail.
"Old Xu Notes"
1. JSON (JavaScript Object notation) is a lightweight data interchange format. Easy for people to read and write. It is also easy to machine parse and generate. It is based on JavaScript programming Language, Standard ECMA-262 a subset of 3rd Edition-december 1999. JSON uses a completely language-independent text format, but it also uses a family of C-language (c, C + +, C #, Java, JavaScript, Perl, Python, and so on). These features make JSON an ideal data exchange language. JSON is constructed of two data types:
(1) A collection of name/value pairs (A collection of name/value pairs). In different languages, it is understood as objects (object), records (record), structure (struct), dictionaries (dictionary), hash tables (hash table), a list of keys (keyed list), or associative arrays (associative Array).
(2) A sequential list of values (an ordered list of values). In most languages, it is understood as an array.
Reference: http://json.org/json-zh.html
2. Pronunciation: [E:j^ks]. Ajax is "Asynchronous JavaScript and XML" (Asynchronous JavaScript and XML), AJAX is not an acronym, but a noun created by Jesse James Gaiiett, a Web development technology that creates interactive Web applications.
"Address": http://www.cnblogs.com/frank_xl/