Bu aralar bu konuda bayağı meraklıyım özellikle WCF konusuna Imagine Cup zamanında yüzeysel olarak girmek zorunda kalmıştım. Ama yaz olup da boş kaldıktan sonra artık bu konuyu halledeyim dedim. Umarım bu konuyu öğrenmek çok zaman almaz.

Bu saçma giriş bölümümden sonra sorumu soruyorum: nedir dağıtık sistemler?

Aslında bunun için internette bir sürü teknik açıklama dolu. Ben teknik tanımlamalarla çok kafa karıştırmak istemiyorum ama isteyen olursa da yardımcı olurum. En basit şekliyle bir dağıtık sistem bilgisayarlar arası bir ağdır, ama öyle bir ağdır ki bu ağ üzerinde bilgisayarlar kaynaklarını (işlemci, hafıza vb…) paylaşabilirler. Yani kocaman bir bilgisayar düşünün bir kısmı bir odada diğer kısmı başka odada diğer bir kısmı da komşunuzda…

Ya da başka bir bakış açısıyla ortada yapılması gereken bir sürü iş var ve bunlar çeşitli bilgisayarlar tarafından yerine getirilip sonuç veri, ihtiyacı olan kısma gönderiliyor.

Böylelikle; uzaydaki olayları inceleme gibi devasa işlem gücüne ihtiyaç duyacak olan işler kullanıcılar arasında bir program vasıtasıyla paylaştırılıyor ve milyonlarca dolar tutacak süperbilgisayarların işi ucuz ve çok sayıdaki kişisel bilgisayar tarafından yapılıyor.

(bu gerçekte olan bir uygulama ama tembellik ettiğimve linki hatırlamadığım için linkini koyamıyorum)

Tabi bu olay yapılırken verilerin nasıl aktarıldığı gibi problemler olsa da bunlara değineceğim.

Sonuç olarak dağıtık sistemler tam gaz gitmekte ve Microsoft ve Sun gibi dev firmalar da geliştirdikleri apilerle bunu desteklemekte. Bu nedenle bu konuyu anlamakta fayda görüyorum.

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)

Bu yazımda biraz üç katmanlı mimariden bahsetmek istiyorum. Tabi ki katman sayısını üçle sınırlamak doğru değil ama başlangıç için bence en ideali üç katman.

Yazılımı Neden Katmanlara Ayırıyoruz?

Aslında cevap herkesin aklına geldiği gibi yönetimi ve bakımı kolaylaştırmak. Şimdi aklınıza bir yazılım getirin bu yazılım veritabanına bağlı olsun. Bu yazılımın tüm kodu bir iki sınıfa sığdırılmış olsun, ve bir zaman sonra yazılımın veritabanına bağlantısında bir hata olduğu ortaya çıksın. Böyle bir durumda tüm kod açılacak içinden zorlukla veritabanı ile ilgili kod bulunacak, gerekli yer düzeltilecek tüm proje baştan derlenecek. Ve tam bu anda yanlışlıkla arayüzü sağlayan kodun bir kısmını sildiğinizi farkediyorsunuz. Onca kod arasından uğraşıp sildiğiniz kodun ne işe yaradığını bulacaksınız tekrar yazıp tekrar derleyeceksiniz. Bu hem size hem de işini yaptığınız kişiye zamana mal olacak.

Peki bundan nasıl kurtulacaksınız?

Cevap şu en başta yazılımı tasarlarken her işi ayırmalı ve mümküm olan en küçük ve en özel sınıfları amaçlamalısınız. İşte bu durumda da çeşitli iş öbekleriyle karşılaşacaksınız. Bazı sınıflar veritabanı ile iletişim kurarken bazıları iletişim kurmuş bu sınıflardan gelen verileri işleyecek ve bunları arayüze yani görünen kısma taşıyacak. İşte tam burada katmanlı mimari devreye giriyor, yapılan işe göre sınıflar kategorize ediliyor. Konumuz olan üç katmanlı mimaride adından da anlaşılacağı üzere 3 katman vardır. Bunlar:

. Veri Katmanı

. İş Katmanı

. Arayüz (Sunum) Katmanı

Veri katmanı:

Veri katmanı adı üstünde veri ile ilgilenir başka hiçbir şey yapmaz. Database ve Stored Procedure ler bu katmandadır.

Önemli nokta: bu katmanda asla verilerle işlem yapılmaz.

İş Katmanı:

Veri katmanından alınan veriler buradaki sınıflarca işlenmelidir. Burda her türlü işlem yapılır. Hesaplamalar, verilerin değişimi vb… Ve ancak bu katmanın işi bitince veriler veritabanına aktarılmak üzere veri katmanına ya da gösterilmek üzere arayüz’e yollanır.

Bu katmanda herhangi bir veri depolanmamalı, arayüze sonuç bastıracak kodlar bulunmamalıdır. Sadece veriyi almalı, işlemeli sonucu geri dönüş değeri olarak döndürmelidir.

Arayüz (Sunum) Katmanı:

Verilerimiz İş katmanında işlendi, ve ekrana sonuçların bastırılması gerekiyor. İş katmanından gelen verileri bu katmandaki sınıflar aracılığıyla alıp ekrana bastırıyoruz veya ilgili başka bir programa aktarıyoruz. Yani bu katman sadece programın üreteceği son değerin şekillerdirilmesi(anlaşılır hale getirilmesi) ve gösterilmesi işinden sorumlu.

Bu katmanda da hiçbir veri işleme işi yapılmamalı sadece iş katmanından gelen veriler biçimlendirilerek sunulmalıdır.  

Üç katmanlı mimari işte bu kadar asıl iş projeyi üç katmanlı hale gelebilecek şekilde moduler olarak tasarlayabilmekte. Bu sağlandığı takdirde Sadece veri tabanımızda sorun varsa veri katmanındaki ilgili sınıfa gidebilir değişikliği yaparız ve programın geri kalanı bu değişimden hiç etkilenmez. Bu şekilde tasarım aynı zamanda takım çalışmasına atılan ilk adımdır. Her programcı başka katmanlarla uğraşabilir, örneğin ben iş katmanını yazarım, kod yazmaktan anlamayan bir sanatçı da arayüzü tasarlar. Gelecek verilerin şekli belli olduğu için, bunu yaparken zorluk da çekmeyecektir.

Hepimizin zaman zaman harika fikirleri  oluyor ama iş bunları koda dökmeye gelince bazı noktalarda tıkanıyoruz nasıl sınıflar olmalı ne nerden hangi veriyi almalı vb…  Peki bu sorunu nasıl aşabiliriz?

Imagine Cup ile başlayan tasarım serüvenimde birkaç noktanın önemini farkettim, bunlar;

. Projeyi hayal etmek

. Bu hayalin aşamalarını Kağıda dökmek (kağıt gerçekten projenin olmassa olmazı)

. Sonra bu aşamaları kendi aralarında ufak parçalara bölmek( mümkün olan en küçük sınıflara ayrılmalı ki modulerlik ve bağımsızlık sağlanabilsin)

. Ve mümkün olduğunca Interface(arayüz) ve Inheritance(türetme) kullanın.

. Bu ufak parçaları ve parçaların birbirlerine olan ilgilerini kağıt üzerinde küçük temsili şekillerle ve oklarla göstermek

. Eğer biliyorsanız UML’den yararlanıp bilmiyorsanız hayal gücünüzle bu parçaları sınıf haline dönüştürmek (hala kağıt üzerinde).

. Sınıf haline dönüştürürken içerebileceği değişkenleri ve metotları (sadece yaptıkları işi kısaca örneğin topla() gibi anlamlı bir isimle) belirtmek

. Sınıfların nasıl haberleşeceğini düşünmek. Burada mutlaka son teknolojileri uygulayabileceğiniz bir yazıım yaratmaya çalışın.

. Bu aşamada karşımıza bir proje şablonu çıkmış olmalı; bu şablonu iyişleştirmek için üzerine kafa yormak (örneğin kod tekrarını yoketmek, gerekirse tasarım şablonlarından faydalanmak)

.  Şu ana kadar hiç kusurunuz yoksa o kusuru bulmak, çünkü mutlaka değişmesi gereken bir yer vardır

. yavaş yavaş koda dökmye başlamak, bazı yerlerin daha kolay yapılabileceğini keşfetmek ve mümkün olan en küçük sınıfları kullanmış olduğunuz için şükretmek.( çünkü değişikliği sadece bir sınıfta yaptık, diğer sınıflarımız güvende)

Bir yandan da;

. O an aklınıza gelen yapmayı düşündüğünüz her şeyi not alın aklınız defter değil bunu unutmayın.

. Kodu yazarken sürekli yorum satırları kullanın ki tekrar döndüğünüzde algoritmanızın ne yaptığını anlayabilesiniz.

. Çizimleri mümkün olduğunca Kurşunkalem kullanarak yapın ki sildiğinizde ki kesinlikle düzeltmeniz gereken yerler olacak; iz kalmasın.

. Ara sıra çıkıp temiz hava alın, aklınızı boşaltın, hiç olmadık anlarda aklınıza muhteşem fikirlerin geldiğini göreceksiniz, ve neden daha önce düşünemedim diye hayıflanacaksınız.

Anlayacağınız üzere iş projeyi tasarlamakta bitiyor, kod nasıl olsa yazılır.