MessagingprotokolleMessaging Protocols

Der Windows Communication Foundation (WCF)-Kanalstapel wendet Codierungs- und Transportkanäle interne nachrichtendarstellung in Übertragungsformat und ihn über einen bestimmten Transport zu senden.The Windows Communication Foundation (WCF) channel stack employs encoding and transport channels to transform internal message representation into its wire format and send it by using a particular transport. Der am häufigsten verwendete Transport, der für die Interoperabilität bei Webdiensten verwendet wird, ist HTTP, und die am häufigsten von Webdiensten verwendeten Codierungen sind das XML-basierte SOAP 1.1, SOAP 1.2 und der Message Transmission Optimization Mechanism (MTOM).The most common transport used for Web services interoperability is HTTP, and the most common encodings used by Web services are XML-based SOAP 1.1, SOAP 1.2, and Message Transmission Optimization Mechanism (MTOM).

Dieses Thema enthält Details zur WCF-Implementierung für die folgenden Protokolle, die vom Anwender verwendete HttpTransportBindingElement.This topic covers WCF implementation details for the following protocols employed by HttpTransportBindingElement.

Spezifikation/DokumentSpecification/document LinkLink
HTTP 1.1HTTP 1.1 http://www.ietf.org/rfc/rfc2616.txt
SOAP 1.1 HTTP-BindungSOAP 1.1 HTTP Binding http://www.w3.org/TR/2000/NOTE-SOAP-20000508/, Abschnitt 7http://www.w3.org/TR/2000/NOTE-SOAP-20000508/, Section 7
SOAP 1,2 HTTP-BindungSOAP 1.2 HTTP Binding http://www.w3.org/TR/soap12-part2/, Abschnitt 7http://www.w3.org/TR/soap12-part2/, Section 7

Dieses Thema enthält Details zur WCF-Implementierung für die folgenden Protokolle TextMessageEncodingBindingElement und MtomMessageEncodingBindingElement einsetzen.This topic covers WCF implementation details for the following protocols that TextMessageEncodingBindingElement and MtomMessageEncodingBindingElement employ.

Spezifikation/DokumentSpecification/Document LinkLink
XMLXML http://www.w3.org/TR/REC-xml
SOAP 1,1SOAP 1.1 http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
SOAP 1.2 CoreSOAP 1.2 Core http://www.w3.org/TR/soap12-part1/
WS-Adressierung 2004/08WS-Addressing 2004/08 http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
W3C Web Services Addressing 1.0 - CoreW3C Web Services Addressing 1.0 - Core http://www.w3.org/TR/2006/REC-ws-addr-core-20060509
W3C Web Services Addressing 1.0 - SOAP-BindungW3C Web Services Addressing 1.0 - SOAP Binding http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509
W3C Web Services Addressing 1.0 - WSDL-BindungW3C Web Services Addressing 1.0 - WSDL Binding http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/
W3C Web Services Addressing 1.0 - MetadatenW3C Web Services Addressing 1.0 - Metadata http://www.w3.org/TR/ws-addr-metadata/
WSDL SOAP1.1-BindungWSDL SOAP1.1 Binding http://www.w3.org/TR/wsdl/
WSDL SOAP1.2-BindungWSDL SOAP1.2 Binding http://www.w3.org/Submission/wsdl11soap12/

Dieses Thema enthält Details zur WCF-Implementierung für die folgenden Protokolle MtomMessageEncodingBindingElement verwendet.This topic covers WCF implementation details for the following protocols that MtomMessageEncodingBindingElement employs.

Spezifikation/DokumentSpecification/document LinkLink
XOPXOP http://www.w3.org/TR/xop10/
MTOM + SOAP 1.2-BindungMTOM + SOAP 1.2 Binding http://www.w3.org/TR/soap12-mtom/
MTOM SOAP 1.1-BindungMTOM SOAP 1.1 Binding http://www.w3.org/Submission/soap11mtom10/
MTOM WS-RichtlinienassertionMTOM WS-Policy Assertion http://www.w3.org/Submission/2006/SUBM-WS-MTOMPolicy-20061101/http://www.w3.org/Submission/2006/SUBM-WS-MTOMPolicy-20061101/.

Die folgenden XML-Namespaces und zugeordneten Präfixe werden überall in diesem Thema verwendet.The following XML namespaces and associated prefixes are used throughout this topic.

PräfixPrefix Namespace Uniform Resource Identifier (URI)Namespace Uniform Resource Identifier (URI)
s11s11 http://schemas.xmlsoap.org/soap/envelope
s12s12 http://www.w3.org/2003/05/soap-envelope
wsawsa http://www.w3.org/2004/08/addressing
wsamwsam http://www.w3.org/2007/05/addressing/metadata
wsapwsap http://schemas.xmlsoap.org/ws/2004/09/policy/addressing
wsa10wsa10 http://www.w3.org/2005/08/addressing
wsaw10wsaw10 http://www.w3.org/2006/05/addressing/wsdl
xopxop http://www.w3.org/2004/08/xop/include
xmimexmime http://www.w3.org/2004/06/xmlmime

http://www.w3.org/2005/05/xmlmime
dpdp http://schemas.microsoft.com/net/2006/06/duplex

SOAP 1.1 und SOAP 1.2SOAP 1.1 and SOAP 1.2

Umschlag und VerarbeitungsmodellEnvelope and Processing Model

WCF implementiert SOAP 1.1-umschlagsverarbeitung, die nach der Basic Profile 1.1 (BP11) und Basic Profile 1.0 (SSBP10).WCF implements SOAP 1.1 envelope processing following Basic Profile 1.1 (BP11) and Basic Profile 1.0 (SSBP10). SOAP 1.2-Umschlagsverarbeitung wird unter Befolgung von SOAP12-Part1 implementiert.SOAP 1.2 Envelope processing is implemented following SOAP12-Part1.

Dieser Abschnitt erklärt bestimmte, die vom WCF im Hinblick auf BP11 und SOAP12-Part1 ausgeführt.This section explains certain implementation choices taken by WCF with regard to BP11 and SOAP12-Part1.

Erforderliche HeaderverarbeitungMandatory Header Processing

WCF folgt den Regeln für die Header verarbeitet markiert mustUnderstand SOAP 1.1 und SOAP 1.2-Spezifikationen mit den folgenden Variationen beschrieben.WCF follows rules for processing headers marked mustUnderstand described in the SOAP 1.1 and SOAP 1.2 specifications, with the following variations.

Eine Nachricht, die WCF-Kanalstapel eingibt, wird von einzelnen Kanälen, die durch zugeordnete Bindungselemente konfiguriert, z. B., Textnachrichtencodierung, Sicherheit, zuverlässiges Messaging und Transaktionen verarbeitet.A message that enters the WCF channel stack is processed by individual channels configured by associated binding elements, for example, Text Message Encoding, Security, Reliable Messaging, and Transactions. Jeder Kanal erkennt Header des zugeordneten Namespace, und kennzeichnet sie als verstanden.Each channel recognizes headers from the associated namespace and marks them as understood. Sobald eine Nachricht in den Verteiler eingeht, liest der Vorgangsformatierer Header, die vom entsprechenden Nachrichten-/Vorgangsvertrag erwartet werden, und kennzeichnet sie als verstanden.Once a message enters the dispatcher, the operation formatter reads headers expected by the corresponding message/operation contract and marks them understood. Der Verteiler überprüft, ob einige der verbleibenden Header nicht verstanden, aber als mustUnderstand gekennzeichnet sind, und löst eine Ausnahme aus.Then the dispatcher verifies whether any remaining headers are not understood but marked as mustUnderstand and throws an exception. Nachrichten, die an den Empfänger gerichtete mustUnderstand-Header enthalten, werden nicht vom Empfängeranwendungscode verarbeitet.Messages that contain mustUnderstand headers that are targeted at the recipient are not processed by recipient application code.

Eine derartige schichtweise Verarbeitung lässt eine Trennung zwischen den Infrastrukturschichten und Anwendungsschichten auf dem SOAP-Knoten zu:Such layered processing allows for separation between infrastructure layers and application layers of the SOAP node:

  • B1111: Header, die nicht verstanden werden, werden nach der Verarbeitung der Nachrichteninhalts durch die WCF-infrastrukturkanalstapel, aber bevor er von der Anwendung verarbeitet wird erkanntB1111: Headers that are not understood are detected after the message is processed by the WCF infrastructure channel stack, but before it is processed by application

    Der mustUnderstand Headerwert variiert zwischen SOAP 1.1 und SOAP 1.2.The mustUnderstand header value differs between SOAP 1.1 and SOAP 1.2. Basic Profile 1.1 erfordert, dass der mustUnderstand-Wert für SOAP 1.1-Nachrichten "0" (null) oder "1" sein muss.Basic Profile 1.1 requires that the mustUnderstand value be 0 or 1 for SOAP 1.1 messages. SOAP 1.2 lässt 0 (null), 1 false und true als Werte zu, empfiehlt aber die Ausgabe einer standardisierten Darstellung der xs:boolean-Werte (false, true).SOAP 1.2 allows 0, 1, false, and true as values, but recommends emitting a canonical representation of xs:boolean values (false, true).

  • B1112: WCF ausgibt mustUnderstand Werte 0 und 1 für SOAP 1.1 und SOAP 1.2-Versionen der SOAP-Umschlags.B1112: WCF emits mustUnderstand values 0 and 1 for both SOAP 1.1 and SOAP 1.2 versions of the SOAP envelope. WCF akzeptiert den gesamten Wertebereich von xs:boolean für die mustUnderstand Header (0, 1, false, true)WCF accepts the entire value space of xs:boolean for the mustUnderstand header (0, 1, false, true)

SOAP-FehlerSOAP Faults

Im folgenden finden eine Liste der WCF-spezifische SOAP-Fehler-Implementierungen.The following is a list of WCF-specific SOAP fault implementations.

  • B2121: WCF gibt die folgenden SOAP 1.1-Fehlercodes: s11:mustUnderstand, s11:Client, und s11:Server.B2121: WCF returns the following SOAP 1.1 Fault Codes: s11:mustUnderstand, s11:Client, and s11:Server.

  • B2122: WCF gibt die folgenden SOAP 1.2-Fehlercodes: s12:MustUnderstand, s12:Sender, und s12:Receiver.B2122: WCF returns the following SOAP 1.2 Fault Codes: s12:MustUnderstand, s12:Sender, and s12:Receiver.

HTTP-BindungHTTP Binding

SOAP 1.1 HTTP-BindungSOAP 1.1 HTTP Binding

WCF implementiert die SOAP1. 1 HTTP-Bindung gemäß der Basic Profile 1.1-Spezifikation, Abschnitt 3.4 mit den folgenden Erklärungen:WCF implements SOAP1.1 HTTP binding following the Basic Profile 1.1 specification section 3.4 with the following clarifications:

  • B2211: WCF-Dienst implementiert keine Umleitung von HTTP POST-Anforderungen.B2211: WCF service does not implement redirection of HTTP POST requests.

  • B2212: WCF-Clients unterstützen HTTP-Cookies in Übereinstimmung mit 3.4.8.B2212: WCF clients support HTTP Cookies in accordance with 3.4.8.

SOAP 1,2 HTTP-BindungSOAP 1.2 HTTP Binding

WCF implementiert SOAP 1.2 http-Bindung gemäß der in der SOAP 1.2-Teil 2 (SOAP12Part2) Spezifikation mit den folgenden Erklärungen.WCF implements SOAP 1.2 HTTP binding as described in the SOAP 1.2-part 2 (SOAP12Part2) specification with the following clarifications.

SOAP 1.2 hat einen optionalen Aktionsparameter für den application/soap+xml-Medientyp eingeführt.SOAP 1.2 introduced an optional action parameter for the application/soap+xml media type. Dieser Parameter ist nützlich bei der Optimierung des Sendens von Nachrichten, ohne dass der Text der SOAP-Nachricht analysiert werden muss, wenn die WS-Adressierung nicht verwendet wird.This parameter is useful to optimize message dispatch without requiring that the body of the SOAP message be parsed when WS-Addressing is not used.

  • R2221: Der application/soap+xml-Aktionsparameter muss, wenn er in einer SOAP 1.2-Anforderung vorliegt, dem Attribut soapAction auf dem Element wsoap12:operation in der dazugehörigen WSDL-Bindung entsprechen.R2221: The application/soap+xml action parameter, when present on a SOAP 1.2 request, must match the soapAction attribute on the wsoap12:operation element inside the corresponding WSDL binding.

  • R2222: Der application/soap+xml-Anwendungsparameter muss, wenn er in einer SOAP 1.2-Nachricht vorliegt, wsa:Action entsprechen, wenn die WS-Adressierung 2004/08 oder die WS-Adressierung 1.0 verwendet wird.R2222: The application/soap+xml action parameter, when present on a SOAP 1.2 message, must match wsa:Action when WS-Addressing 2004/08 or WS-Addressing 1.0 are used.

Wenn die WS-Adressierung deaktiviert ist und eine eingehende Anforderung keinen Aktionsparameter enthält, gilt die Nachrichten-Action als nicht angegeben.When WS-Addressing is disabled and an incoming request does not contain an action parameter, message Action is considered not specified.

WS-AdressierungWS-Addressing

WCF implementiert 3 Versionen der WS-Adressierung:WCF implements 3 versions of WS-Addressing:

  • WS-Adressierung 2004/08WS-Addressing 2004/08

  • W3C Web Services Addressing 1.0 Core (ADDR10-KERN) und SOAP-Bindung (ADDR10-SOAP)W3C Web Services Addressing 1.0 Core (ADDR10-CORE) and SOAP Binding (ADDR10-SOAP)

  • WS-Addressing 1.0 - MetadataWS-Addressing 1.0 - Metadata

EndpunktverweiseEndpoint References

Alle Versionen, die WCF implementiert WS-Adressierung verwenden Endpunktverweise um Endpunkte zu beschreiben.All versions of WS-Addressing that WCF implements use endpoint references to describe endpoints.

Endpunktverweise und WS-AdressierungsversionenEndpoint References and WS-Addressing Versions

WCF implementiert eine Zahl, der Infrastructure-Protokolle, die WS-Adressierung verwenden, insbesondere die EndpointReference Element und W3C.WsAddressing.EndpointReferenceType -Klasse (z. B. WS-ReliableMessaging, WS-SecureConversation und WS-Trust).WCF implements a number of the infrastructure protocols that use WS-Addressing and in particular the EndpointReference element and W3C.WsAddressing.EndpointReferenceType class (for example, WS-ReliableMessaging, WS-SecureConversation, and WS-Trust). WCF unterstützt die Verwendung beider Versionen der WS-Adressierung mit anderen infrastrukturprotokollen.WCF supports the use of either version of WS-Addressing with other infrastructure protocols. WCF-Endpunkte unterstützen eine Version der WS-Adressierung pro Endpunkt.WCF endpoints support one version of WS-Addressing per endpoint.

Für R3111, den Namespace für die EndpointReference Element- oder im Nachrichtenaustausch mit einem WCF-Endpunkt verwendete Datentyp muss der Version der WS-Adressierung von diesem Endpunkt implementierten entsprechen.For R3111, the namespace for the EndpointReference element or type used in messages exchanged with a WCF endpoint must match the version of WS-Addressing implemented by this endpoint.

Z. B. wenn ein WCF-Endpunkt WS-ReliableMessaging implementiert die AcksTo Header, die innerhalb eines solchen Endpunkts zurückgegebenes CreateSequenceResponse Version der WS-Adressierung verwendet, die EncodingBinding Element für diesen Endpunkt angibt.For example, if a WCF endpoint implements WS-ReliableMessaging, the AcksTo header returned by such an endpoint inside CreateSequenceResponse uses the WS-Addressing version that the EncodingBinding element specifies for this endpoint.

Endpunktverweise und MetadatenEndpoint References and Metadata

Eine Anzahl von Szenarien erfordert kommunizierende Metadaten oder einen Verweis auf Metadaten für einen bestimmten Endpunkt.A number of scenarios require communicating metadata or a reference to metadata for a given endpoint.

B3121: WCF wendet Mechanismen, die in der WS-MetadataExchange (MEX)-Spezifikation, Abschnitt 6, um Metadaten für Endpunktverweise nach Wert oder Verweis aufzunehmen beschrieben.B3121: WCF employs mechanisms described in the WS-MetadataExchange (MEX) specification Section 6 to include metadata for endpoint references by value or by reference.

Betrachten Sie ein Szenario, in denen ein WCF-Dienst erfordert Authentifizierung mit einem Security Assertions Markup Language (SAML) Token ausgestellt vom Tokenaussteller unter http://sts.fabrikam123.com.Consider a scenario where a WCF service requires authentication using a Security Assertions Markup Language (SAML) token issued by the token issuer at http://sts.fabrikam123.com. Der WCF-Endpunkt beschreibt diese Authentifizierungsanforderung mit sp:IssuedToken Assertion mit einer verschachtelten sp:Issuer -Assertion verwendet, auf den Tokenaussteller hinweist.The WCF endpoint describes this authentication requirement by using sp:IssuedToken assertion with a nested sp:Issuer assertion pointing to the token issuer. Clientanwendungen, die auf die sp:Issuer-Assertion zugreifen, müssen mit dem Tokenausstellerendpunkt kommunizieren können.Client applications that access the sp:Issuer assertion need to know how to communicate with the token issuer endpoint. Der Client muss Metadaten über den Tokenaussteller kennen.The client needs to know metadata about the token issuer. Verwenden die in MEX definiert sind Erweiterungen für endpunktverweismetadaten, bietet WCF einen Verweis auf die tokenausstellermetadaten.Using the endpoint reference metadata extensions defined in MEX, WCF provides a reference to the token issuer metadata.

<sp:IssuedToken>  
  <sp:Issuer>  
    <wsa10:Address>  
      http://sts.fabrikam123.com  
    </wsa10:Address>  
    <wsa10:Metadata>  
      <mex:Metadata>  
        <mex:MetadataSection>  
          <mex:MetadataReference>  
            <wsa10:Address>  
              http://sts.fabrikam123.com/mex  
            </wsa10:Address>  
          </mex:MetadataReference>  
        </mex:MetadataSection>  
      </mex:Metadata>  
    </wsa10:Metadata>  
  </sp:Issuer>  
</sp:IssuedToken>  

NachrichtenadressierungsheaderMessage Addressing Headers

NachrichtenheaderMessage Headers

Für beide Versionen der WS-Adressierung verwendet WCF die folgenden Nachrichtenheader gemäß den Spezifikationen wsa:To, wsa:ReplyTo, wsa:Action, wsa:MessageID, und wsa:RelatesTo.For both WS-Addressing versions, WCF uses the following message headers as prescribed by the specifications wsa:To, wsa:ReplyTo, wsa:Action, wsa:MessageID,and wsa:RelatesTo.

B3211: Für alle Versionen, die WS-Adressierung, WCF berücksichtigt, aber nicht ausgegeben, WS-Adressierungs-Nachrichtenheader wsa:FaultTo und wsa:From.B3211: For all WS-Addressing versions, WCF honors, but does not produce out of the box, WS-Addressing message headers wsa:FaultTo and wsa:From.

Anwendungen, die Interaktion mit WCF-Anwendungen können diese Nachrichtenheader und WCF entsprechend verarbeiten wird hinzufügen.Applications that interact with WCF applications can add these message headers and WCF will process them accordingly.

Verweisparameter und -eigenschaftenReference Parameters and Properties

WCF implementiert die Verarbeitung von endpunktverweisparametern und Endpunkt VerweisparameterWCF implements processing of endpoint reference parameters and reference p

Verweiseigenschaften in Übereinstimmung mit den jeweiligen Spezifikationen.roperties in accordance with respective specifications.

B3221: Wenn für die Verwendung von WS-Adressierung 2004/08 konfiguriert, werden WCF-Endpunkten nicht unterschieden zwischen der Verarbeitung von Verweiseigenschaften und Verweisparametern.B3221: When configured to use WS-Addressing 2004/08, WCF endpoints do not differentiate between processing Reference Properties and Reference Parameters.

NachrichtenaustauschmusterMessage Exchange Patterns

Die Abfolge von Meldungen Beteiligten die Webdienstvorgangs wird als bezeichnet den Nachrichtenaustauschmuster.The sequence of messages involved in the Web service operation invocation is referred to as the message exchange pattern. WCF unterstützt unidirektionale, Anforderung / Antwort- und duplexnachrichten-austauschmuster.WCF supports one-way, request-reply, and duplex message exchange patterns. Dieser Abschnitt klärt die WS-Adressierungsanforderungen während der Nachrichtenverarbeitung, die vom verwendeten Nachrichtenaustauschmuster abhängig sind.This section clarifies WS-Addressing requirements on message processing depending on the message exchange pattern being used.

Überall in diesem Abschnitt sendet der Anforderungsdienst die erste Nachricht, und der Antwortdienst empfängt die erste Nachricht.Throughout this section, the requester sends the first message and the responder receives the first message.

Unidirektionale NachrichtOne-Way Message

Wenn ein WCF-Endpunkt konfiguriert ist, zur Unterstützung von Nachrichten mit einer bestimmten Action um ein unidirektionales Muster befolgen, befolgt der WCF-Endpunkt die folgenden Verhalten und Anforderungen.When a WCF endpoint is configured to support messages with a given Action to follow a one-way pattern, the WCF endpoint follows the following behaviors and requirements. Sofern nicht anders angegeben, gelten Verhalten und Regeln für beide Versionen der WS-Adressierung in WCF unterstützt:Unless otherwise specified, behaviors and rules apply for both versions of WS-Addressing supported in WCF:

  • R3311: Der Anforderungsdienst muss wsa:To, wsa:Action und Header für alle Verweisparameter, die vom Endpunktverweis angegeben werden, enthalten.R3311: The requester must include wsa:To, wsa:Action, and headers for all reference parameters specified by the endpoint reference. Wenn die WS-Adressierung 2004/08 verwendet wird und [Verweiseigenschaften] vom Endpunktverweis angegeben werden, müssen auch die entsprechenden Header der Nachricht hinzugefügt werden.When WS-Addressing 2004/08 is used and [reference properties] are specified by the endpoint reference, the corresponding headers must be added to the message too.

  • B3312: Der Anforderungsdienst kann MessageID-, ReplyTo- und FaultTo-Header enthalten.B3312: The requester may include MessageID, ReplyTo, and FaultTo headers. Die Empfängerinfrastruktur ignoriert sie, und sie werden an die Anwendung übergeben.The receiver infrastructure will ignore them, and they will be passed to the application.

  • R3313: Wenn HTTP verwendet wird und keine Nachricht an den HTTP-Antwortzweig gesendet wird, muss der Antwortdienst eine HTTP-Antwort ohne Text und mit einem HTTP 202-Statuscode senden.R3313: When HTTP is used and no message is being sent on the HTTP response leg, the responder must send an HTTP response with an empty body and an HTTP 202 status code.

    Wenn die HTTP-Transportmethode verwendet wird und der Vorgangsvertrag eine Nachricht als unidirektional ausweist, kann die HTTP-Antwort immer noch zum Senden von Infrastrukturnachrichten verwendet werden – Reliable Messaging kann beispielsweise eine SequenceAcknowledgement-Nachricht in einer HTTP-Antwort senden.When the HTTP transport is in use and the operation contract declares a message one-way, the HTTP response can still be used for sending infrastructure messages—for example, reliable messaging can send a SequenceAcknowledgement message on an HTTP response.

  • B3314: Der WCF-Beantworter sendet keine Fehlermeldung als Antwort auf eine unidirektionale Nachricht.B3314: The WCF responder does not send a fault message in response to a one-way message.

Anforderung-AntwortRequest-Reply

Wenn ein WCF-Endpunkt konfiguriert ist, für eine Nachricht mit einer angegebenen Action zum Durchführen der Anforderung-Antwort-Muster folgt der WCF-Endpunkt die Verhalten und Anforderungen, die weiter unten.When a WCF endpoint is configured for a message with a given Action to follow the request-reply pattern, the WCF endpoint follows the behaviors and requirements below. Sofern nicht anders angegeben, gelten Verhalten und Regeln für beide Versionen der WS-Adressierung in WCF unterstützt:Unless specified otherwise, behaviors and rules apply for both versions of WS-Addressing supported in WCF:

  • R3321: Der anforderungsdienst muss in der Anforderung enthalten wsa:To, wsa:Action, wsa:MessageID, und der Header für alle Verweisparameter oder Verweis Eigenschaften (oder beides) vom Endpunktverweis angegeben.R3321: The requester must include in the request wsa:To, wsa:Action, wsa:MessageID, and headers for all reference parameters or reference properties (or both) specified by the endpoint reference.

  • R3322: Wenn die WS-Adressierung 2004/08 verwendet wird, muss ReplyTo auch in der Anforderung enthalten sein.R3322: When WS-Addressing 2004/08 is used, ReplyTo must also be included in the request.

  • R3323: Wenn WS-Adressierung 1.0 verwendet wird und ReplyTo ist nicht vorhanden, in der Anforderung, ein standardendpunktverweis, mit dem [Adresse]-Eigenschaft gleich "http://www.w3.org/2005/08/addressing/anonymous" verwendet wird.R3323: When WS-Addressing 1.0 is used and ReplyTo is not present in the request, a default endpoint reference with the [address] property equal to "http://www.w3.org/2005/08/addressing/anonymous" is used.

  • R3324: Der anforderungsdienst muss enthalten wsa:To, wsa:Action, und wsa:RelatesTo Header in der Antwortnachricht als auch Header für alle Verweisparameter oder Verweis Eigenschaften (oder beides) gemäß der ReplyTo -Endpunktverweis in der Anforderung.R3324: The requester must include wsa:To, wsa:Action, and wsa:RelatesTo headers in the reply message, as well as headers for all reference parameters or reference properties (or both) specified by the ReplyTo endpoint reference in the request.

Fehler bei Web Services AddressingWeb Services Addressing Faults

R3411: WCF erzeugt die folgende von WS-Adressierung 2004/08 definierten Fehler.R3411: WCF produces the following faults defined by WS-Addressing 2004/08.

CodeCode UrsacheCause
wsa:DestinationUnreachablewsa:DestinationUnreachable Die Nachricht ist mit ReplyTo angekommen, das sich von der Antwortadresse, die für diesen Kanal festgelegt ist, unterscheidet; für die in der To-Headerzeile angegebene Adresse gibt es kein Endpunkt-Listening.The message arrived with a ReplyTo that is different from the reply address established for this channel; there is no endpoint listening at the address specified in the To header.
wsa:ActionNotSupportedwsa:ActionNotSupported Die Infrastrukturkanäle und -verteiler, die mit dem Endpunkt verbunden sind, erkennen die Aktion, die in der Headerzeile Action angegeben ist, nicht.the infrastructure channels or dispatcher associated with the endpoint do not recognize the action specified in the Action header.

R3412: WCF erzeugt die folgende von WS-Adressierung 1.0 definierten Fehler.R3412: WCF produces the following faults defined by WS-Addressing 1.0.

CodeCode UrsacheCause
wsa10:InvalidAddressingHeaderwsa10:InvalidAddressingHeader Doppelte wsa:To, wsa:ReplyTo, wsa:From oder wsa:MessageID.Duplicate wsa:To, wsa:ReplyTo, wsa:From or wsa:MessageID. Doppelte wsa:RelatesTo mit dem gleichen RelationshipType.Duplicate wsa:RelatesTo with the same RelationshipType.
wsa10:MessageAddressingHeaderRequiredwsa10:MessageAddressingHeaderRequired Der erforderliche Adressierungsheader fehlt.The required Addressing header is missing.
wsa10:DestinationUnreachablewsa10:DestinationUnreachable Die Nachricht ist mit ReplyTo angekommen, das sich von der Antwortadresse, die für diesen Kanal eingeführt wurde, unterscheidet.The message arrived with a ReplyTo that is different from the reply address established for this channel. An der Adresse, die im To-Header angegeben ist, gibt es kein Endpunkt-Listening.There is no endpoint listening at the address specified in the To header.
wsa10:ActionNotSupportedwsa10:ActionNotSupported Eine Aktion, die im Action-Header angegeben ist, wird von den Infrastrukturkanälen oder dem Verteiler, die/der mit dem Endpunkt verbunden sind/ist, nicht erkannt.An action specified in the Action header is not recognized by the infrastructure channels or dispatcher associated with the endpoint.
wsa10:EndpointUnavailablewsa10:EndpointUnavailable Der RM-Kanal schickt diesen Fehler zurück und gibt an, dass der Endpunkt die Sequenz basierend auf einer Untersuchung der Adressheader der Nachricht CreateSequence nicht verarbeiten wird.The RM channel sends this fault back, indicating the endpoint will not process the sequence based upon examination of the CreateSequence message’s addressing headers.

Code in den vorangehenden Tabellen wird auf FaultCode in SOAP 1.1 und SubCode (mit Code=Sender) in SOAP 1.2 abgebildet.Code in the preceding tables maps to FaultCode in SOAP 1.1 and SubCode (with Code=Sender) in SOAP 1.2.

WSDL 1.1-Bindung und WS-RichtlinienassertionenWSDL 1.1 Binding and WS-Policy Assertions

Angeben der Verwendung von WS-AdressierungIndicating Use of WS-Addressing

WCF verwendet Richtlinienassertionen, um endpunktunterstützung für eine bestimmte Version von WS-Adressierung anzugeben.WCF uses policy assertions to indicate endpoint support for a particular WS-Addressing version.

Die folgende Richtlinienassertion verfügt über das Endpoint Policy Subject [WS-PA] und gibt an, dass von diesem Endpunkt gesendete und empfangene Nachrichten WS-Adressierung 2004/08 verwenden müssen.The following policy assertion has Endpoint Policy Subject [WS-PA] and indicates messages sent and received from the endpoint must use WS-Addressing 2004/08.

<wsap:UsingAddressing />  

Diese Richtlinienassertion erweitert die Spezifikation zur WS-Adressierung 2004/08.This policy assertion augments the WS-Addressing 2004/08 specification.

Die folgende Richtlinienassertion gibt an, dass gesendete/empfangene Nachrichten die WS-Adressierung 1.0 verwenden müssen.The following policy assertion this indicates that messages sent/received must use WS-Addressing 1.0.

<wsam:Addressing/>   

Die folgende Richtlinienassertion verfügt über ein Endpoint Policy Subject [WS-PA] und gibt an, dass von diesem Endpunkt gesendete und empfangene Nachrichten WS-Adressierung 2004/08 verwenden müssen.The following policy assertion has an Endpoint Policy Subject [WS-PA] and indicates that messages sent and received from the endpoint must use WS-Addressing 2004/08.

<wsaw10:UsingAddressing />  

Das Element wsaw10:UsingAddressing wird aus der [WS-Addressing-WSDL] ausgeliehen und im Kontext von WS-Policy entsprechend der Spezifikation, Abschnitt 3.1.2, verwendet.The wsaw10:UsingAddressing element is borrowed from [WS-Addressing-WSDL] and is used in the context of WS-Policy in compliance with that specification, section 3.1.2.

Die Nutzung von Adressing verwendet nicht die Semantik von WSDL 1.1-, SOAP 1.1- und SOAP 1.2 HTTP-Bindungen.Use of Addressing does not alter the semantics of WSDL 1.1, SOAP 1.1, and SOAP 1.2 HTTP Bindings. Wenn beispielsweise eine Antwort auf eine Anfrage erwartet wird, die an einen Endpunkt gesendet wird, der Addressing und WSDL SOAP 1.x HTTP-Bindung verwendet, muss die Antwort unter Verwendung der HTTP-Antwort gesendet werden.For example, if a reply is expected to a request that is sent to an endpoint that uses Addressing and WSDL SOAP 1.x HTTP binding, the reply must be sent by using the HTTP response.

Die WS-AM-Assertion von Antworten, die über die HTTP-Antwort gesendet werden, ist Folgende:For replies sent over the http response, the WS-AM assertion is:

<wsam:AnonymousResponses/>  

Die vollständige Richtlinienassertion kann wie folgt aussehen:The complete policy assertion might look like this:

<wsam:Addressing>  
    <wsp:Policy>  
        <wsam:AnonymousResponses />   
    </wsp:Policy>  
</wsam:Addressing>  

Es gibt aber Nachrichtenaustauschmuster, die davon profitieren, zwei unabhängige, entgegengesetzte HTTP-Verbindungen zwischen dem Anforderungsdienst und dem Antwortdienst etabliert zu haben, z. B. unaufgeforderte unidirektionale Nachrichten, die vom Antwortdienst gesendet werden.However, there are message exchange patterns that benefit from having two independent converse HTTP connections established between the requester and the responder, for example, unsolicited one-way messages sent by the responder.

WCF bietet es sich um eine Funktion, die über die zwei zugrunde liegende Transportkanäle bilden können Composite Duplex-Kanal, bei dem ein Kanal für eingehende Nachrichten und der andere für ausgehende Nachrichten verwendet wird.WCF offers a feature by which two underlying transport channels can form a Composite Duplex channel, where one channel is used for input messages and the other is used for output messages. Im Fall des HTTP-Transports stellt Composite Duplex zwei umgekehrte HTTP-Verbindungen bereit.In the case of the HTTP Transport, Composite Duplex provides two converse HTTP connections. Der Anforderungsdienst verwendet eine Verbindung, um Nachrichten an den Antwortdienst zu senden, und der Antwortdienst verwendet die andere, um Nachrichten zurück an den Anforderungsdienst zu senden.The requester uses one connection to send messages to the responder, and the responder uses the other to send messages back to the requester.

Die WS-AM-Assertion von Antworten, die über separate HTTP-Anforderungen gesendet werden, ist Folgende:For replies sent over separate http requests, the ws-am assertion is

<wsam:NonAnonymousResponses/>  

Die vollständige Richtlinienassertion kann wie folgt aussehen:The complete policy assertion might look like this:

<wsam:Addressing>  
    <wsp:Policy>  
      <wsam:NonAnonymousResponses />   
   </wsp:Policy>  
  </wsam:Addressing>  

Die Verwendung der folgenden Assertion, die über Endpoint Policy Subject [WS-PA] an Endpunkten verfügt, die WSDL 1.1 SOAP 1.x HTTP-Bindungen verwenden, erfordert zwei einzelne entgegengesetzte HTTP-Verbindungen, die jeweils für den Nachrichtenfluss vom Anforderungsdienst an den Antwortdienst bzw. vom Antwortdienst an den Anforderungsdienst verwendet werden.Use of the following assertion that has Endpoint Policy Subject [WS-PA] on endpoints that use WSDL 1.1 SOAP 1.x HTTP bindings requires two separate converse HTTP connections to be used for messages flowing from requester to responder and responder to requester, respectively.

<cdp:CompositeDuplex/>  

Die vorherige Anweisung führt bei Anforderungsnachrichten zu den folgenden Anforderungen an den wsa:ReplyTo-Header:The previous statement leads to the following requirements on the wsa:ReplyTo header for request messages:

  • R3514: Anforderung an einen Endpunkt gesendete Anforderungsnachrichten müssen eine ReplyTo Header mit den [address] Eigenschaft, die nicht gleich "http://www.w3.org/2005/08/addressing/anonymous" Wenn der Endpunkt eine WSDL 1.1 SOAP 1.x http-Bindung verwendet und über eine richtlinienalternative verfügt eine wsap10:UsingAddressing oder wsap:UsingAddressing Assertion gekoppelt mit cdp:CompositeDuplex angefügt.R3514: Request messages sent to an endpoint must have a ReplyTo header with the [address] property not equal to "http://www.w3.org/2005/08/addressing/anonymous" if the endpoint uses a WSDL 1.1 SOAP 1.x HTTP binding and has a policy alternative with a wsap10:UsingAddressing or wsap:UsingAddressing assertion coupled with cdp:CompositeDuplex attached.

  • R3515: Anforderung an einen Endpunkt gesendete Anforderungsnachrichten müssen eine ReplyTo Header mit den [address] -Eigenschaft gleich "http://www.w3.org/2005/08/addressing/anonymous", oder nicht über eine ReplyTo Header auf "all", wenn der Endpunkt eine WSDL 1.1 SOAP 1.x http-Bindung verwendet und verfügt über eine richtlinienalternative mit wsap10:UsingAddressing -Assertion und keiner cdp:CompositeDuplex -Assertion angehängt.R3515: Request messages sent to an endpoint must have a ReplyTo header with the [address] property equal to "http://www.w3.org/2005/08/addressing/anonymous", or not have a ReplyTo header at all, if the endpoint uses a WSDL 1.1 SOAP 1.x HTTP binding and has a policy alternative with wsap10:UsingAddressing assertion and no cdp:CompositeDuplex assertion attached.

  • R3516: Anforderung an einen Endpunkt gesendete Anforderungsnachrichten müssen eine ReplyTo Header mit einem [address] -Eigenschaft gleich "http://www.w3.org/2005/08/addressing/anonymous" Wenn der Endpunkt eine WSDL 1.1 SOAP 1.x http-Bindung verwendet und über eine richtlinienalternative verfügt wsap:UsingAddressing Assertion und keine cdp:CompositeDuplex-Assertion angehängt.R3516: Request messages sent to an endpoint must have a ReplyTo header with an [address] property equal to "http://www.w3.org/2005/08/addressing/anonymous" if the endpoint uses a WSDL 1.1 SOAP 1.x HTTP binding and has a policy alternative with wsap:UsingAddressing assertion and no cdp:CompositeDuplex assertion attached.

Die WS-Adressierung-WSDL-Spezifikation versucht, ähnliche Protokollbindungen zu beschreiben, indem sie ein <wsaw:Anonymous/>-Element mit drei Textwerten (erforderlich, optional und verboten) einführt, um die Anforderungen im wsa:ReplyTo-Header (Abschnitt 3.2) anzugeben.The WS-addressing WSDL specification attempts to describe similar protocol bindings by introducing an element <wsaw:Anonymous/> with three textual values (required, optional, and prohibited) to indicate requirements on the wsa:ReplyTo header (section 3.2). Leider ist eine derartige Elementdefinition im Kontext einer WS-Richtlinie als Assertion nicht besonders nützlich, da sie domänenspezifische Erweiterungen benötigt, um den Knotenpunkt von Alternativen zu unterstützen, die ein derartiges Element als Assertion verwenden.Unfortunately, such element definition is not particularly usable as an assertion in the context of WS-Policy, because it requires domain-specific extensions to support the intersection of alternatives using such an element as an assertion. Eine derartige Elementdefinition gibt außerdem den Wert des ReplyTo-Headers als Gegenstück zum Endpunktverhalten auf dem Kabel an und macht ihn somit spezifisch für den HTTP-Transport.Such element definition also indicates the value of the ReplyTo header as opposed to the endpoint behavior on the wire, which makes it specific to HTTP transport.

AktionsdefinitionAction Definition

WS-Adressierung 2004/08 definiert ein wsa:Action-Attribut für die wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault]-Elemente.WS-Addressing 2004/08 defines a wsa:Action attribute for the wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] elements. WS-Adressierung 1.0 WSDL-Bindung (WS-ADDR10-WSDL) definiert ein ähnliches Attribut, wsaw10:Action.WS-Addressing 1.0 WSDL Binding (WS-ADDR10-WSDL) defines a similar attribute, wsaw10:Action.

Der einzige Unterschied zwischen den beiden ist die Standardaktionsmustersemantik, die in Abschnitt 3.3.2 von WS-ADDR bzw. Abschnitt 4.4.4 der 4.4.4 von WS-ADDR10-WSDL beschrieben wird.The only difference between the two is the default Action pattern semantics described in section 3.3.2 of WS-ADDR and section 4.4.4 of WS-ADDR10-WSDL, respectively.

Es ist sinnvoll, zwei Endpunkte verfügen, die denselben portType (oder am Vertrag vor, in der WCF-Terminologie), aber mit verschiedenen Versionen der WS-Adressierung.It is a reasonable to have two endpoints that share the same portType (or contract, in WCF terminology) but using different versions of WS-Addressing. Da aber "Aktion" durch den portType definiert wird und sich nicht zwischen den Endpunkten, die den portType implementieren, ändern sollte, ist es unmöglich, beide Standardaktionsmuster zu unterstützen.But given that Action is defined by the portType and should not change across the endpoints that implement the portType, it becomes impossible to support both default action patterns.

Um diese kontroverse zu beheben, WCF unterstützt eine einzelne Version der Action Attribut.To resolve this controversy, WCF supports a single version of the Action attribute.

B3521: WCF verwendet die wsaw10:Action -Attribut wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] Elemente gemäß Definition in WS-ADDR10-WSDL, um zu bestimmen, die Action URI für die entsprechenden Nachrichten unabhängig von der vom Endpunkt verwendeten WS-Adressierungsversion.B3521: WCF uses the wsaw10:Action attribute on wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] elements as defined in WS-ADDR10-WSDL to determine the Action URI for the corresponding messages irrespective of the WS-Addressing version used by the endpoint.

Verwenden des Endpunktverweises im WSDL-AnschlussUse Endpoint Reference Inside WSDL Port

Abschnitt 4.1 von WS-ADDR10-WSDL erweitert das wsdl:port-Element durch das untergeordnete <wsa10:EndpointReference…/>-Element, um den Endpunkt in WS-Adressierungsbegriffen zu beschreiben.WS-ADDR10-WSDL section 4.1 extends the wsdl:port element to include the <wsa10:EndpointReference…/> child element to describe the endpoint in WS-Addressing terms. WCF erweitert dieses Hilfsprogramm in der WS-Adressierung 2004/08, sodass <wsa:EndpointReference…/> als ein untergeordnetes Element von angezeigt werden wsdl:port.WCF expands this utility on WS-Addressing 2004/08, allowing <wsa:EndpointReference…/> to appear as a child element of wsdl:port.

  • R3531: Wenn einem Endpunkt eine Richtlinienalternative mit einer <wsaw10:UsingAddressing/>-Richtlinienassertion angehängt ist, kann das entsprechendewsdl:port-Element ein untergeordnetes Element<wsa10:EndpointReference …/> enthalten.R3531: If an endpoint has an attached policy alternative with a <wsaw10:UsingAddressing/> policy assertion, the corresponding wsdl:port element can contain a child element <wsa10:EndpointReference …/>.

  • R3532: Wenn ein wsdl:port enthält ein untergeordnetes Element <wsa10:EndpointReference …/>, die wsa10:EndpointReference/wsa10:Address untergeordnete Elementwert entsprechen muss von der @address Attribut des nebengeordneten Elements wsdl:port / wsdl:location Element.R3532: If a wsdl:port contains a child element <wsa10:EndpointReference …/>, the wsa10:EndpointReference/wsa10:Address child element value must match the value of the @address attribute of the sibling wsdl:port/wsdl:location element.

  • R3533: Wenn einem Endpunkt eine Richtlinienalternative mit einer <wsap:UsingAddressing/>-Richtlinienassertion angehängt ist, kann das entsprechendewsdl:port-Element ein untergeordnetes Element<wsa:EndpointReference …/> enthalten.R3533: If an endpoint has an attached policy alternative with <wsap:UsingAddressing/> policy assertion, the corresponding wsdl:port element can contain a child element <wsa:EndpointReference …/>.

  • R3534: Wenn ein wsdl:port enthält ein untergeordnetes Element <wsa:EndpointReference …/>, die wsa:EndpointReference/wsa:Address untergeordnete Elementwert entsprechen muss von der @address Attribut des nebengeordneten Elements wsdl:port / wsdl:location Element.R3534: If a wsdl:port contains a child element <wsa:EndpointReference …/>, the wsa:EndpointReference/wsa:Address child element value must match the value of the @address attribute of the sibling wsdl:port/wsdl:location element.

Gestaltung mit WS-SicherheitComposition with WS-Security

Gemäß den Sicherheitsüberlegungsabschnitten in WS-ADDR und WS-ADDR10 wird empfohlen, dass alle adressierenden Header zusammen mit dem Nachrichtentext signiert werden, um sie zusammenzubinden.According to security consideration sections in WS-ADDR and WS-ADDR10, all addressing message headers are recommended to be signed together with the message body to bind them together.

Wenn WS-Sicherheit für den Nachrichtenintegritätsschutz verwendet wird, müssen die WS-Adressierungs-Nachrichtenheader genauso wie die Header, die aus Referenzparametern oder -eigenschaften (oder beidem) entstanden sind, zusammen mit dem Text der Nachricht signiert werden.When WS-Security is used for message integrity protection, WS-Addressing message headers as well as headers resulted from reference parameters or properties (or both) must be signed together with the body of the message.

BeispieleExamples

Unidirektionale NachrichtOne-Way Message

In diesem Szenario sendet der Absender eine unidirektionale Nachricht zum Empfänger.In this scenario, the sender sends a one-way message to the receiver. SOAP 1.2, HTTP 1.1 und W3C WS-Adressierung 1.0 werden verwendet.SOAP 1.2, HTTP 1.1, and W3C WS-Addressing 1.0 are used.

Die Anforderungsnachrichtenstruktur: Zu den Nachrichtenheadern gehören die Elemente wsa10:To und wsa10:Action.The Request Message Structure: The message headers include wsa10:To and wsa10:Action elements. Der Nachrichtentext schließt ein bestimmtes <app:Ping>-Element vom Anwendungsnamespace ein.The message body includes a specific <app:Ping> element from the application namespace.

HTTP-Header: Das Ziel in POST entspricht den URI in die wsa10:To Element.HTTP Headers: The destination in POST matches the URI in the wsa10:To element.

Der Content-Type-Header entspricht dem Wert application/soap+xml, wie von SOAP 1.2 vorausgesetzt.The Content-Type header has the value of application/soap+xml as required by SOAP 1.2. Die Parameter charset und action sind eingeschlossen.Parameters charset and action are included. Der Parameter action des Content-Type-Headers entspricht dem Wert des wsa10:Action-Nachrichtenheaders.The action parameter of the Content-Type header matches the value of the wsa10:Action message header.

POST http://fabrikam123.com/Service HTTP/1.1  
Content-Type: application/soap+xml; charset=utf-8;    
              action="http://fabrikam123.com/Service/OneWay"  
Host: 131.107.72.15  
Content-Length: 1501  
Expect: 100-continue  
Proxy-Connection: Keep-Alive  
<s12:Envelope>  
  <s12:Header>  
    <wsa10:To s12:mustUnderstand="1">  
        http://fabrikam123.com/Service  
    </wsa10:To>  
    <wsa10:Action s12:mustUnderstand="1">  
        http://fabrikam123.com/Service/OneWay   
    </wsa10:Action>  
  </s12:Header>  
  <s12:Body>  
    <Ping xmlns="http://fabrikam123.com/Service/">  
      <Text>Hello World</Text>  
    </Ping>  
  </s12:Body>  
</s12:Envelope>  

Der Empfänger antwortet mit einer leeren HTTP-Antwort und dem Status 202.The receiver responds with an empty HTTP response and status 202. Ein Beispiel für die HTTP-Antwort:An example of the HTTP response:

HTTP/1.1 202 Accepted  
Date: Fri, 15 Jul 2005 08:56:07 GMT  
Server: Microsoft-IIS/6.0  
MicrosoftOfficeWebServer: 5.0_Pub  
X-Powered-By: ASP.NET  
X-AspNet-Version: 2.0.50215  
Cache-Control: private  
Content-Length: 0  

SOAP-Nachrichten-ÜbertragungsoptimierungsmechanismusSOAP Message Transmission Optimization Mechanism

Dieser Abschnitt beschreibt die Details zur WCF-Implementierung für die HTTP-SOAP MTOM.This section describes the WCF implementation details for the HTTP SOAP MTOM. MTOM-Technologie ist SOAP-nachrichtencodierungsmechanismus der gleichen Klasse wie traditionelle Text-/XML-Codierungs- oder WCF-binärcodierung.MTOM technology is SOAP message encoding mechanism of the same class as traditional text/XML encoding or WCF Binary encoding. Zu MTOM gehören folgende Elemente:MTOM includes the following:

  • Ein XML-Codierungs- und Verpackungsmechanismus, der von [XOP] beschrieben wird, und XML-Informationselemente, die base64-codierte Binärdaten enthalten, die in einzelne Binärteile optimiert wurden.An XML encoding and packaging mechanism described by [XOP] that optimizes XML information items containing base64-encoded binary data into separate binary parts.

  • Eine MIME-Kapselung des XOP-Pakets, das das XML-Infoset und jeden Binärteil des XOP-Pakets in einen einzelnen MIME-Teil serialisiert.A MIME encapsulation of the XOP package that serializes the XML Infoset and each binary part of the XOP package into a separate MIME part.

  • Eine MIME-XOP-Codierung, die auf SOAP 1.x Envelope angewendet wird.A MIME XOP encoding applied to SOAP 1.x Envelope.

  • Eine HTTP-Transportbindung.An HTTP transport binding.

Es ist möglich, MTOM mit nicht-HTTP-Transporte mit WCF verwenden.It is possible to use MTOM with non-HTTP transports with WCF. In diesem Thema konzentrieren wir uns jedoch auf HTTP.However, in this topic we will focus on HTTP.

Das MTOM-Format setzt einen großen Satz von Spezifikationen ein, der MTOM selbst, XOP und MIME abdeckt.The MTOM format leverages a large set of specifications covering MTOM itself, XOP, and MIME. Die Modularität dieses Spezifikationssatzes macht es schwierig, die genauen Anforderungen an die Format- und Verarbeitungssemantik zu rekonstruieren.Modularity of this specification set makes it somewhat difficult to reconstruct exact requirements on the format and processing semantics. In diesem Abschnitt werden die Format- und Verarbeitungsanforderungen an MTOM-HTTP-Bindungen beschrieben.This section describes the format and processing requirements for MTOM HTTP binding.

MTOM-NachrichtencodierungMTOM Message Encoding

Generieren von MTOM-NachrichtenGenerating MTOM messages

[XOP] Abschnitt 3.1 beschreibt den Vorgang der Codierung von XML mit Elementinformationselementen, die base24-Werte enthalten, in ein abstrakt definiertes XOP-Paket.The [XOP] section 3.1 describes the process of encoding XML with element information items that contain base64 values into an abstractly defined XOP package.

Die folgende Sequenz von Schritten beschreibt den MTOM-spezifischen Codierungsprozess:The following sequence of steps describes the MTOM-specific encoding process:

  1. Stellen Sie sicher, dass die SOAP-Umschlags zu codierende kein elementinformationselement mit enthält eine [namespace name] von "http://www.w3.org/2004/08/xop/include" und ein [local name] von Include.Ensure that the SOAP Envelope to be encoded contains no element information item with a [namespace name] of "http://www.w3.org/2004/08/xop/include" and a [local name] of Include.

  2. Erstellen Sie ein leeres MIME-Paket.Create an empty MIME package.

  3. Identifizieren Sie die Elementinformationselemente, die optimiert werden sollten, innerhalb des Original XML Infoset.Identify within the Original XML Infoset the element information items to be optimized. Für die zu optimierenden Elemente müssen die Zeichen, aus denen das [children] des Elementinformationselements besteht, die vorschriftsmäßige Form von xs:base64Binary besitzen (siehe XSD-2, 3.2.16 base64Binary) und dürfen keine Leerzeichen enthalten, die vor dem Nicht-Leerzeichen-Inhalt, in der gleichen Zeile oder dahinter stehen.For the items to be optimized, the characters that make up the [children] of the element information item must be in the canonical form of xs:base64Binary (see XSD-2, 3.2.16 base64Binary) and must not contain any whitespace characters preceding, inline with, or following the non-whitespace content.

  4. Erstellen Sie einen XOP SOAP-Umschlag, der eine Kopie des Original-SOAP-Umschlags ist, aber bei dem das untergeordnete Element jedes Elementinformationselements, das im vorherigen Schritt identifiziert wurde, durch ein xop:Include-Elementinformationselement ersetzt wurde, das wie folgt erstellt wird:Create an XOP SOAP Envelope that is a copy of the Original SOAP Envelope, but with the children of each element information item identified in the previous step replaced by an xop:Include element information item constructed as follows:

    1. Wandeln Sie die ersetzten Zeichen in Binärdaten um, indem Sie sie als base64-codierte Daten verarbeiten.Transform the replaced characters into binary data by processing them as base64-encoded data.

    2. Generieren Sie einen eindeutigen Content-ID-Headerwert, der die Anforderungen R3133 und R3134 zufriedenstellt.Generate a unique Content-ID header value that satisfies requirements R3133 and R3134.

    3. Generieren Sie einen Content-Transfer-Encoding-MIME-Header mit dem Wert "binär".Generate a Content-Transfer-Encoding MIME header with the value binary.

    4. Wenn das optimierte Elementinformationselement (das [übergeordnete Element] des neu eingefügten xop:Include-Elementinformationselements) ein xmime:contentType-Attributelement besitzt, generieren Sie einen Content-Type-MIME-Header mit dem Wert des xmime:contentType-Attributs.If the element information item being optimized (the [parent] of the newly inserted xop:Include element information item) has an xmime:contentType attribute information item, generate a Content-Type MIME header with the value of the xmime:contentType attribute.

    5. Generieren Sie ein neues MIME-Teil mit einem Inhalt aus Binärdaten, die aus den ersetzten Zeichen entschlüsselt wurden, die als base64, Content-ID-Header aus 4b, Content-Transfer-Encoding-Header und Content-Type-Header bei Generierung in Schritt 4d aus 4c verarbeitet wurden.Generate a new binary MIME part with content formed by binary data decoded from the replaced characters processed as base64, Content-ID header from 4b, Content- Transfer-Encoding header from 4c, Content-Type header if generated in step 4d.

    6. Fügen Sie ein href-Attribut zum xop:Include-Element mit dem Wert "cid: uri" hinzu, der in Schritt 4b aus dem Content-ID-Headerwert erstellt wurde.Add an href attribute to the xop:Include element with the value cid: uri derived from Content-ID header value generated in step 4b. Entfernen Sie die umschließenden "<" und ">" Zeichen "," URL-Escape-Zeichenfolge, die verbleibenden, und fügen das Präfix cid:.Remove the enclosing "<" and ">" characters, URL-escape the remaining string, and add the prefix cid:. Der folgende minimale Zeichensatz ist erforderlich, um RFC1738 und RFC2396 mit einem Escapezeichen zu versehen.The following minimum character set is required to be escaped by RFC1738 and RFC2396. Andere Zeichen können mit Escapezeichen versehen werden.Other characters can be escaped.

      Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">  
      "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"  
      
  5. Erstellen Sie ein Stamm-MIME-Teil mit dem XOP SOAP-Umschlag aus Schritt 4.Create a root MIME part with the XOP SOAP Envelope from step 4.

  6. Schreiben Sie die HTTP-Header, einschließlich des HTTP Content-Type-Headers.Write the HTTP headers, including the HTTP Content-Type header.

  7. Schreiben Sie das MIME-Paket.Write the MIME package.

Verarbeiten von MTOM-NachrichtenProcessing MTOM messages

Die Verarbeitung einer MTOM-Nachricht ist das genaue Gegenteil des Vorgangs, der im vorangehenden Abschnitt "Generieren von MTOM-Nachrichten" beschrieben wurde:Processing of an MTOM message is the exact reverse of the process described in the preceding "Generating MTOM messages" section:

  1. Stellen Sie sicher, dass der Stamm-MIME-Teil den Content-Type application/xop+xml hat.Ensure the root MIME part has the Content-Type application/xop+xml.

  2. Erstellen Sie einen SOAP-Umschlag, indem Sie den Stamm-MIME-Teil des Pakets als XML-Dokument analysieren.Construct a SOAP Envelope by parsing the root MIME part of the package as an XML document. Die Zeichencodierung wird vom Parameter charset des Content-Type des Stamm-MIME-Teils bestimmt.Character encoding is determined by the charset parameter of the Content-Type of the root MIME part.

  3. Für jedes Elementinformationselement im erstellten SOAP-Umschlag, der, als einziges Mitglied seiner [untergeordneten] Eigenschaft, ein xop:Include-Elementinformationselement enthält:For each element information item in the constructed SOAP Envelope, which has, as the sole member of its [children] property, an xop:Include element information item:

    1. Löschen Sie das Präfix cid:, und entfernen Sie alle URI-Escape-Zeichensequenzen (RFC 2396) im Wert des @href-Attributs des Elements xop:Include.Remove the cid: prefix and unescape all URI-escape sequences (RFC 2396) in the value of the @href attribute of the xop:Include element. Schließen Sie die Ergebniszeichenfolge in "<", ">".Enclose the result string in "<", ">".

    2. Suchen Sie den MIME-Teil mit dem Content-ID-Headerwert, der mit der in Schritt 3a abgeleiteten Zeichenfolge übereinstimmt.Locate the MIME part with the Content-ID header value that matches the string derived in step 3a.

    3. Ersetzen Sie das Elementinformationselement xop:Include, das in der Eigenschaft children jedes Elements vorkommt, durch Zeicheninformationselemente, die die vorschriftsmäßige base64-Codierung (siehe XSD-2, 3.2.16 base64Binary) des Entitätstexts des in Schritt 3b identifizierten MIME-Teils repräsentieren (ersetzen Sie wirksam das Elementinformationselement xop:Include durch die Daten, die im Paketteil rekonstruiert wurden).Replace the xop:Include element information item that appears in the children property of each item with the character information items that represent the canonical base64 encoding (see XSD-2, 3.2.16 base64Binary) of the entity body of the MIME part identified in step 3b (effectively replace the xop:Include element information item with the data reconstructed from the package part).

HTTP Content-Type HeaderHTTP Content-Type Header

Im folgenden finden Sie eine Liste von WCF-Klärungen des Formats des HTTP Content-Type-Headers einer SOAP 1.x MTOM-codierte Nachricht von Anforderungen, die in der MTOM-Spezifikation selbst abgeleitet und von MTOM und RFC 2387 abgeleitet sind.The following is a list of WCF clarifications for the format of the HTTP Content-Type header of a SOAP 1.x MTOM-encoded message derived from requirements stated in the MTOM specification itself and are derived from MTOM and RFC 2387.

  • R4131: Ein HTTP-Content-Type-Header muss den Wert mehrteilig/verwandt (Groß- und Kleinschreibung nicht beachtend) und seine Parameter besitzen.R4131: An HTTP Content-Type header must have the value of multipart/related (case-insensitive) and its parameters. Bei den Parameternamen braucht die Groß- und Kleinschreibung nicht berücksichtigt werden.Parameter names are case-insensitive. Die Parameterreihenfolge ist nicht wichtig.Parameter order is not significant.

  • Das komplette Backus-Naur Form (BNF) des Content-Type-Headers für MIME-Nachrichten wird in RFC 2045, Abschnitt 5.1 aufgeführt.The full Backus-Naur Form (BNF) of the Content-Type header for MIME messages is listed in RFC 2045, section 5.1.

  • R4132: Ein HTTP Content-Type-Header muss über einen Typparameter mit dem Wert application/xop+xml verfügen, der von doppelten Anführungszeichen umschlossen ist.R4132: An HTTP Content-Type header must have a type parameter with the value application/xop+xml enclosed in double quotation marks.

Während die Anforderung, Anführungszeichen zu verwenden, nicht explizit in RFC 2387 ist, berücksichtigt der Text, alle der mehrteiligen/verwandten medientypparameter am wahrscheinlichsten reservierte Zeichen wie enthalten "@" oder "/" und daher doppelte Anführungszeichen benötigen markiert.While the requirement to use double quotation marks is not explicit in RFC 2387, the text observes that all of the multipart/related media type parameters most likely contain reserved characters like "@" or "/" and therefore need double quotation marks.

  • R4133: Ein HTTP Content-Type-Header sollte einen Startparameter mit dem Wert des Content-ID-Headers des MIME-Teils, der den SOAP 1.x Envelope enthält, in doppelten Anführungszeichen besitzen.R4133: An HTTP Content-Type header should have a start parameter with the value of the Content-ID header of the MIME part that contains the SOAP 1.x Envelope, enclosed in double quotation marks. Wenn der Startparameter weggelassen wird, muss der erste MIME-Teil den SOAP 1.x Envelope enthalten.If the start parameter is omitted, the first MIME part must contain the SOAP 1.x Envelope.

  • R4134: Zum HTTP Content-Type-Header für eine SOAP 1.1 MTOM-codierte Nachricht muss der Startinfo-Parameter, umgeben von doppelten Anführungszeichen, mit dem Wert von text/xml gehören.R4134: An HTTP Content-Type header for a SOAP 1.1 MTOM encoded message must include the start-info parameter with the value of text/xml, enclosed in double quotation marks.

  • R4135: Zum HTTP Content-Type-Header für eine SOAP 1.2 MTOM-codierte Nachricht muss der Startinfo-Parameter mit dem Wert von application/soap+xml, umgeben von doppelten Anführungszeichen, gehören.R4135: An HTTP Content-Type header for a SOAP 1.2 MTOM-encoded message must include the start-info parameter with the value of application/soap+xml, enclosed in double quotation marks.

  • R4136: Der HTTP Content-Type-Header für eine SOAP 1.x MTOM-codierte Nachricht muss den Grenzparameter mit dem Wert (umgeben von doppelten Anführungszeichen), der der MIME-Grenz-BNF entspricht, die in RFC 2046, Abschnitt 5.1.1 definiert wird, enthalten.R4136: HTTP Content-Type header for a SOAP 1.x MTOM-encoded message must have the boundary parameter with the value (enclosed in double quotation marks) that matches the MIME boundary BNF defined in RFC 2046, section 5.1.1

    boundary := 0*69<bchars> bcharsnospace   
    bchars := bcharsnospace / " "   
    bcharsnospace :=    DIGIT / ALPHA / "'" / "(" / ")" / "+"   
                        / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"  
    

    Beispiele:Examples:

    RICHTIGCORRECT

    Content-Type: multipart/related; type="application/xop+xml";start=" <part0@tempuri.org>";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1";start-info="text/xml"  
    

    RICHTIGCORRECT

    Content-Type: Multipart/Related; type="application/xop+xml";start-info="text/xml";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"  
    

    FALSCHINCORRECT

    Content-Type: Multipart/Related; type=application/xop+xml;start=" <part0@tempuri.org>";start-info="text/xml";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"   
    

Infoset-MIME-TeilInfoset MIME Part

SOAP 1.x Envelope ist als Stammteil des XOP MIME-Paket gekapselt und wird häufig der infoset-Teil genannt.The SOAP 1.x Envelope is encapsulated as a root part of the XOP MIME package and is often called the infoset part.

  • R4141: SOAP 1.x Envelope muss als Stammteil des XOP MIME-Pakets, das als infoset-Teil bezeichnet wird und auf das vom HTTP Content-Type verwiesen wird, gekapselt werden.R4141: The SOAP 1.x Envelope must be encapsulated as a root part of the XOP MIME package, called the infoset part and referenced from the HTTP Content-Type.

  • R4142: Der SOAP-Infoset-Teil muss die folgenden MIME-Köpfe einschließen: Content-ID, Content-Transfer-Encoding und Content-Type.R4142: The SOAP Infoset part must include the following MIME headers: Content-ID, Content-Transfer-Encoding, and Content-Type.

Das Format des Content-ID-Headers wird von RFC 2045 alsThe format of the Content-ID header is defined by RFC 2045 as

"Content-ID" ":" msg-id  

definiert, wobei msg-id in RFC 2822 (das RFC 822, auf das in RFC 2045 verwiesen wird, ablöst) als:where msg-id is defined in RFC 2822 (that supersedes RFC 822, referenced in RFC 2045) as:

msg-id    =       [CFWS] "<" id-left "@" id-right ">" [CFWS]  

eingeschlossen ist, wird effektiv eine e-Mail-Adresse in "<" und ">".and is effectively an email address enclosed within "<" and ">". Das [CFWS]-Präfix und -Suffix wurden in RFC 2822 hinzugefügt, um Kommentare auszuführen, und sollten nicht verwendet werden, um die Kompatibilität aufrechtzuerhalten.The [CFWS] prefix and suffix were added in RFC 2822 to carry comments and should not be used to preserve interoperability.

R4143: Der Wert des Content-ID-Headers des Infoset MIME-Teils muss der Produktion msg-id von RFC 2822 folgen, wobei die Präfix- und Suffixteile des [CFWS] entfallen.R4143: The value of the Content-ID header for the Infoset MIME part must follow msg-id production from RFC 2822 with the [CFWS] prefix and suffix parts omitted.

Eine Reihe von MIME-Implementierungen gelockert Anforderungen für den Wert "<" und ">" auf eine e-Mail-Adresse und verwendet absoluteURI eingeschlossen "<", ">" zusätzlich zur e-Mail-Adresse.A number of MIME implementations relaxed requirements for the value enclosed within "<" and ">" to be an email address and used absoluteURI enclosed in "<" , ">" in addition to the email address. Diese Version von WCF Werte des Content-ID MIME Headers des Formulars verwendet werden:This version of WCF uses values of the Content-ID MIME header of the form:

Content-ID: <http://tempuri.org/0>   

R4144: MTOM-Prozessoren sollten Content-ID-Headerwerte akzeptieren, die der folgenden entspannten msg-id entsprechen.R4144: MTOM processors should accept Content-ID header values that match the following relaxed msg-id.

msg-id-relaxed =     [CFWS] "<" (absoluteURI | mail-address) ">" [CFWS]  
mail-address   =     id-left "@" id-right  

MIME (RFC 2045) stellt den Content-Transfer-Encoding-Header bereit, um die Codierung des Inhalts des MIME-Teils zu übermitteln.MIME (RFC 2045) provides the Content-Transfer-Encoding header to communicate encoding of the content of the MIME part. Der für das Content-Transfer-Encoding definierte Standard ist 7-Bit; da dies für die meisten SOAP-Nachrichten nicht geeignet ist, wird der Content-Transfer-Encoding-Header für eine bessere Interoperabilität benötigt:The default defined for Content-Transfer-Encoding is 7-bit, which is not suitable for most SOAP messages, so the Content-Transfer-Encoding header is needed for greater interoperability:

  • R4145: Der SOAP-Infosetteil muss den Content-Transfer-Encoding-Header enthalten.R4145: The SOAP Infoset part must contain the Content-Transfer-Encoding header.

  • R4146: Wenn die SOAP-Umschlag-Zeichencodierung UTF-8 ist, muss der Wert des Content-Transfer-Encoding-Headers 8-Bit sein.R4146: If the SOAP Envelope character encoding is UTF-8, the value of the Content-Transfer-Encoding header must be 8-bit.

  • R4147: Wenn die SOAP-Umschlag-Zeichencodierung UTF-16 ist, muss der Wert des Content-Transfer-Encoding-Headers binär sein.R4147: If the SOAP Envelope character encoding is UTF-16, the value of the Content-Transfer-Encoding header must be binary.

  • Gemäß [XOP] Abschnitt 5,According to [XOP] section 5,

  • R4148: SOAP1. 1 infosetteil muss enthalten Content-Type-Header mit Medien Typ Application/Xop + Xml und Parametertyp = "Text/Xml" und CharsetR4148: SOAP1.1 Infoset part must contain Content-Type header with media type application/xop+xml and parameters type="text/xml" and charset

    Content-Type: application/xop+xml;  
                  charset=utf-8;type="text/xml"  
    
  • R4149: Der SOAP 1.2-infosetteil muss den Content-Type-Header mit Medientyp enthalten application/xop+xml und Parametertyp = "application/soap+xml" und charset.R4149: The SOAP 1.2 Infoset part must contain the Content-Type header with media type application/xop+xml and parameters type="application/soap+xml" and charset.

    Content-Type: application/xop+xml;  
                  charset=utf-8;type="application/soap+xml"  
    

    Obwohl XOP den Parameter charset für application/xop+xml als optional definiert, wird er ähnlich der BP 1.1-Anforderung an den Parameter charset des Medientyps text/xml für die Interoperabilität benötigt.While XOP defines the charset parameter for application/xop+xml to be optional, it is needed for interoperability similar to the BP 1.1 requirement on the charset parameter for the text/xml media type.

  • R4140: Die Parameter type und charset müssen im Content-Type-Header des SOAP 1.x-Infosetteils enthalten sein.R41410: The type and charset parameters must be present on the Content-Type header of the SOAP 1.x Infoset part.

WCF-Endpunkt-Unterstützung für MTOMWCF Endpoint Support for MTOM

Der Zweck von MTOM ist es, eine SOAP-Nachricht zu codieren, um base64-codierte Daten zu optimieren.The purpose of MTOM is to encode a SOAP message to optimize base64-encoded data. Die folgende Liste führt Einschränkungen auf:The following is a list of constraints:

  • R4151: Jedes Elementinformationselement, das base64-codierte Daten enthält, kann optimiert werden.R4151: Any element information item that contains base64-encoded data may be optimized.

  • B4152: WCF optimiert elementinformationselemente, die base64-codierte Daten enthalten und Länge 1024 Bytes überschreitet.B4152: WCF optimizes element information items that contain base64-encoded data and exceed 1024 bytes in length.

Ein WCF-Endpunkt konfiguriert, um MTOM zu verwenden, sendet immer MTOM-codierte Nachrichten.A WCF endpoint configured to use MTOM will always send MTOM-encoded messages. Selbst wenn kein Teil die erforderlichen Kriterien erfüllt, ist die Nachricht noch immer MTOM-codiert (als MIME-Paket mit einem einzelnen MIME-Teil serialisiert, der den SOAP-Umschlag enthält).Even if no parts meet the required criteria, the message is still MTOM-encoded (serialized as a MIME package with a single MIME part containing the SOAP envelope).

WS-Policy-Assertion für MTOMWS-Policy Assertion for MTOM

WCF verwendet die folgende Richtlinienassertion, um die MTOM-Verwendung durch den Endpunkt anzugeben:WCF uses the following policy assertion to indicate MTOM usage by endpoint:

<wsoma:OptimizedMimeSerialization ... />  
  • R4211: Die vorangehende Richtlinienassertion verfügt über ein Endpoint Policy Subject und gibt an, dass alle Nachrichten, die an den Endpunkt gesendet und von diesem empfangen werden, durch den Einsatz von MTOM optimiert werden.R4211: The preceding policy assertion has an Endpoint Policy Subject and specifies that all messages sent to and received from the endpoint must be optimized using MTOM.

  • B4212: Bei der Verwendung von MTOM-Optimierung konfiguriert, ein WCF-Endpunkt Fügt eine MTOM-Richtlinienassertion an die Richtlinie auf den entsprechenden angefügt wsdl:binding.B4212: When configured to use MTOM optimization, an WCF endpoint adds an MTOM Policy assertion to the policy attached to the corresponding wsdl:binding.

Gestaltung mit WS-SicherheitComposition with WS-Security

MTOM ist ein Codierungsmechanismus, der ähnlich wie text/xml und WCF binärem XML.MTOM is an encoding mechanism that is similar to text/xml and WCF Binary XML. MTOM bietet eine natürliche Zusammensetzung aus WS-Sicherheit und anderen WS-*-Protokollen: eine über WS-Sicherheit gesicherte Nachricht kann durch den Einsatz von MTOM optimiert werden.MTOM offers natural composition with WS-Security and other WS-* protocols: a message secured using WS-Security can be optimized using MTOM.

BeispieleExamples

WCF-SOAP 1.1-Nachricht, mit MTOM codiertWCF SOAP 1.1 Message Encoded Using MTOM

POST http://131.107.72.15/Mtom/svc/service.svc/Soap11MtomUTF8 HTTP/1.1  
SOAPAction: "http://xmlsoap.org/echoBinaryAsString"  
Content-Type: multipart/related;type="application/xop+xml";  
              start="<http://tempuri.org/0>";start-info="text/xml";  
       boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"  
Host: 131.107.72.15  
Content-Length: 1501  
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1  
Content-ID: <http://tempuri.org/0>  
Content-Transfer-Encoding: 8bit  
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"  
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">  
  <s:Body>  
    <EchoBinaryAsString xmlns="http://xmlsoap.org/Ping">  
      <array>  
        <xop:Include   
         href="cid:http%3A%2F%2Ftempuri.org%2F1%2F632618206521093670"   
         xmlns:xop="http://www.w3.org/2004/08/xop/include"/>  
      </array>  
    </EchoBinaryAsString>  
  </s:Body>  
</s:Envelope>  
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1  
Content-ID: <http://tempuri.org/1/632618206521093670>  
Content-Transfer-Encoding: binary  
Content-Type: application/octet-stream  
…Binary Content..  
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1  

WCF Secure SOAP 1.2-Nachricht, mit MTOM codiertWCF Secure SOAP 1.2 Message Encoded Using MTOM

In diesem Beispiel wird eine Nachricht mit MTOM und SOAP 1.2 codiert, die mit WS-Sicherheit geschützt wird.In this example, a message is encoded using MTOM and SOAP 1.2 that is protected using WS-Security. Die für die Codierung identifizierten Binärteile sind die Inhalte des BinarySecurityToken, CipherValue der EncryptedData, die zu der verschlüsselten Signatur und dem verschlüsselten Text gehören.The binary parts identified for encoding are the contents of the BinarySecurityToken, CipherValue of the EncryptedData corresponding to the encrypted signature and encrypted body. Beachten Sie, dass die CipherValue von der EncryptedKey konnte nicht ermittelt werden für die Optimierung von WCF, da seine Länge geringer als 1024 Bytes ist.Note that the CipherValue of the EncryptedKey was not identified for optimization by WCF, because its length is less then 1024 bytes.

POST http://131.107.72.15/Mtom/service.svc/Soap12MtomSecureSignEncrypt HTTP/1.1  
Content-Type: multipart/related; type="application/xop+xml";  
              start="<http://tempuri.org/0>";  
            boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3";  
              start-info="application/soap+xml";   
              action="http://xmlsoap.org/echoBinaryAsString"  
Host: 131.107.72.15  
Content-Length: 1941  
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3  
Content-ID: <http://tempuri.org/0>  
Content-Transfer-Encoding: 8bit  
Content-Type: application/xop+xml;charset=utf-8;type="application/soap+xml"  
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">  
  <s:Header>  
    <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">  
      <u:Timestamp u:Id="uuid-4d4ee765-5717-4d53-9ac9-99bddc07df6c-5">  
        <u:Created>2005-09-09T06:57:32.488Z</u:Created>  
        <u:Expires>2005-09-09T07:02:32.488Z</u:Expires>  
      </u:Timestamp>  
      <o:BinarySecurityToken u:Id="uuid-4d4ee765-5717-4d53-9ac9-99bddc07df6c-2" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">  
        <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F1%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>  
      </o:BinarySecurityToken>  
      <e:EncryptedKey Id="_1" xmlns:e="http://www.w3.org/2001/04/xmlenc#">  
        <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>  
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">  
          <o:SecurityTokenReference>  
            <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">Xeg55vRyK3ZhAEhEf+YT0z986L0=</o:KeyIdentifier>  
          </o:SecurityTokenReference>  
        </KeyInfo>  
        <e:CipherData>          <e:CipherValue>oQfpxwT8/SAGyZQzKE2b4yO6dXuQj7pwJ+5CGL3Rf7C06bQ5ttMoQ9GLJcQYkXTzin+WwHEgs5bj5ml9HKTW9QAU5JJ6lksdymmQvWP5ZtGPBVchO4sofEGoCKmBiZL/DYS/cnbzgnc/3a6NYnc10y2fWGaGLiqa00zijAw7o0Y=</e:CipherValue>  
        </e:CipherData>  
      </e:EncryptedKey>  
      <c:DerivedKeyToken u:Id="_2" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">  
        <o:SecurityTokenReference>  
          <o:Reference URI="#_1"/>  
        </o:SecurityTokenReference>  
        <c:Nonce>OrEPRX7fISIS4sXYWPMv3g==</c:Nonce>  
      </c:DerivedKeyToken>  
      <e:ReferenceList xmlns:e="http://www.w3.org/2001/04/xmlenc#">  
        <e:DataReference URI="#_3"/>  
        <e:DataReference URI="#_4"/>  
      </e:ReferenceList>  
      <e:EncryptedData Id="_4" Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:e="http://www.w3.org/2001/04/xmlenc#">  
        <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>  
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">  
          <o:SecurityTokenReference>  
            <o:Reference URI="#_2"/>  
          </o:SecurityTokenReference>  
        </KeyInfo>  
        <e:CipherData>  
          <e:CipherValue>  
            <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F2%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>  
          </e:CipherValue>  
        </e:CipherData>  
      </e:EncryptedData>  
    </o:Security>  
  </s:Header>  
  <s:Body u:Id="_0">  
    <e:EncryptedData Id="_3" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:e="http://www.w3.org/2001/04/xmlenc#">  
      <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>  
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">  
        <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">  
          <o:Reference URI="#_2"/>  
        </o:SecurityTokenReference>  
      </KeyInfo>  
      <e:CipherData>  
        <e:CipherValue>  
          <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F3%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>  
        </e:CipherValue>  
      </e:CipherData>  
    </e:EncryptedData>  
  </s:Body>  
</s:Envelope>  
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3  
Content-ID: <http://tempuri.org/1/632618206525089430>  
Content-Transfer-Encoding: binary  
Content-Type: application/octet-stream  
...Binary content of BinarySecurityToken - X509 Certificate...  
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3  
Content-ID: <http://tempuri.org/2/632618206525089430>  
Content-Transfer-Encoding: binary  
Content-Type: application/octet-stream  
...Binary serialization of the encrypted primary signature...  
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3  
Content-ID: <http://tempuri.org/3/632618206525089430>  
Content-Transfer-Encoding: binary  
Content-Type: application/octet-stream  
...Binary serialization of the encrypted Body...  
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3--