Hizmet Sözleşmeleri Tasarlama

  • Makale

Bu konu başlığı altında hangi hizmet sözleşmelerinin olduğu, bunların nasıl tanımlandığı, hangi işlemlerin kullanılabilir olduğu (ve temel alınan ileti alışverişlerinin etkileri), hangi veri türlerinin kullanıldığı ve senaryonuzun gereksinimlerini karşılayan işlemler tasarlamanıza yardımcı olan diğer sorunlar açıklanmaktadır.

Hizmet Sözleşmesi Oluşturma

Hizmetler bir dizi işlemi kullanıma sunar. Windows Communication Foundation (WCF) uygulamalarında, bir yöntem oluşturup özniteliğiyle OperationContractAttribute işaretleyerek işlemleri tanımlayın. Ardından, bir hizmet sözleşmesi oluşturmak için, işlemlerinizi öznitelikle işaretlenmiş bir arabirim içinde bildirerek veya aynı öznitelikle ServiceContractAttribute işaretlenmiş bir sınıfta tanımlayarak gruplandırın. (Temel bir örnek için bkz. Nasıl yapılır: Hizmet Sözleşmesi Tanımlama.)

Özniteliği olmayan OperationContractAttribute yöntemler hizmet işlemleri değildir ve WCF hizmetleri tarafından kullanıma sunulmaz.

Bu konuda, bir hizmet sözleşmesi tasarlarken aşağıdaki karar noktaları açıklanmaktadır:

  • Sınıfların veya arabirimlerin kullanılıp kullanılmaymayacağı.

  • Değiştirmek istediğiniz veri türlerini belirtme.

  • Kullanabileceğiniz değişim deseni türleri.

  • Açık güvenlik gereksinimlerini sözleşmenin bir parçası yapıp yapamayacağınız.

  • İşlem girişleri ve çıkışları için kısıtlamalar.

Sınıflar veya Arabirimler

Hem sınıflar hem de arabirimler bir işlevsellik grubunu temsil eder ve bu nedenle her ikisi de WCF hizmet sözleşmesi tanımlamak için kullanılabilir. Ancak, doğrudan hizmet sözleşmelerini modellediğinden arabirimleri kullanmanız önerilir. Uygulama olmadan, arabirimler belirli imzalara sahip bir yöntem grubu tanımlamaktan başka bir şey yapmaz. Bir hizmet sözleşmesi arabirimi uygulayın ve bir WCF hizmeti uyguladınız.

Yönetilen arabirimlerin tüm avantajları hizmet sözleşmesi arabirimleri için geçerlidir:

  • Hizmet sözleşmesi arabirimleri, herhangi bir sayıda diğer hizmet sözleşmesi arabirimini genişletebilir.

  • Tek bir sınıf, bu hizmet sözleşmesi arabirimlerini uygulayarak herhangi bir sayıda hizmet sözleşmesi uygulayabilir.

  • Hizmet sözleşmesi aynı kalırken arabirim uygulamasını değiştirerek hizmet sözleşmesinin uygulamasını değiştirebilirsiniz.

  • Eski arabirimi ve yenisini uygulayarak hizmetinizin sürümünü oluşturabilirsiniz. Eski istemciler özgün sürüme bağlanırken, daha yeni istemciler daha yeni sürüme bağlanabilir.

Not

Diğer hizmet sözleşmesi arabirimlerinden devralırken, ad veya ad alanı gibi işlem özelliklerini geçersiz kılamazsınız. Bunu yapmaya çalışırsanız, geçerli hizmet sözleşmesinde yeni bir işlem oluşturursunuz.

Hizmet sözleşmesi oluşturmak için arabirim kullanma örneği için bkz . Nasıl yapılır: Sözleşme Arabirimi ile Hizmet Oluşturma.

Ancak, bir hizmet sözleşmesi tanımlamak ve bu sözleşmeyi aynı anda uygulamak için bir sınıf kullanabilirsiniz. Sınıfa ve sınıf üzerindeki yöntemlere sırasıyla doğrudan ve OperationContractAttribute uygulayarak ServiceContractAttribute hizmetlerinizi oluşturmanın avantajı hız ve basitliktir. Dezavantajları, yönetilen sınıfların birden çok devralmayı desteklememesi ve sonuç olarak aynı anda yalnızca bir hizmet sözleşmesi uygulayabilmesidir. Ayrıca, sınıf veya yöntem imzalarında yapılan tüm değişiklikler, bu hizmetin genel sözleşmesini değiştirir ve bu da değiştirilmemiş istemcilerin hizmetinizi kullanmasını engelleyebilir. Daha fazla bilgi için bkz . Hizmet Sözleşmelerini Uygulama.

Hizmet sözleşmesi oluşturmak için sınıf kullanan ve aynı anda uygulayan bir örnek için bkz . Nasıl yapılır: Sözleşme Sınıfı ile Hizmet Oluşturma.

Bu noktada, bir arabirim kullanarak ve bir sınıf kullanarak hizmet sözleşmenizi tanımlama arasındaki farkı anlamanız gerekir. Bir sonraki adım, bir hizmet ile istemcileri arasında hangi verilerin ileri geri geçirilebileceğine karar vermektir.

Parametreler ve Dönüş Değerleri

Bunlar olsa bile her işlemin bir dönüş değeri ve parametresi vardır void. Ancak, bir nesneden diğerine başvurular geçirebileceğiniz yerel bir yöntemden farklı olarak, hizmet işlemleri nesnelere başvuru geçirmez. Bunun yerine, nesnelerin kopyalarını geçirirler.

Bir parametrede veya dönüş değerinde kullanılan her türün serileştirilebilir olması gerektiğinden bu önemlidir; başka bir ifadeyle, bu tür bir nesneyi bayt akışına ve bayt akışından bir nesneye dönüştürmek mümkün olmalıdır.

.NET Framework'teki birçok tür gibi ilkel türler varsayılan olarak seri hale getirilebilir.

Not

İşlem imzasında parametre adlarının değeri sözleşmenin bir parçasıdır ve büyük/küçük harfe duyarlıdır. Aynı parametre adını yerel olarak kullanmak ancak yayımlanan meta verilerdeki adı değiştirmek istiyorsanız, bkz System.ServiceModel.MessageParameterAttribute. .

Veri Sözleşmeleri

Windows Communication Foundation (WCF) uygulamaları gibi hizmet odaklı uygulamalar, hem Microsoft hem de Microsoft dışı platformlarda mümkün olan en fazla sayıda istemci uygulamasıyla birlikte çalışacak şekilde tasarlanmıştır. Mümkün olan en geniş birlikte çalışabilirlik için, hizmet sözleşmenizin hizmet operasyonlarınızın değiş tokuş ettiği verileri açıklayan bölümü olan bir veri sözleşmesi oluşturmak için ve öznitelikleriyle DataContractAttributeDataMemberAttribute türlerinizi işaretlemeniz önerilir.

Veri sözleşmeleri kabul stili sözleşmelerdir: Veri sözleşmesi özniteliğini açıkça uygulamadığınız sürece hiçbir tür veya veri üyesi serileştirilemez. Veri sözleşmeleri yönetilen kodun erişim kapsamıyla ilişkili değildir: Özel veri üyeleri seri hale getirilebilir ve genel erişim için başka bir yere gönderilebilir. (Veri sözleşmesinin temel bir örneği için bkz. Nasıl yapılır: Bir Sınıf veya Yapı için Temel Veri Sözleşmesi Oluşturma.) WCF, işlemin işlevselliğini sağlayan temel SOAP iletilerinin tanımını ve veri türlerinizin iletilerin gövdesine ve dışına seri hale getirilmesini sağlar. Veri türleriniz serileştirilebilir olduğu sürece, işlemlerinizi tasarlarken temel alınan ileti değişimi altyapısını düşünmeniz gerekmez.

Tipik WCF uygulaması işlemler için veri sözleşmeleri oluşturmak için ve DataMemberAttribute özniteliklerini kullansa DataContractAttribute da, diğer serileştirme mekanizmalarını kullanabilirsiniz. Standart ISerializable, SerializableAttributeve IXmlSerializable mekanizmalarının tümü, veri türlerinizi bir uygulamadan diğerine taşıyan temel SOAP iletilerine serileştirmeyi işlemek için çalışır. Veri türleriniz özel destek gerektiriyorsa daha fazla serileştirme stratejisi kullanabilirsiniz. WCF uygulamalarında veri türlerini serileştirme seçenekleri hakkında daha fazla bilgi için bkz . Hizmet Sözleşmelerinde Veri AktarımıNı Belirtme.

Parametreleri ve Dönüş Değerlerini İleti Değişimleriyle Eşleme

Hizmet işlemleri, uygulamanın belirli standart güvenlik, işlem ve oturumla ilgili özellikleri desteklemek için gerektirdiği verilere ek olarak, uygulama verilerini ileri geri aktaran soap iletilerinin temel değişimiyle desteklenir. Bu durumdan dolayı, bir hizmet işleminin imzası, veri aktarımını ve bir işlemin gerektirdiği özellikleri destekleyebilecek belirli bir temel alınan ileti değişimi desenini (MEP) belirler. WCF programlama modelinde üç desen belirtebilirsiniz: istek/yanıt, tek yönlü ve çift yönlü ileti desenleri.

İstek/Yanıtla

İstek/yanıt deseni, istek gönderenin (istemci uygulaması) isteğin bağıntılı olduğu bir yanıt aldığı düzendir. Bir veya daha fazla parametrenin işleme geçirildiği ve dönüş değerinin çağırana geri geçirildiği bir işlemi desteklediğinden, bu varsayılan MEP'dir. Örneğin, aşağıdaki C# kod örneği bir dize alıp bir dize döndüren temel bir hizmet işlemini gösterir.

[OperationContractAttribute]  
string Hello(string greeting);

Eşdeğer Visual Basic kodu aşağıdadır.

<OperationContractAttribute()>  
Function Hello (ByVal greeting As String) As String

Bu işlem imzası, temel alınan ileti değişimi biçimini belirler. Hiçbir bağıntı yoksa, WCF dönüş değerinin hedeflendiği işlemi belirleyemez.

Farklı bir temel alınan ileti deseni belirtmediğiniz sürece, (NothingVisual Basic'te) döndüren void hizmet işlemlerinin bile istek/yanıt iletisi değişimi olduğunu unutmayın. İşleminizin sonucu, bir istemci işlemi zaman uyumsuz olarak çağırmadığı sürece, istemci normal durumda boş olsa bile dönüş iletisi alınana kadar işlemeyi durdurur. Aşağıdaki C# kod örneği, istemci yanıt olarak boş bir ileti alıncaya kadar döndürülmeyen bir işlemi gösterir.

[OperationContractAttribute]  
void Hello(string greeting);

Eşdeğer Visual Basic kodu aşağıdadır.

<OperationContractAttribute()>  
Sub Hello (ByVal greeting As String)

Yukarıdaki örnek, işlemin gerçekleştirilmesi uzun sürüyorsa istemci performansını ve yanıt hızını yavaşlatabilir, ancak döndürseler voidbile istek/yanıt işlemlerinin avantajları vardır. En belirgin olanı, soap hatalarının yanıt iletisinde döndürülebileceğidir. Bu durum, iletişim veya işlem sırasında hizmetle ilgili bazı hata koşullarının oluştuğunu gösterir. Bir hizmet sözleşmesinde belirtilen SOAP hataları istemci uygulamasına nesne FaultException<TDetail> olarak geçirilir ve burada tür parametresi hizmet sözleşmesinde belirtilen türdür. Bu, WCF hizmetlerindeki hata koşullarını istemcilere bildirmeyi kolaylaştırır. Özel durumlar, SOAP hataları ve hata işleme hakkında daha fazla bilgi için bkz . Sözleşmelerde ve Hizmetlerde Hataları Belirtme ve İşleme. İstek/yanıt hizmeti ve istemcisinin bir örneğini görmek için bkz . Nasıl yapılır: İstek-Yanıt Sözleşmesi Oluşturma. İstek-yanıt düzeniyle ilgili sorunlar hakkında daha fazla bilgi için bkz . İstek-Yanıt Hizmetleri.

Tek yönlü

WCF hizmet uygulamasının istemcisi işlemin tamamlanmasını beklememelidir ve SOAP hatalarını işlemezse, işlem tek yönlü bir ileti düzeni belirtebilir. Tek yönlü işlem, istemcinin bir işlemi çağırdığı ve WCF iletiyi ağa yazdıktan sonra işlemeye devam ettiği işlemdir. Bu genellikle giden iletide gönderilen veriler son derece büyük olmadığı sürece istemcinin neredeyse hemen çalışmaya devam etmesi anlamına gelir (verileri gönderirken bir hata olmadığı sürece). Bu tür bir ileti değişimi düzeni, istemciden hizmet uygulamasına olay benzeri davranışı destekler.

Bir iletinin gönderildiği ve hiçbirinin alınmadığı bir ileti değişimi, dışında voidbir dönüş değeri belirten bir hizmet işlemini desteklemez; bu durumda özel InvalidOperationException durum oluşturulur.

Dönüş iletisi yok, işleme veya iletişimdeki hataları belirtmek için soap hatası döndürülemez anlamına da gelir. (İşlemler tek yönlü işlemler olduğunda hata bilgilerinin iletilmesi çift yönlü ileti değişimi deseni gerektirir.)

döndüren voidbir işlem için tek yönlü ileti değişimini belirtmek için, aşağıdaki C# kod örneğinde olduğu gibi özelliğini trueolarak ayarlayınIsOneWay.

[OperationContractAttribute(IsOneWay=true)]  
void Hello(string greeting);

Eşdeğer Visual Basic kodu aşağıdadır.

<OperationContractAttribute(IsOneWay := True)>  
Sub Hello (ByVal greeting As String)

Bu yöntem önceki istek/yanıt örneğiyle aynıdır, ancak özelliğini true olarak ayarlamakIsOneWay, yöntemin aynı olmasına rağmen hizmet işleminin bir dönüş iletisi göndermediği ve giden ileti kanal katmanına teslim edildikten sonra istemcilerin hemen döndüreceği anlamına gelir. Bir örnek için bkz . Nasıl yapılır: Tek Yönlü Sözleşme Oluşturma. Tek yönlü desen hakkında daha fazla bilgi için bkz . Tek Yönlü Hizmetler.

Çift Yönlü

Çift yönlü desen, hem hizmetin hem de istemcinin tek yönlü veya istek/yanıt mesajlaşması kullanarak birbirinden bağımsız olarak birbirlerine ileti gönderebilmesiyle karakterize edilir. Bu iki yönlü iletişim biçimi, doğrudan istemciyle iletişim kurması gereken hizmetler için veya olay benzeri davranış dahil olmak üzere ileti değişiminin her iki tarafına zaman uyumsuz bir deneyim sağlamak için kullanışlıdır.

çift yönlü desen, istemciyle iletişim kurmak için ek mekanizma nedeniyle istek/yanıt veya tek yönlü desenlerden biraz daha karmaşıktır.

Çift yönlü sözleşme tasarlamak için, bir geri çağırma sözleşmesi tasarlamanız ve bu geri çağırma sözleşmesinin türünü hizmet sözleşmenizi CallbackContract işaretleyen özniteliğin ServiceContractAttribute özelliğine atamanız gerekir.

Çift yönlü desen uygulamak için istemcide çağrılan yöntem bildirimlerini içeren ikinci bir arabirim oluşturmanız gerekir.

Hizmet oluşturma örneği ve bu hizmete erişen bir istemci için bkz. Nasıl yapılır: Çift Yönlü Sözleşme Oluşturma ve Nasıl yapılır: Çift Yönlü Sözleşme ile Access Hizmetleri. Çalışan bir örnek için bkz . Çift yönlü. Çift yönlü sözleşmeleri kullanma sorunları hakkında daha fazla bilgi için bkz . Çift Yönlü Hizmetler.

Dikkat

Bir hizmet çift yönlü bir ileti aldığında, yanıtın ReplyTo nereye gönderileceğini belirlemek için bu gelen iletideki öğesine bakar. İletiyi almak için kullanılan kanalın güvenliği sağlanmazsa, güvenilmeyen bir istemci hedef makineninkiyle kötü amaçlı bir ileti gönderebilir ve bu da hedef makinenin ReplyTohizmet reddine (DOS) yol açabilir.

Out ve Ref Parametreleri

Çoğu durumda, parametreleri (ByValVisual Basic'te) ve refout parametreleri (ByRefVisual Basic'te) kullanabilirsinizin. Hem hem de outref parametreleri bir işlemden veri döndürüldüğünü gösterdiğinden, aşağıdaki gibi bir işlem imzası, işlem imzası döndürse voidbile bir istek/yanıt işlemi gerektiğini belirtir.

[ServiceContractAttribute]  
public interface IMyContract  
{  
  [OperationContractAttribute]  
  public void PopulateData(ref CustomDataType data);  
}

Eşdeğer Visual Basic kodu aşağıdadır.

<ServiceContractAttribute()> _  
Public Interface IMyContract  
  <OperationContractAttribute()> _  
  Public Sub PopulateData(ByRef data As CustomDataType)  
End Interface

Tek özel durumlar, imzanızın belirli bir yapıya sahip olduğu durumlardır. Örneğin, istemcilerle iletişim kurmak için bağlamayı NetMsmqBinding yalnızca bir işlemi bildirmek için kullanılan yöntem döndürürse voidkullanabilirsiniz; dönüş değeri, refveya out parametresi olsun, çıkış değeri olamaz.

Buna ek olarak, veya ref parametrelerinin kullanılmasıout, işlemin değiştirilen nesneyi geri almak için temel alınan bir yanıt iletisine sahip olmasını gerektirir. İşleminiz tek yönlü bir işlemse, çalışma zamanında bir InvalidOperationException özel durum oluşturulur.

Sözleşmede İleti Koruma Düzeyini Belirtin

Sözleşmenizi tasarlarken, sözleşmenizi uygulayan hizmetlerin ileti koruma düzeyine de karar vermeniz gerekir. Bu, yalnızca sözleşmenin uç noktasındaki bağlamaya ileti güvenliği uygulandığında gereklidir. Bağlamanın güvenliği kapalıysa (sistem tarafından sağlanan bağlama değerini SecurityMode.NoneayarlarsaSystem.ServiceModel.SecurityMode) sözleşmenin ileti koruma düzeyine karar vermeniz gerekmez. Çoğu durumda, ileti düzeyi güvenlik uygulanmış sistem tarafından sağlanan bağlamalar yeterli bir koruma düzeyi sağlar ve her işlem veya her ileti için koruma düzeyini göz önünde bulundurmanız gerekmez.

Koruma düzeyi, bir hizmeti destekleyen iletilerin (veya ileti bölümlerinin) imzalanıp imzalanmadığını, imzalanıp şifrelenmediğini veya imzalar ya da şifreleme olmadan gönderilip gönderilmediğini belirten bir değerdir. Koruma düzeyi çeşitli kapsamlarda ayarlanabilir: Hizmet düzeyinde, belirli bir işlem için, bu işlem içindeki bir ileti için veya ileti bölümü. Bir kapsamda ayarlanan değerler, açıkça geçersiz kılınmadığı sürece daha küçük kapsamlar için varsayılan değer olur. Bağlama yapılandırması sözleşme için gerekli en düşük koruma düzeyini sağlayamıyorsa bir özel durum oluşturulur. Sözleşmede açıkça hiçbir koruma düzeyi değeri ayarlanmazsa bağlama yapılandırması, bağlamanın ileti güvenliği varsa tüm iletiler için koruma düzeyini denetler. Bu varsayılan davranıştır.

Önemli

Bir sözleşmenin çeşitli kapsamlarının tam koruma düzeyinden ProtectionLevel.EncryptAndSign daha az olacak şekilde açıkça ayarlanıp ayarlanmayacağına karar vermek genellikle artan performans için bir miktar güvenlikle işlem gören bir karardır. Bu gibi durumlarda, kararlarınızın işlemleriniz ve onların değiş tokuş ettikleri verilerin değeri etrafında dönmesi gerekir. Daha fazla bilgi için bkz . Hizmetlerin Güvenliğini Sağlama.

Örneğin, aşağıdaki kod örneği sözleşmede ProtectionLevel veya ProtectionLevel özelliğini ayarlamaz.

[ServiceContract]  
public interface ISampleService  
{  
  [OperationContractAttribute]  
  public string GetString();  
  
  [OperationContractAttribute]  
  public int GetInt();
}

Eşdeğer Visual Basic kodu aşağıdadır.

<ServiceContractAttribute()> _  
Public Interface ISampleService  
  
  <OperationContractAttribute()> _  
  Public Function GetString()As String  
  
  <OperationContractAttribute()> _  
  Public Function GetData() As Integer  
  
End Interface

Varsayılan bir uç noktadaki bir ISampleService uygulamayla etkileşim kurarken (varsayılan System.ServiceModel.SecurityModeMessageolan ), bu varsayılan WSHttpBinding koruma düzeyi olduğundan tüm iletiler şifrelenir ve imzalanır. Ancak, bir ISampleService hizmet varsayılan BasicHttpBinding ile kullanıldığında (varsayılan SecurityModeolan None), bu bağlama için güvenlik olmadığından ve koruma düzeyi yoksayıldığından (yani, iletiler şifrelenmediğinden veya imzalandığından) tüm iletiler metin olarak gönderilir. SecurityMode olarak değiştirildiyseMessage, bu iletiler şifrelenir ve imzalı olur (çünkü bu artık bağlamanın varsayılan koruma düzeyi olacaktır).

Sözleşmenizin koruma gereksinimlerini açıkça belirtmek veya ayarlamak istiyorsanız, özelliği (veya daha küçük bir kapsamdaki ProtectionLevel özelliklerden herhangi birini) hizmet sözleşmenizin gerektirdiği düzeye ayarlayınProtectionLevel. Bu durumda, açık bir ayar kullanmak için bağlamanın kullanılan kapsam için en az bu ayarı desteklemesi gerekir. Örneğin, aşağıdaki kod örneği işlem için GetGuid bir ProtectionLevel değeri açıkça belirtir.

[ServiceContract]  
public interface IExplicitProtectionLevelSampleService  
{  
  [OperationContractAttribute]  
  public string GetString();  
  
  [OperationContractAttribute(ProtectionLevel=ProtectionLevel.None)]  
  public int GetInt();
  [OperationContractAttribute(ProtectionLevel=ProtectionLevel.EncryptAndSign)]  
  public int GetGuid();
}

Eşdeğer Visual Basic kodu aşağıdadır.

<ServiceContract()> _
Public Interface IExplicitProtectionLevelSampleService
    <OperationContract()> _
    Public Function GetString() As String
    End Function
  
    <OperationContract(ProtectionLevel := ProtectionLevel.None)> _
    Public Function GetInt() As Integer
    End Function
  
    <OperationContractAttribute(ProtectionLevel := ProtectionLevel.EncryptAndSign)> _
    Public Function GetGuid() As Integer
    End Function
  
End Interface

Bu IExplicitProtectionLevelSampleService sözleşmeyi uygulayan ve varsayılan (varsayılan WSHttpBindingSystem.ServiceModel.SecurityModeolan ) kullanan bir uç noktası olan Messagebir hizmet aşağıdaki davranışa sahiptir:

  • İşlem GetString iletileri şifrelenir ve imzalar.

  • İşlem GetInt iletileri şifrelenmemiş ve işaretsiz (düz) metin olarak gönderilir.

  • İşlem GetGuidSystem.Guid şifrelenmiş ve imzalanmış bir iletide döndürülür.

Koruma düzeyleri ve bunların nasıl kullanılacağı hakkında daha fazla bilgi için bkz . Koruma Düzeyini Anlama. Güvenlik hakkında daha fazla bilgi için bkz . Hizmetlerin Güvenliğini Sağlama.

Diğer İşlem İmzası Gereksinimleri

Bazı uygulama özellikleri belirli bir işlem imzası türü gerektirir. Örneğin bağlama, NetMsmqBinding bir uygulamanın iletişimin ortasında yeniden başlatılabildiği ve ileti kaçırmadan kaldığı yerden devam edebilmesi için dayanıklı hizmetleri ve istemcileri destekler. (Daha fazla bilgi için bkz. WCF'deki kuyruklar.) Ancak, dayanıklı işlemlerin yalnızca bir in parametre alması ve dönüş değeri olmaması gerekir.

Bir diğer örnek de işlemlerde türlerin Stream kullanılmasıdır. Parametre ileti gövdesinin Stream tamamını içerdiğinden, bir giriş veya çıkış (parametre ref , out parametre veya dönüş değeri) türündeyse Stream, işleminizde belirtilen tek giriş veya çıkış olmalıdır. Ayrıca, parametre veya dönüş türü , System.ServiceModel.Channels.Messageveya System.Xml.Serialization.IXmlSerializableolmalıdırStream. Akışlar hakkında daha fazla bilgi için bkz . Büyük Veri ve Akış.

AdLar, Ad Alanları ve Gizleme

Sözleşmelerin ve işlemlerin tanımındaki .NET türlerinin adları ve ad alanları, sözleşmeler WSDL'ye dönüştürüldüğünde ve sözleşme iletileri oluşturulup gönderildiğinde önemlidir. Bu nedenle, hizmet sözleşmesi adlarının ve ad alanlarının, , , DataContractAttributeOperationContractAttribute, DataMemberAttributeve diğer sözleşme öznitelikleri gibi ServiceContractAttributetüm destekleyici sözleşme özniteliklerinin ve özellikleri kullanılarak NameNamespace açıkça ayarlanması kesinlikle önerilir.

Bunun sonucunda adlar ve ad alanları açıkça ayarlanmamışsa, derlemede IL gizlemenin kullanılması sözleşme türü adlarını ve ad alanlarını değiştirir ve genellikle başarısız olan değiştirilmiş WSDL ve kablo değişimleriyle sonuçlanır. Sözleşme adlarını ve ad alanlarını açıkça ayarlamaz, ancak karartma kullanmayı planlıyorsanız, sözleşme türü adlarının ObfuscationAttribute ve ad alanlarının değiştirilmesini önlemek için ve ObfuscateAssemblyAttribute özniteliklerini kullanın.

Ayrıca bkz.