Fill in the message address
Now that we've looked at the entities that interact with the message, dissected the message structure, and looked at WCF for several message encoders, let's take a look at how to express the destinations we send in detail. After all, the message is useless unless it can be sent to the recipient. As well as the Postal Service requires a well-formed address structure, service-oriented messaging also requires a well-defined address structure. In this section, we will build our own address structure (SCHEME) to see that it can not be widely applied to all messaging applications and then associate it with the address structure that is used with WCF messages.
Mark address in transit vs. address in message
Service-oriented messages specify the final recipient directly in the message. This is a trivial but very important issue. If the message destination is specified in the message, a complete set of message patterns becomes possible. You will learn more about message patterns in the 3rd Chapter, "Message exchange patterns, topologies, and choreography."
When we insert the address directly into the message, we are preparing for more efficient message handling. Efficiency can refer to many things, in this sense, in contrast to the speed at which messages are created, I am talking about the ease of implementing a more advanced message-sending behavior. It takes time to write an envelope address, and it takes time to serialize the address to the message. In any case, writing addresses to envelopes improves the efficiency of the postal service, and it improves processing efficiency in the serialization of addresses to messages, especially when more advanced messaging behavior is implemented (like message routing and intermediaries).
Specify the final recipient
What type of entry should be put in the address? For the initiator, the address should be able to identify the final recipient of the message. Because the final recipient may host multiple services, we should have a way to be the only area of the final recipient of the service. An address element can also describe the final recipient of the managed service and the service itself. Take a look at the following example:
Http://wintellect.com/OrderService
During the internet period, we know that the address consists of the address of the final recipient and the Access Protocol we can use. Because the big so message is a SOAP message, we need to construct some SOAP messages to convey the message.
We know that SOAP messages contain 3 types of elements: envelopes, message headers and message bodies that contain multiple message blocks. Message envelopes are not a good choice because an envelope element can only appear once. Select only the message headers and message bodies to be candidates. So what about the message body? From our early discussions, we know that the message body is only used by the final message recipient. After the elimination process, the message head can provide us with the logical space containing the address. So what does the message header look like? So how to:
<Envelope>
<Header>
<To>http://wintellect.com/OrderService</To>
</Header>
<Body> …</Body>
</Envelope>
At a higher level, this simple XML structure achieves the purpose of identifying the final recipient and the service we are sending.
Specify the initial sender
It may be useful to include sender information in a message, just like the letter's return address. The sender information is added for 2 purposes: The sender is pointed out for the final recipient, and the sender is indicated for the broker. We have seen URLs that can be used to authenticate messages. So in fact we can use the same structure to identify the sender. Examples are as follows:
<Envelope>
<Header>
<To>http://wintellect.com/ReceiveService</To>
<From>http://wintellect.com/SendService</From>
</Header>
<Body> …</Body>
</Envelope>
Add simple elements to soap to support the source of the message, which can be used both by the mediator and by the final recipient.