SOA, Service Oriented Architecture, yani Hizmet Tabanlı Mimari. Yazılım
geliştirme sürecinde ilk başlarda analiz yaparken ortaya çıkan "iş
senaryolarının" ayrı birimler olarak ele alınması ve kendi başına var olabilecek
hizmetler olarak tasarlanması olarak yorumlayabiliriz. Her hizmet kendi başına
bir iş halleder. Nesne Yönelimli Analiz metodu olarak ne kullanırsanız kullanın
(Shlaer-Mellor, Hatley-Pirbhai, UML vesaire.) sonuçta elinizde bir kaç katmana
yayılmış hizmetler olacaktır. Veritabanından, grafik arabirime (sunum katmanı)
kadar uzanan bu katmanlar birbirleri arasında veri alışverişi yaparak istenilen
operasyonu başarmaya çalışır. SOA mimarisi ile tasarlanmış bir uygulamada bakım
ve onarım işleri daha ucuza mal olur diyebiliriz. Arayüzlere dokunmadıkça ve
giriş çıkış veri formatını değiştirmedikçe içeride her türlü değişikliği
yapabiliriz. Ayrıca SOA ile tekrar kullanımı arttırıyoruz ki bu da tekrar eden
işlemler için aynı programın tekrar tekrar yazılmasını ortadan kaldırıyor.
İyi bir SOA tasarımının kalitesi ilk etapta yapılan analizin kalitesine
bağlıdır. Benim değinmek istediğim konu bir Analyst Developer’ın gerekli
araçları temin ederek bu analiz aşamasından yüzünün akı ile çıkmasıdır.
Kalitenin anlaşılabilmesi için bazı ölçülere de burada değineceğim.
1- Metodu belirleyin
Analiz aşamasında takip edeceğiniz metod size analizin yapılması için gerekli
izlenecek yolu verir. Bu metoda uyduğunuz sürece hata yapma yada bazı adımları
atlama olasılığınız en aza inmiş olacaktır. Metodu kendi isteğinize göre de
değiştirebilirsiniz fakat yapılan değişikliklerin verimliliği nasıl etkilediği
test edilmeli ve metoda kattığı artılar gözler önüne serilmelidir. Belli bir
metod ile analiz yapmak ilk etapta yorucu gelebilir (daha önce gelişi güzel
analiz yapanlar için), doldurulması gereken formlar ve yazılması gereken
belgeler yük olabilir ama yarın bir şeylere ihtiyacınız olduğunda cevaplar bu
belgelerde ve formlarda saklı olacaktır ayrıca ortaya çıkacak üründe müşteri
gereksinimlerini tam olarak karşılayacak bir ürün olacaktır.
2- Seçtiğiniz metoda uygun bir modelleme aracı kullanın.
Örneğin Hatley-Pirbhai ile analiz yapmaya karar verdiniz. Elinizdeki uygulamanın
Data Flow (Veri Akışı) şemalarını çizebiliyor olması gerekir. Çizilen şemaların
ekip tarafından paylaşılabilmesi ve yorumların online olarak girilebilmesi
gerekir. Böylece ekipten gelecek yorumlar hızlı bir şekilde modellere
yansıtılabilinir. Modellerin sürekli el altında olması gerekir.
3- Karmaşık operasyonları bölün
Normalize her aşamada uygulanabilecek bir yöntem. Karmaşık operasyonlar atomize
parçalara ayrılarak kodlama süresi kısaltılabilir. Ayrıca hata ayıklama da ve
testlerde problemlerin kaynağının doğru olarak bulunmasını kolaylaştırır.
Servisleri mümkün olduğunca bölün ve en ufak atomik parçaya varıncaya kadar
katmanlar oluşturmaktan korkmayın. Emin değilseniz diğer ekip elemanları ile
tartışarak en iyi çözüme ulaşmaya çalışın.
4- Hazır modülleri araştırın
Eğer firmanın yapısı ve müşterinin istekleri izin veriyorsa açık kaynak
projelerden yararlanmaya çalışın. Açık kaynak projelerin lisans anlaşmalarını
iyi inceleyin ve açık kaynak kullanacağınız projelerin sahiplerini bu konuda
haberdar edin. Projelerin tamamını olmasada bazı parçalarını kullanabilirsiniz.
5- Veritabanı ve grafik arayüz değişebilir
Yaptığınız tasarımın hedeflerinden biri de zaman içinde veritabanının ve grafik
arayüzün değişimlerinden etkilenmemesidir. Tasarım tamamı ile modüler olmalı ve
sadece iş kurallarını uyguladığınız katman sizin için önemli olmalıdır.
Veritabanı ve Grafik arayüz tümden çöpe atılıp yeniden geliştirilebilmeli ve iş
kurallarını uygulayan katmana kolayca eklenebilmelidir. İşte hizmet tabanlı
mimarilerin önemi burada ortaya çıkıyor.
Bir işi analiz ederken veritabanı tablolarını ve grafik arayüzü düşünüyorsanız,
büyük ihtimalle ortaya çıkacak dizayn da veritabanına ve grafik arayüze sıkı
sıkıya bağlı olacaktır. Unutmayın yarın öbürgün teknoloji ilerler ve
veritabanları ile grafik arabirimleri değişebilir (oldu bile, işte Vista ile
Avalon geliyor). Bu aşamada programınızın tamamını mı yazmak daha kolay olur
yoksa sadece veritabanı ile grafik arayüzünü mü değiştirmek kolay olur?
Teknoloji ne kadar ilerlese de işin işleyiş kuralları değişmemiştir. İş gene
olduğu gibi gider. Tabii ki özel sektör işleri, devlet birimlerine göre biraz
daha statik yapıdadır. Eğer özel sektöre program yazıyorsanız (örneğin bir hava
yoluna bilet satış işlerini koordine edecek bir program yazıyorsunuz) iş
kuralların değişmesi nadirdir. Fakat devlet birimlerine yazılan programlarda ki
iş kuralları genelde değişime uğrar. Yasa değişiklikleri, yeni yasaların
gelmesi, bürokrasi ve işleyiş değişiklikleri iş kurallarının değişmesine neden
olur. Buda hizmet katmanınızdaki hizmetlerin değişmesi demek olacaktır. Bu durum
da SOA mimarisi pek elverişli olmaz. O zaman iş kurallarının parametre haline
getirilmesi ve hizmetlerin bu parametreler ile güdümlü olarak çalışması gerekir.
Neyse konuyu dallandırmayalım, devlete program yazmak işlerin temelinden
başlanmasını gerektirir ve analizlerin çok uzun sürmesi de bundandır. Bu
paragrafı toparlarsak; bir işi modellerken sadece işin verdiği tepkileri ve
girdi çıktıları modelleyin. Veritabanı ve grafik arayüz en son gelmelidir.
Analist Yazılım Uzmanının yapması gereken hem işi bu şekilde modellemek hemde
modellere uygun sistemi oluşturmaktır.
SOA mimarilerinde koddan müşteri gereksinimlerine yani geriye doğru takip çok
kolaydır. Bu tür bir özellik testlerin yazılmasını da kolaylaştırır ve kaliteyi
arttırır. Her servis belli bir işi yapar ve belli iş kurallarını uygular. Her
servisin bir belgesi vardır. Belgenin formatı az çok İş Senaryoları belgesine
benzer fakat biraz daha teknik bir belgedir. Belgede bulunması gerekenleri
aşağıda listeledim. Her belgede olması gereken, içindekiler, değişiklik
yönetimi, onay ekibi ve dağıtım listesini geçiyorum.
Servis Dizayn
Alt başlık: Servisin ismi
Bu alt başlıkta kısaca servisin ne yaptığını yazmak gerekir.
Alt Başlık: Tip
Servislerde kendi aralarında katmanlara ayrılabilir. Eğer bir DFD şeması varsa
katmanları görmek kolaylaşır, yada iş ve sistem senaryoları olarak ikiye
ayrılmış senaryoları gerçekleyen servisler tiplerine göre isimlendirilebilir.
İş Kuralları
Bu servisde uygulanan iş kurallarının bir listesi yada iş kurallarının bulunduğu
dökümana link verilebilir.
Servisin Girdileri
Burada servisin işleyeceği verinin yapısı anlatılır. Ne tür bir girdi olacak
tablo halinde yazılmalıdır. Eğer veritabanı şekillenmeye başladı ise verinin
tipide belirmeye başlamıştır.
Servisin Çıktıları
Servisten beklenen verinin yapısıda burada yazılır.
Varsayımlar
Eğer servisin çalışması için gerekli varsayımlar varsa burada listelenir.
Önceden var olması gereken koşullar yada çalışmış olması gereken servisler
burada listelenir.
Oluşabilecek Hatalar
Servisin oluşturacağı hataların listesi (exception yada bir hata listesi
olabilir) burada listelenir. İleride servisi kullanacak olan programcı (yada
bizzat siz) servisin geriye döndüreceği hataları kontrol etmekle hükümlüdür.
Çağırılan Diğer Servisler
Bu servisden çağırılan diğer servisler burada listelenir ve Servis İçerik
belgelerine link verilir. Tabii her çağırılan servisin bir de geriye döndürdüğü
hata durumları var ve bunların kontrol edilmesi gerekiyor. Eğer bu servisden 100
adet servis çağırıldıysa kontrol edilecek hata listesi bini geçecektir. Bu
durumda oluşan hataların yönetimi için bir sistem oluşturulup her servis de
uygulanmalıdır. Hazır hata kontrol modülleri mevcuttur, yada açık kaynak bu tür
projeler de var.
Akış Şeması
Firma genelinde kullanılan metoda göre burada bir şema yer almalı ve servisin
yaptığı işi anlatmalıdır. Servisi kodlarken kullanılacak en önemli kısımlardan
biridir. Bu bölümü yazarken kesinlikle programlama dilinden uzak durmanız gerek,
aksi takdirde yanlış yorumlamalara yada iş akışında oluşacak farklı durumlara
sebebiyet verilmiş olunur. Eğer yukarıda belirttiğim gibi modelleri oluşturmak
için bir araç kullanıyorsanız ve modeller iç-örütbağı üzerinden erişilebilir
ise, bu servisin ilişkili olduğu modele bir link te verebilirsiniz. Bakımı daha
kolay olur.
Test Senaryoları
Yukarıda bu servisin geriye döndüreceği hata durumlarını yazdınız, şimdide bu
hata durumlarını meydana getirecek durumları listelemeniz gerekiyor. Servis
kodlanıp test aşamasına geldiği zaman bu test senaryolarında bulunan senaryolar
kullanılacaktır. Eğer TDD (Test Driven Development – Test Güdümlü Yazılım
Geliştirme (felaket bir çevirim oldu :-)) ) yapıyorsanız kodlamaya bu test
modelinden başlayacaksanız demektir. Testler için kullanılacak veriyide tablolar
halinde yazın.
Kullanıldığı Yerler
İlerleyen zamanlarda bu servisin çağırıldığı servisler buraya kaydedilir. Yada
link verilebilir. Söz konusu servis değişikliğe uğradığında buradaki listede
bulunan servisler de bu değişiklikten haberdar edilmelidir. Böylece
değişikliklerden kimler etkilenecek sorusunun yanıtını anında alabilirsiniz
başımızdaki saçlar da yerinde daha uzun durur.
Görüldüğü gibi bazı kurallara uyarak yazılım geliştirmek gerçekten de hatırı
sayılır bir kaliteye ulaşmamızı sağlıyor. Ortaya çıkan belgelerin ve modellerin
yönetimi, erişimi, kontrolü ve değişimi ne kadar kolay ve sorunsuz ise yapılan
işin kaliteside o kadar artıyor.
Kaliteli günler dilerim.
