Hizmet Sürümü Oluşturma

İlk dağıtımdan sonra ve kullanım ömrü boyunca büyük olasılıkla birkaç kez, hizmetlerin (ve kullanıma açtıkları uç noktaların) iş gereksinimlerini değiştirme, bilgi teknolojisi gereksinimleri veya diğer sorunları çözmek gibi çeşitli nedenlerle değiştirilmesi gerekebilir. Her değişiklik, hizmetin yeni bir sürümünü tanıtır. Bu konuda, Windows Communication Foundation'da (WCF) sürüm oluşturmayı nasıl göz önünde bulunduracakları açıklanmaktadır.

Dört Hizmet Değişikliği Kategorisi

Hizmetlerde yapılması gerekebilecek değişiklikler dört kategoride sınıflandırılabilir:

• Sözleşme değişiklikleri: Örneğin, bir işlem eklenebilir veya iletideki bir veri öğesi eklenebilir veya değiştirilebilir.

• Adres değişiklikleri: Örneğin, bir hizmet uç noktaların yeni adresleri olduğu farklı bir konuma taşınır.

• Bağlama değişiklikleri: Örneğin, bir güvenlik mekanizması değişir veya ayarları değişir.

• Uygulama değişiklikleri: Örneğin, bir iç yöntem uygulaması değiştiğinde.

Bu değişikliklerden bazıları "bozucu" ve diğerleri "bölünemez" olarak adlandırılır. Önceki sürümde başarıyla işlenen tüm iletiler yeni sürümde başarıyla işlenirse, değişiklik bölünemez . Bu ölçüte uymayan her değişiklik bir geri uyumsuz değişikliktir.

Hizmet Yönlendirmesi ve Sürüm Oluşturma

Hizmet yönlendirmesinin ilkelerinden biri, hizmetlerin ve istemcilerin otonom (veya bağımsız) olmasıdır. Diğer şeylerin yanında bu, hizmet geliştiricilerinin tüm hizmet istemcilerini denetlediklerini ve hatta bildiklerini varsayamayacakları anlamına gelir. Bu, bir hizmet sürümleri değiştirdiğinde tüm istemcileri yeniden oluşturma ve yeniden dağıtma seçeneğini ortadan kaldırır. Bu konu, hizmetin bu ilkeye bağlı olduğu varsayımına dayanır ve bu nedenle istemcilerinden bağımsız bir şekilde değiştirilmesi veya "sürümlenmesi" gerekir.

Beklenmedik ve önlenemeyen bir değişikliğin söz konusu olduğu durumlarda, bir uygulama bu ilkeyi görmezden gelmeyi seçebilir ve müşterilerin hizmetin yeni bir sürümüyle yeniden oluşturulmasını ve yeniden dağıtılmasını gerektirebilir.

Sözleşme Sürümü Oluşturma

İstemci tarafından kullanılan sözleşmelerin hizmet tarafından kullanılan sözleşmeyle aynı olması gerekmez; yalnızca uyumlu olmaları gerekir.

Hizmet sözleşmeleri için uyumluluk, hizmet tarafından kullanıma sunulan yeni işlemlerin eklenebileceği ancak mevcut işlemlerin kaldırılamayacağı veya değiştirilemeyeceği anlamına gelir.

Veri sözleşmeleri için uyumluluk, yeni şema türü tanımlarının eklenebileceği ancak mevcut şema türü tanımlarının hataya neden olan yollarla değiştirilemeyeceği anlamına gelir. Uyumsuz değişiklikler veri üyelerini kaldırmayı veya veri türlerini uyumsuz bir şekilde değiştirmeyi içerebilir. Bu özellik, hizmetin müşterilerini etkilemeden sözleşmelerinin sürümünü değiştirmede biraz esneklik sağlar. Sonraki iki bölümde WCF verilerinde ve hizmet sözleşmelerinde yapılabilecek bölünemez ve bozucu değişiklikler açıklanmaktadır.

Veri Sözleşmesi Sürümü Oluşturma

Bu bölüm, DataContractSerializer ve DataContractAttribute sınıflarını kullanırken veri sürümlendirme ile ilgilidir.

Sıkı Sürüm Yönetimi

Sürümleri değiştirmenin sorun olduğu birçok senaryoda, hizmet geliştiricisi istemciler üzerinde denetim sahibi değildir ve bu nedenle ileti XML'sindeki veya şemadaki değişikliklere nasıl tepki verecekleri hakkında varsayımlarda bulunamaz. Bu gibi durumlarda, yeni iletilerin eski şemaya göre doğrulanacağına iki nedenden dolayı garanti etmeniz gerekir:

• Eski istemciler, şemanın değişmeyeceği varsayımıyla geliştirilmiştir. Tasarlanmadıkları iletileri işleyemeyebilirler.

• Eski istemciler, iletileri işlemeye çalışmadan önce eski şema üzerinde gerçek şema doğrulaması gerçekleştirebilir.

Bu tür senaryolarda önerilen yaklaşım, mevcut veri sözleşmelerini sabit olarak ele almak ve benzersiz XML nitelemeli adlarla yenilerini oluşturmaktır. Hizmet geliştiricisi daha sonra mevcut bir hizmet sözleşmesine yeni yöntemler ekleyebilir veya yeni veri sözleşmesini kullanan yöntemlerle yeni bir hizmet sözleşmesi oluşturur.

Genellikle bir hizmet geliştiricisinin veri sözleşmesinin tüm sürümlerinde çalışması gereken bir iş mantığı ve veri sözleşmesinin her sürümü için sürüme özgü iş kodu yazması gerekir. Bu konunun sonundaki ek, arabirimlerin bu gereksinimi karşılamak için nasıl kullanılabileceğini açıklar.

Gevşek Sürüm Oluşturma

Diğer birçok senaryoda, hizmet geliştiricisi veri sözleşmesine yeni ve isteğe bağlı bir üye eklemenin mevcut istemcileri bozmayacağını varsayabilir. Bu, hizmet geliştiricisinin mevcut istemcilerin şema doğrulaması yapıp yapmadığını ve ayrıca bilinmeyen veri üyelerini yoksayıp yoksaymadığını araştırmasını gerektirir. Bu senaryolarda, yeni üyeleri bölünemez bir şekilde eklemek için veri sözleşmesi özelliklerinden yararlanmak mümkündür. Sürüm oluşturma için veri sözleşmesi özellikleri hizmetin ilk sürümü için zaten kullanılıyorsa hizmet geliştiricisi bu varsayımı güvenle yapabilir.

WCF, ASP.NET Web Hizmetleri ve diğer birçok Web hizmeti yığını , gevşek sürüm oluşturma desteği sunar. Diğer bir deyişle, alınan verilerde yeni bilinmeyen veri üyeleri için özel durumlar oluşturmaz.

Yeni üye eklemenin mevcut istemcileri bozmayacağına yanlışlıkla inanmak kolaydır. Tüm istemcilerin gevşek sürüm oluşturma işlemini gerçekleştirebileceğinden emin değilseniz, öneri katı sürüm oluşturma yönergelerini kullanmak ve veri sözleşmelerini sabit olarak ele almaktır.

Veri sözleşmelerinin hem gevşek hem de katı sürüm oluşturmayla ilgili ayrıntılı yönergeler için bkz . En İyi Yöntemler: Veri Sözleşmesi Sürüm Oluşturma.

Veri Sözleşmesi ile .NET Türlerini Ayırt Etme

.NET sınıfı veya yapısı, özniteliği sınıfa uygulanarak DataContractAttribute veri sözleşmesi olarak yansıtılabilir. .NET türü ve veri sözleşmesi projeksiyonları iki ayrı konu vardır. Aynı veri sözleşmesi projeksiyonuyla birden çok .NET türüne sahip olmak mümkündür. Bu ayrım özellikle öngörülen veri sözleşmesini korurken .NET türünü değiştirmenize ve böylece sözcüğün katı anlamıyla bile mevcut istemcilerle uyumluluğu sürdürmenize olanak sağlamak için kullanışlıdır. .NET türü ve veri sözleşmesi arasındaki bu ayrımı korumak için her zaman yapmanız gereken iki şey vardır:

• Bir Name ve Namespace belirtin. .NET türünüzün adının ve ad alanının sözleşmede kullanıma sunulmasını önlemek için her zaman veri sözleşmenizin adını ve ad alanını belirtmeniz gerekir. Bu şekilde, daha sonra .NET ad alanını veya tür adını değiştirmeye karar verirseniz, veri sözleşmeniz aynı kalır.

• Name belirtin. .NET üye adınızın sözleşmede kullanıma sunulmasını önlemek için her zaman veri üyelerinizin adını belirtmeniz gerekir. Bu şekilde, daha sonra üyenin .NET adını değiştirmeye karar verirseniz, veri sözleşmeniz aynı kalır.

Üyeleri Değiştirme veya Kaldırma

Gevşek sürüm kontrolü izni olsa bile, bir üyenin adını veya veri türünü değiştirmek ya da veri üyelerini kaldırmak, büyük bir değişikliktir. Bu gerekiyorsa yeni bir veri sözleşmesi oluşturun.

Hizmet uyumluluğu yüksek önem taşıyorsa, kodunuzda kullanılmayan veri üyelerini yok saymayı ve bunları yerinde bırakmayı düşünebilirsiniz. Bir veri üyesini birden çok üyeye bölerseniz, alt düzey istemciler (en son sürüme yükseltilmeyen istemciler) için gerekli bölme ve yeniden toplama işlemlerini gerçekleştirebilen bir özellik olarak mevcut üyeyi yerinde bırakmayı düşünebilirsiniz.

Benzer şekilde, veri sözleşmesinin adında veya ad alanında yapılan değişiklikler de yeni değişikliklerdir.

Bilinmeyen Veri Round-Trips

Bazı senaryolarda, yeni sürüme eklenen üyelerden gelen bilinmeyen "gidiş dönüş" verilerine ihtiyaç vardır. Örneğin, "versionNew" hizmeti yeni eklenen bazı üyeleri içeren verileri bir "versionOld" istemcisine gönderir. İstemci, iletiyi işlerken yeni eklenen üyeleri yoksayar, ancak yeni eklenen üyeler de dahil olmak üzere bu verileri versionNew hizmetine geri gönderir. Bunun tipik senaryosu, verilerin hizmetten alındığı, değiştirildiği ve döndürüldüğü veri güncelleştirmeleridir.

Belirli bir tür için döngüsel işlemeyi etkinleştirmek amacıyla, türün IExtensibleDataObject arabirimini uygulaması gerekir. Arabirim, ExtensionData türünü döndüren ExtensionDataObject bir özellik içerir. özelliği, geçerli sürümde bilinmeyen veri sözleşmesinin gelecek sürümlerinden verileri depolamak için kullanılır. Bu veriler istemci için anlaşılmazdır, ancak örnek serileştirildiğinde, ExtensionData özelliğinin içeriği veri sözleşmesi üyelerinin diğer verileriyle birlikte yazılır.

Gelecekteki yeni ve bilinmeyen üyeleri barındırmak için tüm türlerinizin bu arabirimi uygulaması önerilir.

Veri Sözleşmesi Kitaplıkları

Bir sözleşmenin merkezi bir depoda yayımlandığı veri anlaşmaları kitaplıkları olabilir ve hizmet ve tür uygulayıcıları bu depodan veri sözleşmelerini uygular ve kullanıma sunar. Bu durumda, depoda bir veri sözleşmesi yayımladığınızda, bunu uygulayan türleri kimlerin oluşturduğu üzerinde hiçbir denetiminiz olmaz. Bu nedenle, sözleşme yayımlandıktan sonra değiştirilemez hale gelir ve bu yüzden sözleşmeyi değiştiremezsiniz.

XmlSerializer Kullanırken

Aynı sürüm oluşturma ilkeleri, sınıfı kullanılırken XmlSerializer de geçerlidir. Katı sürüm oluşturma gerektiğinde, veri sözleşmelerini sabit olarak kabul edin ve yeni sürümler için benzersiz, nitelenmiş adlarla yeni veri sözleşmeleri oluşturun. Gevşek sürümleme kullanılabildiğinden emin olduğunuzda, yeni sürümlerde yeni serileştirilebilir üyeler ekleyebilirsiniz, ancak mevcut üyeleri değiştiremez veya kaldıramazsınız.

Uyarı

XmlSerializer, bilinmeyen verilerin gidiş-dönüşünü desteklemek için XmlAnyElementAttribute ve XmlAnyAttributeAttribute özniteliklerini kullanır.

İleti Sözleşmesi Sürümü Oluşturma

İleti sözleşmesi sürüm oluşturma yönergeleri, sürüm oluşturma veri sözleşmelerine çok benzer. Katı sürüm yönetimi gerekiyorsa, ileti gövdesini değiştirmemeli, bunun yerine benzersiz bir nitelikli ada sahip yeni bir ileti sözleşmesi oluşturmalısınız. Gevşek sürüm oluşturma özelliğini kullanabileceğinizi biliyorsanız, yeni ileti gövdesi bölümleri ekleyebilir, ancak mevcut olanları değiştiremez veya kaldıramazsınız. Bu kılavuz hem çıplak hem de sarılmış ileti sözleşmeleri için geçerlidir.

İleti üst bilgileri, katı bir sürüm oluşturma sistemi kullanılıyor olsa bile her zaman eklenebilir. MustUnderstand bayrağı sürüm oluşturma işlemini etkileyebilir. Genel olarak, WCF'deki üst bilgilerin sürüm oluşturma modeli SOAP belirtiminde açıklandığı gibidir.

Hizmet Sözleşmesi Versiyonlama

Veri sözleşmesi sürüm oluşturma işlemine benzer şekilde, hizmet sözleşmesi sürüm oluşturma işlemleri eklemeyi, değiştirmeyi ve kaldırmayı da içerir.

Ad, Ad Alanı ve Eylem Belirtme

Varsayılan olarak, hizmet sözleşmesinin adı arabirimin adıdır. Varsayılan ad alanı olur http://tempuri.orgve her işlemin eylemi olur http://tempuri.org/contractname/methodname. Hizmet sözleşmesi için açıkça bir ad ve ad alanı belirtmeniz ve arabirim ve yöntem adlarının hizmet sözleşmesinde kullanılmasını http://tempuri.org önlemek ve önlemek için her işlem için bir eylem belirtmeniz önerilir.

Parametre ve İşlem Ekleme

Mevcut istemcilerin bu yeni işlemler hakkında endişelenmesi gerekmediğinden hizmet tarafından kullanıma sunulan hizmet işlemlerinin eklenmesi bölünemez bir değişikliktir.

Uyarı

Çift yönlü geri çağırma sözleşmesine işlem eklemek uyumsuzluğa neden olan bir değişikliktir.

İşlem Parametresini veya Dönüş Türlerini Değiştirme

Yeni tür eski tür tarafından uygulanan aynı veri sözleşmesini uygulamadığı sürece parametre veya dönüş türlerinin değiştirilmesi genellikle hataya neden olan bir değişikliktir. Böyle bir değişiklik yapmak için hizmet sözleşmesine yeni bir işlem ekleyin veya yeni bir hizmet sözleşmesi tanımlayın.

Kaldırma İşlemleri

İşlemlerin kaldırılması da önemli bir değişikliktir. Böyle bir değişiklik yapmak için yeni bir hizmet sözleşmesi tanımlayın ve yeni bir uç noktada kullanıma açın.

Hata Sözleşmeleri

FaultContractAttribute özniteliği, bir hizmet sözleşmesi geliştiricisinin sözleşmenin işlemlerinden döndürülebilecek hatalar hakkında bilgi belirtmesini sağlar.

Bir hizmetin sözleşmesinde açıklanan hataların listesi kapsamlı olarak kabul edilmez. Herhangi bir zamanda, bir işlem sözleşmesinde açıklanmayan hatalar döndürebilir. Bu nedenle sözleşmede açıklanan hata kümesini değiştirmek hata olarak kabul edilmez. Örneğin, FaultContractAttribute kullanarak sözleşmeye yeni bir hata eklemek veya mevcut bir hatayı sözleşmeden kaldırmak.

Hizmet Sözleşmesi Kitaplıkları

Kuruluşlar, bir sözleşmenin merkezi bir depoda yayımlandığı sözleşme kitaplıklarına sahip olabilir ve hizmet uygulayıcıları bu depodan sözleşmeler uygular. Bu durumda, depoda bir hizmet sözleşmesi yayımladığınızda, bunu uygulayan hizmetleri kimin oluşturduğu üzerinde hiçbir denetiminiz yoktur. Bu nedenle, hizmet sözleşmesini yayımlandıktan sonra etkili bir şekilde sabit hale gelen şekilde değiştiremezsiniz. WCF, mevcut sözleşmeleri genişleten yeni bir sözleşme oluşturmak için kullanılabilen sözleşme devralmayı destekler. Bu özelliği kullanmak için eski hizmet sözleşmesi arabiriminden devralan yeni bir hizmet sözleşmesi arabirimi tanımlayın ve ardından yeni arabirime yöntemler ekleyin. Ardından, yeni sözleşmeyi uygulamak için eski sözleşmeyi uygulayan hizmeti değiştirirsiniz ve "versionOld" uç nokta tanımını yeni sözleşmeyi kullanacak şekilde değiştirirsiniz. "versionOld" istemcileri için, uç nokta "versionOld" sözleşmesini ortaya çıkarıyormuş gibi görünmeye devam eder; "versionNew" istemcilerine ise uç nokta, "versionNew" sözleşmesini ortaya çıkarıyormuş gibi görünür.

Adres ve Bağlantı Sürümleme

İstemciler yeni uç nokta adresini veya bağlamayı dinamik olarak bulamadığı sürece uç nokta adresi ve bağlamada yapılan değişiklikler hataya neden olur. Bu özelliği uygulamaya yönelik mekanizmalardan biri, evrensel bulma açıklaması ve tümleştirme (UDDI) kayıt defteri ve istemcinin bir uç noktayla iletişim kurmaya çalıştığı ve hata durumunda geçerli uç nokta meta verileri için iyi bilinen bir UDDI kayıt defterini sorguladığı UDDI Çağırma Düzeni'dir. İstemci daha sonra uç noktayla iletişim kurmak için bu meta verilerden gelen adresi ve bağlamayı kullanır. Bu iletişim başarılı olursa, istemci gelecekte kullanmak üzere adres ve bağlama bilgilerini önbelleğe alır.

Yönlendirme Hizmeti ve Sürüm Oluşturma

Bir hizmette yapılan değişikliklerde hataya neden olan değişiklikler varsa ve aynı anda çalışan iki veya daha fazla farklı hizmet sürümüne sahip olmanız gerekiyorsa, wcf yönlendirme hizmetini kullanarak iletileri uygun hizmet örneğine yönlendirebilirsiniz. WCF Yönlendirme Hizmeti içerik tabanlı yönlendirme kullanır, başka bir deyişle iletinin nereye yönlendirileceğini belirlemek için iletideki bilgileri kullanır. WCF Yönlendirme Hizmeti hakkında daha fazla bilgi için bkz. Yönlendirme Hizmeti. Hizmet sürümü oluşturma için WCF Yönlendirme Hizmeti'nin nasıl kullanılacağına ilişkin bir örnek için bkz . Nasıl Yapılır: Hizmet Sürümü Oluşturma.

Ek bölüm

Katı sürüm oluşturma gerektiğinde genel veri sözleşmesi sürüm oluşturma kılavuzu, veri sözleşmelerini sabit olarak ele almak ve değişiklikler gerektiğinde yenilerini oluşturmaktır. Her yeni veri sözleşmesi için yeni bir sınıf oluşturulması gerektiğinden, eski veri sözleşmesi sınıfı açısından yazılmış mevcut kodu almak ve yeni veri sözleşmesi sınıfı açısından yeniden yazmak zorunda kalmamak için bir mekanizma gerekir.

Bu tür mekanizmalardan biri, her veri sözleşmesinin üyelerini tanımlamak için arabirimleri kullanmak ve arabirimleri uygulayan veri sözleşmesi sınıfları yerine arabirimler açısından iç uygulama kodu yazmaktır. Bir hizmetin 1. sürümü için aşağıdaki kod bir IPurchaseOrderV1 arabirim ve bir PurchaseOrderV1gösterir:

public interface IPurchaseOrderV1  
{  
    string OrderId { get; set; }  
    string CustomerId { get; set; }  
}  
  
[DataContract(  
Name = "PurchaseOrder",  
Namespace = "http://examples.microsoft.com/WCF/2005/10/PurchaseOrder")]  
public class PurchaseOrderV1 : IPurchaseOrderV1  
{  
    [DataMember(...)]  
    public string OrderId {...}  
    [DataMember(...)]  
    public string CustomerId {...}  
}  

Hizmet sözleşmesinin işlemleri PurchaseOrderV1 açısından yazılırken, gerçek iş mantığı IPurchaseOrderV1 açısından ifade edilecektir. Ardından, sürüm 2'de aşağıdaki kodda gösterildiği gibi yeni IPurchaseOrderV2 bir arabirim ve yeni PurchaseOrderV2 bir sınıf olacaktır:

public interface IPurchaseOrderV2  
{  
    DateTime OrderDate { get; set; }  
}

[DataContract(
Name = "PurchaseOrder",  
Namespace = "http://examples.microsoft.com/WCF/2006/02/PurchaseOrder")]  
public class PurchaseOrderV2 : IPurchaseOrderV1, IPurchaseOrderV2  
{  
    [DataMember(...)]  
    public string OrderId {...}  
    [DataMember(...)]  
    public string CustomerId {...}  
    [DataMember(...)]  
    public DateTime OrderDate { ... }  
}  

Hizmet sözleşmesi, PurchaseOrderV2 açısından tanımlanmış yeni operasyonları içerecek şekilde güncellenecektir. Mevcut IPurchaseOrderV1 açısından yazılmış iş mantığı, PurchaseOrderV2 için çalışmaya devam edecek ve OrderDate özelliğine ihtiyaç duyan yeni iş mantığı, IPurchaseOrderV2 açısından yazılacaktır.

Ayrıca bakınız

• DataContractSerializer
• DataContractAttribute
• Name
• Namespace
• Order
• IsRequired
• IExtensibleDataObject
• ExtensionDataObject
• ExtensionData
• XmlSerializer
• Veri Sözleşmesi Eşdeğerliği
• Version-Tolerant Serileştirme Geri Çağırma İşlemleri