Merhaba Arkadaşlar,

Geçen gün şöyle eskiden yazmış olduğum makalelere bir bakayım dedim. Derken gözüm WCF 4.0’ ın Betazamanlarında yazdıklarıma takıldı. O zamanlar .Net Framework 4.0' ün Beta sürümü çıktığında, incelemeye çalıştığım önemli yeniliklerden birisi de yönlendirme servisleri(Routing Service) idi.

İstemciden gelen talepleri analiz ederek, arka planda yer alan asıl servislere mesajların taşınması noktasında göz önüne alınabilecek önemli bir kabiliyet sunulmaktaydı. Aslında RoutingService, buradaki işi güçlü filtreleme özellikleri ile epeyce kolaylaştıran bir tip olarak karşımıza çıkmaktaydı. Hatta bu konuyu bir kaç makale ile de ele almaya çalışmıştım.

WCF 4.0 Yenilikleri - Routing Service Geliştirmek - Giriş [Beta 1] 

WCF 4.0 Yenilikleri - Routing Service Geliştirmek - Hello World [Beta 1]

WCF 4.0 Yenilikleri - Routing Service - Hata Yönetimi [Beta 1]

WCF 4.0 Yenilikleri - Routing Service - MatchAll Filtresi [Beta 1]

WCF WebHttp Services - Routing

Tabi bunların hepsi Beta sürümüne ait incelemelerdi. Zaman ilerledikçe yönlendirme servislerinin önemli senaryolarda göz önüne alınabileceğini de gördük. Örneğin Load Balancing gibi.

Service yönelimli mimarinin(Service Oriented Architecture) uygulandığı WCF(Windows Communication Foundation) gibi alt yapılarda karşılaşılan önemli sorunlardan birisi de, aynı servisin birden fazla farklı versiyona sahip sürümlerinin bulunması ve böyle bir durumda istemcilerin istedikleri versiyonu nasıl çağırabilecekleridir. Bu tip bir durum ile pek çok sebepten ötürü karşılaşılabilir. Tabi bir versiyonlamanın söz konusu olması için servis üzerinde bir takım değişikliklerin mevzu bahis olması da gerekmektedir   Bu değişiklikler aşağıda görülen 4 farklı kategori üzerinden ele alınabilirler.

• Contract(Sozlesme) degisimleri : Ornegin servise bir operasyon ilave edilmis veya operasyona gelip giden parametre yapisinda değişiklikler (ekleme, cikartma vb) yapilmis olabilir.
• Address(Adres) degisimleri : Servis farkli bir lokasyona tasindigi icin yeni bir endpoint adresine gereksinim duyulabilir.
• Binding(Baglayici tip) degisimleri : Ornegin servis endpoint' i icin WS-I ile belirtilen bir security değişikliği soz konusu olabilir. Bu durumda yeni bir baglayici tipin(Binding Type) uygulanmasi gundeme gelebilir.
• Implementation degisimleri : Servis icerisinde yer alan operasyonel bir metodun icerigi degismis olabilir.

Tum bu degisim cesitleri mumkun olabilir ve bu son derece de olagandir. Ancak uzun vadede bakildiginda, yasamakta olan bazi sistemlerin yenilenmesi sirasinda veya kademeli olarak guncellenmeleri noktalarinda, istemcilerin soz konusu degisime ugrasmis servislerin hangi surumlerini/versiyonlarini kullanmasi da bir sorun olarak karsimiza cikmaktadir. Ornegin yenilenecek olan bir urunun modullerinin bir kismi A servisinin 1.0 versiyonu ile calismaya devam edecek iken, diger bir kismi da yine ayni A servisinin 2.0 versiyonu ile calismak durumunda kalabilir. Iste bu noktada versiyonlanan servislerden hangisinin, istemciler tarafindan nasil ele alinabileceginin bir cozumunun olmasi gerekmektedir. Biz bu yazimizda soz konusu versiyonalama problemini WCF tarafindaki Routing servis araciligi ile cozumlemeye calisiyor olacagiz. Bildiginiz uzere Routing servisler sayesinde, istemciden gelen taleplerin karsilanarak arka planda duran asil servislere yonlendirilmesi mumkun olabilir. Bu, Load Balancing gibi cozumlerde ele alinabilecek bir servis cesidi olmakla birlikte, biraz sonra gorecegimiz gibi versiyonlama probleminde de degerlendirilebilmektedir. Tabi biz ornegimizde asagidaki senaryoyu goz onune aliyor olacagiz.

Musteri bilgisini cekmek icin kullanilan bir servisin standart olarak kullandigi operasyonlarin bazilarinin(ki ornegimizde basitlik acisindan tek bir operasyon olacak) parametrik yapisinda degisimler olmustur. Var olan surum musterinin hesap numarasina gore calismaktayken, yeni surumde soz konusu servis operasyonu TCKN ile calisiyor olacaktir. Buna gore var olan uygulamalar eski versiyonu kullanmaya devam edecek iken, yeni gelistirilecek olan uygulamalar son surumu ele alacaktir. Ama ilerleyen zamanlarda eski surumlerin icerisine mudahalelerde bulunarak hangi versiyonu kullanacaklarina calisma zamaninda karar verilmesi yetenegine sahip olmalari da gundemdedir. Iste burada servis surumlerinin uygun olan versiyonlarna calisma zamaninda karar verilmesi yetenegi, Routing Service_ lerin onemini biraz daha arttiracaktir.

Goruldugu uzere servis sozlesmesinde bir degisim soz konusudur. Routing servisin buradaki gorevi, istemciden gelecek olan versiyon talebine gore arka planda istenen servislere yonlendirme yapmaktir. Ilk sıkıntılardan birisi sudur. Aslinda servisin iki farkli versiyonu olmasina ragmen operasyon adlari aynidir. Bu yuzden Routing servisi yonlendirmeye karar vermek icin Action adlarindan yararlanamaz(Bir baska deyisle Action Filters kullanilamaz bu senaryoda) Bunun yerine, istemciden gelen mesaj icerisinde ozel bir baslik bilgisi(Custom Header) kullanilabilir ve bu bilgi Routing servis tarafinda filtrelenebilir. Kafalar karisti degil mi? Benim de Gelin basit adimlar ile ilerleyerek bir Solution uzerinden ilgili senaryoyu ele almaya calisalim. Senaryomuzda asagidaki sekilde gorulen uygulamalar soz konusudur. Åžekilden de gorulecegi uzere versiyonlari farkli olan iki servisimiz ve bunlara istemciden gelen talep dogrultusunda yonlendirme yapan bir Router Service uygulamamiz bulunmaktadir.

Senaryomuzda islemleri olabildigince basite indirgedik ve tum servis noktalarinda BasicHttpBinding baglayici tipinden yararlandik. Cok dogal olarak arka planda yer alan servislerin sayisi artabilir ve her biri farkli Binding tipleri ile de bezenmis olabilir ki bu durumda Binding bazli bir versiyonlama farki da olusacaktir. Soz gelimi servislerden birisin In-Proc modda erisilebilecek sekilde tasarlanmisken, diger biri WS Federation 2007 standartlarinda kullanilabilecek sekilde gelistirilmis olabilir.

CustomerServiceV1 ve CustomerServiceV2 temel olarak iki farkli WCF servis uygulamasi icerisinde yer almaktadir(Bu tabiki zorunlu degildir. Ayni WCF Service uygulamasi icerisinde de birden fazla svc bulunabilir ve bu sekilde bir versiyonlama yaptirilabilir) Senaryoda bu servisler farkli WCF Service Application projeleri icerisine serpistirilmislerdir. Her ikisi de ayni servis sozlesmesini(ICustomerService) disariya sunmaktadir ve GetCustomer isimli bir operasyon icermektedirler. Lakin ilk versiyon Musteri numarasi ile calisacak sekilde tasarlanmisken, ikinci versiyon TC Kimlik Numarasini kullanmaktadir. Soz konusu uygulamalarin kod ve konfigurasyon icerikleri(web.config) asagidaki gibidir. CustomerServiceV1 icin ; using System.ServiceModel; namespace CustomerServiceV1
{
    [ServiceContract]
    public interface ICustomerService
    {
        [OperationContract]
        string GetCustomer(string customerNumber);
    }
}
namespace CustomerServiceV1
{
    public class CustomerService
        : ICustomerService
    {
        public string GetCustomer(string customerNumber)
        {
            return "Musteri numarasi ile musteri bilgisi talep edildi";
        }
    }
} <?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <behaviors>
            <serviceBehaviors>
                <behavior name="">
                    <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
                    <serviceDebug includeExceptionDetailInFaults="false" />
                </behavior>
            </serviceBehaviors>
        </behaviors>
        <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
            multipleSiteBindingsEnabled="true" />
    </system.serviceModel>
</configuration> CustomerServiceV2 icin; using System.ServiceModel; namespace CustomerServiceV2
{
    [ServiceContract]
   public interface ICustomerService
    {
        [OperationContract]
        string GetCustomer(string tckn);
    }
}

namespace CustomerServiceV2
{
    public class CustomerService
        : ICustomerService
    {
        public string GetCustomer(string tckn)
        {
            return "TCKN ile musteri bilgisi cekilir";
        }
    }
} <?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <behaviors>
            <serviceBehaviors>
                <behavior name="">
                    <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
                    <serviceDebug includeExceptionDetailInFaults="false" />
                </behavior>
            </serviceBehaviors>
        </behaviors>
        <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
            multipleSiteBindingsEnabled="true" />
    </system.serviceModel>
</configuration> Buraya kadar ki kisimda goruldugu uzere standart WCF servislerinin gelistirilmesi soz konusudur. Asil muhim olan nokta ise Routing Service uygulamasinin icerigidir. Bu servis uygulamasini basit bir Console Application seklinde tasarliyor olacagiz. Kendisi bir Service Host olarak gorev yapiyor olacak. Dolayisiyla acik kaldigi surece istemcilere hizmet verebilecek. En onemli nokta konfigurasyon icerigidir. Ornek senaryomuzda app.config icerigi asagidaki gibidir.

Console uygulamasina, System.ServiceModel.Routing ve System.ServiceModel assembly' larinin referans edilmesi gerektigini hatirlatmak isterim.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service behaviorConfiguration="rtngCnfg"
               name="System.ServiceModel.Routing.RoutingService">
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:62323/routingservice/router/" />
          </baseAddresses>
        </host>
        <endpoint address="customer"
                  binding="basicHttpBinding"
                  name="routerEndpoint"
                  contract="System.ServiceModel.Routing.IRequestReplyRouter" />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="rtngCnfg">
          <routing filterTableName="versioningFilterTable" />
        </behavior>
      </serviceBehaviors>
    </behaviors>     <client>
      <endpoint name="customerServiceV1"
                address="http://localhost:62292/CustomerService.svc"
                binding="basicHttpBinding"
                contract="*" />       <endpoint name="customerServiceV2"
                address="http://localhost:62291/CustomerService.svc"
                binding="basicHttpBinding"
                contract="*" />
    </client>
    <routing>
      <namespaceTable>
        <add prefix="customer" namespace="http://core.services.customer/"/>
      </namespaceTable>
      <filters>
        <filter name="XPathFilterForVersion1" filterType="XPath"
                filterData="sm:header()/customer:SrvVersion = '1'"/>
        <filter name="XPathFilterForVersion2" filterType="XPath"
                filterData="sm:header()/customer:SrvVersion = '2'"/>
      </filters>
      <filterTables>
        <filterTable name="versioningFilterTable">
          <add filterName="XPathFilterForVersion1" endpointName="customerServiceV1"/>
          <add filterName="XPathFilterForVersion2" endpointName="customerServiceV2"/>
        </filterTable>
      </filterTables>
    </routing>
  </system.serviceModel>
</configuration> Pek tabi bu uygulama bir Routing servis oldugundan, arka planda kullanacagi servisler icin de bir Client gibi dusunulmelidir. Bu sebepten client elementi icerisinde, CustomerServiceV1 ve CustomerServiceV2 icin gerekli End Point tanimlamalari bulunmaktadir.

Router servis uygulamasi herhangibir sekilde CustomerService' lerin servis referanslarini icermemektedir.No Add Service Reference yani

Servisin kendisi System.ServiceModel.Routing.IRequestReplyRouter sozlesme tipini kullanmaktadir. Config dosyasi icerisindeki en onemli parca ise routing elementinin icerigi ve tanimlanan filtreleme opsiyonlaridir. XPath teknigine gore, gelen mesajin Header kismi analiz edilmekte ve SrvVersion kelimesinin karsiligi olan degere bakilmaktadir. Bu degerin 1 olmasi halinde CustomerService' in 1nci versiyonu, 2 olmasi halinde ise 2nci versiyonu icin bir yonlendirme yapilacagi planlanmistir. Filtreleme degeri ile, arka plandaki servis uc noktasinin eslestirilmesi ise filterTables elementi icerisinde gerceklestirilmektedir. Istemci uygulamanin Main metodunun icerigi ise son derece basit ve sadedir. using System;
using System.ServiceModel;
using System.ServiceModel.Routing; namespace RouterServer
{
    class Program
    {
        static void Main(string[] args)
        {
            using (ServiceHost serviceHost =new ServiceHost(typeof(RoutingService)))
            {
                serviceHost.Open();
                Console.WriteLine("Yonlendirme servisi etkin. Kapatmak icin bir tusa basiniz.");
                Console.ReadLine();
            }
        }
    }
} Dikkat edilecegi uzere, RoutingService tipinden bir ServiceHost ornegi olusturulmaktadir. Bu, .Net Framework_ un built-in routing alt yapisinin yuklenmesi icin yeterlidir. Gelelim istemci tarafina Istemci, musteri servislerinden hangi versiyonu kullanirsa kullansin, bir sekilde sozlesmeden haberdar olmali ve GetCustomer metoduna erisebilmelidir. Nitekim bu operasyonun cagirilabilmesi icin bir de Proxy tipine ihtiyaci vardir. Burada CustomerServiceV1 veya CustomerServiceV2 isimli servislerin herhangibigirisinden yararlanilip bir servis referansinin istemci uygulamaya eklenmesi mumkundur. Åžahsen ben bu sekilde bir yolu tercih ettim

Unutmayin! Istemcinin bilmesi gereken sozlesme Router servise ait degildir. Zaten Router servis icin Metadata Publishing opsiyonu da kapalidir ve hatta ortada bir Contract' da yoktur. Istemci, GetCustomer operasyonunu kullanacagi CustomerService sozlesmesine gereksinim duymaktadir. Sadece uygun versiyonu cagirmak icin Router servisden yararlanacak ama aslinda CustomerService' ine ait GetCustomer metodunu cagiriyor olacaktir.

Istemci tarafina Add Service Reference ile ilgili sozlesme eklendikten sonra(ki svcutil komut satiri araciligi ile de ortak bir isim adi altinda uretim yaptirilip eklenmesi tercih edilebilirdi) Main metodu icerisine asagidaki ornek kodlari eklememiz yeterli olacaktir. using ClientApp.CustomerServiceReference;
using System;
using System.ServiceModel;
using System.ServiceModel.Channels; namespace ClientApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Calistirmak istediginiz servise ait versiyon numarasini giriniz. 1, 2");
            string versionNumber=Console.ReadLine();             try
            {
                //Routing servis icin bir Endpoint bildirimi yapilir
                EndpointAddress ea = new EndpointAddress("http://localhost:62323/routingservice/router/customer");                 // Proxy nesnesi orneklenir
                CustomerServiceClient client = new CustomerServiceClient(new BasicHttpBinding(), ea);                 // Scope orneklenir
                using (OperationContextScope context = new OperationContextScope((client.InnerChannel)))
               {
                    //Header bilgisi alinir
                    MessageHeaders header = OperationContext.Current.OutgoingMessageHeaders;
                    //Header bilgisine kullanilmak istenen versiyon numarasi verilir
                    header.Add(MessageHeader.CreateHeader("SrvVersion", "http://core.services.customer/", versionNumber));
                    // Operasyon calistirilir
                    string result1 = client.GetCustomer("1122");                     Console.WriteLine(result1);
                    Console.ReadLine();
               }
            }
            catch (Exception excp)
            {
                Console.WriteLine(excp.Message);
            }
        }
    }
} Istemci uygulamada dikkat edilecegi uzere kod uzerinden bir EndPoint tanimlamasi ile ise baslanmakta ve bu uc noktayi BasicHttpBinding ile kullanan bir proxy ornegi(CustomerServiceClient) uretilmektedir. Kodun onemli olan kismi MessageHeader icerisine istenen versiyon bilgisinin eklenmesidir. Bu, o andaki operasyonel Context' in elde edilmesinin ardindan MessageHeaders tipi kullanilarak gerceklestirilmektedir. Artik senaryomuzu test edebiliriz. Iste benim uygulamalari test ederken aldigim sonuclara ait ekran ciktilari. Ilk olarak 1 degerini girerek bir cagrida bulunuyoruz; Ardindan 2 degerini girerek; Pek tabi gecerli olmayan bir degerin girilmesi halinde istemci tarafinda Exception alinmasi da son derece dogaldir Goruldugu gibi bir servisin farkli versiyonlarini host ettigimiz senaryolarda, istemcilerin istedikleri servislere gitmelerini saglamak icin araya konuslandiracagimiz bir Routing servis uygulamasindan kolayca yararlanabiliriz. Senaryoda teknik olarak istemcinin Message Header icerisine koydugu versiyon bilgisinin, yonlendirme servisi uzerinde XPath ile sorgulanmasi ile yakalanmaya calisilmasi degerlendirilmistir. Ornek senaryo istenirse daha da zorlastirilabilir. Soz gelimi servislerin sozlesmelerinde yapilacak kritik değişiklikler sonucu istemcinin bilmesi gereken contract bilgisinin de guncellenmesi sarttir. Bu konuyu bir dusunmenizi ve boyle bir senaryo olusmasi halinde istemcinin istedigi versiyonlara nasil gidebilecegini arastirmanizi ve bir cozum yolu bulmaya calismanizi oneririm. Bu iyi bir ev odevi gibi geldi bana Versiyonlama her zaman icin zor ve karmaşık bir konudur. Boylece geldik bir makalemizin daha sonuna. Tekrardan gorusunceye dek hepinize mutlu gunler dilerim. RoutingAndVersioning.zip (117,79 kb)