Service Oriented Architecture (SOA)

Müşterilere verilen hizmetlerin birer servis olarak düşünülmeye başlamasını ve SOA (Service Oriented Architecture) yaklaşımını birbirlerini tamamlayan, bir elmanın iki parçası gibi düşünebiliriz. Bu bir dönüşüm… Uygulama/sistem temelli bir yaklaşım yerine servis kavramı üzerine inşa edilen bu konseptin çok anlamlı bir gerekçesi de var aslında. Bu gerekçeyi basit anlamda ele alalım;

Müşteriler almış oldukları hizmetin hangi uygulamadan hangi sistemden sağlandığını ve bu hizmetin teknolojideki karşılığını tabiki bilmiyorlar. Ama biliyor oldukları en önemli veri, örneğin telekomünikasyon sektörü için ‘Telefon numarası yönlendirme hizmeti’ aldıkları ya da örneğin bankacılık sektörü için ‘Vadeli hesap oluşturma’ hizmeti aldıkları diyebiliriz. Sunulan çeşitli hizmetlerin teknolojik karşılığı olarak bu işi gerçekleştiren uygulamalar dünyasına şimdi tekrar dönelim. Müşterinin almış olduğu bu hizmetlerin her birinin karşısında bir IT/NW servisi bulunuyor. Bu servisler de farklı farklı uygulamalar, farklı farklı sistemler üzerine dağıtılmış halde bulunabiliyor. Yani müşteriye verilen bir hizmetin mutlaka tek bir uygulama üzerinden sunulması gibi bir zorlama yok. Hatta tam tersine günümüzde işler kompleks bir hal aldığı ve her hizmeti tek bir uygulama üzerinde toplamanın imkan dahilinde olmadığı bir noktaya geldiğimiz için bir servisi verebilmek amacıyla birden çok uygulama/sistem/servis senkron ya da asenkron bir şekilde iş yapmak durumunda kalıyor. Dolayısıyla en başa dönecek olursak, bugünün koşullarının ve iş gereksinimlerinin getirmiş olduğu doğal bir sonuçtur aslında SOA yaklaşımının oluşması. Madem müşteri servis temelli hizmet alıyor, aldığı hizmet kompleks ve iş ihtiyaçlarına göre değişiyor o halde bu hizmetin karşılığındaki teknolojik yapının da servis temelli bir yaklaşım üzerine temellenmesi daha sağlıklı olacaktır. Sonuç olarak bir tanım ortaya koymamız gekirse;

SOA, iş gereksinimlerini esnek bir şekilde karşılayabilmek amacıyla her birisi kendi işinde özelleşmiş, tanımları da net bir şekilde ortaya koyulmuş servislerin birbiri ile uyum içinde çalışmasını sağlayan bir orkestrasyondur.

Dilimiz döndüğünce bir tanım ortaya koyduğumuza göre artık bu tanımın içerdiği söyleme biraz daha yakından bakabiliriz;

İş gereksinimleri
SOA, günün birinde teknoloji ile ilgilenen birkaç mühendisin çay sohbetinde ‘Hadi bizim şu mimarimizi bir değiştirilim!’ düşüncesiyle ortaya çıkan bir konsept olarak düşünülmemelidir. Bu noktaya gelinmesini sağlayan yegane etmen yine iş gereksinimleridir. Yani bu düşünce “Yapılan işi nasıl daha düzenli, esnek ve yüksek çıktı alacak şekilde tasarlayabiliriz?” sorusuna cevap olarak doğmuştur.

Esnek
SOA, yinelenen yapıları pek sevmez. Bir servis, birden fazla servis tarafından kullanılabilir. Yani bir servis, yalnızca tek bir başka servis tarafından kullanılması amacıyla yazılmıyor. Süreçler de zaten bu felsefeye göre tasarlanırlar ki bir iş isteği sonucunda yapılacak değişiklik kolayca tüm servislerde aktif olabilisin. Dolayısıyla irili ufaklı birçok servisin varlığı, değişiklik yapılması ve süreçlerin güncellenmesi aşamasında esneklik sağlamaktadır. SOA, iş yapma, iş değiştirme becerisine hız kazandırmaktadır.

Net tanımlamalar
SOA içerisinde yer alan servislerin tanımlamaları net bir şekilde yapılmıştır. Servisin girdileri, çıktıları standart protokoller ile net bir şekilde belirlenmiştir. Standart tanımlamalar, servislerin farklı farklı platformlar (Linux, Unix, Windows, vb…), farklı farklı sistemler (Weblogic, Java, C#, IIS, vb…) tarafından kullanılmasını mümkün kılmaktadır ve mimari bütünlüğü korumaktadır.

Orkestrasyon
Birçok servisin birbiri ile bir harmoni içerisinde çalışması bir orkestranın her bir enstürümanının yerli yerinde nota basması gibidir. Yanlış basılan her notanın müşterinin duyduğu sese yansıması, müşteri şikayetlerini beraberinde getirir.

Özelleşmiş yapılar
Her bir servis kendi işinde özelleşmiştir ve ‘Bu işi kim yapar?’ sorusunun karşılığında okların yöneldiği yer ilgili servisi de işaret eder aslında.

Bu düşünceyi yazılım geliştirme açısından ele aldığımızda konuyu fonksiyon/method kavramına benzetebiliriz. Methodlar da yapmış olduğu işler açısından özelleşmiş birer parçacıktırlar. Yazılım geliştiriciler sık kullanılan iş ve kod bloklarını birer method haline getirirler ki proje içerisinde işin yapıldığı her yerde tekrar tekrar aynı kodların yazılmasına gerek kalmasın. Daha sonraları, aynı proje içerisinde kullanılan bu methodlar neden farklı projelerde de kullanılmasın düşüncesiyle kütüphane kavramı ortaya çıkmıştır. Böylece kod blokları artık bir defa yazılıp derlenip, birden çok projede kullanılabilir hale gelmiştir.

SOA, aslında bahsetmiş olduğum bu felsefenin mimari alana yansımış bir ifadesidir de aynı zamanda.

Referans dokümanlarda bahsedilen SOA’nın temel 6 bileşeni bulunuyor;

Service
Tüm bu konseptin üzerine inşa edildiği en temel varlıktır. Servislerin otonom, özerk yapıları bulunmaktadır ve sözleşmeler ile sunmuş oldukları fonksiyonel yetilerini gerçekleştimelidirler. Kullanılmaya hazır iş kaynaklarıdırlar.

Policies
Bir servisin hangi şartlar altında kullanılabileceğini içeren politikalardır. Kullanıcılar ancak ve ancak bu şartların sağlanması durumunda servislerden hizmet alabilirler. 

End-Point
Servisin ulaşılacağı adres bilgisini içeren URI’lerdir. End-point’ler sözleşmeleri sunarlar.

Contract
Servisler tarafından desteklenen mesajların bütünü sözleşme olarak anılır.

Messages
Servisten hizmet alabilmek için kullanılan iletişim türüdür. Örneğin http GET, JMS, SOAP olabilir. Mesajlaşmalar, sözleşmeler tarafından sunulur ve bu tanıma uygun olarak iletişim sağlanır.

Service Consumer
Bir servis üzerinden hizmet alan herhangi bir kullanıcıdır. Kullanıcı olabilmek için politikalar ve sözleşmeler ile anılan şartlar sağlanmış olmalıdır. Kullanıcı her hangi bir uygulama olabileceği gibi bir başka servis de olabilir.

Bir kurum içerisinde SOA vardır ya da yoktur şeklinde kesin bir kanıya varmak çok anlamlı değildir. Burada ulaşılabilecek karar, kurumun ne kadar SOA’ya yakın ne kadar uzak olduğu şeklinde ortaya çıkabilir. Nihayetinde SOA, anlatılan tüm bu özelliklerden dolayı orta, büyük ölçekli mimarilerde iş birimlerine sunulan yetilerin artırılmasına, teknoloji birimlerine de kolaylık sağlamasına yardımcı olmaktadır. Fakat herşeyin bu konsepte uygun olması da tabiki yerine göre olumsuz sonuçlar doğurabilir. Küçük işletmelerde, yalnzıca birkaç uygulamadan oluşan ve değişmeyen yapılarda SOA tercih etmek çok da optimal görülmemektedir.

Kaynaklar:

Microsoft – Understanding Service-Oriented Architecture
IBM – What is SOA?
Oracle – Introduction to Oracle SOA Suite Components
Open Group – The SOA Source Book