Servis Tabanlı Geliştirme

Hatırlayacağınız üzere bir önceki makalemizde, dayanıklı WCF servislerinin (Durable WCF Services) nasıl geliştirilebileceğini incelemeye başlamıştık. Kısaca hatırlatmak gerekirse dayanıklı WCF servislerini şu şekilde tanımlayabiliriz; belirli bir süre için durumlarını bir depolama alanında saklayarak koruyabilen ve t süre sonrasında istemci uygulama tarafından bırakıldığı haliyle kullanılabilen servisler. Konunun ilk aşamasında, varsayılan olarak SQL sunucusu üzerindeki bir depolama alanının kullanıldığı senaryo üzerinde durmuştuk. (Hatırlayaım, SQL sunucusu üzerinde veriyi saklamak yönetsel açıdan pek çok işi kolaylaştırmaktadır.) Bu makalemizde ise kaldığımız yerden devam edeceğiz ve aşağıdaki iki soruya yönelik çözümler geliştirmeye gayret edeceğiz.

Uzun zamandır Windows Communication Foundation (WCF) konulu bir araştırma üzerinde durmamıştık. Aslında WCF 4.0 ve WF 4.0 ile ilgili yeniliklerin uzun süredir konuşulduğu şu günlerde, WCF tarafında oldukça önemli bir yere sahip olan ve hatta Workflow Foundation açısından da değer arz eden bir konuya değiniyor olacağız. Dayanıklı WCF Servisleri (Durable WCF Services).

Pek çok istemci uygulama için önem arz eden konular arasında doğrulama (Authentication), Rol Yönetimi (Roles Management), profile (Profile) göre kişiselleştirme yer almaktadır. Özellikle Web tabanlı uygulamalarda bu kıstaslar daha çok ön plana çıkmaktadır. Nitekim Client/Server mimarinin en güzel uyarlamalarından birisi olan web tabanlı geliştirmelerde, istemcilerin doğrulanması, rollerine göre ne yapabileceklerinin belirlenmesi, profillerine göre istekte bulundukları sayfaların kişiselleştirilmesi önemlidir. Bu noktada Asp.Net 2.0 sürümünden itibaren saymış olduğumuz bu kriterlerin çok daha kolay bir şekilde uygulanabilmesi sağlanmıştır.

Bir önceki makalemizde WCF (Windows Communication Foundation) mimarisinde veri sözleşmelerinin (Data Contracts) karşı taraflarda farklı versiyonlarının olması durumunda oluşan vakaları incelemeye çalışmıştık. Versiyonlama (Versioning) vakaları dışında serileştirmede önem arz eden konulardan biriside, servis tarafında yayınlanan veri sözleşmeleri içerisinde serileştirilemeyen (NotSerializable) tiplerin var olmasıdır. Bu durum çoğunlukla, serieştirilebilen tipin kullandığı bazı dahili tiplerin farklı assembly dosyaları içerisinde yer aldığı vakalarda ortaya çıkmaktadır. Öyleki, diğer assembly içerisinde yer alan tipe (type) geliştirici tarafından müdahale edilemeyebilir ve bu sebepten serileştirilebilmesi için DataContract veya DataMember üyeleri uygulanamayabilir. Bu durum aşağıdaki şekilde örnek bir senaryo üzerinden ifade edilmeye çalışılmaktadır.

Bir önceki makalemizde WCF (Windows Communication Foundation) mimarisinin kullandığı serileştirici tiplerden bahsetmiş ve son olarak versiyonlama (Versioning) vakalarına değinmiştik. Bu makalemizde ise versiyonlama vakalarının örnek uygulama üzerinden test ederek analiz etmeye çalışacağız. Versiyonlama vakalarının merkezinde veri sözleşmesi (Data Contract) farklılıkları yer almaktadır. Daha öncedende değinildiği üzere üç farklı versiyonlama vakası bulunmaktadır. New Members, Missing Members, Round-Trip.

Serileştirme (Serialization) ve çözümleme (Encoding) çoğu zaman bir birlerine karıştırılan kavramlar olabilmektedir. Oysaki aralarında çok ince ama bir o kadarda önemli farklılıklar vardır. Serileştirme ve çözümleme, SOA (Service Oritented Architecture) tarzındaki uygulama çözümlerinde sıklıkla kullanılmaktadır. Nitekim bu tip mimarilerde servis ve istemci arasında yapılan veri transferlerinde bilginin serileştirilmesi ve mesajların çözümlenmesi gerekmektedir.

WCF (Windows Communication Foundation) mimarisinde sunucu (Server) tarafındaki çalışma ortamınının (WCF Runtime) hazırlanması ile ilişkili olaraktan ServiceHost sınıfı kullanılmaktadır. Bir başka deyişle ServiceHost sınıfı uygulama sunucusu (Application Server) üzerindeki gerekli hazırlıkların yapılmasını sağlamaktadır. ServisHost sınıfı çoğunlukla, servis nesnesinin IIS (Internet Information Services) veya WAS (Windows Activation Services) üzerinden yayınlanmadığı durumlarda kullanılmaktadır.

Dağıtık mimari uygulamaları (Distributed Applications) geliştirilirken çoğunlukla Client/Server veya N-Tier modelleri göz önüne alınmaktadır. Oysaki dağıtık mimari uygulamaları için Peer-to-Peer (P2P) modelide söz konusudur. P2P modelinde istemci ve sunucu arasında bir fark yoktur ve alt yapı hazırlıkları diğer modellere göre biraz daha karmaşıktır. Programlama zorluğu nedeni ile geliştiriciler zaman zaman bu modelden kaçınırlar.

Uzun bir aradan sonra tekrar birlikteyiz. Windows Communication Foundation mimarisinin geliştirilmesininin tek amacı, var olan dağıtık mimari modellerini bir çatı altında birleştirmek değildir. Buna paralel olaraktan WCF mimarisi,.Net Remoting, Xml Web Servisleri, WSE (Web Service Enhancements), MSMQ (Microsoft Message Queue), COM+ gibi pek çok dağıtık uygulama geliştirme modelinin çalışma zamanı alt yapısının kolayca oluşturulabilmesinide hedeflemektedir. Burada dekleratif programlama modelinin benimsenmesinin önemli katkısı vardır. Sonuçta geliştiricinin sıklıkla yapmak zorunda kaldığı alt yapı hazırlıklarının attribute (nitelik) veya konfigurasyon bazlı olacak şekilde ayarlanabilmesi son derece avantajlıdır.

Bir önceki yazımızda WCF (Windows Communication Foundation) servislerinin, WF (Windows WorkFlow) uygulamaları içerisinden nasıl çağırıldığını incelemiştik. Bu yazımızda ise tam tersine, bir Workflow örneğinin servis olarak nasıl sunulabileceğini analiz ediyor olacağız. Bazı durumlarda kod akışlarının birer servis olarak istemcilere sunulması gerekebilir. Burada söz konusu kod akışlarının Servis Yönelimli Mimarinin (Service Oriented Architecture) imkanlarından yararlanıyor olması isteği ön plana çıkmatadır. Çok doğal olarak servis gibi yayınlanan akış tipleri (Workflow Instance), istemci ile olan mesajlaşmalarında SOA temelli olanakları kullanabilir hale gelmektedir. Bu noktada WCF ile WF entegrasyonu göz önüne alınmalıdır.

Bilindiği üzere Window Communication Foundation ve Windows Workflow Foundation,.Net Framework 3.0 ile birlikte gelen önemli teknolojilerdendir. WCF servis yönelimli mimariye (Service Oriented Architecture) yeni bir yaklaşım getirip, dağıtık mimari uygulama geliştirme kavramlarını bir çatı altında toplayarak güçlü, daha platform bağımsız ve güvenilir bir ortamda geliştirme yapılabilmesini olanaklı kılan bir alt yapı sunmaktadır. WF ise, birden fazla adımdan oluşan kod süreçlerinin iş akışı (Workflow) tarzında olay güdümlü (Event-Driven) yada sırasal (Sequential) olacak şekilde tasarlanarak çeşitli.Net uygulamalarında kullanılabilmelerini mümkün kılan bir alt yapı tesit etmektedir.

Yazılım dünyası çeşitli ürün gruplarını ve bunların üretimini içeren materyaller içermektedir. Son kullanıcıya (End User) veya geliştiricilere (Developers) yönelik olarak tasarlanan ürünlerin yazılmasında çeşitli program geliştirme arabirimleri kullanılmaktadır. Belkide bunlardan en popüler olanları Microsoft tarafından üretilen Visual Studio ailesidir. Visual Studio.Net ile başlayan serüvende kısa bir süre öncede Visual Studio 2008 sürümü son haliyle yayınlanmıştır. Yeni sürüm özellikle.Net Framework 2.0, 3.0 ve 3.5 için ortak ve tek bir geliştirme ortamı sunmasıyla hemen dikkati çekmektedir. Bu ve benzer özelliklerin yanında Windows Communication Foundation çözümleri içinde ek bir takım yenilikleri gelmektedir.

Windows Communication Foundation ile geliştirilen Servis Yönelimli Uygulama (SOA-Service Oriented Architecture) çözümlerinde konfigurasyon bazlı (Configuration Based) geliştirme süreci oldukça yaygındır. Konfigurasyon dosyaları içerisinde yer alan bilgiler yardımıyla WCF çalışma zamanı (WCF Runtime) ortamı otomatik olarak bazı işlemler gerçekleştirir. Söz gelimi istemci (Client) ve servis (Service) arasında taşınacak olan mesajların çözümlenmesi (Encoding), bunların seçilen bağlayıcı tipin (Binding Type) belirlediği protokole göre aktarılması gibi alt yapı (Infrastructure) hazırlıkları otomatik olarak gerçekleştirilir. Hatta istemcinin servis üzerinden talep ettiği bir operasyon (Service Operation), servis tarafındaki konfigurasyon bilgilerinden yola çıkılarak hazırlanan çalışma zamanı sayesinde, anlamlı bir metod çağrısı haline dönüşür.

Son yıllarda özellikle Web uygulamalarında AJAX (Asynchronous Javascript And XML) mimarisi oldukça yaygın bir şekilde kullanılmaktadır. Özellikle sunucu taraflı (Server-Side) çalışan Asp.Net gibi web uygulaması geliştirme modellerinde istemciler (Clients) tarafından sunucuya (Server) doğru gerçekleştirilen POST işlemleri sırasında, sayfanın tamamının gönderilmesi söz konusudur. AJAX modeli sayesinde istemci tarafında yer alan sayfanın tüm içeriği yerine sadece değiştirilmesi istenen parçaların sunucuya gönderilmesi, işlenmesi ve cevapların alınarak tarayıcı uygulama (Browser Application) üzerinde gösterilmesi mümkün olmaktadır. Böylece sayfanın gerçektende değişmesi gereken içeriğinin istemci ve sunucu arasındaki hareketi söz konusudur. Bir başka deyişle gereksiz olan içeriğin sunucuya tekrar gönderilmesinin, işlenmesinin önüne geçilmesi sağlanmaktadır. Bu bir anlamda son kullanıcı (End User) için daha zengin etkileşime sahip ve performanslı bir web ortamı oluşturulması anlamına da gelir.

Web programlama modelinin en büyük avantajlarından biriside istemci (Client) tarafındaki uygulamaları düşünmeye gerek kalmadan istemci-sunucu (Client/Server) mimarisine uygun sistemler geliştirilebilmesidir. Basit olarak HTTP protokolünün farklı metodlarına göre işleyen bu sistemde, istemcilerin farklı tipte olabilecek tarayıcı programlar (Browsers) üzerinden talepte bulunmaları söz konusudur.

Windows Communication Foundation, Net Framework 3.5 ile gelen bazı yeni CLR (Common Language Runtime) tipleri sayesinde RSS 2.0 ve Atom 1.0 formatlarında yada diğer özel formatlarda içerik paylaşımı (Syndication) yapılmasına izin veren özelliklere sahip olmuştur. Bu tipler sayesinde bir WCF servisi (Service) üzerinden özellikle HTTP protokolünün GET, POST, HEAD ve benzeri metodlarına göre talep-cevap (Request-Response) işlemleri gerçekleştirilebilmektedir. Bir başka deyişle EndPoint noktaları üzerinden farklı tipte verilerin, dünya standartlarına uygun olacak şekilde yayınlanması mümkündür. İşte bu makalemizde bir WCF servisi üzerinden en basit haliyle RSS veya Atom formatında içerik paylaşımlarının nasıl yapılabileceğini incelemeye çalışacağız.

Windows Communication Foundation (WCF) mimarisinde belkide en kritik unsurlardan birisi EndPoint kavramıdır. EndPoint, Servis Yönelimli Mimari (Service Oriented Architecture - SOA) uygulamaları geliştirmek için kullanılan WCF modelinde, istemciler (Clients) ile servis (Service) arasındaki haberleşmede yer alan kritik bir parçadır. WCF’in temellerini incelediğimiz daha önceki yazılarımızda, EndPoint kavramının aslında WCF mimarisinin ABC’si olduğundan bahsetmiştik. ABC bilindiği üzere adres (Address), bağlayıcı (Binding) ve sözleşme (Contract) bilgilerinden oluşmaktadır. Buna göre bir EndPoint yardımıyla, servisin istemcilere hangi adresten, hangi protokolle, hangi kurallara göre neyi sunacağı bilgisi aktarılabilir. Bununla birlikte, EndPoint’ler istemci tarafından gelecek olan taleplerin karşılanmasında da büyük öneme sahiptir.

Windows tabanlı olan Servis Yönelimli Mimari (Service Oriented Architecture) tekniklerinden biriside.Net Remoting’dir..Net Remoting mimarisi ağırlıklı olarak TCP bazlı ve Binary tabanlı paket iletiminde kullanılır. En büyük özelliklerinden birisi, sadece Windows işletim sistemlerinden oluşan ağlarda koşabilmesidir. Elbette HTTP üzerinden SOAP-Simple Object Access Protocol formatına uygun alt yapı kurulmasıda mümkündür. Bu sayede internet ağındada ektin şekilde kullanılabilir. Ancak Windows bağımlı olması platform bağımsızlığını ortadan kaldırmaktadır. Günümüzde WCF (Windows Communication Foundation) gibi daha ölçeklenebilir (Scalable), birleştirilmiş (Unified) bir Servis Yönelimli Mimari (SOA) açılımıda mevcuttur. Bu durumda geliştiricilerin karşısına önemli bazı sorular ve sorunlar çıkmaktadır. İşte bunlardan bir kaçı;

Günümüzde resim,ses, video, doküman formatında kaynakların yoğun olarak kullanıldığı pek çok sistem bulunmaktadır. Söz gelimi içerik yönetim sistemleri (Content Management Systems) neredeyse sırf bu tip verilerin kullanılması üzerine kurulmuştur. Resim, ses, video formatındaki veri kaynaklarının oluşturduğu en büyük problem ise boyutlarının söz konusu sistemlerde ne kadar etkin bir şekilde ölçeklenebildiğidir. Büyük boyutlu dosyalar çeşitli amaçlarla kullanılabilirler.

TCP veya HTTP bazlı iletişimlerde, tarafların aynı zaman dilimi içerisinde çalışıyor olmaları gerekmektedir. Böyle bir mesajlaşma sürecinde taraflardan herhangibirin çalışmaması, aradaki bağlantının kopması gibi nedenlerden dolayı tüm iletişimin aksamasıda muhtemeldir. Bazı gerçek hayat senaryolarında, sistemin tarafları olan istemci (Client), sunucu (Server), ağ (Network) bileşenlerinin çökmesi durumlarında dahi işlevselliğin devam edebilmesi istenebilir. Bunun dışında, çalışan sistemin içerisindeki bileşenlerin sürekli bir bağlantıda olmadığı durumlarda bu tip iletişimleri zorlaştırmaktadır. Bir başka deyişle ağa sürekli olarak bağlanamayan ama offline olarak çalışabilen istemcilerin bu tip bir mesajlaşma sisteminin parçası olması istendiğinde senkronizasyon güçlükleri ortaya çıkmaktadır.