Freigeben über

Messagingprotokolle

Der Windows Communication Foundation (WCF)-Kanalstapel verwendet Codierungs- und Transportkanäle, um die interne Nachrichtendarstellung in das Drahtformat zu transformieren und mithilfe eines bestimmten Transports zu senden. Der am häufigsten für die Interoperabilität von Webdiensten verwendete Transport ist HTTP, und die gängigsten Codierungen, die von Webdiensten verwendet werden, sind XML-basierte SOAP 1.1, SOAP 1.2 und MTOM (Message Transmission Optimization Mechanism).

Dieser Artikel enthält WCF-Implementierungsdetails für die folgenden Protokolle, die von HttpTransportBindingElement verwendet werden.

Spezifikation/Dokument:

Dieses Thema behandelt WCF-Implementierungsdetails für die folgenden Protokolle, die von TextMessageEncodingBindingElement und MtomMessageEncodingBindingElement eingesetzt werden.

Spezifikation/Dokument:

Das Thema behandelt WCF-Implementierungsdetails für die Protokolle, die von MtomMessageEncodingBindingElement verwendet werden.

Spezifikation/Dokument:

In diesem Thema werden die folgenden XML-Namespaces und zugehörige Präfixe verwendet:

Präfix Namespace Uniform Resource Identifier (URI)
s11 http://schemas.xmlsoap.org/soap/envelope
s12 http://www.w3.org/2003/05/soap-envelope
wsa http://www.w3.org/2004/08/addressing
wsam http://www.w3.org/2007/05/addressing/metadata
wsap http://schemas.xmlsoap.org/ws/2004/09/policy/addressing
wsa10 http://www.w3.org/2005/08/addressing
wsaw10 http://www.w3.org/2006/05/addressing/wsdl
xop http://www.w3.org/2004/08/xop/include
xmime http://www.w3.org/2004/06/xmlmime

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

SOAP 1.1 und SOAP 1.2

Umschlag- und Verarbeitungsmodell

Die WCF implementiert die SOAP 1.1-Umschlagsverarbeitung unter Befolgung von Basic Profile 1.1 (BP11) und Basic Profile 1.0 (SSBP10). SOAP 1.2-Umschlagsverarbeitung wird unter Befolgung von SOAP12-Part1 implementiert.

In diesem Abschnitt werden bestimmte Implementierungsoptionen von WCF in Bezug auf BP11 und SOAP12-Part1 erläutert.

Pflicht-Headerverarbeitung

WCF folgt den Regeln für die Verarbeitung von Headern, die mit mustUnderstand markiert sind, wie in den SOAP 1.1- und SOAP 1.2-Spezifikationen beschrieben, unter Berücksichtigung der folgenden Variationen.

Eine Nachricht, die den WCF-Kanalstapel eingibt, wird von einzelnen Kanälen verarbeitet, die durch zugeordnete Bindungselemente konfiguriert werden, z. B. Textnachrichtencodierung, Sicherheit, zuverlässiges Messaging und Transaktionen. Jeder Kanal erkennt Kopfzeilen aus dem zugeordneten Namespace und kennzeichnet sie als verstanden. Sobald eine Nachricht den Dispatcher erreicht, liest der Operationsformatierer Kopfzeilen, die vom entsprechenden Nachrichten-/Vorgangsvertrag erwartet werden, und kennzeichnet sie als verstanden. Der Verteiler überprüft, ob einige der verbleibenden Header nicht verstanden, aber als mustUnderstand gekennzeichnet sind, und löst eine Ausnahme aus. Nachrichten, die mustUnderstand Kopfzeilen enthalten, die für den Empfänger bestimmt sind, werden nicht vom Anwendungscode des Empfängers verarbeitet.

Eine solche mehrschichtige Verarbeitung ermöglicht die Trennung zwischen Infrastrukturebenen und Anwendungsebenen des SOAP-Knotens:

  • B1111: Header, die nicht verstanden werden, werden erkannt, nachdem die Nachricht vom WCF-Infrastrukturkanalstapel verarbeitet wurde, aber bevor sie von der Anwendung verarbeitet wird

    Der mustUnderstand Headerwert unterscheidet sich zwischen SOAP 1.1 und SOAP 1.2. Basic Profile 1.1 erfordert, dass der mustUnderstand Wert 0 oder 1 für SOAP 1.1-Nachrichten sein muss. SOAP 1.2 ermöglicht 0, 1, false, und true als Werte, empfiehlt jedoch, eine kanonische Darstellung von xs:boolean Werten (false, true).

  • B1112: WCF gibt mustUnderstand Werte 0 und 1 für sowohl SOAP 1.1- als auch SOAP 1.2-Versionen des SOAP-Umschlags aus. WCF akzeptiert den gesamten Wertbereich von xs:boolean für die mustUnderstand-Kopfzeile (0, 1, false, true)

SOAP-Fehler

Es folgt eine Liste der WCF-spezifischen SOAP-Fehlerimplementierungen.

  • B2121: WCF gibt die folgenden SOAP 1.1-Fehlercodes zurück: s11:mustUnderstand, , s11:Clientund s11:Server.

  • B2122: WCF gibt die folgenden SOAP 1.2-Fehlercodes zurück: s12:MustUnderstand, , s12:Senderund s12:Receiver.

HTTP-Bindung

SOAP 1.1 HTTP-Bindung

WCF implementiert SOAP1.1-HTTP-Bindung gemäß Abschnitt 3.4 der Grundprofil 1.1-Spezifikation, mit den folgenden Klarstellungen:

  • B2211: DER WCF-Dienst implementiert keine Umleitung von HTTP POST-Anforderungen.

  • B2212: WCF-Clients unterstützen HTTP-Cookies gemäß 3.4.8.

SOAP 1,2 HTTP-Bindung

WCF implementiert SOAP 1.2-HTTP-Bindung, wie in der SOAP 1.2-Part 2 -Spezifikation (SOAP12Part2) mit den folgenden Klarstellungen beschrieben.

SOAP 1.2 hat einen optionalen Aktionsparameter für den application/soap+xml Medientyp eingeführt. Dieser Parameter ist nützlich, um den Nachrichtenversand zu optimieren, ohne dass der Textkörper der SOAP-Nachricht analysiert werden muss, wenn WS-Addressing nicht verwendet wird.

  • R2221: Der application/soap+xml Aktionsparameter, der in einer SOAP 1.2-Anforderung vorhanden ist, muss mit dem soapAction Attribut des wsoap12:operation Elements innerhalb der entsprechenden WSDL-Bindung übereinstimmen.

  • R2222: Der application/soap+xml Aktionsparameter, der in einer SOAP 1.2-Nachricht vorhanden ist, muss mit wsa:Action übereinstimmen, wenn WS-Addressing 2004/08 oder WS-Addressing 1.0 verwendet werden.

Wenn WS-Addressing deaktiviert ist und eine eingehende Anforderung keinen Aktionsparameter enthält, wird die Nachricht Action als nicht angegeben betrachtet.

WS-Adressierung

WCF implementiert 3 Versionen von WS-Adressierung:

  • WS-Adressierung 2004/08

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

  • WS-Addressing 1.0 – Metadaten

Endpunktverweise

Alle Versionen von WS-Addressing, die WCF implementiert, verwenden Endpunktverweise, um Endpunkte zu beschreiben.

Endpunktverweise und WS-Adressierungsversionen

WCF implementiert eine Reihe von Infrastrukturprotokollen, die WS-Addressing verwenden, insbesondere das EndpointReference-Element und die W3C.WsAddressing.EndpointReferenceType-Klasse (z. B. WS-ReliableMessaging, WS-SecureConversation und WS-Trust). WCF unterstützt die Verwendung einer der beiden Versionen von WS-Addressing mit anderen Infrastrukturprotokollen. WCF-Endpunkte unterstützen eine Version von WS-Addressing pro Endpunkt.

Für R3111 muss der Namespace des EndpointReference-Elements oder Typs, das in Nachrichten verwendet wird, die mit einem WCF-Endpunkt ausgetauscht werden, mit dem Namespace der Version von WS-Addressing übereinstimmen, die von diesem Endpunkt implementiert wird.

Wenn beispielsweise ein WCF-Endpunkt WS-ReliableMessaging implementiert, verwendet der AcksTo-Header, der von einem derartigen Endpunkt in CreateSequenceResponse zurückgegeben wird, die WS-Addressing-Version, die das EncodingBinding-Element für diesen Endpunkt angibt.

Endpunktverweise und Metadaten

Eine Reihe von Szenarien erfordert die Kommunikation von Metadaten oder einen Verweis auf Metadaten für einen bestimmten Endpunkt.

B3121: WCF verwendet Mechanismen, die in Abschnitt 6 der Spezifikation WS-MetadataExchange (MEX) beschrieben sind, um Metadaten für Endpunktverweise sowohl durch Wert als auch durch Referenz einzubinden.

Stellen Sie sich ein Szenario vor, in dem ein WCF-Dienst die Authentifizierung über ein SAML-Token (Security Assertions Markup Language) erfordert, das vom Tokenaussteller unter http://sts.fabrikam123.com ausgestellt wurde. Der WCF-Endpunkt beschreibt diese Authentifizierungsanforderung durch Verwendung der sp:IssuedToken-Assertion mit einer geschachtelten sp:Issuer-Assertion, die auf den Tokenaussteller verweist. Clientanwendungen, die auf die sp:Issuer Assertion zugreifen, müssen wissen, wie sie mit dem Tokenherausgeberendpunkt kommunizieren. Der Client muss Metadaten über den Tokenherausgeber kennen. Mithilfe der in MEX definierten Endpunktreferenzmetadatenerweiterungen stellt WCF einen Verweis auf die Tokenherausgebermetadaten bereit.

<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>

Nachrichtenadressierungsheader

Nachrichtenkopfzeilen

Für beide WS-Addressing Versionen verwendet WCF die folgenden Nachrichtenköpfe: wsa:To, wsa:ReplyTo, wsa:Action, wsa:MessageID und wsa:RelatesTo gemäß den Spezifikationen.

B3211: Für beide WS-Addressing-Versionen akzeptiert die WCF die WS-Addressing-Nachrichtenheader wsa:FaultTo und wsa:From, erstellt sie aber nicht selbst.

Anwendungen, die mit WCF-Anwendungen interagieren, können diese Nachrichtenkopfzeilen hinzufügen, und WCF verarbeitet sie entsprechend.

Referenzparameter und Eigenschaften

WCF implementiert die Verarbeitung von Endpunktverweisparametern und Referenzeigenschaften in Übereinstimmung mit den jeweiligen Spezifikationen.

B3221: Wenn die WCF-Endpunkte für die Verwendung von WS-Addressing 2004/08 konfiguriert sind, machen sie keinen Unterschied zwischen der Verarbeitung von Verweiseigenschaften und Verweisparametern.

Nachrichtenaustauschmuster

Die Abfolge von Nachrichten, die an dem Aufruf des Webdienstvorgangs beteiligt sind, wird als Nachrichtenaustauschmuster bezeichnet. WCF unterstützt unidirektionale, Anfrage-Antwort- und Duplex-Nachrichtenaustausch-Muster. In diesem Abschnitt werden WS-Addressing Anforderungen an die Nachrichtenverarbeitung in Abhängigkeit vom verwendeten Nachrichtenaustauschmuster erläutert.

In diesem Abschnitt sendet der Antragsteller die erste Nachricht, und der Antwortende empfängt die erste Nachricht.

Unidirektionale Nachricht

Wenn ein WCF-Endpunkt so konfiguriert ist, dass Nachrichten mit einem bestimmten Action Muster unterstützt werden, um einem unidirektionalem Muster zu folgen, folgt der WCF-Endpunkt den folgenden Verhaltensweisen und Anforderungen. Sofern nicht anders angegeben, gelten Verhalten und Regeln für beide Versionen von WS-Addressing, die in WCF unterstützt werden:

  • R3311: Der Anforderer muss wsa:To, wsa:Action und Kopfzeilen für alle Referenzparameter einschließen, die durch den Endpunktverweis angegeben sind. 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.

  • B3312: Der Antragsteller kann die Header MessageID, ReplyTo und FaultTo enthalten. Die Empfängerinfrastruktur ignoriert sie, und sie werden an die Anwendung übergeben.

  • R3313: Wenn HTTP verwendet wird und keine Nachricht auf dem HTTP-Antwortteil gesendet wird, muss der Responder eine HTTP-Antwort mit einem leeren Textkörper und einem HTTP 202-Statuscode senden.

    Wenn der HTTP-Transport verwendet wird und der Vorgangsvertrag eine Nachricht als unidirektional deklariert, kann die HTTP-Antwort weiterhin zum Senden von Infrastrukturnachrichten verwendet werden, z. B. können zuverlässige Nachrichten eine SequenceAcknowledgement Nachricht in einer HTTP-Antwort senden.

  • B3314: Der WCF-Responder sendet keine Fehlermeldung als Reaktion auf eine unidirektionale Nachricht.

Anforderung-Antwort

Wenn ein WCF-Endpunkt für eine Nachricht konfiguriert ist, die dem Action Anforderungsantwortmuster folgt, folgt der WCF-Endpunkt den folgenden Verhaltensweisen und Anforderungen. Sofern nicht anders angegeben, gelten Verhalten und Regeln für beide Versionen von WS-Addressing, die in WCF unterstützt werden:

  • R3321: Der Anforderer muss wsa:To, wsa:Action, wsa:MessageID und Header für alle vom Endpunktverweis angegebenen Referenzparameter oder Referenzeigenschaften (oder beide) in die Anforderung aufnehmen.

  • R3322: Wenn WS-Addressing 2004/08 verwendet wird, ReplyTo muss auch in der Anforderung enthalten sein.

  • R3323: Wenn WS-Addressing 1.0 verwendet wird und ReplyTo in der Anforderung nicht vorhanden ist, wird ein Standardendpunktverweis mit der [address]-Eigenschaft verwendet, die http://www.w3.org/2005/08/addressing/anonymous gleich ist.

  • R3324: Der Anforderer muss wsa:To, wsa:Action und wsa:RelatesTo Kopfzeilen in der Antwortnachricht sowie Kopfzeilen für alle Referenzparameter oder Verweiseigenschaften (oder beides) enthalten, die durch den Endpunktverweis in der ReplyTo Anforderung angegeben werden.

Webdienste zur Behebung von Fehlern

R3411: WCF erzeugt die folgenden Fehler, die von WS-Addressing 2004/08 definiert sind.

Programmcode Ursache
wsa:DestinationUnreachable Die Nachricht kam mit einer ReplyTo Adresse an, die von der für diesen Kanal eingestellten Antwortadresse abweicht. Es gibt keinen Endpunkt, der die angegebene Adresse in der An-Kopfzeile entgegennimmt.
wsa:ActionNotSupported die dem Endpunkt zugeordneten Infrastrukturkanäle oder Verteiler erkennen die im Action Header angegebene Aktion nicht.

R3412: WCF erzeugt die folgenden Fehler, die von WS-Addressing 1.0 definiert sind.

Programmcode Ursache
wsa10:InvalidAddressingHeader Duplizieren Sie wsa:To, wsa:ReplyTo, wsa:From oder wsa:MessageID. Dupliziere wsa:RelatesTo mit demselben RelationshipType.
wsa10:MessageAddressingHeaderRequired Der erforderliche Adressierungsheader fehlt.
wsa10:DestinationUnreachable Die Nachricht wurde mit einer ReplyTo gesendet, die sich von der für diesen Kanal eingerichteten Antwortadresse unterscheidet. An der Adresse, die im To-Header angegeben ist, gibt es kein Endpunkt-Listening.
wsa10:ActionNotSupported Eine im Action Header angegebene Aktion wird von den Infrastrukturkanälen oder Dem Endpunkt zugeordneten Verteiler nicht erkannt.
wsa10:EndpointUnavailable Der RM-Kanal sendet diesen Fehler zurück, der angibt, dass der Endpunkt die Sequenz basierend auf der Untersuchung der Adressheader der CreateSequence Nachricht nicht verarbeitet.

Code in den vorangehenden Tabellen wird auf FaultCode in SOAP 1.1 und SubCode (mit Code=Sender) in SOAP 1.2 abgebildet.

WSDL 1.1-Bindung und WS-Richtlinienassertionen

Angeben der Verwendung von WS-Adressierung

WCF verwendet Richtlinienaussagen, um die Endpunktunterstützung für eine bestimmte Version WS-Addressing anzugeben.

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.

<wsap:UsingAddressing />

Diese Richtlinienaussage erweitert die Spezifikation WS-Addressing 2004/08.

Die folgende Richtlinienbehauptung gibt an, dass gesendete/empfangene Nachrichten WS-Addressing 1.0 verwenden müssen.

<wsam:Addressing/>

Die folgende Richtlinienaussage hat ein Endpunktrichtlinienobjekt [WS-PA] und gibt an, dass vom Endpunkt gesendete und empfangene Nachrichten WS-Addressing 2004/08 verwenden müssen.

<wsaw10:UsingAddressing />

Das wsaw10:UsingAddressing Element stammt aus [WS-Addressing-WSDL] und wird im Kontext von WS-Policy gemäß dieser Spezifikation, Abschnitt 3.1.2, verwendet.

Die Verwendung der Adressierung ändert nicht die Semantik von WSDL 1.1, SOAP 1.1 und SOAP 1.2 HTTP-Bindungen. Wenn beispielsweise eine Antwort auf eine Anforderung erwartet wird, die an einen Endpunkt gesendet wird, der Adressierung und WSDL SOAP 1.x-HTTP-Bindung verwendet, muss die Antwort mithilfe der HTTP-Antwort gesendet werden.

Bei Antworten, die über die HTTP-Antwort gesendet werden, lautet die WS-AM Assertion:

<wsam:AnonymousResponses/>

Die vollständige Richtlinienbehauptung kann wie folgt aussehen:

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

Es gibt jedoch Nachrichtenaustauschmuster, die von zwei unabhängigen umgekehrten HTTP-Verbindungen profitieren, die zwischen dem Anforderer und dem Antwortenden eingerichtet wurden, z. B. nicht angeforderte unidirektionale Nachrichten, die vom Antwortenden gesendet werden.

WCF bietet ein Feature, mit dem zwei zugrunde liegende Transportkanäle einen zusammengesetzten Duplexkanal bilden können, in dem ein Kanal für Eingabenachrichten und das andere für Ausgabenachrichten verwendet wird. Im Fall des HTTP-Transports stellt Composite Duplex zwei umgekehrte HTTP-Verbindungen bereit. Der Antragsteller verwendet eine Verbindung, um Nachrichten an den Antwortenden zu senden, und der Antwortende verwendet die andere, um Nachrichten zurück an den Antragsteller zu senden.

Die WS-AM-Assertion von Antworten, die über separate HTTP-Anforderungen gesendet werden, ist Folgende:

<wsam:NonAnonymousResponses/>

Die vollständige Richtlinienbehauptung kann wie folgt aussehen:

<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.

<cdp:CompositeDuplex/>

Die vorherige Anweisung führt zu den folgenden Anforderungen für den wsa:ReplyTo Header für Anforderungsnachrichten:

  • R3514: Anforderungsnachrichten, die an einen Endpunkt gesendet werden, müssen einen ReplyTo-Header enthalten, dessen Eigenschaft [address] nicht gleich http://www.w3.org/2005/08/addressing/anonymous ist, wenn der Endpunkt eine WSDL 1.1 SOAP 1.x-HTTP-Bindung verwendet und eine Richtlinienalternative mit einer wsap10:UsingAddressing- oder wsap:UsingAddressing-Aussage aufweist, die mit cdp:CompositeDuplex verbunden ist.

  • R3515: Die an einen Endpunkt gesendeten Anforderungsnachrichten müssen einen ReplyTo-Header umfassen, dessen [address]-Eigenschaft http://www.w3.org/2005/08/addressing/anonymous entspricht, oder sie dürfen keinen ReplyTo-Header umfassen, wenn der Endpunkt eine WSDL 1.1 SOAP 1.x-HTTP-Bindung verwendet und über eine Richtlinienalternative mit wsap10:UsingAddressing-Assertion und keine cdp:CompositeDuplex-Assertion verfügt.

  • R3516: An einen Endpunkt gesendete Anforderungsnachrichten müssen über einen ReplyTo Header mit einer [address] Eigenschaft verfügen, die http://www.w3.org/2005/08/addressing/anonymous gleich ist, wenn der Endpunkt eine WSDL 1.1 SOAP 1.x-HTTP-Bindung verwendet und eine Richtlinienalternative mit wsap:UsingAddressing Assertion und ohne cdp:CompositeDuplex angefügte Assertion aufweist.

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. Leider ist diese Elementdefinition nicht besonders als Assertion im Kontext von WS-Policy verwendbar, da domänenspezifische Erweiterungen erforderlich sind, um die Schnittmenge von Alternativen zu unterstützen, die ein solches Element als Assertion verwenden. Diese Elementdefinition gibt auch den Wert des ReplyTo Headers im Gegensatz zum Endpunktverhalten für das Draht an, wodurch er für den HTTP-Transport spezifisch ist.

Aktionsdefinition

WS-Addressing 2004/08 definiert ein wsa:Action Attribut für die wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] Elemente. WS-Addressing 1.0 WSDL Binding (WS-ADDR10-WSDL) definiert ein ähnliches Attribut, 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 von WS-ADDR10-WSDL beschrieben wird.

Es ist sinnvoll, zwei Endpunkte zu verwenden, die sich denselben portType (bzw. „Vertrag“ in der WCF-Terminologie) aufweisen, aber verschiedene WS-Addressing-Versionen verwenden. Da die Aktion jedoch durch die portType definiert wird und sich nicht über die Endpunkte ändern sollte, die die portType umsetzen, wird es unmöglich, beide Standardaktionsmuster zu unterstützen.

Um diese Kontroverse zu beheben, unterstützt WCF eine einzelne Version des Action Attributs.

B3521: WCF verwendet das wsaw10:Action Attribut für wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] Elemente, die in WS-ADDR10-WSDL definiert sind, um den Action URI für die entsprechenden Nachrichten unabhängig von der vom Endpunkt verwendeten WS-Addressing Version zu ermitteln.

Verwenden Sie die Endpunktreferenz innerhalb des WSDL-Ports

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. WCF erweitert dieses Hilfsprogramm auf WS-Addressing 2004/08, sodass <wsa:EndpointReference…/> als untergeordnetes Element von wsdl:port erscheinen kann.

  • R3531: Wenn ein Endpunkt eine zugehörige Richtlinienalternative mit einer <wsaw10:UsingAddressing/>-Richtlinienaussage hat, kann das entsprechende wsdl:port-Element ein untergeordnetes Element <wsa10:EndpointReference …/> enthalten.

  • R3532: Wenn ein untergeordnetes wsdl:port Element <wsa10:EndpointReference …/>enthält, muss der wsa10:EndpointReference/wsa10:Address untergeordnete Elementwert mit dem Wert des @address Attributs des gleichgeordneten wsdl:port/wsdl:location Elements übereinstimmen.

  • R3533: Wenn ein Endpunkt über eine angefügte Richtlinienalternative mit der <wsap:UsingAddressing/> Richtlinienaussage verfügt, kann das entsprechende wsdl:port-Element ein untergeordnetes <wsa:EndpointReference …/>-Element enthalten.

  • R3534: Wenn ein untergeordnetes wsdl:port Element <wsa:EndpointReference …/>enthält, muss der wsa:EndpointReference/wsa:Address wert des untergeordneten Elements mit dem Wert des @address Attributs des gleichgeordneten wsdl:port/wsdl:location Elements übereinstimmen.

Gestaltung mit WS-Sicherheit

Gemäß den Abschnitten zu Sicherheitsüberlegungen in WS-ADDR und WS-ADDR10 wird empfohlen, alle Nachrichtenkopfzeilen zusammen mit dem Nachrichtentext zu signieren, um sie miteinander zu binden.

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.

Beispiele

Unidirektionale Nachricht

In diesem Szenario sendet der Absender eine unidirektionale Nachricht an den Empfänger. SOAP 1.2, HTTP 1.1 und W3C WS-Addressing 1.0 werden verwendet.

Die Anforderungsnachrichtenstruktur: Die Nachrichtenkopfzeilen enthalten wsa10:To und wsa10:Action Elemente. Der Nachrichtentext enthält ein bestimmtes <app:Ping> Element aus dem Anwendungsnamespace.

HTTP-Header: Das Ziel in POST entspricht dem URI im wsa10:To Element.

Der Content-Type-Header hat den Wert application/soap+xml, wie von SOAP 1.2 gefordert. Parameter charset und action sind enthalten. Der action Parameter der Inhaltstypkopfzeile entspricht dem Wert der wsa10:Action Nachrichtenkopfzeile.

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. Beispiel für die HTTP-Antwort:

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übertragungsoptimierungsmechanismus

In diesem Abschnitt werden die WCF-Implementierungsdetails für http SOAP MTOM beschrieben. MTOM-Technologie ist SOAP-Nachrichtencodierungsmechanismus der gleichen Klasse wie herkömmliche Text-/XML-Codierung oder WCF Binary-Codierung. MTOM umfasst Folgendes:

  • Ein von [XOP] beschriebener XML-Codierungs- und Verpackungsmechanismus, der XML-Informationselemente mit base64-codierten Binärdaten in separate Binäre Teile optimiert.

  • Eine MIME-Kapselung des XOP-Pakets, das das XML-Infoset und jeden binären Teil des XOP-Pakets in einen separaten MIME-Teil serialisiert.

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

  • Eine HTTP-Transportbindung.

Es ist möglich, MTOM mit Nicht-HTTP-Transporten mit WCF zu verwenden. In diesem Thema konzentrieren wir uns jedoch auf HTTP.

Das MTOM-Format nutzt eine große Reihe von Spezifikationen, die MTOM selbst, XOP und MIME abdecken. Die Modularität dieses Spezifikationssatzes macht es etwas schwierig, genaue Anforderungen an die Format- und Verarbeitungsemantik zu rekonstruieren. In diesem Abschnitt werden die Format- und Verarbeitungsanforderungen für die MTOM-HTTP-Bindung beschrieben.

MTOM-Nachrichtencodierung

Generieren von MTOM-Nachrichten

Der Abschnitt [XOP] 3.1 beschreibt den Prozess der Codierung von XML mit Elementinformationselementen, die Base64-Werte in ein abstraktes XOP-Paket enthalten.

Die folgende Abfolge der Schritte beschreibt den MTOM-spezifischen Codierungsprozess:

  1. Stellen Sie sicher, dass der zu codierende SOAP-Umschlag kein Elementinformationselement mit dem [namespace name]http://www.w3.org/2004/08/xop/include und dem [local name]Include enthält.

  2. Erstellen Sie ein leeres MIME-Paket.

  3. Identifizieren Sie im Original-XML-Infoset die zu optimierenden Elementinformationselemente. Damit die Elemente optimiert werden können, müssen die Zeichen, aus denen der [children] Element-Informationsposten besteht, in der kanonischen Form von xs:base64Binary vorliegen (siehe XSD-2, 3.2.16 base64Binary) und dürfen keine Leerzeichen enthalten, die vorangestellt, mitten im oder nach dem Nicht-Leerzeichen-Inhalt stehen.

  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:

    1. Transformieren Sie die ersetzten Zeichen in Binärdaten, indem Sie sie als base64-codierte Daten verarbeiten.

    2. Generieren Sie einen eindeutigen Content-ID-Headerwert, der den Anforderungen R3133 und R3134 entspricht.

    3. Generieren Sie einen Content-Transfer-Encoding-MIME-Header mit dem Wert 'binary'.

    4. Wenn das zu optimierende Elementinformationselement (das [übergeordnete] Element des neu eingefügten xop:Include Elementinformationselements) ein xmime:contentType Attributinformationselement aufweist, generieren Sie einen MIME-Header vom Inhaltstyp mit dem Wert des xmime:contentType Attributs.

    5. Generieren Sie einen neuen binären MIME-Teil mit einem Inhalt, der aus binären Daten besteht, die aus den ersetzten Zeichen decodiert und als Base64 verarbeitet werden, sowie einem Inhalts-ID-Header von 4b, einem Content-Transfer-Encoding-Header von 4c und einem Content-Type-Header, falls in Schritt 4d generiert.

    6. Fügen Sie dem href Element ein xop:Include Attribut mit dem Wert "cid" hinzu: URI, der aus dem in Schritt 4b generierten Inhalts-ID-Headerwert abgeleitet wurde. Entfernen Sie die einschließenden Zeichen "<" und ">", versehen Sie die verbleibende Zeichenfolge mit URL-Escape, und fügen Sie das Präfix cid: hinzu. Der folgende minimale Zeichensatz ist erforderlich, um RFC1738 und RFC2396 mit einem Escapezeichen zu versehen. Andere Zeichen können mit Escapezeichen versehen werden.

      Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
"{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"

  5. Erstellen Sie einen MIME-Stammteil mit dem XOP SOAP Envelope aus Schritt 4.

  6. Schreiben Sie die HTTP-Header, einschließlich des HTTP-Content-Type-Headers.

  7. Schreiben Sie das MIME-Paket.

Verarbeiten von MTOM-Nachrichten

Die Verarbeitung einer MTOM-Nachricht ist die genaue Umkehrung des im vorherigen Abschnitt "Generieren von MTOM-Nachrichten" beschriebenen Prozesses:

  1. Stellen Sie sicher, dass der MIME-Stammteil den Inhaltstyp application/xop+xmlaufweist.

  2. Erstellen Sie einen SOAP-Umschlag, indem Sie den MIME-Stammteil des Pakets als XML-Dokument analysieren. Die Zeichencodierung wird durch den charset Parameter des Inhaltstyps des MIME-Stammteils bestimmt.

  3. Für jedes Elementinformationselement im erstellten SOAP-Umschlag, der, als einziges Mitglied seiner [untergeordneten] Eigenschaft, ein xop:Include-Elementinformationselement enthält:

    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. Umgeben Sie die Ergebniszeichenfolge mit "<", ">".

    2. Suchen Sie den MIME-Teil mit dem Inhalts-ID-Headerwert, der der in Schritt 3a abgeleiteten Zeichenfolge entspricht.

    3. Ersetzen Sie das xop:Include Elementinformationselement, das in der children Eigenschaft jedes Elements angezeigt wird, durch die Zeicheninformationselemente, die die kanonische Base64-Codierung darstellen (siehe XSD-2, 3.2.16 base64Binary) des Entitätstexts des in Schritt 3b identifizierten MIME-Teils (effektiv ersetzen Sie das xop:Include Elementinformationselement durch die aus dem Paketteil umgebauten Daten).

HTTP-Inhaltstypheader

Es folgt eine Liste der WCF-Klarstellungen für das Format des HTTP Content-Type-Headers einer SOAP 1.x MTOM-codierten Nachricht, die von anforderungen abgeleitet ist, die in der MTOM-Spezifikation selbst angegeben sind und von MTOM und RFC 2387 abgeleitet werden.

  • R4131: Ein HTTP-Content-Type-Header muss den Wert mehrteilig/verwandt (Groß- und Kleinschreibung nicht beachtend) und seine Parameter besitzen. Bei den Parameternamen braucht die Groß- und Kleinschreibung nicht berücksichtigt werden. Die Parameterreihenfolge ist nicht signifikant.

  • Das komplette Backus-Naur Form (BNF) des Content-Type-Headers für MIME-Nachrichten wird in RFC 2045, Abschnitt 5.1 aufgeführt.

  • R4132: Ein HTTP Content-Type-Header muss einen Typparameter mit dem Wert application/xop+xml haben, der in doppelte Anführungszeichen eingeschlossen ist.

Obwohl die Anforderung, doppelte Anführungszeichen zu verwenden, in RFC 2387 nicht explizit ist, stellt der Text fest, dass alle parameter vom Typ "multipart/related media" höchstwahrscheinlich reservierte Zeichen wie "@" oder "/" enthalten und daher doppelte Anführungszeichen benötigen.

  • R4133: Ein HTTP Content-Type-Header sollte über einen Startparameter mit dem Wert des Content-ID-Headers des MIME-Teils verfügen, der den SOAP 1.x Envelope enthält, der in doppelte Anführungszeichen eingeschlossen ist. Wenn der Startparameter nicht angegeben wird, muss der erste MIME-Teil den SOAP 1.x Envelope enthalten.

  • R4134: Ein HTTP-Inhaltstypheader für eine MTOM-codierte SOAP 1.1-Nachricht muss den Start-Info-Parameter mit dem Wert von Text/XML enthalten, der in doppelte Anführungszeichen eingeschlossen ist.

  • R4135: Ein HTTP Content-Type-Header für eine SOAP 1.2 MTOM-codierte Nachricht muss den Start-Info-Parameter mit dem Wert enthalten application/soap+xml, der in doppelte Anführungszeichen eingeschlossen ist.

  • 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.

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

    Beispiele

    RICHTIG

    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"

    RICHTIG

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

    UNRICHTIG

    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-Teil

Der SOAP 1.x Envelope wird als Stammteil des XOP MIME-Pakets gekapselt und wird häufig als infoset-Teil bezeichnet.

  • 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.

  • R4142: Der SOAP-Teil Infoset muss die folgenden MIME-Header enthalten: Content-ID, , Content-Transfer-Encodingund Content-Type.

Das Format des Inhalts-ID-Headers wird durch RFC 2045 definiert als

"Content-ID" ":" msg-id

wobei msg-id in RFC 2822 definiert ist (die RFC 822 ersetzt, auf die in RFC 2045 verwiesen wird) wie folgt:

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

und ist effektiv eine E-Mail-Adresse, die in "<" und ">" eingeschlossen ist. Die Präfixe und Suffixe [CFWS] wurden in RFC 2822 hinzugefügt, um Kommentare aufzunehmen und sollten nicht verwendet werden, um die Interoperabilität zu gewährleisten.

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.

Eine Reihe von MIME-Implementierungen lockerte die Anforderungen dafür, dass der in „<“ und „>“ eingeschlossene Wert eine E-Mail-Adresse sein muss, und verwendete zusätzlich zu der E-Mail-Adresse auch „absoluteURI“ eingeschlossen in „<“, „>“. Diese Version von WCF verwendet Werte des MIME-Headers "Content-ID" des Formulars:

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

R4144: MTOM-Prozessoren sollten Content-ID-Headerwerte akzeptieren, die der folgenden entspannten msg-id entsprechen.

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 kommunizieren. Der für "Content-Transfer-Encoding" definierte Standard ist 7-Bit, was für die meisten SOAP-Nachrichten nicht geeignet ist, sodass der Header "Content-Transfer-Encoding" für eine größere Interoperabilität erforderlich ist:

  • R4145: Der SOAP-Infoset-Teil muss den Header "Content-Transfer-Encoding" enthalten.

  • R4146: Wenn die SOAP Envelope-Zeichencodierung UTF-8 ist, muss der Wert des Headers "Content-Transfer-Encoding" 8-Bit sein.

  • R4147: Wenn die SOAP Envelope-Zeichencodierung UTF-16 ist, muss der Wert des Headers "Content-Transfer-Encoding" binär sein.

  • Gemäß [XOP] Abschnitt 5,

  • R4148: Ein SOAP 1.1-Infosetteil muss den Content-Type-Header mit dem Medientyp "application/xop+xml" und Parametertyp "text/xml" sowie „charset“ enthalten.

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

  • R4149: Der SOAP 1.2-Infosetteil muss den Content-Type-Header mit dem Medientyp application/xop+xml und Parametertyp "application/soap+xml" sowie charset enthalten.

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

    Während XOP den charset Parameter als application/xop+xml optional definiert, ist er für die Interoperabilität erforderlich, die der BP 1.1-Anforderung für den Parameter für den charsettext/xml Medientyp ähnelt.

  • R41410: Die Parameter type und charset müssen im Content-Type-Header des SOAP 1.x Infoset-Teils vorliegen.

WCF-Endpunktunterstützung für MTOM

Der Zweck von MTOM besteht darin, eine SOAP-Nachricht zu codieren, um base64-codierte Daten zu optimieren. Es folgt eine Liste mit Einschränkungen:

  • R4151: Jedes Elementinformationselement, das base64-codierte Daten enthält, kann optimiert werden.

  • B4152: WCF optimiert Elementinformationselemente, die base64-codierte Daten enthalten und 1024 Byte länge überschreiten.

Ein WCF-Endpunkt, der für die Verwendung von MTOM konfiguriert ist, sendet immer MTOM-codierte Nachrichten. Auch wenn keine Teile die erforderlichen Kriterien erfüllen, wird die Nachricht weiterhin MTOM-codiert (serialisiert als MIME-Paket mit einem einzelnen MIME-Teil, der den SOAP-Umschlag enthält).

WS-Policy-Assertion für MTOM

Die WCF verwendet die folgende Richtlinienassertion, um die MTOM-Verwendung durch den Endpunkt anzugeben:

<wsoma:OptimizedMimeSerialization />

  • R4211: Die vorangehende Richtlinienaussage weist ein Endpunktrichtlinienthema auf und gibt an, dass alle Nachrichten, die an den Endpunkt gesendet werden und vom Endpunkt empfangen werden, mithilfe von MTOM optimiert werden müssen.

  • B4212: Wenn ein WCF-Endpunkt für die Verwendung der MTOM-Optimierung konfiguriert wird, fügt er eine MTOM-Richtlinien-Assertion zur Richtlinie hinzu, die dem entsprechenden wsdl:binding zugeordnet ist.

Gestaltung mit WS-Sicherheit

MTOM ist ein Mechanismus zur Codierung, der ähnlich wie bei text/xml und WCF Binary XML ist. MTOM bietet natürliche Zusammensetzung mit WS-Security und anderen WS-*-Protokollen: Eine mit WS-Security gesicherte Nachricht kann mithilfe von MTOM optimiert werden.

Beispiele

WCF SOAP 1.1-Nachricht codiert mit 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 codiert mit MTOM

In diesem Beispiel wird eine Nachricht mit MTOM und SOAP 1.2 codiert, die mit WS-Security geschützt ist. Die binären Teile, die für die Codierung identifiziert wurden, sind der Inhalt von BinarySecurityToken und CipherValue des EncryptedData, die der verschlüsselten Signatur und dem verschlüsselten Körper entsprechen. Beachten Sie, dass das CipherValue von EncryptedKey nicht für die Optimierung durch WCF identifiziert wurde, da seine Länge kleiner als 1024 Bytes ist.

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--