Son zamanlarda dünyada ve özellikle IBM’in konferansından sonra Türkiye’de de hızla önem kazanan bir konu SOA (service oriented architecture).  Peki SOA nedir?

Herşeyden önce SOA’nın değişik bir yaklaşım olduğunu kabul etmemiz gerekiyor. Burda değişikten kasıt Fonksiyonel programlamadan da, Nesne Yönelimli (OOP) programlamadan da farklı olması. Klasik nesne yönelimli yaklaşımda herşeyi bir nesne olarak görüp nesnelerin birbirleri arasındaki iletişimi modelleyerek programlarımızı oluşturuyoruz. SOA da ise adından da belli olduğu üzere işin odağında servisler var.

Servisleri, basitçe yerine getirilmesi gereken işleri yapan, işverenden bağımsız işçiler olarak düşünebiliriz.

Zaten pek çoğumuz farkında olarak ya da olmadan Web Servisleri aracılığıyla ucundan da olsa bu yaklaşımı kullandık. Bildiğiniz üzere web servisleri yayınladıkları servislere gelen uygun istekleri değerlendirip uygun sonucu geri çeviriyorlar, bunu yaparken de istemcinin aynı projenin bir parçası olup olmadığını önemsemiyorlar. Zaten amaç da işinde uzman servisler yaratıp bu çözüme talip olacak uygulamala hizmet verebilmek.  En güzel yanı da servsin nasıl kodlandığı hakkında bir şey bilmenizin gerekmemesi. Sadece verileri uygun formatta yolluyorsunuz gerisini servis halediyor.  

“Verileri uygun formatta yollamak”demişken farkettiğiniz üzere SOA da öne çıkan bir diğer önemli konu ise haberleşmenin şekli, öyle rastgele servis odaklı sistemler kuramıyoruz. İşte burda belitmeliyim ki SOA nın kendisi zaten bir soyut framework, kendi kuralları kendi yöntemleri olan bir yaklaşım ve bunun sayesinde Platformalar arası bağımsızlık sağlanıyor, bu da maliyetten tasarruf ve müşteri portföyünde artış olarak yansıyor.

SOA’nın gerektirdiklerine bakacak olursak SOA:

            .Referans modeline uygun servisler içermeli,

            .Kullanıcı ve Servisler arasında görünürlüğü sağlamalı

            .Servisler ve kullanıcı arası etkileşime nasıl aracılık edeceğini bilmeli

            .Servislerin nasıl kullanışacağını anlatmalı

.Servisin yaptığı iş hakkında bilgi vermeli

            .Yeniden kullanılabilir olmalı

            .Modüler olmalı

            .Mümkün olan en küçük parçalardan oluşmalı

.Poliçelerin nasıl ele alındığı hakkında bilgi vermelidir.

Servislere bakacak olursak etkileşim esnasındaki özelliklerini ve genel özelliklerini ayırmanın iyi olacağı kanısındayım;

Servislerin Etkileşim esnasındaki özellikleri ;

1) Görünürlük:  Adından da anlaşılacağı gibi görünürlük kullanıcı ile hizmet verenin birbirlerini görebilmesidir. Tabi bunun da bazı koşulları vardır.

            a) Farkındalık: Kullanıcı ile hizmet birbirlerinin farkında olmalıdır.

            b) İsteklilik: Özellikle servis sağlayıcının bu alışverişe istekli olmasıdır.

            c) Erişilebilirlik: Servisin başvurulduğu anda erişilebiliyor olması demektir

                        (Doğru adreste olması, izinlerinin uygun olması …)

2) Etkileşim: Servislerle etkileşime girilebilmesidir. Bu genellikle gönderilen mesajlar aracılığıyla olur. Tabi bu mesajlar da bazı kurallara bağlıdır.

            a) Bilgi Modeli: Servise gönderilecek bilginin şekillendirilmesidir.

                        . Yapı: Verinin yapısıdır, kullanıcı için açıklamalar bulundurmalıdır.

                        . Anlam: Gönderilen veri ilgili herkes tarafından anlaşılabilir olmalıdır.

b) Davranış Modeli: Servisin talepten sonra nasıl davranacağının ve geri dönüşünün bilinmesidir.

c)Hareket Modeli: Servisin işlem sırasında hangi yöntemleri kullandığının bilinmesidir

3) Gerçek Hayata Etkisi: Kullanıcı uygulamanın sahibinin hizmet verenden beklentisi vardır ve bu hizmetin sonucunda hedeflenen amaca ulaşılıp ulaşılmadığı önemlidir.

Servislerin genel özellikleri:

1)      İyi tanımlanmış ve anlatılmış olmalı

2)      Erişilebilir ve fonksiyonel olmalı

3)      Poliçeler ve Kontratlar içermeli

4)      Gevşek bağlı olmalı (loose binding)

Servis odaklı mimariyi kullanmak illaki sıfırdan SOA özelliklerini sağlayan bir yazılım üretmek gerekmiyor, zaten bunca yardımcı API varken eğer gerçekten lazım değilse sıfırdan üretim zaman kaybı olurdu.  WCF işte tam burada devreye giriyor. COM+, .Net Remoting gibi Dağıtık sistem geliştirme araçlarını da içeren bir toplama API gibi düşünebiliriz WCF’yi. Ama sadece bu tanımı yapmak da WCF ye haksızlık olur. Asıl amacı Hızlı bir bişimde SOA yazılımları geliştirebilmek ve hakkaten bunu becerebiliyor. En azından benim görüşüm bu, kendi öğrenci başıma geliştirdiğim bazı ufak tefek yazılımlarda yıldırım hızı kazandırdığı bir gerçek. (Kısmet Firmalarda Çalışmakta ahh ahh). ( bu arada bir parantez notu WCF’yi anlattığım bir arkadaş bana sadece windows makinaların yararlanacağı bir servisi ben ne yapayım demişti ama WCF diğer platformlardaki makinalara servis verebilecek yazılımlar geliştirmemize olanak sunuyor, ama o bunu anlamamakta ısrarcı )

WCF ile yapılan servislerin çalışma prensibi için temel olarak bilmemiz gereken şeyler şunlar:

            . Aynı ya da farklı bilgisayarlardaki farklı uygulama alanlarıyla etkileşim sağlanabilir.

            . Servis - Kullanıcı etkileşimi esnasında bir proxy nesnesi kullanılır

            . Servise giriş ve Servisten çıkışlarda bir endpoint nesnesi bulunur.

Birinci madde aslında dağıtık sistemin özü, çünkü bilgisayarlararası bir etkileşim söz konusu.

Proxy nesnesi ise servise gelen istekleri endPoint’e yollar ya da endPointten gelen verileri İstemciye ulaştırır.

endPoint nesnesi aslında servise ulaşmak isteyen kullanıcılara bir arayüz, çıkan veriler için ise son şekillerndirme noktasıdır.

(EndPoint hakkında ayrıca bir yazı yazarak içeriğinden bahsedeceğim)

Başlangıç olarak WCF hakkında bir fikir vermek istedim, konuya diğer yazılarımda devam etmek istiyorum (öğrendikçe).