Servis Tabanlı Geliştirme

Servis Yönelimli Mimari (Service Oriented Architecture) çözümlerinde zaman zaman yönlendirme amaçlı servislerin yazılması gerekmektedir (Router Service). Bu servislerin genel kullanım amacı çoğunlukla, istemcilerden gelecek olan talepleri değerlendirip asıl işi yapacak olan servislere devretmek ile ilişkilidir.

Yandaki resimdeki gibi çok çok uzun bir yolun başında ve ulaşmanız gereken yere yüzlerce kilometre mesafede olduğunuzu hayal edin. Sabırlı bir şekilde bu yolu gidebilmek için çok iyi bir disipline sahip olmanız gerekir. Yazılım geliştirme denilen büyük okyanusun içerisinde de bu tip yollar ile karşılaşmaz mıyız? Hemde sıklıkla karşılaşırız. Yılmadan yola devam edenler, nihayetinde mutlu sona ulaşırlar. Ama belkide ulaşmazlar. Bu tamamen zamanın o andaki çevresel koşullarına bağlı olarak değişir. İşte bu yazımızda hakikaten sadece geliştirme aşaması dahi insanı çileden çıkarabilen zahmetli bir yola baş koyuyor olacağız. Hedefimiz, WS-Discovery tabanlı WCF sistemlerinde Managed Discovery modelini uygulayabilmek.

WCF 4.0 tarafında WS-Discovery tabanlı olarak gerçekleştirilen uygulamalarda önem arz eden noktalardan biriside, servislerin online veya offline olma durumlarını, bulundukları ağ üzerindeki dinleyicilere (Listeners) bildirmeleridir (Announce). Bildiri şeklinde yapılan yayınlamalar aslında istemcinin ağ üzerine yaydığı multicast mesajların yoğunluğunu azaltmak gibi olumlu bir etkiye de sahiptir. Şimdi bu bildirim işlemlerinin nasıl yapılacağını incelemeye çalışalım. Ad Hoc modelinin uygulanması ile ileişkili yazımızdaki örneğimizi bu amaçla devam ettirebiliriz. Servis tarafında konfigurasyon dosyasında sadece aşağıdaki eklemeleri yapmamız yeterli olacaktır.

Bir öncekiyazımızda WCF 4.0 tabanlı servislerde WS-Discovery protokolünün, Ad Hoc modeline göre nasıl uygulanabileceğini görmüştük. Ad Hoc modelinde istemcinin, yerel ağ üzerine dahil olan bir servisi aramak için kullanabileceği kriterleri önceden belirlemesi ve bunları kullanması gerektiğinden bahsetmiştik. Bu amaçla kod tarafında FindCriteria tipinden yararlanılmaktadır. Bir önceki örneğimizde, arama kriterinde sadece servis sözleşmesini (Service Contract) kullanmıştık.

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.

Bir önceki blog yazımızda,.Net RIA Servislerin kullanıldığı Silverlight uygulamalarında doğrulama (Validation) işlemlerinin nasıl yapılabileceğini incelemeye çalışmıştık. Bu yazımızda ise, Range, Required, StringLength, RegularExpression gibi built-in niteliklerle (attribute) gerçekleştirilen doğrulamalar haricinde kalan özel durumlar için nasıl ilerleyebileceğimizi araştıracağız. Konuyu adım adım irdelersek, aşağıdaki işlemleri yapmamız gerekmektedir.

Her ne kadar şu günlerde güzel ülkemizin Ege kıyılarında kısa bir dinlenme molası vermiş olsamda, internetin sahil kıyılarındaki cafe’lere kadar girmiş olması, herşeyi değiştiriyor. Artık bir yaşam tarzı haline gelen Yazılımdan, onun gizemli dünyasından uzak durmak bu nedenle, şu sıralar aşağıdaki şekilde görülen yerde tatilde bile olsam çok zor. Bu kısa yazımda sizlere yine.Net RIA Servisleri ile ilişkili bilgilerimi aktarmaya gayret edeceğim. Bu seferki konumuz DomainDataSource isimli Silverlight kontrolü.

Bildiğiniz gibi bir süredir.Net RIA Servisleri ile ilişkili araştırmalarıma devam etmekteyim. Bu yazımızda,.Net RIA Servislerinde Insert, Update ve Delete işlemlerini nasıl yapabileceğimizi basit bir örnek üzerinden adım adım aktarmaya çalışacağım. Daha önceki Hello World örneğimizden farklı olarak, DAL (Data Access Layer) içerisinde LINQ to SQL modelini kullanıyor olacağız. İlk adımımız elbetteki bir Silverlight Application projesi oluşturmak olmalıdır..Net RIA Servisini kullanacağımız için, projenin oluşturulması sırasında Link to ASP.NET Server Project seçeneğinin işaretli olmasına dikkat edelim.

Hatırlayacağınız gibi bir önceki blogyazımda,.Net RIA Servisleri hakkında edindiğim kısa ve özet teorik bilgileri sizinle paylaşmaya çalışmıştım. Bu yazımda ise, teoriği pratiğe dökmeye gayret edeceğim. Geliştireceğimiz örnek,.Net RIA Servisini kullanan bir Silverlight uygulaması olacak. Geliştirmeyi Visual Studio 2008 üzerinde, Silverlight 3.0 ortamını kullanarak gerçekleştireceğim. Bu nedenle aşağıdaki şekilde görüldüğü gibi, klasik bir silverlight projesi oluşturarak işe başlayabiliriz.

Son yıllarda bildiğiniz üzere Servis Tabanlı Uygulamalar (Service Oriented Applications) hayatımızda oldukça fazla yer kaplamaya başladı. Microsoft cephesinden olaya baktığımızda, en büyük sıçramanın Windows Communication Foundation ile.Net Framework 3.0’ da yaşandığını söyleyebiliriz. WCF’in getirdiği servis bazlı uygulama geliştirme yaklaşımı,.Net Framework 3.5 ile dahada zenginleşti. Eklenen Web programlama modeli (Web Programming Model) özellikleri sayesinde, REST (Representational State Transfer) bazlı servislerin geliştirilebilmesinin yolu açıldı. Sonrasında Workflow Foundation ile iç içe geçen WCF özellikleri sayesinde, iş akışlarının farklı domainler ile haberleşebilmesi veya servis gibi sunulabilmesi olanaklı hale geldi. Derken.Net Framework 3.5 Service Pack 1 ile hayatımıza başka bir kavram daha girdi. Ado.Net Data Services.

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. Nedir bu WCF REST Starter Kit? Bizlere ne gibi avantajlar getirmektedir?