SOA Nedir? Gelişimi, Prensipleri, Avantajları ile Kapsamlı Bir SOA İncelemesi

SOA – Service Oriented Architecture Nedir?

SOA, Service Oriented Architecture yani Servis Odaklı Mimari veya Hizmet Odaklı Mimari; değiştirilmesi zor olan eski monolitik bağımsız uygulamalardan, iş hedeflerine ulaşmak için birlikte çalışmak üzere birleştirilen yeniden kullanılabilir kurumsal bir yapıya geçiş için mimari bir yaklaşımdır.

SOA, kurumsal uygulamalarda bulunan farklı fonksiyonları iş ihtiyaçlarını karşılamak için hızla birleştirilebilen ve yeniden kullanılabilen, birlikte çalışabilir, standartlara dayalı servis organizasyonudur.

Detaylı açıklamalardan önce yazılım mimarisi nedir, monolitik ne demek buna bakalım. Yazılım mimarisi kısaca bir sistemin tüm yapılarını tanımlayan ve gösteren üst seviye plan olarak ifade edebiliriz. Yazılım mimarisi ile ilgili daha fazla detayı Yazılım Mimarisi yazısında bulabilirsiniz.

Monolitik (monolithic) ise Türkçe’de tek parça, yekpare sıfatı anlamındadır. Monolitik mimari; sağlanan tüm fonksiyonların, tüm modüllerin tek pakette olduğu bir yaklaşımdır. Monolitik uygulamaların birden fazla görevi olur. Monolitik uygulamada kodlar derlendikten sonra tek bir uygulama paketi ortaya çıkar. Uygulamanın tüm fonksiyonları bu paketten sağlanır. Herhangi bir fonksiyonda değişiklik yapıldığı takdirde tüm uygulamanın derlenmesi gerekir. Bu durum basit bir örnek olarak, regresyon testi gibi tüm uygulama üzerinde testin yapılması gibi konuları ortaya çıkarır.

SOA ise standart arayüzler ve protokoller kullanan, farklı platformların sorunsuz entegre olabildiği dağıtık sistem mimarisidir. Farklı bileşenleri, ortak bir arabirim ve Enterprise Service Bus adı verilen kanal aracılığıyla iletişim kurmaları ve entegre etmek için kullanılır.

SOA, tüm servislerin kapalı kutu (black box) gibi göründüğü belirli tasarım ilkelerine sahip bir mimari yaklaşımdır.

SOA’nın Amacı

SOA’nın temel amacı, büyük monolitik uygulamaları yeniden kullanılabilir ve birlikte çalışabilir bağımsız servislere ayrıştırmak ve standart protokoller üzerinden iletişim kurmalarını sağlamaktır. SOA farklı servisleri kullanan ya da sağlayan dağıtık bileşenlerin koleksiyonudur. Bu koleksiyonda servisi sağlayan ve tüketen bileşenler farklı uygulama dilleri ve platformları kullanabilir.

Servisler büyük ölçüde bağımsız varlıklardır. Her bileşen kendi içinde monolitik bir yapıya sahip olabilir. Servisi sağlayanla kullanan genelde birbirlerinden bağımsızdır. Çoğu zaman farklı sistemlere hatta farklı kuruluşlara aittir.

Mevcut uygulamalar heterojen ve çeşitli sistemler arasında dağıtılmış olsa da SOA modeli uygulanarak standart arayüzlerle erişilebilir:

SOA’yı Daha İyi Anlamak için Bir Analoji

SOA’yı daha iyi anlamak için gerçek hayattan somut bir uygulama üzerinden gidelim. Örneğin filo takip sistemi olarak kullanılan bir web uygulamasını ele alalım. Bu uygulamada temel şu fonksiyonlar olacaktır: kimlik doğrulaması, oturum açma, harita işlevini gören bir alt sistem, yakıt ve ceza ödemeleri için başka bir alt sistem ve başka diğer bileşenler.

Bileşenlerin tüm servislerini sadece uygulama içerisinden sunabilmek hem çok fazla efor gerektirecek hem çok maliyetli olacak hem de uygulama çok karmaşık hal alacaktır. Bunun yerine yaygın olarak kullanılan global ve online olarak sağlanan harita hizmetleri, ödeme sistemleri ve kullanıcı oturum açma hizmetlerinden faydalanabiliriz.

O zaman yapılması gereken iş, uygulamanın istenen işlevselliğini sağlamak için bu farklı hizmetlerin kullanıcıya rehberlik eden ortak platformda bu hizmetleri bütünleştirmek olacaktır. Böylece tüm farklı bileşenleri ve servisleri uygulamanın içerisinde sunmak yerine, servis odaklı mimari ile farklı servislerin uyum içerisinde çalıştığı bir ortam oluşturularak daha kolay bir şekilde işin üstesinden gelebiliriz.

SOA’nın Temel Fikri

SOA, uygulama (application) seviyesinde değil kurumsal (enterprise) seviyede bir mimaridir. Herhangi bir teknik mekanizma veya uygulama önermez. SOA daha çok sistemler arasındaki sınır / entegrasyon etkileşimi ile ilgilidir.

Kurumsal uygulamalarda bulunan ayrı fonksiyonları, iş ihtiyaçlarını karşılamak için hızla birleştirilebilen ve yeniden kullanılabilen, birlikte çalışabilir, standartlara dayalı hizmetler halinde organize eden bir BT stratejisidir.

Service Oriented Architecture modeli altında find-bind-publish yani bul-bağla(çalıştır)-yayınla düşüncesi yatar. SOA ne demek sorusunun cevabı da işte burada belirtilen birlikte çalışabilen servislerin koleksiyonudur. Servis odaklı mimari için servisin temel yapısı şu şekildedir:

Şimdi bunların kısa bir açıklamalarını yapalım:

» Service Provider (Servis Sağlayıcı): İş açısından bakıldığında, bu verilen hizmetin sahibidir. Mimari açıdan bakıldığında, bu servise erişimi barındıran platformdur.

» Service Requestor (Servis Kullanıcısı): İş açısından bakıldığında, bu belirli işlevlerin yerine getirilmesini gerektiren iştir. Mimari açıdan bakıldığında, bir servisle etkileşimi arayan ve başlatan uygulamadır.

» Service Registry (Servis Kaydı): Servis sağlayıcıların açıklamalarını yayınladıkları servis tanımlarının aranabilir bir kaydıdır. Servisi talep edenler servisi bulur ve servis açıklamalarından binding bilgilerini alır. Servis bilgileri servisi talep edenlere doğrudan gönderebildiğinden servis registry mimaride isteğe bağlı bir roldür. Benzer şekilde, servis talebinde bulunanlar, yerel bir dosya, FTP sitesi, web sitesi gibi diğer kaynaklardan da bir servis tanımı alabilirler.

» Publish (Yayınla): Servisin erişilebilir ve talep edenin bulabilmesi için bir servis açıklamasının yayınlanması gerekir. Yayınlandığı yer, başvurunun gereksinimlerine bağlı olarak değişebilir.

» Find (Bul): Find işleminde kullanıcı ya doğrudan servis bilgilerini alır ya da servis registry’den sorgular. Bulma işlemi tasarım zamanında program geliştirme için servis arayüz tanımlarını almak için yapılır. İkincisi, runtime’da yanı çalışma zamanında servising binding (bağlama) ve lokasyon bilgilerini almak için kullanılır.

» Bind (Bağla): Son durumda servisin çağrılması gerekir. Bağlama işleminde, servis talebinde bulunan uygulama iletişim kurmak ve servisi çağırmak için hizmet açıklamasındaki bağlama ayrıntılarını kullanarak çalışma zamanında servisle bir etkileşim başlatır.

SOA Neden Ortaya Çıktı?

Teknoloji geliştikçe yazılımlar da daha karmaşık sistemler olarak ortaya çıktığı için yazılım mimarisinin karmaşık sistemlerin temel özellikleriyle başa çıkabilmesi gerekir. Yüksek düzeyde farklılık ve çeşitlilik olduğu için “birlikte çalışabilirlik” başa çıkılması gereken en önemli konulardan biridir.

Birbirinden bağımsız bileşenlerin esnek, dağıtık yapıda ve yazılım mühendisliği prensiplerine uygun bir şekilde konumlandırılmış olması gerekir. Doğal olarak sistemlerin karmaşıklığını aşmak için de yüksek düzeyde bir soyutlama yapılması gerekir. Dolayısıyla sürekli gelişen karmaşık mühendislik sistemlerini modellemek ve tasarlamak sistem mimarisinde alternatif paradigma ihtiyacını doğurmuştur.

Bu yeni sistem mimarisi paradigması, Service Oriented Architecture (SOA) yani Servis Odaklı Mimari olarak ortaya çıkmıştır. SOA mimarisi internetin daha yaygın hale getirdiği dağıtık ve heterojen ortamlara göre uyarlanmış yazılımlar oluşturma ihtiyacına bir yanıttır.

SOA Nasıl Ortaya Çıktı?

2000’lerin başlarında SOA ortaya çıktığında, kurumsal uygulamalar bir hizmeti sağlamak içerisinde birden çok uygulamadan oluşuyordu. Dolayısıyla aynı kod çoğu zaman farklı bir uygulama veya modülde mükerrer bir şekilde kullanılıyordu. Bu durum da doğal olarak daha verimsiz, daha fazla efor sağlanan daha fazla bütçe gerektiren uygulamaların ortaya çıkmasına sebep olmaktadır.

Üstelik sistemler daha fazla karmaşık hale geldikçe geliştiriciler için de bakımı daha zor uygulama haline geliyordu. Tek bir servisin değiştirilmesi gerektiğinde birden çok uygulamanın güncellenmesi gerekiyordu.

Bu nedenle uygulama çerçevesinde değil servis bazında SOA tasarlandı. Bu sayede farklı hizmetler dağıtık bir şekilde sağlanabilir hale geldi. Örneğin bir sistemin bir hizmeti cloud’dan verilebilirken, diğer hizmeti on-premise olarak yani lokal bir altyapıda verilebilir.

Peki SOA’nın gelişimi nasıl oldu? Yazılım krizi olarak bilinen durum (software crisis) yazılım mühendisliğini tetiklediğinden beri IT endüstrisi ortaya çıkan sorunları çözmek için sürekli efor sarf etmiştir. Daha esnek ve sürekli değişen iş gereksinimlerine duyarlı ve heterojen uygulamaların mümkün olduğunca sorunsuz iletişim kurabildiği bir ortama ihtiyacı bulunuyordu. Bunu sağlamak için aşağıdaki şekilde gösterildiği gibi IT dünyası iş dünyasının gelişimine de paralel olarak gelişim sağladı:

“SOA” terimi ilk olarak 1996 tarihli bir araştırma makalesinde kullanılmıştır. SOA, bilgi işlemin tüm yinelenen ihtiyaçlarını karşılayan, önceki teknolojilerden edinilen bilgileri pekiştiren, mevcut teknolojilerin avantajlarından yararlanan ve riskleri azaltan bir IT evrimiydi. Servis Yönelimli Mimari herhangi bir teknolojiye bağlı değildir, ancak sağlam, birlikte çalışabilir sistemler oluşturmak için birçok seçenek sunar.

SOA’nın Temel Bileşenleri

Servis Odaklı Mimari; bir uygulama önyüzü, servis, repository (servis muhafazası) ve servis bus (veri yolu) temel yapı taşlarına dayanan bir yazılım mimarisidir. SOA’nın temel bileşenleri şu şekildedir:

» Application Frontend (Uygulama Önyüzü): Veriyi son kullanıcılara aktaran aktif SOA öğesidir. Kurumsal sistemin tüm faaliyetlerini başlatır ve kontrol eder. Web uygulaması ya da GUI’ye sahip bir uygulama örnek olarak verilebilir.

» Service (Servis): üst düzey bir iş konseptini kapsayan bir yazılım bileşenidir.

» Contract (Anlaşma): Servislerin amacı, işlevselliği, kısıtlamaları ve kullanımına ilişkin bir tanımlama sağlar.

» Interface (Arayüz): Bir servisin sağladığı fonksiyonun bunu kullanacak istemcilerin bağlanıp kullanabilmesi için sağlanan yöntemdir. Bir servisin metodu olabileceği gibi komut satırı da olabilir.

» Implementation (Uygulama): Servisin uygulaması, gerekli iş mantığını ve uygun verileri sağlar. Program, konfigürasyon, veri ve veritabanları gibi bir veya daha fazla yapıt içerir.

» Service Repository (Servis Deposu): Servislerin keşfedilmesini kolaylaştırmak için servisleri ve operasyon, erişim hakları, sahip, nitelikler vb. özelliklerini kaydeder.

» Service Bus (Servis Veri Yolu): Uygulamaları ve servisleri entegre etmek için kullanılan esnek bir altyapıdır. Mesajları yönlendirir. Servisler arasındaki etkileşimi yönlendirir. Mediation ve güvenlik gibi özellik sağlar. Business event adı verilen olayları yönetir ve iletir.

SOA’nın Mimari Tasarım Prensipleri

Servis odaklı mimari tasarlarken göz önüne alınması gereken bazı ilkeleri bulunmaktadır. Bu ilkeler veya prensipler SOA’nın karakteristiğidir. Yani SOA’yı SOA yapan özelliklerdir. Bu ilkeler ürün, satıcı veya teknolojiden bağımsızdır.

Teknolojiden bağımsız olarak uygulanması önemli olan SOA ile ilişkili vurgulanan 8 tasarım ilkesini göreceğiz. SOA’nın temel amaçlarından biri interoperability yani birlikte çalışabilirliktir. Bu 8 ilkenin her biri birlikte çalışabilirliği bir şekilde destekler veya katkıda bulunur. Dolayısıyla bu özellik ayrı bir ilke olarak ele alınmamıştır. Bu ilkeleri ayrı ayrı açıklayalım.

Standardized Service Contracts (Standart Servis Sözleşmeleri)

Bu tasarım ilkesi, aynı envanterdeki servisler için aynı standardın olacağını ifade eder. Bu prensibe göre servisin iyi tanımlanmış veri modeli, veri tanımlamaları, transport mekanizması açıklamaları ve servis sözleşmesinin ilke tanımları olmalıdır. Böylece servisin amacı ve yetenekleri kolayca anlaşılacak ve envanterin sınırını belirleyecektir.

Standartlaştırılmış servis sözleşmeleri, servisi kullanmak isteyen herhangi bir son kullanıcı veya herhangi bir müşteri sistemi için uygulamayı kolaylaştırır. Örneğin, SOAP web servisleri gibi web servislerini kullanan bir uygulamada WSDL servis sözleşmesidir.

Servisin tüm detayları ilgili sözleşme ile iyi bir şekilde ortaya çıkarılmalıdır, böylece servisten yararlanmak isteyen herhangi bir müşteri servisin fonksiyonlarının, ilkelerinin, transport mekanizmalarının, input/output türlerinin neler olduğunu ve ne tür veri formatı beklediğini ve kolay bir şekilde anlayabilir.

Servis sözleşmeleri teknolojik düzeyde yer alır ve SOA için en önemli meta datalardan biridir.

Loose Coupling (Servislerin Düşük Bağımlılığı, Gevşek Bağlantı)

En fazla vurgulanan prensiplerden biridir. Bu tasarım prensibi servisler arasında en az bağımlılık olacak, ideal olarak hiçbir bağımlılık olmayacak şekilde uygulanması gerektiğini belirtir. Yani herhangi bir servisin uygulanması diğer servisleri etkilememelidir. Ayrıca arayüzden üzerinden kullanılan servis arka planda değişse bile arayüzde değişiklik olmayacağı için servisi kullananlar etkilenmeyecektir.

Service Abstraction (Servis Soyutlama)

Bu tasarım prensibi, servislerin alt düzeyde soyutlanmış olarak uygulanması gerektiğini önerir. Yani servislerin fonksiyonları ve yetenekleri, dışarıya açık olmayan ve tamamen soyutlanmış herhangi bir teknik detay olmadan sözleşmeler aracılığıyla ortaya çıkarılmalıdır.

Servisteki değişiklikler istemciyi etkilememelidir. Servis sözleşmesi gerekli olmayan bilgiyi paylaşmamalıdır. Bilgiler verilen sözleşmeyle sınırlı olmalıdır.Bu prensiple servisin teknik ayrıntılarını dış ortamdan soyutlarız.

Service Reusability (Servisin Yeniden Kullanılabilirliği)

Bu tasarım prensibi de en fazla vurgulanan prensiplerden biridir. Bu prensip servisi bir kez geliştir birçok kez kullan der. Servisler ihtiyaç olduğunda bir uygulamada “plug and play” gibi yeniden kullanılabilecek durumda olmalıdır.

Service Autonomy (Servislerin Özerk Olması)

Servisin özerkliği tasarım prensibi, hizmetin kendi yetenekleri üzerinde güçlü ve tam kontrole sahip olması gerektiğini belirtir. Bu, servisin başka herhangi bir servise bağımlı olmadan işlevlerini yerine getirebilmesi veya sorumluluklarını yerine getirebilmesi gerektiği anlamına gelir.

Başka bir deyişle, diğer servisler herhangi bir nedenle mevcut olmasa bile, servis görevini tamamlayabilmelidir. Bu özerkliğe duyulan ihtiyaç, büyük ölçüde yeniden kullanım ihtiyacından dolayıdır. Bir servisin işleyişi bir şekilde servisin dışındaki başka bir şeye bağlıysa servisin yeniden kullanılabilir olmasını bekleyemeyiz.

Service Statelessness (Durum Bilgisine Sahip Olmama)

SOA, servisin minimum state bilgisi ile uygulanmasını önerir. SOA servisleri, oturum verileri, önceki olaylar veya daha önce bildirilen servis sonuçları hakkında hiçbir bilgiyi kaydetmemelidir. Yani servislerin statüsü olmamalıdır. Servisler yalnızca alınan girdiye ve ilgili iş kurallarına karşılık gelen davranışı sağlamalıdır. Bu ilkenin ayrıca özerklik, yeniden kullanılabilirlik ve gevşek bağlantı ile çok yakın bir ilişkisi vardır.

Service Discoverability (Servisin Keşfedilebilirliği)

Bu tasarım prensibi, servislerin ihtiyaç duyulduğu zaman ve yerde, yetenekleriyle birlikte sunulabilmesi içindir. Servisin fonksiyonlarının keşfedilebilir olması gerektiğini belirtir. Herhangi bir uygulama veya başka bir servis, ihtiyacı olduğu fonksiyonları sağlayan bir hizmetin zaten mevcut olduğunu bir kataloğu kontrol ederek gerçekleştirebilir. Bu sayede servisin fonksiyonlarını kullanabilir.

Bu nedenle, mevcut servislerin daha iyi kullanılması için servislerin fonksiyonları servis registry adı verilen kataloglarda olmalıdır. Servis keşfedilebilirliği prensibi, yeniden kullanabileceğimiz servisleri belirlemek için arama yapmamıza olanak tanıyan bir dizi meta veri ile SOA servisleri kataloğuna ihtiyaç olduğunu ifade eder.

Servis registry yani servis kataloğu kısaca servis bilgilerini tutan bir veritabanıdır. Telefon rehberine benzetebiliriz. Örneğin UDDI (Universal Description, Discovery, and Integration) XML tabanlı yaygın olarak kullanılan servis kataloğudur.

Service Composability (Servis Birleştirilebilirliği)

Belirli bir iş hedefine ulaşmak için iki veya daha fazla servis bileşik bir servis haline getirmek için bir tür gruplandırma yapılabilir. Servisler daha karmaşık süreçleri çözmek için kombinasyon gerektiğinde uygulanmalıdır.

SOA’nın Avantajları

Bu bölümde, geliştirme perspektifinden SOA’nın sunduğu avantajlara bakacağız. Doğru kullanıldığında SOA’nın IT dünyası için büyük avantajları vardır. Aslında tasarım ilkelerinin her birini teknik avantaj olarak görebiliriz. Önemli avantajlarını teknik ve iş kapsamı olarak 2 ayrı kısımda görelim.

Teknik Avantajlar

» Birlikte Çalışabilirlik: Daha önce de belirtildiği gibi SOA’nın temel amaçlarından biridir, en önemli ilke olarak kabul edebiliriz. Örneğin REST ve XML web servislerinin birlikte çalışması gibi yazılım sistemleri perspektifinden bakacak olursak SOA uygulamaları birlikte çalışabilirliğe olanak tanır.

» Yeniden Kullanılabilirlik: Servislerin yeniden kullanılabilir olması koddaki fazlalığı ortadan kaldırarak kod bakımını kolaylaştırır ve tekrarlanan çalışmaları ortadan kaldırır. Şirketlerin yeni geliştirme sırasında riski azaltmasına yardımcı olduğu için kuruluşlar için de avantajlıdır.

» Orkestrasyon (Orchestration): SOA uygulamaları, iş süreçlerini soyutlayarak, birleştirerek ya da ayrı ayrı sunarak birden çok bileşenden oluşturulmuş basit ve birleşik iş akışlarını düzenleyebilir veya yönetebilir. Ayrıca minimum insan müdahalesiyle doğru veriler sağlamak için farklı süreçler çalıştırabilir.

» Görev Ayrımı (Separation of Concerns): Her bölümün kendisiyle ilgili görevi vardır ve hepsi birbirinden ayrıdır. Her bölüm kendi ilgilendiği konusunu ele alır. Bu farklı platformlarda bulunan bileşenlerin birbirleriyle etkileşime girmesine olanak tanır. SOA sistemleri, uygulama ve arayüz arasında net bir çizgi çizer. SOA sistemleri, her bir servis için yani her bir görev için arayüzleri servis sözleşmeleri aracılığıyla sunar.

» Esneklik ve Çeviklik: Bir servis oluşturmak için çeşitli teknolojiler ve platformlar arasında özgür bir şekilde seçim yapabiliriz. En iyi araç ve en uygun platform seçilerek bir bileşik (composite) sistem oluşturulabilir. Bu sayede bir servis için istenilen platformu veya konumu seçebiliriz. Loose coupling ile de esneklik sağlanır.

Örneğin sistem parametreleri de daha sağlam ve güvenilir ortam için değiştirilebilir. Herhangi bir composite uygulama istenilen an diğerlerinden bağımsız olarak yaygınlaştırılabilir (deployment).

» Kapsülleme (Encapsulation): Geleneksel nesne yönelimli programlama, daha çok nesnelerin kapsüllenmesine odaklanır. SOA ise iş süreçlerini kapsüller. Yani her servise atanan iş süreci dış ortamdan soyutlanır. Bu sayede daha basit ve gereksiz bilgilerin olmadığı bir yapı sunulabilir.

» Standartlaştırma: SOA’ya çağrı yapılan adres olarak arayüz (interface) standart olmuştur. Bunu zaten SOA’nın temel bileşenlerinde belirtmiştik. Dolayısıyla bu standartlaştırma sayesinde yeni servis oluşturan bir programcının servisin temelinde kullanılan teknolojileri anlaması ve bilmesi gerekmez.

» Artımlı Yaygınlaştırma (Incremental Deployment): Loose coupling özelliği artımlı yaygınlaştırmaya olanak tanır. Büyük kurumsal sistemlerde sistem bileşenlerinin daha yeni bileşenlerle veya farklı bileşenlerle değiştirilmesi olağandır. Bileşenlerin arayüzleri iyi tanımlanmışsa, aynı işlevselliği uygulayan ve sergileyen daha yeni veya farklı sistemler, sistemin çalışmasını uzun süre engellemeden mevcut bileşeni değiştirmek için kolayca kullanılabilir.

» Soyutlama (Abstraction): SOA’da soyutlama, basit, açık ve anlaşılması kolay arayüzler aracılığıyla iş süreçlerinin uygulanmasındaki karmaşıklıkların gizlenmesini sağlar. SOA, bir organizasyonun sınırları içinde ve dışında iş süreçlerinin ve bilginin paylaşımına odaklanır.

» Veri Kullanılabilirliği (Data Availability): SOA veritabanları veya dosyalar gibi farklı kaynaklardan veri çekebilir. İyi tasarlanmış bir SOA birden fazla kaynaktan gelen verileri aynı tek biçimli şekilde (choreography / koreografi) sergileyebilir.

» Yatay Ölçeklendirme (Horizontal Scaling): Yatay ölçeklendirme mevcut altyapıda CPU/memory vs. artırımı yapmadan basitçe aynı makineden eklemek demektir. Her servis aldığı yüke göre ölçeklenebilir, bu da altyapının verimli kullanılmasına yardımcı olur.

İş Avantajları

» Uygulamayı Daha Hızlı Pazara Sunma: Her projeyle yeniden servis yazmak, yeniden servis entegre etmek yerine SOA’nun sunduğu birleştirmenin verimliliği geliştiricilerin uygulamaları çok daha hızlı oluşturmasını sağlar. Yeniden kullanılabilirlik özelliği ile geliştirme ve test eforları ya çok az olacak ya da hiç olmayacağı için yeni hizmet hızlı bir şekilde devreye alınabilir.

Ayrıca SOA, uygulama entegrasyonu, veri entegrasyonu ve orchestration tarzı otomasyon için senaryoları destekler. Bu da geliştiricilerin entegrasyonla uğraşmak yerine geliştirmeye daha fazla zaman ayırmalarını sağlayarak yazılım tasarımını ve geliştirmesini hızlandırır.

» Düşük Maliyetle Pazar Koşullarına Cevap: İyi hazırlanmış bir SOA, geliştiricilerin fonksiyonları kolayca anlamasına, yeni ortamlar için kullanmasına ve genişletmesine olanak tanır. Yeniden kullanılabilirlik hem geliştirme eforunu hem test eforunu düşüreceği için işletmelerin değişen piyasa koşullarına daha ekonomik bir şekilde yanıt vermesine yardımcı olur.

» İşletme ve IT Arasında İşbirliği Sağlama: SOA, iş birimlerinin daha iyi sonuca yol açabilecek temel bilgiler üzerinde geliştiricilerle daha etkili bir şekilde çalışmasına olanak tanır.

» Takımlar Arasında Etkileşim: SOA, ekiplerin farklı platformlar ve cihazlar için ek hizmetler geliştirmesini ve bunları sorunsuz bir şekilde sisteme entegre etmesini sağlar.

SOA vs Microservices: İki Mimari Arasında Farklar ve Benzerlikler

Servis Odaklı Mimari ile Mikroservis Mimarisi ilk bakışta çok benzer yaklaşımlar olarak göze çarpar. Her ikisi de aynı veya benzer tasarım prensiplerine sahiptir. Her ikisi de client/server yaklaşımından geliştirilmiştir.

Her ikisi de geleneksel, monolitik mimariden farklıdır çünkü her servisin kendi sorumluluğu vardır. Hatta şu da eklenebilir; büyük ve karmaşık uygulamaları, birlikte çalışması daha kolay olan küçük, esnek bileşenlere böler.

Ancak bu temel ortak noktalarla birlikte bu iki mimari yaklaşımın önemli bazı farklılıkları vardır. Bu karşılaştırma da ayrıca yeni bilgiler de bulacaksınız. Daha iyi fikir vermesi açısından bu iki mimariyle ilgili bazı farklılıkları ve öne çıkan bazı benzerliklerini yakından görelim:

Konu	SOA	Microservices
Gelişim Süreci	İstemci-Sunucu paradigmasından geliştirilmiştir.	İstemci-Sunucu paradigmasından geliştirilmiştir.
Kapsam	Kurumsal seviyede bir mimaridir.	Uygulama seviyesinde bir mimaridir.
Birlikte Çalışabilirlik (Interoperability)	Interoperability, SOA’nın temel amaçlarından biridir. Kuruluşların, sistemlerin birlikte çalışabilirliği geliştirmesine olanak tanır.	Mesaj tabanlı iletişim yolu ile interoperability’yi yani birlikte çalışabilirliği destekler.
Uygulama Boyutu	Mikroservis mimarisine göre büyük ölçekli proje ve entegrasyonlar için daha uygundur.	SOA’ya göre daha küçük ve web tabanlı uygulamalar için daha uygundur. Bu mimari; bir servis çok büyükse, iki veya daha fazla servise bölünmesi gerektiğini, böylece ayrıntı düzeyinin korunmasını ve yalnızca tek bir iş yeteneği sağlamaya odaklanmayı önerir.
Parçalar Arası İş birliği ve İletişim (Mainstream Communication)	Çoğunlukla orkestrasyon olarak sağlanır. Orkestrasyon, diğer servislere istek gönderecek ve yanıtları alarak süreci denetleyecek bir merkezi hizmet olan bir yönetici gerektirir. SOA iş kısıtlamaları, mesaj yönlendirme ve hizmet düzenlemesi de dahil olmak üzere karmaşık işlemleri ESB’de (Enterprise Service Bus) üzerinden sağlar.	Çoğunlukla koreografi olarak sağlanır. Koreografi, hiçbir merkezileşme olmadığını varsayar ve iş birliğini kurmak için olayları ve yayınlama/abone olma mekanizmalarını kullanır. SOA’dan farklı olarak, mikroservisler, servis düzenlemesinden sorumlu entegrasyon bileşenine sahip değildir ve koreografiyi tercih eder. Her servis kendi iletişim protokolü ile bağımsız olarak geliştirilir. Mikroservisler arasındaki iletişim için API Gateway kullanılabilir. API Gateway istemcinin isteklerini uygun servislere yönlendiren arabirim görevini görür.
Servis Ayrıntı Düzeyi – Servis Büyüklüğü (Service Granularity)	Coarse grained (üst seviye görevleri olan, büyük, ayrıntı düzeyi düşük) ve fine grained (oldukça detaylı ve küçük) servisler. SOA’da servisler küçük boyutlu servislerden kurumsal çaptaki servislere kadar değişebilir. Yani SOA’da servislerin boyutu ve kapsamı özel ve tek bir göreve sahip fine grained (ince detaylı) servislerden dağıtık sistemin yeteneklerini gerçekleştiren coarse-grained (büyük boyutlu, üst düzey) servislere kadar değişebilir.	Fine grained (oldukça detaylı, küçük) servisler. Fine grained servisler minimum düzeyde sorumluluğa sahiptir ve sınırlı miktarda veri alışverişi ile görevlerini yerine getirir. Yani tek bir atomik işlem uygular. Mikroservis mimarisi her servisin sahip olduğu sorumluluğun diğer fonksiyonlardan yani sorumluluklardan açıkça ayrı olmasını önerir. Amaç temel olarak tüm işlevselliğin her servis özelinde ayrıştırılmasıdır. Bu da servis boyutlarının küçülmesi ve servis etkileşimlerinin azalması anlamına gelmektedir.
Servislerin İşlevselliği	Her servis ayrı bir uygulama olarak kabul edilmez. SOA’da bir servisin birden fazla işlevi, fonksiyonu olabilir. Sistem fonksiyonlarını; görünür veya keşfedilebilir, yeniden kullanılabilir, birleştirilebilir veya teknolojik çeşitliliğe sahip olabilen servislerle sağlar.	Her hizmet bağımsız bir uygulama olarak kabul edilir. Mikroservis, genellikle belirli bir iş akışını ve uygulama gereksinimlerini kapsayan, küçük işlevsel kapsamı olan servistir.
Monolitik Servisler	Bulunur.	Bulunmaz.
Servislerin Düşük Bağımlılığı, Gevşek Bağlantısı (Loose Coupling)	Servisler arasında minimum bağımlılık önerilir, bir servisteki değişiklik başka bir serviste değişiklik gerektirmez. SOA’nın ana ilkelerinden biridir.	Servisler arasında minimum bağımlılık önerilir, bir servisteki değişiklik başka bir serviste değişiklik gerektirmez. Microservices’in ana ilkelerinden biridir.
Servislerin Yeniden Kullanılabilirliği	Entegrasyonların yeniden kullanılabilirliği ana özelliklerden biri ve birincil hedefidir. Gevşek bağlı (loosely coupled) servisler yeniden kullanılabilirliği sağlar. Uygulama sahip olduğu servisinin yeniden kullanılabilirliğini en üst düzeye çıkarmaya odaklanmıştır.	Bu özellik sağlanmış olsa bile ana konu veya birincil amaç değildir. Daha çok ayrıştırmaya odaklanmıştır.
Servislerin Özerkliği (Autonomy)	Servisler başka herhangi bir servise bağımlı olmadan kendi işlevselliğini sağlar, sorumlulukları yerine getirir. SOA’nın ilkelerinden biridir.	Her mikroservis doğası gereği bağımsız ve özerktir. Bir servis bir görev için tam sorumluluk alır. Servisler bağımsız olarak çalıştırılabilir. Her mikroservis, tüm uygulamanın özerk bir iş modülü olmalıdır. Bu nedenle uygulama minimum bağımlı olacak şekilde yapılandırılmış olur. Bu özellik bakım maliyetini düşürmeye de yardımcı olur.
İşlevsel Ayrım (Functional Separation)	Her bölümün kendisine ait görevi vardır. Görevlerin ayrımı (separation of concerns) konusu SOA’da dikkate alınır.	Bir sistem, tam işlevsellik sunan tek bir bileşene sahip olmak yerine, her bir bileşenin genel sistem davranışına katkıda bulunduğu izole bileşenlerden oluşur.
Yönetim (Governance)	Merkezi olarak yapılır.	Dağıtık yapıdadır. Servisleri modellemenin belirli bir yolu yoktur. Mikroservisler, tercih edilen herhangi bir teknolojiyi kullanabilir. Bunu kullanırken tek bir görev yapmalıdır.
Ölçeklenebilirlik	Daha az ölçeklenebilir. Mikroservislere kıyasla sınırlıdır. Sınırlı esneklik sağlar.	Son derece ölçeklenebilir. Her görevin diğerinden bağımsız olması, yalnızca gerekli bileşenleri ölçeklendirmeyi kolaylaştırır, zamandan ve kaynaklardan tasarruf sağlar. Mikroservisler kullanılarak bir uygulama oluşturulduğunda, bu, sistemin yalnızca gerekli bölümlerinin büyütülmesine olanak verir.
Çalışma Zamanı, Tasarım Zamanı (Lookup)	Servis registry kalıbı kullanılır.	Özel servis registry ve repository’leri (ör. Swagger tabanlı) ve uygulamada düzeyi ile ağ düzeyinde servis discovery kullanılır.
Veritabanı / Veri Depolama	Paylaşımlıdır. Servisler arasında veri depolaması paylaşır.	Birim başına ayrı veri depolaması bulunur. Her servisin bağımsız bir veri deposunu önerir. Her birimin kendi veri depolaması bulunur.
Mesaj Yükü (Payload)	Mesaj yükünde sınır bulunmaz.	Mesaj yükünde burada da sınır bulunmaz.

Özet

SOA’yı kısaca özetleyecek olursak;

» SOA, iş merkezli IT mimarisi yaklaşımıdır. Dağıtık hizmetleri organize edip birlikte çalışabilmelerini sağlayan bir modeldir.

» SOA client-server mimari yaklaşımı üzerinden geliştirilmiştir.

» SOA’nın temelinde her biri kapalı kutu olan servisler vardır. SOA farklı servisleri kullanan ya da sağlayan dağıtık bileşenlerin koleksiyonudur.

» Bu mimari yaklaşım servislerin yeniden kullanılabilir ve birlikte çalışabilir olmasını amaçlar.

» SOA’nın kapsamı kurumsaldır yani uygulama seviyesinde değil kurumsal seviyede bir mimari yaklaşımdır.

» SOA mimarisi büyük ve kurumsal uygulamalar için idealdir.

» SOA hangi teknolojinin kullanılacağını önermez. Ancak Servis Yönelimli Mimari’de servislerin oluşturulduğu XML tabanlı web servisler, SOAP, HTTP, WSDL, UDDI, REST servisler, RPC teknolojileri kullanılıyor diyebiliriz.

» Piyasada çeşitli firmaların örneğin Oracle SOA Suite gibi SOA ürünleri bulunmaktadır. Ancak Service Oriented Architecture yani Servis Odaklı Mimari, belirtildiği gibi ürün veya teknoloji bazlı bir yaklaşım değildir. Kendi tasarım ilkeleri olan bir paradigmadır.