Mesajlaşma Protokolleri

Windows Communication Foundation (WCF) kanal yığını, iç ileti gösterimini kablo biçimine dönüştürmek ve belirli bir aktarım kullanarak göndermek için kodlama ve aktarım kanalları kullanır. Web hizmetlerinin birlikte çalışabilirliği için kullanılan en yaygın aktarım HTTP'dir ve Web hizmetleri tarafından kullanılan en yaygın kodlamalar XML tabanlı SOAP 1.1, SOAP 1.2 ve İleti İletim İyileştirme Mekanizması'dır (MTOM).

Bu konu, tarafından HttpTransportBindingElementkullanılan aşağıdaki protokoller için WCF uygulama ayrıntılarını kapsar.

Şartname/belge:

Bu konu, TextMessageEncodingBindingElement ve MtomMessageEncodingBindingElement tarafından kullanılan aşağıdaki protokoller için WCF uygulama ayrıntılarını kapsar.

Şartname/Belge:

Aşağıdaki protokolleri kullanan MtomMessageEncodingBindingElement için WCF uygulama ayrıntılarını kapsayan bu konudur.

Şartname/belge:

Bu konu başlığında aşağıdaki XML ad alanları ve ilişkili ön ekler kullanılır:

Önek	Ad Alanı Tekdüzen Kaynak Tanımlayıcısı (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 ve SOAP 1.2

Zarf ve İşleme Modeli

WCF, Temel Profil 1.1 (BP11) ve Temel Profil 1.0 (SSBP10) sonrasında SOAP 1.1 zarf işleme uygular. SOAP 1.2 Zarf işleme, SOAP12-Part1 sonrasında uygulanır.

Bu bölümde, BP11 ve SOAP12-Part1 ile ilgili olarak WCF tarafından alınan bazı uygulama seçimleri açıklanmaktadır.

Zorunlu Üst Bilgi İşleme

WCF, SOAP 1.1 ve SOAP 1.2 belirtimlerinde açıklanan başlıkların işlenmesine yönelik kuralları, aşağıdaki varyasyonlarla izler.

WCF kanal yığınına giren bir ileti, metin iletisi kodlaması, güvenlik, güvenilir mesajlaşma ve işlemler gibi ilişkili bağlama öğeleri tarafından yapılandırılan tek tek kanallar tarafından işlenir. Her kanal, ilişkili ad alanından üst bilgileri tanır ve anlaşılır olarak işaretler. İleti dağıtıcıya girdikten sonra, işlem biçimlendirici ilgili ileti/işlem sözleşmesi tarafından beklenen üst bilgileri okur ve anlaşıldı olarak işaretler. Ardından dağıtıcı, kalan üst bilgilerin anlaşılmadığı halde mustUnderstand olarak işaretlenip işaretlenmediğini doğrular ve bir istisna oluşturur. Alıcıyı hedefleyen üst bilgiler içeren mustUnderstand iletiler, alıcı uygulama kodu tarafından işlenmez.

Bu tür katmanlı işleme, ALTYAPı katmanları ile SOAP düğümünün uygulama katmanları arasında ayrım yapılmasını sağlar:

B1111: Anlaşılmayan başlıklar, ileti WCF altyapı kanal yığını tarafından işlem gördükten sonra, fakat uygulama tarafından işlenmeden önce tespit edilir.

Başlık mustUnderstand değeri SOAP 1.1 ile SOAP 1.2 arasında farklılık gösterir. Temel Profil 1.1, SOAP 1.1 iletileri için değerin mustUnderstand 0 veya 1 olmasını gerektirir. SOAP 1.2, 0, 1, falseve true değerlerine izin verir, ancak değerlerin kurallı gösterimini xs:boolean (false, true) yaymanızı önerir.
B1112: WCF, SOAP zarfının mustUnderstand hem SOAP 1.1 hem de SOAP 1.2 sürümleri için 0 ve 1 değerlerini yayar. WCF, xs:boolean üst bilgisi için mustUnderstand tüm değer alanını kabul eder (0, 1, false, true)

SOAP Hata Mesajları

Aşağıda WCF'ye özgü SOAP hata uygulamalarının listesi yer alır.

B2121: WCF, şu SOAP 1.1 Hata Kodlarını döndürür: s11:mustUnderstand, s11:Clientve s11:Server.
B2122: WCF, şu SOAP 1.2 Hata Kodlarını döndürür: s12:MustUnderstand, s12:Senderve s12:Receiver.

HTTP Bağlama

SOAP 1.1 HTTP Bağlaması

WCF, SOAP1.1 HTTP bağlamasını, Temel Profil 1.1 belirtimi bölüm 3.4'e uygun olarak, aşağıdaki açıklamalarla birlikte uygular:

B2211: WCF hizmeti HTTP POST isteklerinin yeniden yönlendirmesini uygulamaz.
B2212: WCF istemcileri HTTP Çerezlerini 3.4.8'e uygun olarak destekler.

SOAP 1.2 HTTP Bağlaması

WCF, SOAP 1.2 bölüm 2 (SOAP12Part2) belirtiminde açıklandığı gibi SOAP 1.2 HTTP bağlamasını aşağıdaki açıklamalarla uygular.

SOAP 1.2, medya türü için application/soap+xml isteğe bağlı bir eylem parametresini kullanıma sunar. Bu parametre, WS-Addressing kullanılmadığında SOAP iletisinin gövdesinin ayrıştırılması gerekmeden ileti dağıtımını iyileştirmek için yararlıdır.

R2221: application/soap+xml Bir SOAP 1.2 isteğinde mevcut olduğunda eylem parametresi, ilgili WSDL bağlamasının soapAction içindeki öğedeki özniteliğiyle eşleşmelidirwsoap12:operation.
R2222: SOAP 1.2 iletisinde mevcut olduğunda, application/soap+xml eylem parametresinin, WS-Addressing 2004/08 veya WS-Addressing 1.0 kullanıldığında wsa:Action ile eşleşmesi gerekir.

WS-Addressing devre dışı bırakıldığında ve gelen istek bir eylem parametresi içermiyorsa, ileti Action belirtilmemiş olarak kabul edilir.

WS-Addressing

WCF, WS-Addressing'in 3 sürümünü uygular:

WS-Addressing 2004/08
W3C Web Services Addressing 1.0 Core (ADDR10-CORE) ve SOAP Bağlama (ADDR10-SOAP)
WS-Addressing 1.0 - Meta Veriler

Uç Nokta Referansları

WCF'nin uyguladığı tüm WS-Addressing sürümleri, uç noktaları açıklamak için uç nokta başvurularını kullanır.

Uç Nokta Referansları ve WS-Addressing Versiyonları

WCF, bir dizi altyapı protokolü uygular; WS-Addressing'ı ve özellikle EndpointReference öğesini ve W3C.WsAddressing.EndpointReferenceType sınıfını kullanan (örneğin, WS-ReliableMessaging, WS-SecureConversation ve WS-Trust). WCF, diğer altyapı protokolleriyle WS-Addressing sürümlerinden birinin kullanımını destekler. WCF uç noktaları, uç nokta başına bir WS-Addressing sürümünü destekler.

R3111 için EndpointReference , WCF uç noktasıyla iletilerde kullanılan öğenin veya türün ad alanı, bu uç nokta tarafından uygulanan WS-Addressing sürümüyle eşleşmelidir.

Örneğin, bir WCF uç noktası WS-ReliableMessaging uyguluyorsa, AcksTo içindeki CreateSequenceResponse üst bilgisi, EncodingBinding öğesinin bu uç nokta için belirttiği WS-Addressing sürümünü kullanır.

Uç Nokta Başvuruları ve Meta Verileri

Çeşitli senaryolar için meta verilerin iletilmesi veya belirli bir uç noktanın meta verilerine başvuru yapılması gerekir.

B3121: WCF, uç noktaların meta verilerini değer veya referans olarak dahil etmek için WS-MetadataExchange (MEX) özelliği Bölüm 6'da açıklanan mekanizmaları kullanır.

Bir WCF hizmetinin http://sts.fabrikam123.com adresinde yer alan belirteç sağlayıcı tarafından verilen bir Güvenlik Onayları Biçimlendirme Dili (SAML) belirteci kullanarak kimlik doğrulaması gerektiği bir senaryo düşünün. WCF uç noktası, sp:IssuedToken onayı kullanarak ve belirteç verene işaret eden iç içe sp:Issuer onay ile bu kimlik doğrulama gereksinimini açıklar. Onaya erişen istemci uygulamalarının sp:Issuer belirteç veren uç noktasıyla nasıl iletişim kuracaklarını bilmesi gerekir. İstemcinin belirteç veren hakkındaki meta verileri bilmesi gerekir. WCF, MEX'te tanımlanan uç nokta başvuru meta veri eklemelerini kullanarak, belirteç verenin meta verilerine atıfta bulunur.

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

Mesaj Adresleme Başlıkları

İleti Üst Bilgileri

WCF, hem wsa:To hem de wsa:ReplyTo olmak üzere her iki WS-Addressing sürümü için, belirlenen yöntemler uyarınca aşağıdaki mesaj başlıklarını kullanır: wsa:To, wsa:ReplyTo, wsa:RelatesTo, , ve .

B3211: Tüm WS-Addressing sürümleri için WCF, wsa:FaultTo ve wsa:FromWS-Addressing ileti üst bilgilerini tanır, ancak bunları varsayılan olarak üretmez.

WCF uygulamalarıyla etkileşim kuran uygulamalar bu ileti üst bilgilerini ekleyebilir ve WCF bunları uygun şekilde işler.

Başvuru Parametreleri ve Özellikleri

WCF, ilgili belirtimlere uygun olarak uç nokta başvuru parametrelerinin ve başvuru özelliklerinin işlenmesini uygular.

B3221: WS-Addressing 2004/08 kullanacak şekilde yapılandırıldığında, WCF uç noktaları Başvuru Özelliklerini ve Başvuru Parametrelerini işleme arasında ayrım yapmaz.

İleti Değişimi Desenleri

Web hizmeti işlemi çağrısında yer alan iletilerin dizisi, ileti değişimi deseni olarak adlandırılır. WCF tek yönlü, istek-yanıt ve çift yönlü ileti değişim desenlerini destekler. Bu bölümde, kullanılan ileti değişimi düzenine bağlı olarak ileti işlemeye ilişkin WS-Addressing gereksinimleri açıklanmıştır.

Bu bölüm boyunca istekte bulunan ilk iletiyi gönderir ve yanıtlayan ilk iletiyi alır.

One-Way İleti

Bir WCF uç noktası, tek yönlü bir deseni izlemek için verilen Action ile iletileri destekleyecek şekilde yapılandırıldığında, WCF uç noktası aşağıdaki davranışlara ve gereksinimlere uyar. Aksi belirtilmedikçe, davranışlar ve kurallar WCF'de desteklenen her iki WS-Addressing sürümü için de geçerlidir:

R3311: İstekte bulunan, uç nokta referansı tarafından belirtilen tüm başvuru parametreleri için wsa:To, wsa:Action ve başlıkları içermelidir. WS-Addressing 2004/08 kullanıldığında ve [başvuru özellikleri] uç nokta referansı aracılığıyla belirtildiğinde, ilgili üst bilgiler de iletiye eklenmelidir.
B3312: İstekte bulunan, MessageID, ReplyTo ve FaultTo üst bilgilerini içerebilir. Alıcı altyapısı bunları yoksayar ve uygulamaya iletilir.
R3313: HTTP kullanıldığında ve HTTP yanıt bacağında ileti gönderilmediğinde, yanıtlayanın boş gövdeli bir HTTP yanıtı ve HTTP 202 durum kodu göndermesi gerekir.

HTTP aktarımı kullanımda olduğunda ve işlem sözleşmesi bir iletiyi tek yönlü olarak bildirdiğinde, HTTP yanıtı altyapı iletileri göndermek için kullanılabilir; örneğin, güvenilir mesajlaşma bir HTTP yanıtında ileti SequenceAcknowledgement gönderebilir.
B3314: WCF yanıtlayıcısı tek yönlü iletiye yanıt olarak hata iletisi göndermez.

Request-Reply

BIR WCF uç noktası, istek-yanıt desenini izlemek üzere verilen Action bir ileti için yapılandırıldığında, WCF uç noktası aşağıdaki davranışlara ve gereksinimlere uyar. Aksi belirtilmedikçe, davranışlar ve kurallar WCF'de desteklenen her iki WS-Addressing sürümü için de geçerlidir:

R3321: İstek sahibi, uç nokta başvurusu tarafından belirtilen tüm başvuru parametreleri veya başvuru özellikleri (veya her ikisi) için wsa:To, wsa:Action, wsa:MessageID ve üst bilgilerini isteğe eklemelidir.
R3322: WS-Addressing 2004/08 kullanıldığında, ReplyTo isteğe de dahil edilmelidir.
R3323: WS-Addressing 1.0 kullanıldığında ve ReplyTo istekte mevcut olmadığında, [address] özelliğine http://www.w3.org/2005/08/addressing/anonymous eşit bir varsayılan uç nokta başvurusu kullanılır.
R3324: İstekte bulunan, yanıt iletisinde wsa:To, wsa:Action ve wsa:RelatesTo üst bilgilerini ve ayrıca istekteki ReplyTo uç nokta başvurusu tarafından belirtilen tüm başvuru parametreleri veya başvuru özellikleri (veya her ikisi) için üst bilgileri içermelidir.

Hataları Gideren Web Hizmetleri

R3411: WCF, WS-Addressing 2004/08 tarafından tanımlanan aşağıdaki hataları üretir.

Kod	Nedeni
`wsa:DestinationUnreachable`	İleti, bu kanal için oluşturulan yanıt adresinden farklı bir `ReplyTo` mesaj ile geldi; Kime başlığında belirtilen adreste dinleyen bir uç nokta yok.
`wsa:ActionNotSupported`	uç noktayla ilişkilendirilmiş altyapı kanalları veya dağıtıcı üst bilgide `Action` belirtilen eylemi tanımıyor.

R3412: WCF, WS-Addressing 1.0 tarafından tanımlanan aşağıdaki hataları üretir.

Kod	Nedeni
`wsa10:InvalidAddressingHeader`	Çoğalt `wsa:To`, `wsa:ReplyTo`, `wsa:From` veya `wsa:MessageID`. Aynı `wsa:RelatesTo` ile `RelationshipType` çoğaltın.
`wsa10:MessageAddressingHeaderRequired`	Gerekli Adresleme üst bilgisi eksik.
`wsa10:DestinationUnreachable`	İleti, bu kanal için oluşturulan yanıt adresinden farklı bir `ReplyTo` iletiyle geldi. Bitiş üst bilgisinde belirtilen adreste dinleyen uç nokta yok.
`wsa10:ActionNotSupported`	Üst bilgide `Action` belirtilen bir işlem, uç noktayla ilişkilendirilmiş altyapı kanalları veya dağıtıcı tarafından tanınmaz.
`wsa10:EndpointUnavailable`	RM kanalı bu hatayı geri gönderir ve uç nokta, `CreateSequence` iletisinin adresleme üst bilgilerini inceledikten sonra sırayı işlemeyeceğini belirtir.

Önceki tablolardaki kod, SOAP 1.1'de FaultCode'ya ve (Code=Sender ile) SOAP 1.2'de SubCode'ye eşleniyor.

WSDL 1.1 Bağlama ve WS-Policy Savları

WS-Addressing Kullanımını Gösteren İşareti

WCF, belirli bir WS-Addressing sürümü için uç nokta desteğini belirtmek için ilke onaylarını kullanır.

Aşağıdaki ilke beyanı, Uç Nokta İlkesi Konusu [WS-PA] içerir ve uç noktadan gönderilen ve alınan iletilerin WS-Addressing 2004/08 kullanması gerektiğini gösterir.

<wsap:UsingAddressing />

Bu ilke beyanı, WS-Addressing 2004/08 belirtimini desteklemektedir.

Aşağıdaki ilke onayı, gönderilen/alınan iletilerin WS-Addressing 1.0 kullanması gerektiğini gösterir.

<wsam:Addressing/>

Aşağıdaki ilke beyannamesi, Uç Nokta Politikası Konusuna [WS-PA] sahiptir ve uç noktadan gönderilen ve alınan mesajların WS-Addressing 2004/08 kullanmak zorunda olduğunu gösterir.

<wsaw10:UsingAddressing />

wsaw10:UsingAddressing öğesi [WS-Addressing-WSDL] öğesinden ödünç alınır ve bu belirtim, bölüm 3.1.2'ye uygun olarak WS-Policy bağlamında kullanılır.

Adresleme kullanımı WSDL 1.1, SOAP 1.1 ve SOAP 1.2 HTTP Bağlamalarının semantiğini değiştirmez. Örneğin, Adresleme ve WSDL SOAP 1.x HTTP bağlaması kullanan bir uç noktaya gönderilen bir isteğe yanıt bekleniyorsa, yanıtın HTTP yanıtı kullanılarak gönderilmesi gerekir.

HTTP yanıtı üzerinden gönderilen yanıtlar için WS-AM bildirimi şöyledir:

<wsam:AnonymousResponses/>

İlke onaylama işleminin tamamı şöyle görünebilir:

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

Ancak, istekte bulunan ve yanıtlayan arasında iki bağımsız karşılıklı HTTP bağlantısı kurulmasının (örneğin, yanıtlayan tarafından gönderilen istenmeyen tek yönlü iletiler) yarar sağlayan ileti değişimi desenleri vardır.

WCF, temel alınan iki aktarım kanalının bileşik çift yönlü kanal oluşturabileceği, bir kanalın giriş iletileri için, diğerinin ise çıkış iletileri için kullanıldığı bir özellik sunar. HTTP Aktarımı söz konusu olduğunda, Composite Duplex iki karşılıklı HTTP bağlantısı sağlar. İstekte bulunan, yanıtlayana ileti göndermek için bir bağlantı kullanır ve yanıtlayan diğerini kullanarak istekte bulunana ileti gönderir.

Ayrı http istekleri üzerinden gönderilen yanıtlar için ws-am onayı şu şekildedir:

<wsam:NonAnonymousResponses/>

İlke onaylama işleminin tamamı şöyle görünebilir:

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

WSDL 1.1 SOAP 1.x HTTP bağlamalarını kullanan uç noktalarda Uç Nokta İlkesi Konusu [WS-PA] ile ilgili aşağıdaki onayın kullanılması, istek sahibinden yanıtlayana ve yanıtlayandan isteyene giden iletiler için ayrı iki HTTP bağlantısının kullanılmasını gerektirir.

<cdp:CompositeDuplex/>

Önceki ifade, istek iletileri için wsa:ReplyTo üst başlığında aşağıdaki gereksinimlere yol açar:

R3514: Uç noktaya gönderilen istek iletilerinin, uç nokta WSDL 1.1 SOAP 1.x HTTP bağlaması kullanıyorsa ve bir ReplyTo veya [address] onayı ile beraber http://www.w3.org/2005/08/addressing/anonymous ekli bir ilke alternatifi varsa, özelliği wsap10:UsingAddressing eşit olmayan bir wsap:UsingAddressing üst bilgiye sahip olması gerekir.
R3515: Uç noktanın WSDL 1.1 SOAP 1.x HTTP bağlaması kullanması ve bir ReplyTo onayı içeren, ancak bir [address] onayı içermeyen bir ilke alternatifine sahip olması durumlarında, uç noktaya gönderilen istek iletilerinin ya http://www.w3.org/2005/08/addressing/anonymous özelliğine sahip bir ReplyTo üst bilgisine sahip olması ya da hiç wsap10:UsingAddressing üst bilgisi içermemesi gerekir.
R3516: Uç noktaya gönderilen istek iletilerinin, uç nokta WSDL 1.1 SOAP 1.x HTTP bağlaması kullanıyor ve ReplyTo onayı içeren bir ilke alternatifi varsa ve [address] onayı eklenmemişse, http://www.w3.org/2005/08/addressing/anonymous değerine eşit bir wsap:UsingAddressing özelliğine sahip cdp:CompositeDuplex üst bilgisi olmalıdır.

WS-Adresleme WSDL belirtimi, <wsaw:Anonymous/> üstbilgisi üzerindeki gereksinimleri belirtmek için üç metin değeri (gerekli, isteğe bağlı ve yasak) ile bir wsa:ReplyTo öğesi tanıtarak benzer protokol bağlamalarını tanımlamaya çalışır (bölüm 3.2). Ne yazık ki, bu tür öğe tanımı özellikle WS-policy bağlamında onay olarak kullanılamaz, çünkü onay olarak böyle bir öğeyi kullanan alternatiflerin kesişimini desteklemek için etki alanına özgü uzantılar gerektirir. Bu tür öğe tanımı, kablodaki ReplyTo uç nokta davranışının aksine üst bilginin değerini de gösterir ve bu da onu HTTP aktarımına özgü hale getirir.

Eylem Tanımı

WS-Addressing 2004/08, wsa:Action öğeleri için wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] özniteliğini tanımlar. WS-Addressing 1.0 WSDL Bağlaması (WS-ADDR10-WSDL) benzer bir özniteliği tanımlar. wsaw10:Action

İkisi arasındaki tek fark, sırasıyla WS-ADDR bölüm 3.3.2 ve WS-ADDR10-WSDL'nin 4.4.4. bölümünde açıklanan varsayılan Eylem düzeni semantiğidir.

WS-Addressing'in farklı sürümlerini kullanarak aynı portType (veya WCF terminolojisinde sözleşme) paylaşan iki uç noktanın olması mantıklıdır. Ancak, Eylemin portType tarafından tanımlandığı ve portType'i uygulayan uç noktalar arasında değişmemesi gerektiği göz önüne alındığında, her iki varsayılan eylem desenini desteklemek imkansız hale gelir.

Bu tartışmayı çözmek için WCF özniteliğin Action tek bir sürümünü destekler.

B3521: WCF, WS-ADDR10-WSDL'de tanımlandığı şekilde wsaw10:Action özniteliğini wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] öğeleri üzerinde kullanarak, uç noktanın kullandığı WS-Addressing sürümünden bağımsız olarak ilgili iletiler için Action URI'sini belirler.

WSDL Bağlantı Noktasında Uç Nokta Başvurusu Kullanma

WS-ADDR10-WSDL bölüm 4.1, wsdl:port öğesini, uç noktayı WS-Addressing terimlerle açıklamak üzere <wsa10:EndpointReference…/> alt öğesini içerecek şekilde genişletir. WCF, bu yardımcı programı WS-Addressing 2004/08 tarihinde genişleterek <wsa:EndpointReference…/> öğesinin wsdl:portalt öğesi olarak görünmesini sağlar.

R3531: Bir uç noktanın ilke onayını içeren ekli bir <wsaw10:UsingAddressing/> ilke alternatifi varsa, ilgili wsdl:port öğe bir alt öğesi <wsa10:EndpointReference …/>içerebilir.
R3532: Bir wsdl:port alt öğe <wsa10:EndpointReference …/>içeriyorsa, wsa10:EndpointReference/wsa10:Address alt öğe değeri eşdüzey @addresswsdl:port/ öğenin özniteliğinin değeriyle wsdl:location eşleşmelidir.
R3533: Bir uç noktanın ilke onayını içeren ekli bir ilke alternatifi <wsap:UsingAddressing/> varsa, ilgili wsdl:port öğe bir alt öğesi <wsa:EndpointReference …/>içerebilir.
R3534: Bir wsdl:port alt öğe <wsa:EndpointReference …/>içeriyorsa, wsa:EndpointReference/wsa:Address alt öğe değeri eşdüzey @addresswsdl:port/ öğenin özniteliğinin değeriyle wsdl:location eşleşmelidir.

WS-Security ile kompozisyon

WS-ADDR ve WS-ADDR10'daki güvenlik konuları bölümlerine göre, tüm adresleme iletisi üst bilgilerinin, bunları birbirine bağlamak için ileti gövdesiyle birlikte imzalanması önerilir.

İleti bütünlüğü koruması için WS-Security kullanıldığında, WS-Addressing ileti üst bilgilerinin yanı sıra başvuru parametrelerinden veya özelliklerinden (veya her ikisinden) kaynaklanan üst bilgiler iletinin gövdesiyle birlikte imzalanmalıdır.

Örnekler

One-Way İleti

Bu senaryoda, gönderen alıcıya tek yönlü bir ileti gönderir. SOAP 1.2, HTTP 1.1 ve W3C WS-Addressing 1.0 kullanılır.

İstek İleti Yapısı: İleti üst bilgileri wsa10:To ve wsa10:Action öğelerini içerir. İleti gövdesi, uygulama ad alanından belirli <app:Ping> bir öğe içerir.

HTTP Üstbilgileri: POST içindeki hedef, wsa10:To elemanındaki URI ile eşleşir.

content-Type üst bilgisi SOAP 1.2 için gerekli olan değerine application/soap+xml sahiptir. Parametreler charset ve action dahil edilmiştir. action Content-Type başlığının parametresi, ileti başlığının wsa10:Action değeriyle eşleşir.

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>

Alıcı boş bir HTTP yanıtı ve 202 durumuyla yanıt verir. HTTP yanıtı örneği:

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 İleti İletimi İyileştirme Mekanizması

Bu bölümde, HTTP SOAP MTOM için WCF uygulama ayrıntıları açıklanmaktadır. MTOM teknolojisi, geleneksel metin/XML kodlama veya WCF İkili kodlama ile aynı sınıfın SOAP ileti kodlama mekanizmasıdır. MTOM şunları içerir:

[XOP] tarafından tanımlanan ve base64 kodlanmış ikili verileri içeren XML bilgi öğelerini ayrı ikili parçalara en iyi duruma getiren bir XML kodlama ve paketleme mekanizması.
XML Infoset'ini ve XOP paketinin her ikili bölümünü ayrı bir MIME parçasına seri hale getiren XOP paketinin MIME kapsüllemesi.
SOAP 1.x Zarf'a uygulanan MIME XOP kodlaması.
HTTP aktarım bağlaması.

WCF ile HTTP olmayan aktarımlarda MTOM kullanmak mümkündür. Ancak, bu konuda HTTP'ye odaklanacağız.

MTOM biçimi, MTOM'un kendisini, XOP'yi ve MIME'yi kapsayan büyük bir belirtim kümesinden yararlanmaktadır. Bu belirtim kümesinin modülerliği, biçim ve işleme semantiği üzerinde tam gereksinimlerin yeniden yapılandırılmasını biraz zorlaştırır. Bu bölümde MTOM HTTP bağlaması için biçim ve işleme gereksinimleri açıklanmaktadır.

MTOM İleti Kodlaması

MTOM iletileri oluşturma

[XOP] bölüm 3.1, base64 değerleri içeren öğe bilgileri öğeleriyle XML'i soyut olarak tanımlanmış bir XOP paketine kodlama işlemini açıklar.

Aşağıdaki adım dizisi, MTOM'a özgü kodlama işlemini açıklar:

Kodlanacak SOAP Zarfı'nın herhangi bir öğe bilgisi öğesinin [namespace name] öğesi http://www.w3.org/2004/08/xop/include ile ve [local name] öğesi Include ile olmadığından emin olun.
Boş bir MIME paketi oluşturun.
en iyi duruma getirilecek öğe bilgileri öğelerini Özgün XML Bilgi Kümesi içinde tanımlayın. Öğelerin en iyi duruma getirilebilmesi için, öğe bilgi öğesini oluşturan [children] karakterlerin kurallı biçiminde xs:base64Binary (bkz. XSD-2, 3.2.16 base64Binary) olması ve boşluk olmayan içerikten önce gelen, satır içi veya izleyen boşluk karakterleri içermemesi gerekir.
Özgün SOAP Zarfı'nın bir kopyası olan, fakat önceki adımda tanımlanan her öğe bilgi öğesinin alt öğelerinin yerine aşağıdaki gibi oluşturulmuş bir xop:Include öğe bilgi öğesi getirilen bir XOP SOAP Zarfı oluşturun.
1. Değiştirilen karakterleri base64 ile kodlanmış veri olarak işleyerek ikili verilere dönüştürün.
2. R3133 ve R3134 gereksinimlerini karşılayan benzersiz bir Content-ID üst bilgi değeri oluşturun.
3. İkili değere sahip bir content-Transfer-Encoding MIME üst bilgisi oluşturun.
4. İyileştirilen öğe bilgi öğesinin (yeni eklenen xop:Include öğe bilgi öğesinin [üst] öğesi) bir xmime:contentType özniteliği varsa, xmime:contentType özniteliğinin değeriyle bir içerik-tipi MIME üst bilgisi oluşturun.
5. Base64 olarak işlenen değiştirilen karakterlerden kod çözülen ikili veriler tarafından oluşturulan içerik, 4b'den Content-ID üst bilgisi, 4c'den Content- Transfer-Encoding üst bilgisi, 4d adımında oluşturulduysa Content-Type üst bilgisi ile yeni bir ikili MIME bölümü oluşturun.
6. Adım 4b'de oluşturulan Content-ID başlık değerinden türetilen cid: URI değeriyle href öğesine bir xop:Include öznitelik ekleyin. Kapsayan "<" ve ">" karakterlerini kaldırın, kalan dizeye URL kaçışı yapın ve ön ekini cid:ekleyin. aşağıdaki en düşük karakter kümesinin RFC1738 ve RFC2396 tarafından kaçılması gerekir. Diğer karakterler kaçırılabilir.
```
Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
"{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"
```
4. adımdaki XOP SOAP Zarfı ile bir kök MIME bölümü oluşturun.
HTTP İçerik Türü üst bilgisi de dahil olmak üzere HTTP üst bilgilerini yazın.
MIME paketini yazın.

MTOM iletilerini işleme

MTOM iletisinin işlenmesi, önceki "MTOM iletileri oluşturma" bölümünde açıklanan işlemin tam tersidir:

Kök MIME bölümünde content-Type application/xop+xmlolduğundan emin olun.
Paketin kök MIME bölümünü XML belgesi olarak ayrıştırarak SOAP Zarfı oluşturma. Karakter kodlaması, kök MIME bölümünün content-Type parametresi tarafından charset belirlenir.
Oluşturulan SOAP Zarfı'ndaki [children] özelliğinin tek üyesi olarak bir xop:Include öğe bilgi öğesi bulunduran her öğe bilgi öğesi için:
1. "cid:" ön ekini kaldırın ve @href öğesinin xop:Include özniteliğindeki değer içindeki tüm URI kaçış dizilerini (RFC 2396) çözümleyin. Sonuç dizesini "<", ">" içine alın.
2. 3a adımında türetilen dizeyle eşleşen Content-ID üst bilgi değeriyle MIME bölümünü bulun.
3. xop:Include Her öğenin özelliğinde görüntülenen öğe bilgileri öğesini, adım 3b'de children tanımlanan MIME bölümünün varlık gövdesinin kurallı base64 kodlamasını temsil eden karakter bilgileri öğeleriyle (bkz. XSD-2, 3.2.16 base64Binary) değiştirin (öğe bilgileri öğesini etkili bir şekilde paket bölümünden yeniden oluşturulmuş verilerle değiştirinxop:Include).

HTTP İçerik Türü Üst Bilgisi

Aşağıda, MTOM belirtiminde belirtilen gereksinimlerden türetilen ve MTOM ve RFC 2387'den türetilen SOAP 1.x MTOM kodlu iletinin HTTP İçerik Türü üst bilgisinin biçimine ilişkin WCF açıklamalarının listesi yer alır.

R4131: HTTP İçerik Türü üst bilgisi, çok bölümlü/ilişkili (büyük/küçük harfe duyarlı olmayan) değerine ve parametrelerine sahip olmalıdır. Parametre adları büyük/küçük harfe duyarlı değildir. Parametre sırası önemli değil.
MIME iletileri için İçerik Türü üst bilgisinin tam Backus-Naur Formu (BNF), RFC 2045, bölüm 5.1'de listelenir.
R4132: Bir HTTP Content-Type üst başlığının, değeri çift tırnak içine alınmış application/xop+xml olan bir tür parametresi içermesi gerekir.

RFC 2387'de çift tırnak işareti kullanma gereksinimi açık olmasa da, metinde çok bölümlü/ilgili medya türü parametrelerinin tümü büyük olasılıkla "@" veya "/" gibi ayrılmış karakterler içerdiğini ve bu nedenle çift tırnak işaretine ihtiyaç duyulduğunu gözlemler.

R4133: HTTP İçerik Türü üst bilgisinde, çift tırnak içine alınmış bir başlangıç parametresi olarak, SOAP 1.x Zarfını içeren MIME bölümünün Content-ID üst bilgisinin değeri kullanılmalıdır. Başlangıç parametresi atlanırsa, ilk MIME bölümü SOAP 1.x Zarfını içermelidir.
R4134: SOAP 1.1 MTOM ile kodlanmış iletinin HTTP İçerik Türü üst bilgisi, çift tırnak içine alınmış metin/xml değeriyle start-info parametresini içermelidir.
R4135: SOAP 1.2 MTOM kodlu ileti için HTTP İçerik Türü üst bilgisi, değeri çift tırnak içine alınmış start-info parametresini application/soap+xmliçermelidir.

R4136: SOAP 1.x MTOM ile kodlanmış bir iletinin HTTP İçerik Türü üst bilgisi, RFC 2046, bölüm 5.1.1'de tanımlanan MIME sınırı BNF ile eşleşen değerle (çift tırnak içine alınmış) sınır parametresine sahip olmalıdır

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

Örnekler:

DOĞRU

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"

DOĞRU

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

YANLIŞ

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 Bölümü

SOAP 1.x Zarfı, XOP MIME paketinin kök parçası olarak kapsüllenerek genellikle infoset parçası olarak adlandırılır.

R4141: SOAP 1.x Zarfı, XOP MIME paketinin kök parçası olarak kapsüllenmelidir ve infoset bölümü olarak adlandırılır ve HTTP İçerik Türünden referans almalıdır.
R4142: SOAP Infoset bölümü şu MIME üst bilgilerini içermelidir: Content-ID, Content-Transfer-Encodingve Content-Type.

Content-ID üst bilgisinin biçimi RFC 2045 tarafından şu şekilde tanımlanır:

"Content-ID" ":" msg-id

rfc msg-id 2822'de (RFC 2045'te başvuruda bulunan RFC 822'nin yerini alan) şu şekilde tanımlanır:

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

ve "<" ve ">" içine alınmış etkin bir e-posta adresidir. Rfc [CFWS] 2822'de açıklamaları taşımak için önek ve sonek eklenmiştir ve birlikte çalışabilirliği korumak için kullanılmamalıdır.

R4143: Infoset MIME bölümünün Content-ID üst bilgisinin değeri, önek ve sonek bölümlerinin atıldığı haliyle RFC 2822'de belirtilen msg-id üretim kuralına uygun olmalıdır.

Bazı MIME uygulamaları, "<" ve ">" içinde yer alan değerin bir e-posta adresi olma zorunluluğunu gevşetti ve e-posta adresine ek olarak "absoluteURI", "<" içinde yer alan >'yi kullandı. WCF'nin bu sürümü, formun Content-ID MIME üst bilgisinin değerlerini kullanır:

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

R4144: MTOM işlemcileri, aşağıdaki gevşek msg-idile eşleşen Content-ID üst bilgi değerlerini kabul etmelidir.

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

MIME (RFC 2045), MIME bölümünün içeriğinin kodlamasını iletmek için content-Transfer-Encoding üst bilgisini sağlar. Content-Transfer-Encoding için varsayılan olarak tanımlanan 7 bittir ve bu çoğu SOAP iletisi için uygun değildir, bu nedenle daha fazla birlikte çalışabilirlik için content-Transfer-Encoding üst bilgisi gereklidir:

R4145: SOAP Infoset bölümü content-Transfer-Encoding üst bilgisini içermelidir.
R4146: SOAP Zarfı karakter kodlaması UTF-8 ise content-Transfer-Encoding üst bilgisinin değeri 8 bit olmalıdır.
R4147: SOAP Zarfı karakter kodlaması UTF-16 ise, content-Transfer-Encoding üst bilgisinin değeri ikili olmalıdır.
[XOP] bölüm 5'e göre,
R4148: SOAP1.1 Infoset bölümü, application/xop+xml medya türüne sahip Content-Type üst bilgisi ve type="text/xml" ve charset parametreleri içermelidir
```
Content-Type: application/xop+xml;
              charset=utf-8;type="text/xml"
```
R4149: SOAP 1.2 Infoset bölümü, medya türü application/xop+xml ve type="application/soap+xml" ve charsetparametreleriyle content-Type üst bilgisini içermelidir.
```
Content-Type: application/xop+xml;
              charset=utf-8;type="application/soap+xml"
```
XOP her ne kadar charset parametresini application/xop+xml için isteğe bağlı olarak tanımlasa da, charset medya türü için text/xml parametresinin BP 1.1 gereksinimine benzer şekilde, birlikte çalışabilirlik açısından gereklidir.
R41410: type VE charset parametreleri SOAP 1.x Infoset bölümünün content-Type üst bilgisinde bulunmalıdır.

MTOM için WCF Uç Noktası Desteği

MTOM'in amacı, base64 ile kodlanmış verileri iyileştirmek için bir SOAP iletisi kodlamaktır. Kısıtlamaların listesi aşağıdadır:

R4151: base64 ile kodlanmış veriler içeren tüm öğe bilgileri öğesi iyileştirilebilir.
B4152: WCF, base64 ile kodlanmış veriler içeren ve uzunluğu 1024 bayt'ı aşan öğe bilgileri öğelerini iyileştirir.

MTOM kullanmak üzere yapılandırılmış bir WCF uç noktası her zaman MTOM ile kodlanmış iletiler gönderir. Gerekli ölçütlere uyan parça olmasa bile, ileti yine de MTOM ile kodlanır (SOAP zarfını içeren tek bir MIME parçasıyla MIME paketi olarak seri hale getirilir).

WS-Policy MTOM Doğrulaması

WCF, uç noktaya göre MTOM kullanımını belirtmek için aşağıdaki ilke onayını kullanır:

<wsoma:OptimizedMimeSerialization />

R4211: Yukarıdaki ilke onaylama işlemi bir Uç Nokta İlkesi Konusuna sahiptir ve uç noktaya gönderilen ve uç noktadan alınan tüm iletilerin MTOM kullanılarak iyileştirilmesi gerektiğini belirtir.
B4212: MTOM iyileştirmesini kullanacak şekilde yapılandırıldığında, bir WCF uç noktası, ilgili wsdl:binding öğesine eklenen ilkeye bir MTOM İlke Beyanı ekler.

WS-Security ile kompozisyon

MTOM, ve WCF İkili XML'sine text/xml benzer bir kodlama mekanizmasıdır. MTOM, WS-Security ve diğer WS-* protokolleri ile doğal kompozisyon sunar: WS-Security kullanılarak güvenliği sağlanan bir ileti MTOM kullanılarak iyileştirilebilir.

Örnekler

MTOM Kullanılarak Kodlanmış WCF SOAP 1.1 İletisi

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

MTOM Kullanılarak Kodlanmış WCF Güvenli SOAP 1.2 İletisi

Bu örnekte, bir ileti, WS-Security kullanılarak korunan MTOM ve SOAP 1.2 kullanılarak kodlanmıştır. Kodlama için tanımlanan ikili parçalar, BinarySecurityToken ve CipherValueEncryptedData öğesinin, şifrelenmiş imza ve şifrelenmiş gövdeye karşılık gelen içeriğidir. CipherValue öğesinin EncryptedKey, uzunluğu 1024 bayttan az olduğundan WCF tarafından iyileştirme için tanımlanmadığına dikkat edin.

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

Last updated on 2025-06-17

Aracılığıyla paylaş

Mesajlaşma Protokolleri

SOAP 1.1 ve SOAP 1.2

Zarf ve İşleme Modeli

Zorunlu Üst Bilgi İşleme

SOAP Hata Mesajları

HTTP Bağlama

SOAP 1.1 HTTP Bağlaması

SOAP 1.2 HTTP Bağlaması

WS-Addressing

Uç Nokta Referansları

Uç Nokta Referansları ve WS-Addressing Versiyonları

Uç Nokta Başvuruları ve Meta Verileri

Mesaj Adresleme Başlıkları

İleti Üst Bilgileri

Başvuru Parametreleri ve Özellikleri

İleti Değişimi Desenleri

One-Way İleti

Request-Reply

Hataları Gideren Web Hizmetleri

WSDL 1.1 Bağlama ve WS-Policy Savları

WS-Addressing Kullanımını Gösteren İşareti

Eylem Tanımı

WSDL Bağlantı Noktasında Uç Nokta Başvurusu Kullanma

WS-Security ile kompozisyon

Örnekler

One-Way İleti

SOAP İleti İletimi İyileştirme Mekanizması

MTOM İleti Kodlaması

MTOM iletileri oluşturma

MTOM iletilerini işleme

HTTP İçerik Türü Üst Bilgisi

Infoset MIME Bölümü

MTOM için WCF Uç Noktası Desteği

WS-Policy MTOM Doğrulaması

WS-Security ile kompozisyon

Örnekler

MTOM Kullanılarak Kodlanmış WCF SOAP 1.1 İletisi

MTOM Kullanılarak Kodlanmış WCF Güvenli SOAP 1.2 İletisi

Ek kaynaklar