Mesajlaşma Protokolleri

Makale
06/08/2023

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.

Belirtim/belge:

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

Belirtim/Belge:

Bu konu, kullanan aşağıdaki protokoller MtomMessageEncodingBindingElement için WCF uygulama ayrıntılarını kapsar.

Belirtim/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 üst bilgileri mustUnderstand işlemek için aşağıdaki çeşitlemelerle kuralları 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ığını ancak olarak mustUnderstand işaretlenip işaretlenmediğini doğrular ve bir özel durum 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 üst bilgiler, ileti WCF altyapı kanal yığını tarafından işlendikten sonra ancak uygulama tarafından işlenmeden önce algılanır

Üst mustUnderstand bilgi 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, üst bilgi için mustUnderstand tüm değer alanını xs:boolean kabul eder (0, 1, false, true)

SOAP Hataları

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, Temel Profil 1.1 belirtimi bölüm 3.4'e aşağıdaki açıklamalarla birlikte SOAP1.1 HTTP bağlaması uygular:

B2211: WCF hizmeti HTTP POST isteklerinin yeniden yönlendirmesini uygulamaz.
B2212: WCF istemcileri HTTP Tanımlama Bilgilerini 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 wsoap12:operation içindeki öğedeki özniteliğiyle eşleşmelidirsoapAction.
R2222: application/soap+xml SOAP 1.2 iletisinde mevcut olduğunda eylem parametresi, WS-Addressing 2004/08 veya WS-Addressing 1.0 kullanıldığında eşleşmelidir wsa:Action .

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

WS Adresleme

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

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

Uç Nokta Başvuruları

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

Uç Nokta Başvuruları ve WS Adresleme Sürümleri

WCF, WS-Addressing ve özellikle EndpointReference de öğe ve W3C.WsAddressing.EndpointReferenceType sınıfı (örneğin, WS-ReliableMessaging, WS-SecureConversation ve WS-Trust) kullanan bir dizi altyapı protokolü uygular. WCF, WS-Addressing'in iki sürümünün de diğer altyapı protokolleriyle kullanılmasını destekler. WCF uç noktaları, her uç nokta için 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 uygularsa, AcksTo içinde CreateSequenceResponse böyle bir uç nokta tarafından döndürülen üst bilgi, öğesinin EncodingBinding 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, değere veya başvuruya göre uç nokta başvuruları için meta verileri dahil etmek üzere WS-MetadataExchange (MEX) belirtimi Bölüm 6'da açıklanan mekanizmaları kullanır.

BIR WCF hizmetinin adresinde http://sts.fabrikam123.combelirteç veren tarafından verilen bir Güvenlik Onayları Biçimlendirme Dili (SAML) belirteci kullanarak kimlik doğrulaması gerektirdiği bir senaryo düşünün. WCF uç noktası, belirteç verene işaret eden iç içe bir sp:Issuer onay ile onay kullanarak sp:IssuedToken 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 uzantılarını kullanarak belirteç veren meta verilerine bir başvuru sağlar.

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

İleti Adresleme Üst Bilgileri

İleti Üst Bilgileri

Her iki WS-Addressing sürümü için WCF, , , wsa:MessageIDwsa:ReplyTowsa:Actionve wsa:RelatesTobelirtimleri wsa:Totarafından belirtildiği gibi aşağıdaki ileti üst bilgilerini kullanır.

B3211: Tüm WS-Addressing sürümleri için WCF, WS-Addressing ileti üst bilgileri wsa:FaultTo ve wsa:Fromyerine getirilir ancak kullanıma hazır olarak üretilmez.

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 işleme ile Başvuru Parametreleri 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.

Tek Yönlü İ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 WS-Addressing'in her iki sürümü için de geçerlidir:

R3311: İstekte bulunan, uç nokta başvurusu tarafından belirtilen tüm başvuru parametreleri için , wsa:Actionve üst bilgileri içermelidirwsa:To. WS-Addressing 2004/08 kullanıldığında ve [başvuru özellikleri] uç nokta başvurusu tarafından belirtildiğinde, ilgili üst bilgiler de iletiye eklenmelidir.
B3312: İstekte bulunan , ReplyTove FaultTo üst bilgilerini içerebilirMessageID. Alıcı altyapısı bunları yoksayar ve uygulamaya geçirilir.
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.

İstek-Yanıt

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 WS-Addressing'in her iki 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 istek wsa:To, wsa:Actionwsa:MessageID, ve üst bilgilerine eklenmelidir.
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 eşit http://www.w3.org/2005/08/addressing/anonymous varsayılan uç nokta başvurusu kullanılır.
R3324: İstekte bulunan, yanıt iletisinde , wsa:Actionve üst bilgilerinin yanı sıra istekteki uç nokta başvurusu tarafından ReplyTo belirtilen tüm başvuru parametreleri veya başvuru özellikleri (veya her ikisi) için üst bilgiler içermelidirwsa:Towsa:RelatesTo.

Hataları Gideren Web Hizmetleri

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

Kod	Neden
`wsa:DestinationUnreachable`	İleti, bu kanal için oluşturulan yanıt adresinden farklı bir `ReplyTo` iletiyle geldi; Bitiş üst bilgisinde 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	Neden
`wsa10:InvalidAddressingHeader`	Çoğalt `wsa:To`, `wsa:ReplyTo`veya `wsa:Fromwsa:MessageID`. Aynı `RelationshipType`ile çoğaltın`wsa:RelatesTo`.
`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 eylem, 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ç noktanın iletinin adresleme üst bilgilerinin incelenmesine göre sırayı `CreateSequence` işlemeyeceğini belirtir.

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

WSDL 1.1 Bağlama ve WS İlkesi Onaylamaları

WS-Adresleme kullanımını belirtme

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 onaylama işlemi 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 onayı, WS-Addressing 2004/08 belirtimini genişletiyor.

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 onaylama işlemi bir Uç Nokta İlkesi Konusuna [WS-PA] sahiptir ve uç noktadan gönderilen ve alınan iletilerin WS-Addressing 2004/08 kullanması gerektiğini gösterir.

<wsaw10:UsingAddressing />

wsaw10:UsingAddressing öğesi [WS-Addressing-WSDL] öğesinden ödünç alınır ve WS-Policy bağlamında bu belirtim, bölüm 3.1.2 ile uyumlu olarak 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 onayı şö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, Bileşik Çift Yönlü iki ters 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] olan aşağıdaki onayların kullanılması, istek sahibinden yanıtlayana ve yanıtlayana giden iletiler için sırasıyla iki ayrı ters HTTP bağlantısı kullanılmasını gerektirir.

<cdp:CompositeDuplex/>

Önceki deyim, istek iletileri için üst bilgide wsa:ReplyTo aşağıdaki gereksinimlere yol açar:

R3514: Uç noktaya gönderilen istek iletilerinin[address], uç nokta WSDL 1.1 SOAP 1.x HTTP bağlaması kullanıyorsa ve ekli veya wsap:UsingAddressing onay ile bir cdp:CompositeDuplex ilke alternatifi varsa, özelliği eşit http://www.w3.org/2005/08/addressing/anonymous olmayan bir wsap10:UsingAddressing üst bilgi içermelidirReplyTo.
R3515: Uç noktaya gönderilen istek iletilerinin[address], WSDL 1.1 SOAP 1.x HTTP bağlaması kullanıyorsa ve onay içeren wsap10:UsingAddressing bir ilke alternatifi varsa ve hiçbir cdp:CompositeDuplex onay eklenmemişse, uç noktaya gönderilen istek iletilerinin özelliğine eşit http://www.w3.org/2005/08/addressing/anonymousbir üst bilgi olması veya ReplyTo üst bilgi içermemesi gerekirReplyTo.
R3516: Uç noktaya gönderilen istek iletilerininReplyTo, uç nokta WSDL 1.1 SOAP 1.x HTTP bağlaması kullanıyorsa ve onay içeren wsap:UsingAddressing bir ilke alternatifi varsa ve hiçbir cdp:CompositeDuplex onay eklenmemişse, buna eşit http://www.w3.org/2005/08/addressing/anonymous bir özelliğe sahip üst bilgi [address] olmalıdır.

WS adresleme WSDL belirtimi, üst bilgideki gereksinimleri wsa:ReplyTo belirtmek için üç metin değeri (gerekli, isteğe bağlı ve yasak) içeren bir öğe <wsaw:Anonymous/> ekleyerek benzer protokol bağlamalarını açıklamaya ç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 öğeleri için wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] bir wsa:Action öznitelik 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'nin 3.3.2 bölümünde ve WS-ADDR10-WSDL'nin 4.4.4. bölümünde açıklanan varsayılan Eylem deseni 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 tarafından portType tanımlandığı ve öğesini uygulayan uç noktalar arasında değişmemesi gerektiği göz önüne alındığında, her iki varsayılan eylem desenini portTypede desteklemek imkansız hale gelir.

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

B3521: WCF, uç nokta tarafından kullanılan WS-Addressing sürümünden bağımsız olarak ilgili iletilerin Action URI'sini belirlemek için WS-ADDR10-WSDL'de tanımlanan öğelerde özniteliğini wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] kullanırwsaw10:Action.

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

WS-ADDR10-WSDL bölüm 4.1, WS-Addressing terimlerinde wsdl:port uç noktayı açıklamak için öğesini alt öğeyi içerecek <wsa10:EndpointReference…/> şekilde genişletir. WCF, bu yardımcı programı WS-Addressing 2004/08'de genişleterek <wsa:EndpointReference…/> öğesinin alt öğesi olarak görünmesine wsdl:portolanak 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 wsdl:port/wsdl:location öğenin özniteliğinin değeriyle @address 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 wsdl:port/wsdl:location öğenin özniteliğinin değeriyle @address eşleşmelidir.

WS-Security ile Oluşturma

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

Tek Yönlü İ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 ve wsa10:Action öğelerini içerirwsa10:To. İleti gövdesi, uygulama ad alanından belirli <app:Ping> bir öğe içerir.

HTTP Üst Bilgileri: POST içindeki hedef, öğesindeki URI ile wsa10:To eşleşir.

content-Type üst bilgisi SOAP 1.2 için gerekli olan değerine application/soap+xml sahiptir. ve parametreleri charsetaction dahil edilir. action content-Type üst bilgisinin parametresi ileti üst bilgisinin değeriyle wsa10:Action 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 ve [local name]Includeile öğe [namespace name]http://www.w3.org/2004/08/xop/include bilgisi öğesi içermediğinden 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 ancak önceki adımda tanımlanan her öğe bilgi öğesinin alt öğeleriyle birlikte aşağıdaki gibi oluşturulan bir öğe bilgi öğesiyle değiştirilen bir xop:Include 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 bilgileri öğesinin (yeni eklenen xop:Include öğe bilgileri öğesinin [üst] öğesi) öznitelik xmime:contentType bilgileri öğesi varsa, özniteliğin xmime:contentType değeriyle bir content-Type 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. 4b adımında xop:Include oluşturulan Content-ID üst bilgi değerinden türetilen cid: uri değeriyle öğesine bir href ö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çış olabilir.
```
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.
[children] özelliğinin tek üyesi olarak bir xop:Include öğe bilgi öğesi olan, oluşturulan SOAP Zarfı'ndaki her öğe bilgi öğesi için:
1. ön ekini kaldırın ve öğesinin cid: özniteliğinin xop:Include değerindeki @href tüm URI kaçış dizilerini (RFC 2396) kaldırın. 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 content-Type üst bilgisinin tam Backus-Naur Formu (BNF), RFC 2045, bölüm 5.1'de listelenir.
R4132: HTTP content-Type üst bilgisinin, değeri application/xop+xml çift tırnak içine alınmış bir tür parametresi olmalıdır.

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, SOAP 1.x Zarfını içeren MIME bölümünün Content-ID üst bilgisinin değeri çift tırnak içine alınmış bir başlangıç parametresi olmalı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üllenmiş ve genellikle parça olarak adlandırılır infoset .

R4141: SOAP 1.x Zarfı, XOP MIME paketinin kök parçası olarak kapsüllenmelidir; bu bölüm olarak adlandırılır infoset ve HTTP İçerik Türünden başvurulmalı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 etkin bir şekilde "" ve> "<" içine alınmış 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ümleri atlanmış olarak RFC 2822'den üretime [CFWS] uygun msg-id olmalıdır.

Bir dizi MIME uygulaması, "" ve "<>" içinde yer alan değerin e-posta adresi olmasını ve e-posta adresine ek olarak "" , "<>" içine alınmış olarak kullanılmasının absoluteURI gereksinimlerini gevşetir. 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 tanımlanan varsayılan değer 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 isteğe bağlı olması için parametresini charset tanımlasa da, medya türü parametresindeki charset BP 1.1 gereksinimine benzer şekilde birlikte çalışabilirlik için text/xmlapplication/xop+xml 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).

MTOM için WS İlkesi Onaylama

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, WCF uç noktası ilgili wsdl:bindingöğesine eklenen ilkeye bir MTOM İlkesi onayı ekler.

WS-Security ile Oluşturma

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 bileşim 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, şifrelenmiş imzaya ve şifrelenmiş gövdeye karşılık gelen öğesinin içeriğidir BinarySecurityTokenCipherValueEncryptedData. CipherValue uzunluğu 1024 bayt'ın altında olduğundan, değerinin EncryptedKey WCF tarafından iyileştirme için tanımlanmadığını unutmayın.

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

Share via

Mesajlaşma Protokolleri

SOAP 1.1 ve SOAP 1.2

Zarf ve İşleme Modeli

Zorunlu Üst Bilgi İşleme

SOAP Hataları

HTTP Bağlama

SOAP 1.1 HTTP Bağlaması

SOAP 1.2 HTTP Bağlaması

WS Adresleme

Uç Nokta Başvuruları

Uç Nokta Başvuruları ve WS Adresleme Sürümleri

Uç Nokta Başvuruları ve Meta Verileri

İleti Adresleme Üst Bilgileri

İleti Üst Bilgileri

Başvuru Parametreleri ve Özellikleri

İleti Değişimi Desenleri

Tek Yönlü İleti

İstek-Yanıt

Hataları Gideren Web Hizmetleri

WSDL 1.1 Bağlama ve WS İlkesi Onaylamaları

WS-Adresleme kullanımını belirtme

Eylem Tanımı

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

WS-Security ile Oluşturma

Örnekler

Tek Yönlü İ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

MTOM için WS İlkesi Onaylama

WS-Security ile Oluşturma

Örnekler

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

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

Ek kaynaklar