Servis Tabanlı Geliştirme

Uzun süredir macera dolu bir rüya görmüyordum. Geçtiğimiz gece askeri bir birlikte görev yapmaktaydım ve gerideki topçu birliklerime hedeflere ait koordinatları bildiriyordum. Tabi gerçek hayatta yedek subak eğitimimi Topçu sınıfında, Ateş Destek üzerine aldığım için keşif, arama ve bulma gibi konularda azda olsa bilgi sahibiydim. Rüyamda da bu bilgilerimi kullandığımı itiraf edebilirim. Peki konumuz nedir?

Nihayet WCF 4.0 için basitleştirilmiş konfigurasyon (Simplified Configuration) yeniliklerinden sonuncusuna değineceğimiz blog girişimize ulaştık. Tabiki WCF 4.0 tarafındaki diğer yenilikleride zaman içerisinde inceliyoruz olacağız. Örneğin Discovery, Routing, RESTful geliştirmeleri vb…Ancak diğer köklü değişikliklere başlamadan önce konfigurasyon tarafına son noktayı koyalım artık.

WCF 4.0 ile birlikte gelen yenilikler bitmek bilmiyor.

Bir süredir WCF 4.0 ile birlikte gelen yenilikleri tek tek incelemeye çalışıyoruz. İlk incelediğimiz noktalar konfigurasyon ayarları üzerinde yapılmış olan basitleştirmeleri içermektedir. Bu değişimlerden bir diğerini inceleyerek serimize devam ediyor olacağız. Bu anlamda konumuz Standard Endpoints başlığı altında gelen yeniliklerdir. Bu özelliği inceledikten sonra konuyu anlamanın en iyi yolunun bir önceki versiyonda ne olduğuna bakmak olduğuna karar verdim.

Bir kaç gece önce evde DVD keyfi yapmak için A Fistful Of Dollars (Per un pugno di dollari) isimli çok eski bir Western filmi seyrettim. Filmi seyretmeyenler için bir kaç hatırlatma yapayım. Film aslında The Good The Bad and The Ugly ile For a Few Dollars More birlikte oluşan bir üçlemenin ilk halkasını oluşturmakta. Hepside çok güzeldi. Bu filmin belkide en can alıcı ve etkileyici yeri ise sonlarında yaşanan silahlı dövüş sahneleridir.

WCF 4.0 ile birlikte gelmesi muhtemel yenilikleri incelemeye kaldığımız yerden devam ediyoruz. Bu yazımızda ele alacağımız konu, config dosyası içerisinde kullanılan bağlayıcı tipe (Binding Type) özel konfigurasyon ayarları ile ilişkili olacak. Konuyu net bir şekilde anlayabilmek için.Net Framework 3.5 tabanlı olarak geliştirilmiş basit bir servis uygulaması ile işe başlamamız gerekiyor. Uygulamamıza ait App.config dosyasının içeriği aşağıdaki gibidir.

Bir önceki blog yazımızda, WCF 4.0 ile birlikte gelebilecek özelliklerden birisi olan Default EndPoints kavramına değinmeye çalışmıştık. Durumu kısaca özetleyip, bu konu ile bağlantılı olan başka bir yenileğe bakarak devam edelim. Default EndPoints özelliği sayesinde, WCF çalışma zamanına (Runtime) açık bir şekilde EndPoint bildirimi yapma zorunluluğumuz ortadan kalkmaktaydı. Bir başka deyişle config dosyalarında veya kod bazında herhangibir EndPoint bildirimi yapmasak dahi, WCF çalışma zamanı, ServiceHost nesnesinde bildirilen Uri bilgilerine göre varsayılan iletişim noktalarını üretmekteydi. Ancak bir geliştirici gözü ile olaya yaklaştığımızda, Uri içerisinde yer alan string bilgiden nasıl yararlanılabildiği, yararlanıldıysada neye göre varsayılan bağlayıcı tiplerin (Binding Type) seçildiği bir soru işareti oluşturmaktadır.

Çok eskinden.Net Remoting ile ilişkili uygulamalarda çalışırken, servis ve istemci taraflarının konfigurasyon dosyası bazlı ayarlamaları sırasında, Visual Studio.Net 2003 intelli-sense özelliğinin kaybolduğuna şahit olmuştum. Gerçektende config dosyası içerisindeki intelli-sense özelliği belirli bir elemente kadar destek veriyor ama sonrasında kayboluyordu. Böyle bir durumda pek çok ayarlamayı ezbere yapmak zorunda kaldığımı hatırlıyorum.

Minik bir çocukken Televizyon bağımlılığı (Malesef bu aptal kutuda çok vakiy geçirebiliyor çocuklar ) nedeniyle pek çok çizgi filmi izlediğimi hatırlıyorum. Voltran, Transformers, Red Kit ve Daltonlar, Denver The Last Dinasour, Clementine filan derken arada sıradada “Bi kedi gördüm sanki” diyen Tweety

Geçtiğimiz günlerde çok ilginç bir rüya daha gördüm. Ne zamandır paylaşmayı planlıyordum. Kısmet bu yazıymış. Rüyamda bir uçak yolculuğu ile Japonya’nın başkenti Tokyo’ya gidiyordum. Antartika üzerinden önce Hawai’ye oradanda Eminönü iskelesine uğradıktan sonra bir anda kendimi Tokyo’da buldum. E rüya tabi…Bir süre Japonya’ya vizesiz gidilebildiğini duymuştum.

Bildiğiniz üzere bir süredir WCF REST Starter Kitile ilişkili yazılarımı ve görsel derslerimi sizlerle paylaşmaktayım. Ancak önemli bir noktayı kaçırdığımı düşünüyorum.

REST bazlı WCF servislerinde zaman zaman istemcilere içerik boyutları yüksek olan çıktılar veriyor olabiliriz. Bunlara örnek olarak resim veya metin dosyaları verilebilir. Aslında Stream veya TextWriter bazlı içerikler dersek çok daha doğru olacaktır.(Neden TextWriter olarak belirttiğimi yazının sonunda öğrenebileceğiz.) Özellikle istemci/sunucu bazlı uygulamalar göz önüne alındığında, büyük boyutlu içeriklerin karşı tarafa aktarılması sırasında karşılaşılabilecek pek çok performans kaybı söz konusudur. Sunucu tarafından bakıldığında, istemcinin talep ettiği içeriğin Stream olarak elde edilmesi sırasında bellek ve işlemci bazında yüklenmeler olabilir. Buda sunucunun performansının olumsuz yönde etkiliyebilir. Nitekim kaynakların israfı söz konusudur. Tabi istemci tarafı açısından bakıldığında da, gelen Stream içeriğinin işlenmesi esnasında bazı sıkıntılar ile karşılaşılabilir.

REST (REpresentational State Transfer) modelini uygulayan WCF servislerinin geliştirilmesinde, WCF Rest Starter Kit ile birlikte gelen kolaylıklardan biriside, önbellekleme (Caching) işlemlerinin dekleratif (Declarative) olarak yapılabilmesidir. Burada dekleratiflikten kastımız, önbellekleme bildirimlerinin çalışma zamanına nitelik (Attribute) yoluyla bildirilmesidir. Web programlama modeline göre geliştirilen servislerin çeşidi ne olursa olsun, performans kriterleri söz konusu olduğunda önemli olan noktalardan biriside verilerin istemciye gönderilmeden önce gerekiyorsa belirli süreler boyunca veya bazı koşullar sağlanıncaya kadar sunucu ön belleğinde (hatta bazen istemci tarafında tarayıcı uygulama için ayrılan özel bölgelerde) tutulmasıdır.

Bir önceki yazımızdaREST bazlı WCF servisleri için, WCF Rest Stater Kit yardımıyla istemci uygulamaların nasıl geliştirilebileceğini incelemeye çalışmıştık. İstemci açısından önemli olan konulardan biriside, uzun sürebilecek request/response operasyonları sırasında uygulamasını kullanmaya devam edebiliyor olmasıdır. Tahmin edeceğiniz üzere istemci tarafında bir request’in asenkron olarak gönderilip, işlenmesi konusunu değerlendiriyor olacağız. Aslında asenkron erişimden kastımız, istemcinin talebi gönderdikten sonra cevabın anında gelmesini beklemeden çalışmasına devam edebilmesidir. Servis tabanlı uygulamalar söz konusu olduğunda, asenkron işlemleri iki lokasyonda tasarlayabiliriz.

Bir önceki blog yazımızda, koleksiyon bazlı WCF servislerinin REST modeline göre geliştirilmesini incelemeye çalışmış ve REST Starter Kit’in sağladığı kolaylıklara değinmiştik. Belkide yazının en zor kısımlarından biriside CUD (CreateUpdateDelete) işlemlerinin test edilmesiydi. Nitekim burada istemciden gönderilecek Request paketlerinin HTTP protokolünün uygun olan POST, PUT, DELETE metodlarından birisine göre hazırlanıp iletilmesi gerekmekteydi. Bu nedenle, Fiddler aracını kullanarak talepleri oluşturmuş ve testleri gerçekleştirmiştik. Aslında, sadece veri çekilmesi işleminde (HTTP GET) işimiz nispeten çok daha kolay olmaktadır. Basit bir tarayıcı uygulama bu iş için yeterlidir. Peki ya istemci, bir geliştirici tarafından yazılacak ve söz konusu REST bazlı koleksiyon servisini tüketecek bir uygulama olacaksa…

Bildiğiniz üzere bir süredir WCF servislerinin REST modeline göre geliştirilmesi ile ilgili bilgilerimi ve öğrendiklerimi sizlerle paylaşmaktayım. Bu nedenle dün gece yaşadığım bir macerayıda aktararak başıma gelenleri sizlerle paylaşmak istiyorum. Bir süre önce WCF Rest Starter Kit’i incelemeye başlamış ve bu konuyla ilgili olaraktan bir görsel video yayınlamıştım.(NedirTv? bağlantısı)

SOAP (Simple Object Access Protocol) bazlı WCF servislerininin REST (REpresentational State Transfer) modeline taşınmasını ele aldığımız bir önceki yazımızdavarsayılan URL şablonu kullanılmıştır. Varsayılan URL şablonu, WebGet niteliğinde herhangibir başka desen belirtilmediğinde devreye girmektedir. Kabaca aşağıdaki dizime benzer bir yapıdadır.

.Net Framework 3.5 ile birlikte, WCF (Windows Communication Foundation) tarafına kazandırılan önemli yeteneklerden biriside Web programlama modelidir. Bu modelin getirileri arasında, WCF servislerinin REST (Representational State Transfer) tekniğine göre yazılıp, kullanılabilmesi de vardır. Özellikle SOAP (Simple Object Access Procotol) bazlı WCF Servisleri ile REST modeline göre tasarlanmış servisler arasındaki en büyük fark, HTTP metodunun çeşididir.

Yazdığımız programların belirli kriterlere göre test edilmesi proje süreçleri içerisinde önem arz eden konulardan birisidir. Bilindiği üzere pek çok test çeşidi vardır. Bunların bir kısmı standart haline gelmiş tekniklerden oluşmaktadır. Örneğin web uygulamalarının beliri bir düzenle çalıştırılaran Request’ler ile test edilmesi. Stres testlerine tabi tutularaktan çok sayıda request sonrası web uygulamasının çalışmasının analiz edilmesi veya en basit anlamda bir programın çalışmasının ana parçalarından olan metodlarının, beklenen sonuçları verip vermediğinin araştırılması vb…

Servis tabanlı uygulamalarda en önemli noktalardan biriside aradaki bilgi transferlerinin nasıl ve ne şekilde gerçekleştirildiğidir. Gerçek şuki, bu bilgi transferinin oluşma şekli çoğu zaman geliştiricinin gözünden kaçan yada çok fazla ilgilenmediği bir konu olmaktadır. Nitekim çoğu servis geliştirme aracı buradaki söz konusu içeriğin hazırlanmasını, gönderilmesini veya alınmasını otomatikleştirmektedir. Özellikle Windows Communication Foundation tarafında, bilginin istemci ve servis arasındaki dolaşımında bağlayıcı tiplerin (Binding Type) seçilmesi ile zaten arka tarafta ne şekilde bir haberleşme olacağı ve paketlerin nasıl hazırlanacağı belirlenmiş olur.