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, hataya neden olan bir 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 konuda, hizmetin bu tenet'e bağlı olduğu varsayılır ve bu nedenle istemcilerinden bağımsız olarak değiştirilmesi veya "sürümü" yapılması gerekir.
Hataya neden olan bir değişikliğin beklenmeyen olduğu ve önlenemediği durumlarda, bir uygulama bu ağı yoksaymayı seçebilir ve istemcilerin 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. Hataya neden olan değişiklikler veri üyelerini kaldırmayı veya veri türlerini uyumsuz olarak değiştirmeyi içerebilir. Bu özellik, hizmetin istemcilerini bozmadan sözleşmelerinin sürümünü değiştirmesinde biraz enlem 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, ve DataContractAttribute sınıflarını kullanırken veri sürümü oluşturma ile DataContractSerializer ilgilidir.
Katı Sürüm Oluşturma
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. Hiç tasarlanmamış 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.
Lax 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 bilinmeyen veri üyelerini yoksayıp yok saydığı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 Namespacebelirtin. .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
Üyenin adını veya veri türünü değiştirmek veya veri üyelerini kaldırmak, gevşek sürüm oluşturma izni olsa bile hataya neden olan 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 Verilerin Gidiş Dönüşleri
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 yuvarlak kopyalamayı etkinleştirmek için türün arabirimi uygulaması IExtensibleDataObject 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 istemciye uygun değildir, ancak örnek seri hale getirildiğinde, özelliğin ExtensionData içeriği veri sözleşmesi üyelerinin verilerinin geri kalanıyla 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 etkili bir şekilde sabit hale getirilirken 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üm oluşturmanın kullanılabildiğinden emin olduğunuzda, yeni sürümlerde yeni seri hale getirilebilir üyeler ekleyebilirsiniz, ancak mevcut üyeleri değiştiremez veya kaldıramayın.
Not
, XmlSerializer bilinmeyen verilerin yuvarlama işlemini desteklemek için ve XmlAnyAttributeAttribute özniteliklerini kullanırXmlAnyElementAttribute.
İ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 oluşturma gerekiyorsa, ileti gövdesini değiştirmemeli, bunun yerine benzersiz bir nitelenmiş 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 sarmalanmış ileti sözleşmeleri için geçerlidir.
Katı sürüm oluşturma kullanılıyor olsa bile ileti üst bilgileri 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 Sürümü Oluşturma
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.
Not
Çift yönlü geri çağırma sözleşmesine işlem eklemek hataya 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.
İşlemleri Kaldırma
İşlemlerin kaldırılması da hataya neden olan 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, sözleşmeden mevcut bir hatayı kullanarak veya kaldırarak sözleşmeye FaultContractAttribute yeni bir hata ekleme.
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" istemcilerinde uç nokta "versionOld" sözleşmesini ortaya çıkarmış gibi görünmeye devam eder; "versionNew" istemcilerine, uç nokta "versionNew" sözleşmesini kullanıma sunar.
Adres ve Bağlama Sürümü Oluşturma
İ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
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 açısından PurchaseOrderV1yazılacak olsa da, gerçek iş mantığı açısından IPurchaseOrderV1olacaktır. 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, açısından PurchaseOrderV2yazılmış yeni işlemleri içerecek şekilde güncelleştirilecektir. açısından IPurchaseOrderV1 yazılmış mevcut iş mantığı için PurchaseOrderV2 çalışmaya devam edecek ve özelliğine ihtiyaç duyan OrderDate yeni iş mantığı açısından IPurchaseOrderV2yazılacaktır.