MİMARİ ÖRÜNTÜLER

SOA (Service Oriented Architecture) Nedir ?

Bir sistem üzerinde bir çok uygulamanın tek bir veri tabanı üzerinden veri tabanı şablonları ile ayrışması, uygulamlar arası soyutlamanın veritabanı şemalarına yıkılması sağlıklı bir yaklaşım değildi. Bunun yerine uygulamaların birbirlerine servis olarak ulaşması, hatta çok karmaşık durumlarda Event Bus üzerinden kontrollü şekilde iletişimi ve veri paylaşımı yapması sağlandığı mimariye denir.

SOA (Servis Odaklı Mimari) kavramının ne olduğuna anlatmadan önce bu kavramı ilk defa nerde duyduğum ve ne için kullanıldığını anlatmaya çalışarak SOA kavramını daha iyi anlatabileceğimi düşünüyorum.

Servis Odaklı Mimari’yi ilk defa T2 firmasında Türk Telekom için çalışmaya başladığımızda duydum. Türk Telekom’da Entegrasyon ve Mimari ekibinin sürekli üzerinde uğraştığı konulardan biri de buydu.

Telekom’un içerisinde 100 lerce proje geliştirilmiş. Zaman içinde bu uygulamalar giderek artmış ve aynı veritabanı üzerine kullanılan bir sürü proje olmuş. Her projenin ekstra ihtiyaçları doğrultusunda veritaban tabloları giderek artmış, üzerine yapılan sorgular giderek artmış ve karmaşıklık bu işi başka bir şekilde çözmeye itmiş.

Daha sonrasında veritabanı soyutlanmış ve belli uygulamaların dışarıya servis vermesi şeklinde tasarımlar yapılmış. Fakat ilerleyen sürede uygulamaların birbirlerinden kullandıkları servislerin karmaşası ile karşılaşılmış ve bunu çözmek için tüm uygulamaları SOA yapısı üzerine oturtmayı ve bu servisleri ESB(Enterprise Service Bus) üzerinden vermeye çalışıyorlardı.

Verilen hizmet çeşitliliği ve kampanyalar bu kadar yaygın değil iken uygulamalar Telekom’un ürün ve hizmetler ihtiyaçlarına göre karar verilip geliştiriliyordu. IT ile ilgili olan bu projeler genelde Telekom’un kendi iştirak firması tarafından geliştiriliyordu. Örneğin

• Müşteri İlişkileri Yönetim Sistemi,
• Kurumsal ve Bireysel Hizmet Merkezleri,
• Çağrı Merkezi
• Arıza Sistemi
• Tahakkuk Sistemi
• Kampanya Yönetim Sistemi
• Ürün Satış ve Pazarlama
• vb…

Bu ve benzeri projelerin kapsamlarının artması, bunları geliştiren firmaların sayıların artması ve çeşitlenmesi alt yüklenici sayısını arttırmış bir çok farklı firma Accenture, Etiya, Innova, T2 vb.. firmalar bu şirketler için aynı sistem üzerinde uygulama geliştirmeye başlamışlardır.

Bu şirketlerin geliştirdiği uygulamaların birbirlerine servis vermeleri ve bunların yönetilmelerini zorunlu hale getirmiştir. Daha önceden olduğu gibi herkesin aynı veritabanı üzerinde geliştireceği uygulamalar ile çözülebilecek bir yöntemden farklı bir yönteme geçilmesi gerekmektedir.

ESB üzerinden SOA Mimari

Gerçekten güzel bir strateji. Verinin yönetimi, business mantıklarının tekrar tekrar yazımının engellenmesi, uygulamaların direk veritabanı katmanına erişmesi yerine önünde tekrar kullanabilen servislerin bulunması.

Temelde problem veri’ den kaynaklanıyor. Örneğin Müşteriye erişebileceğiniz telefon numarasını düşünün

• Bu verinin sahibi veya sahipleri kimlerdir ?
• Bu veri kim üretir ?
• Bu veriyi kim günceller ?
• Bu veriyi kim görüntüler ?
• Bu veriyi kim siler ?
• Bu veri güncellenince nereler nasıl etkilenir ?
• Bu verinin tüm alanlarını görme yetkisi var mıdır ?

Veriyi uygulamalardan soyutlayarak bir servis aracılığı ile sağlarsak. Verinin;

• güvenilirliğini,
• güncellenmesini
• dağıtılmasını sağlamış oluruz.

ESB (Enterprise Service Bus)

Buraya kadar her şey güzel peki bu ESB nerden, hangi ihtiyaçtan doğmuş. SOA mimari için gerekli mi ?

Uygulamaların giderek artması sonucu karşımıza aşağıdaki gibi sorunlar çıkar ?

• Uygulamalar birbirlerine verecekleri servisleri hangi protokol üzerinde sağlıyacakları HTTP,AMQP,SMTP, FTP, SOAP vb üzerinden sağlıyacakları, Bu servislerin güvenlik seviyeleri, Servislerde sağlıyacakları veri formatları JSON, HTML, XML, Binary vb.. olması
• Uygulamaların görmeleri gereken veri içeriğinin birbirinden farklı olması
• Verilmesi gereken servisteki verinin yeterli olmaması 2,3 servis verisinin birleştirilerek bir veri oluşturma isteği.
• Servislerin versiyonları. Bir servis eski versiyon ile çalışırken, diğer servis yeni bir versiyonla çalışması gerekebilir.
• vb..

Tüm bu gerekçeler servislerin yönetilemez bir hal almasına sebep olabilir.

Servislerin Çağrımlarının Karmaşıklığı

Monolithic vs SOA vs Microservices

Micro-service ile kıyaslama yaparken buradaki servislerin küçük ve basit olmadığını daha monolitik yapıdaki büyük uygulamaların servis haline getirildiğini ve baştan tasarlanmak yerine iletişim yapılarına çözümler getirilmeye çalıştığınızı düşünün. Bu açıdan SOA kurumsal ölçekteki yapılar için kullanılan bir mimari iken, Microservisler uygulama seviyesinde kullanılan mimarilerdir.

Büyük uygulamaların servis haline dönüştürülmesi ve birbirleri ile güvenilir, güvenlikli bağlanması için ESB(Enterprise Service Bus) ihtiyaç bulunur. ESB, servislerin bir kanal üzerinden akacak şekilde yönetilmelerini sağlar. Farklı farklı projeler ve ortamlar tüm bu servisleri bu Bus üzerinden alıp kullanabilirler.

Monolithic vs SOA vs Microservices

Enterprise Service Bus İçeriği

ESB’nin iç yapısına baktığımızda;

• Adapters/Tranports,
• Service Hosting,
• Security,
• Mediation ve
• Operations and Management bölümlerinden oluşur.

ESB içeriği

Adapters / Transports: Uygulamaların değişik ihtiyaçlarına göre servislerle erişim protokolleri, veritabanı adaptörleri ve 3rd Party Adaptörleri sağlaması (SOAP, HTTP, REST, JMS, Email, FTP, EJB, DB Adapter, 3rd Party Adapter, Custom Adapter)

Service Hosting : Servislerin yüklendiği, servislere erişimin sağlandığı, yaşam döngülerinin yönetildiği kısım.
(Service Container, Component Model)

Security: Transport ve Mesaj seviyesinde güvenlik sağlandığı kısımdır. Servisler için kimlik doğrulaması ve yetkilendirmenin yapılabilmesine olanak sağlar. Mesajların Encryption/Decryption yapılmasını sağlar.
(Authentication, Authorization, Encryption, Security Mediation)

Mediation: Mesaj dönüşümlerinin, protokol dönüşümlerinin, mesaj sıralamalarının gerçekleştirildiği modüldür.
(Message Transformation, Reliable Messaging, Caching, Msg Routing, Protocol Translation, Transaction, Service Callout, Msg Validation, Msg Re-sequencing, Pass-Through Messaging, Service Composition)

Operation And Management: ESB hakkında istatistik toplama, performansı hakkında bilgi alma ve buna göre yükü dağıtma işlemlerinin gerçekleştirildiği kısımdır. Mesajın gereğinden fazla olması durumunda kuyruğa atılıp işlenmesi , konfigürasyon yönetimi vb bir sürü operasyon ve yönetim bu modül aracılığı ile gerçekleştirilir.
(Statistics & Status, Alerting, SLA Rules, Msg Tracking, Msg Re-delivery, Endpoint Failover, Load Balancing, Msg Throttling, Logging & Reporting, Config Management, Service Registry, High Availability, Error Handling, Deployment, Service Usage)

Okumaya Devam Et 😃

Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.