"WCF Technology Insider" Translation 8:1th Part _ 2nd Chapter _ Service-oriented: message profiling, message transmission

Message Profiling

As a child, we learned that stamps should be affixed to the upper right corner of the envelope, and the address should be in the middle. If we want, we can add a reply address in the upper left corner of the envelope. All processed letters must adhere to this basic structure. If the format is not correct, or the address is unclear, or the address is not valid, the postal service will consider the message invalid and cannot deliver. If we are lucky, the mail will be returned (if the address is written). You can imagine how confusing it is not to write an address. If the sender can allow a stamp or address to be misplaced, the postal service needs to check the entire envelope to determine the stamp and address. It is likely that, in order to complete the new delivery task, each time may increase the postage of far more than 2 cents. In fact, the envelope structure defined by the Post Office, from the sender's point of view, improves the efficiency and consistency of the letter processing without sacrificing availability.

Contrary to the example of mailing letters, so messages do not need to be in compliance with structural patterns. Like mailing letter examples, a well-defined envelope format improves productivity, reliability, and system functionality. Remember that the message application system concept is not new. Messages originating from a variety of different vendors have been in the development of applications for decades. Without a standard structure, each vendor can develop its own message architecture, with the result that these disparate message architectures cannot be used for interoperability between systems.

If we look at the FedEx, UPS, and DHL companies, we can see a similar pattern. Each organization has defined their own address formats and packaging specifications. It's hard to see a overnight parcel with UPS tags posted in fedex. Technically feasible, but business pressures and efficiencies hinder the company's address format and packaging standards for another company.

Using the same concept to test the computing system of a buy-out enterprise is not a pain. In general, vendors do not want their application systems to interact with other systems. They have enough time to make their systems communicate with individual devices and interoperate with other systems alone. In the past, customers wanted to, to some extent, use a vendor's toolset to address their corporate needs. The choice customers face is "who can sell me a complete package like this?" "Instead of" that product is best for my every need? ”。 With the development of society, one-stop sales can hardly meet the potential customers. As a result, software vendors have to sit together to set up a set of public-message specifications and standards that allow their application to generate messages that comply with these specifications. It has taken years for these standards to resume and pass, but ultimately these standards are born, and we can hope that these standards are becoming more perfect.

There are many articles about the standard of the message, and we can refer to these standards many times in reading this book. These specifications are that, in either case, many are based on soap, and each specification has different roles. For the sake of learning curiosity, the complete SOAP message specification can be viewed here: http://www.w3.org/TR/soap12-part1/. Because of the flexibility of soap, the message for the so message is now a SOAP message. SOAP, at its core, is an xml-based message structure. SOAP defines 3 main XML elements that can define arbitrary XML messages: envelopes, message bodies, and message headers. Here is an example of a simple SOAP message:

<?xml　version='1.0'　?>
<env:Envelope　xmlns:env="http://www.w3.org/2003/05/soap- envelope">
<env:Header>

　　　　　 </env:Header>
　 <env:Body>

　 </env:Body>
</env:Envelope>

Because WCF is a platform for interoperability with other systems, it sends, accepts, and processes SOAP messages. As you will see in the 4th Chapter: "WCF101," we can assume that WCF is a toolkit that can create, send, and parse messages in countless behaviors. For now, we can figure out what all the SOAP messages have in common.

Message Envelope

As the name implies, the message envelope wraps the message body and message headers. All SOAP messages have a message envelope as the root element. Message envelopes are often used to define different namespaces (and prefixes) that run through the message. This is exciting for SOAP messages.