Merhaba Arkadaşlar,

Yazılım dünyasının zor anlaşılan kavramlarından birisi de çeşitli mimari modellemeleridir. SOA(Service Oriented Architecture) en popüler yazılım mimarilerinden birisi olmakla beraber, anlaşılması ve uygulanması en zor olanlarındandır. Gelin SOA' yı dilimiz döndüğünce anlamaya ve en önemlisi hangi ihtiyacı/ihtiyaçları çözdüğünü bulmaya çalışalım. İlk olarak basit ve genel bir tanımlama ile işe başlamakta fayda var.

Bu arada Makale ile ilişkili SOA Gerçekleri sunumuna Slideshare üzerinden erişebilirsiniz.

İlk Tanımlama

SOA servis olarak adlandırılan, gevşek bağlı(Loosely Coupled), iri taneli(Coarse Grained-her ne demekse) ve özerk(Autonoums) yapıdaki bileşenlere dayalı dağıtık sistemlerin geliştirilmesi için kullanılan mimari bir stildir. (Zaten SOA' nın Architecture kelimesi bunun bir mimari yaklaşım olmasından dolayıdır)

Temel Bileşenler

SOA' nın yukarıda yapılan tanımına benzer daha pek çok ifade vardır. Genel hatları ile bu yeterli gibi görünebilir ancak SOA' yı kavramak için aslında temel bileşenlerini de bilmek gerekir. Pratikte SOA' nın aşağıdaki çizelgede görüldüğü gibi altı adet bileşeni vardır.

Söz konusu bileşenler birbirleriyle yakın ilişki içerisindedir. Aşağıdaki diagrama bakarak bu ilişkileri görmeye çalışalım.

Her bir servis(Service) sözleşmeler(Contracts) yoluyla iş süreçleri ve bunlara bağlı davranışlar sunar ki bu sözleşmeler keşfedilebilir EndPoint' ler üzerinden taşınabilecek mesajları(Messages) tanımlarlar. Bir servisin davranışı(Behavior), endüstriyel anlamda standartlaşmış çeşitli ilkeler(Policies) ile uyumlu olmak zorundadır. Servisleri tüketen taraflar(Service Consumers) ise, sözleşmeler ve mesajlar yoluyla tanımlanmış iş fonksiyonelliklerine(Business Functions) ulaşmaktadır.

SOA Neyi Çözer?

Öncelike SOA' nın dağıtık yazılım sistemlerinin kalitesini arttırma noktasında pek çok mimari kritere sahip olduğunu söylememiz gerekir. Yeniden kullanılabilirlik(Reusability), Uyumluluk(Adaptability) ve Bakım Yeteneği(Maintainability) bunlardan bir kaçıdır. Ancak en önemlisi SOA' nın özellikle Point-To-Point entegrasyon yapan sistemlerdeki bağımlılıkları ortadan kaldıracak çözümleri içermesidir.

Pek çok büyük sistem zamanla iş birimden gelen istekler doğrultusunda büyür ve genişler. Bir süre sonra bu sistemler arasında veri paylaşımı yapılması gerekebilir. Bu, çok doğal olarak iş sahibi birimlerin ihtiyaçlarından doğar. Dolayısıyla sistemler arası veri paylaşımı üzerine çeşitli entegrasyonlar gerekir. Eğer Point-to-Point gibi yaklaşımlar benimsenirse, sistemler arası entegrasyon giderek karmaşıklaşır. Tekrar edilen fonksiyonellikler/modüller çoğalır. Bakım ve dağıtım gibi operasyonlar giderek zorlaşır. Sistemin yeni nesil gelişimi de olumsuz yönde etkilenir.

Stovepipe olarak adlandırılan bu sistemlerde olayın çıkış noktası aslında az çok bellidir. Her departman kendi sistemini inşa ederken, bu sistemleri kullananların bazı ihtiyaçlarının diğer sistemlerde olabileceğini önceden kestirmez/düşünmez. Çözüm için Point-to-Point entegrasyonlar yapılmaya başlanır. Bu yaklaşıma iten pek çok sebep vardır. Planlama yetersizliği, doğru bir süreç sisteminin seçilmemiş olması vb...

Stovepipe System : Tek bir authentication fonksiyonelliğinin kurumun tüm sistemlerinde ortak kullanımı yerine, birbirleri ile iletişimde olma ihtimali bulunan bu sistemlerin kendi authentication fonksiyonelliklerine sahip olması olarak örneklenebilir. Stovepipe sistemler aynı zamanda bir anti-pattern olarak değerlendirilir.

Point-To-Point denildiğinde aşağıdaki çizelgede görülen teknikler sıralanabilir.

İyi tasarlanmış bir SOA, Point-to-Point yaklaşımlar yerine çeşitli tipte tüketicilerce kullanılabilecek, daha genel çerçevede düşünülmüş arayüzler(Interfaces) sunar.

Buna göre SOA' nın makarna haline gelmiş Stovepipe tadındaki sistemlerdekinin aksine daha disipline edilmiş bir iletişim mekanizması sunduğunu ifade edebiliriz.

SOA, endüstriyel anlamda standartlaştırılmış sözleşmeleri temel aldığından, sistemleri platform bağımsız ele alabilir/düşünebilir. Yani farklı platformlar, uygulamalar ve servisler için daha saydam bir iletişim mümkündür.

Güvenlik(Security) ve bakım(Maintaining) gibi bazı farklı bakış açıları, SOA için konfigure edilebilir kavramlardır. Bu esneklik ilke tabanlı(Policy Based) olmaktan kaynaklanır ve bakım ile adapte edilebilirliği en üst seviyede kolaylaştırır. Bunun doğal sonucu olarak bir takım sorumlulukların geliştirme takımlarından sistem operasyon gibi IT taraflarına alınması da mümkün hale gelmektedir. Bu, organizasyonel anlamda sorumlulukların dağıtımı olarak düşünülebilir.

Aslında tüm bu yazılanları bir kenara bırakırsak temel sorun şudur : IT'nin değişen iş süreçlerine kolay bir şekilde adapte olamayışı ve bunun sonucu olarak işin çevik anlamda ilerleyemeyişidir. SOA, IT ile iş birimi arasındaki boy farkını eşitlemek için bir yol sunar. Aynen aşağıdaki şekilde görüldüğü gibi...

İş Birimi İçin Nasıl Faydaları Olabilir?

SOA' nın elbette IT alt yapısındaki yazılımsal vizyonu dışında bir de iş birimine sağladığı faydalar söz konusudur. Bu faydalar aşağıdaki çizelgedeki gibi ifade edilebilir.

Mimarın Yükü

SOA, sistemlerin tekonoloji bağımsız bir şekilde inşa edilmesine odaklanır. Bu yüzden WCF Service denmez bunun yerine örneğin SOAP-Based Services denir ya da JAX-RS service denmez, REST Based Services denir. SOA' yı uygulayacak olan mimarın önemli görevlerinden birisi de, mimarinin parçalarını belirli teknolojilere doğru yönlendirmektir. Mimarın elinde ona yardımcı olacak bir takım girdiler de vardır. Aşağıdaki şekile bir bakalım.

Mimar teknolojiyi kullanır. Ancak teknik toplulukların veya standart koyucuların belirlediği bir takım prensip ve desenleri de baz alır. Bu noktada bir takım anti-pattern' lerin oluşumu da söz konusudur. Diğer yandan organizasyonel açıdan bakıldığında işin içerisine dahil olan paydaşlar da vardır. Bu paydaşlar pek tabi çeşitli kalite kriterlerini işin içerisine dahil eder ve bazı kıstasları(Constraints) belirlerler. Mimar tüm bu girdileri harmanlayarak mimariyi üretmeye çalışır.

Desenler

SOA' ya dayalı bir sistemi veya sistemler bütününü inşa etmek kolay değildir. Problemlerden birisi de güvenlik(Security), ölçeklenebilirlik(Scalability), performans(Performance), kullanılabilirlik(Availability) gibi kalite unsurlarını adreslemenin zor olmasıdır. Bunlara ek olarak SOA'nın tasarlanması ve inşa edilmesi de ayrı bir derttir. Örneğin uygulama arayüzleri(User Interfaces) servislere nasıl bağlanacaktır? Mimari içindeki iş verileri nasıl gizlenecek veya dış ortamdan soyutlanacaktır? Peki bu söz konusu iş verileri nasıl merkezileşecektir? Bunlar gibi pek çok sorunun cevaplanması zordur. İşte SOA desenleri de tam bu noktada devereye girmekte ve ilgili soruların cevaplanmasında kullanılmaktadır. Desenler(Patterns) problemi ortaya koyar ve bir çözüm yolu(Solution) önerir. Aynı zamanda bu çözüm yolları uygulanırken dikkat edilmesi gereken noktaları da belirler.

Desenleri Görebilmek

Aslında SOA' nın desenleri genel hatları ile aşağıdaki görsel de olduğu gibi özetlenebilir.

Bu şekli aslında bir akıl haritası olarak da ifade edebiliriz. Arnon Rotem' in SOA Patterns isimli kitabında buna benzer bir çizime yer verilmektedir. Ben desenlerin kolay ayırt edilebilmesi adına ayrıldıkları altı kategori için renklendirdim. Bu şekle bakarak aslında SOA' nın desenleri arasındaki ilişkileri de görmemiz mümkündür.

Örneğin Service Host deseni, Service örneklerini host eden bir çözüm sunarken doğal olarak Service Instance deseni ile ilişkilidir. Eğer servisler arası mesajlaşmaların nasıl olması gerektiğine dair bilgi lazımsa kahverengi renkteki Message Exchange kutucuklarına bakılması yeterlidir. Bu kutucuklara bakarak diğer ana kategoriler ile olan ilişkileri görmek de kolaylaşır. Çizimdeki tüm ilişkilere bakıldığında SOA' nın Big Picture olarak tabir edebileceğimiz görüntüsünü elde edebildiğimizi özetleyebiliriz.

Desen Kartları

SOA içerisinde oldukça fazla sayıda desen var. Bunların hepsini okumak bir yana, idrak edebilmek ve hayata geçirebilmek de çok kolay değil. Bu yüzden size tavsiyem, ilgili desenleri öğrenirken özet kartlar(post-it kıvamında) kullanmanız. Örneğin aşağıda SOA' nın en temel desenlerinden birisi olan Service Host Pattern' e ait bir takım bilgiler yer alıyor. Herşey SOA dünyasına gönderilen bir soru ile başlıyor. Daha sonra bu sorunun cevabı yazılıyor. Cevabı takiben kısa bir tanım, ilgili desenin genel bileşenlerini gösteren küçük bir çizim, teknolojik eşlenikleri(yani örneğin hangi ürünlerde görebiliriz sorusunun cevabı) ve kalite kriterleri yer almakta.

Kaynaklar