Learn from scratch WCF 7 (Message Protocol)

• Message Protocol Overview

Generally, it is enough to use data protocols to define the message architecture.

Sometimes you must precisely control how to map types to soap messages transmitted over the network.

In this case, the most common solution is to insert a custom SOP header.

Another common solution is to define the security attributes of the message header and body, that is, to determine whether to digitally sign and encrypt these elements. Message-style operations provide such control.

A message style operation can have a maximum of one parameter and one return value. Both the parameter and return value types are message types. That is, these two types can be directly serialized into the specified SOP message structure.

It can be any type or message type marked with messagecontractattribute.

• Define message protocols

To define a message protocol for a type (that is, to define the ing between this type and the SOAP envelope), apply messagecontractattribute to this type. then, the messageheaderattribute will be applied to the members of the type to be the SOAP header, and messagebodymemberatti.pdf will be applied to the members of the soap body to be the message.

Messageheaderattribute and messagebodymemberattribute can be applied to all fields, attributes, and events, regardless of whether these fields, attributes, and events are public, private, protected, or internal.

• Use custom types within message protocols

Each separate message header and message body are serialized (converted to XML) using the serialization engine selected for the service protocol used by the message ).

The default serialization engine xmlformatter can be explicitly processed (by using system. runtime. serialization. datacontractattribute) or implicitly processed (by using system. serializableattribute as a primitive type) with any type of Data Protocol

You can use an array of repeated elements in message protocols in two ways. Use messageheaderattribute or messagebodymemberattribute directly on the array, and use messageheaderarrayattribute directly.

• Sign and encrypt the message

Message protocols can indicate whether the message and body should be digitally signed and encrypted.

You can set the system. servicemodel. messagecontractmemberattributre. protectionlevel attribute (property) on the messageheaderattribute and messagebodymemberattribute attributes.

System. net. Security. protectionlevel

None (not encrypted or signed)

Sign (near digital signature)

Encryptandsign (encrypted and digital signature)

The default value is none.

To enable these security functions to work, you must correctly configure the binding and behavior. If these security features are used without proper configuration (for example, attempting to sign a message without providing creden), an exception is thrown during verification.

For each message header, the protection level is determined for each message header.

For the message body, the protection level can be understood as "minimum protection level ". The body has only one protection level, regardless of the body. The protection level of the body is determined by the highest protectionlevel attribute of all body parts. However, you should set the protection level of each body part to the minimum protection level actually required

• Name and namespace of the control header and body

In the soap representation of message protocols, each header and body are mapped to an XML element with a name and namespace. You can change these default values by operating system. servicemodel. messagecontractmemberattribute. Name and system. servicemodel. messagecontractmemberattribute. namespace (on the parent class of messageheaderattribute and messagebodymemberattribute ).

• Controls whether to wrap the soap body

By default, the soap body is serialized inside the packaging element.

To unwrap the elements, set iswrapped comfort to false.

To control the name and namespace of the packaging element, use the wrappername and wrappernamespace attributes.

• SOAP header attributes

The soap standard defines the following attributes that can be stored on the header:

Actor/role (set to actor in soap1.1 and role in soap1.2) specifies the Uniform Resource Identifier of the node to use the given Header

Mustunderstand specifies whether the node of the vinegar chestnut header must understand this Header

Relay specifies the large downstream node to relay the header

WCF does not process these attributes of the incoming message (except mustunderstand)

Set these attributes to any required values in static mode.

You can also useCodeDynamically control these attributes

If both the dynamic and static control mechanisms are used, the static settings are used as the default settings, but can be rewritten later using the dynamic mechanism.

• Sequence of soap body parts

By default, the body elements are alphabetically ordered.

The system. servicemodel. messagebodymemberattribute. Order attribute can be used for control.

In message protocols, the base type body members are not arranged before the derived type body members.

• Message Protocol Version Management

Change Message Protocol

ApplicationProgramThe new version may add additional headers to messages. When sending messages from a new application to an earlier application, the system must process additional headers. Similarly, when operating in the opposite direction, the system must process missing headers.

The following rules apply to header version management:

WCF does not oppose the lack of headers. The corresponding members retain their default values.

The exception of this rule is that the mustunderstand attribute of the additional header is set to true in the incoming SOAP message. in this case, an exception is thrown because a header cannot be processed but must be understood.

The message body has similar version management rules, that is, the missing and appended message body parts are ignored.

Performance Considerations

Each message header and message body are serialized independently. Therefore, you can re-declare the same namespace for each header and body. To improve performance, especially for the size of messages on the network, combine multiple headers and body parts into one header or body part.