5. SOA GERÇEKLERİ Burak Selim Şenyurt – www.buraksenyurt.com
HR Modülü
Asp.Net MVC
Üretim
Modülü
C, Assembly
Rapor Modülü
SQL, Oracle,
NoSQL
BMPX
Tibco
Doküman
Yönetim
Sharepoint
AR-GE Modülü
C, Assembly
Dış Ağ
SOA Motor Company
Yazılım
Departmanının
Uğraştığı
Modüller/
Domainler
Yan Sanayi A
System
Alpha
Yan Sanayi B
System
Beta
Mobil
Saha Ekibi
Android, iOS
SOA Bank
İş Modelleri
Süreçleri
6. Genel Tanım
SOA, servis olarak adlandırılan, gevşek bağlı (Loosely Coupled), iri taneli (Coarse
Grained) ve özerk(Autonoums) yapıdaki bileşenlere dayalı dağıtık sistemlerin
geliştirilmesi için kullanılan mimari bir stildir.
Burak Selim Şenyurt – www.buraksenyurt.com
Zaten SOA' nın
Architecture kelimesi
bunun bir mimari
yaklaşım olmasından
dolayıdır.
SOA GERÇEKLERİ
7. Coarse-Grained Derken
Objects Components Services
Less Business Value More Business Value
Burak Selim Şenyurt – www.buraksenyurt.comSOA GERÇEKLERİ
Fine-Grained Coarse-Grained
10. Service
Servisler SOA’nın en temel ve önemli üyesidir.
Bir servis çoğunlukla ayrık bir iş fonksiyonelliği sunar.
Policies
(İlkeler)
Bir servisin tüketicileri tarafından kullanılabilmesi için kısıtlar ve
terimler tanımlar. Security, Auditing, SLAs vb Policy içerisinde yer alan
dinamik özelliklerdir.
EndPoints
Bir URI(Uniform Resource Identifier) dir. Servisin bulunduğu adrestir.
Endpoint’ ler sözleşmeleri sunar.
Contracts
(Sözleşmeler)
Servis tarafından desteklenen mesajların tümü, bir sözleşme ile
sunulur.
Messages
(Mesajlar)
SOA içindeki iletişim birimidir. REST(Representational State Transfer),
SOAP(Simple Object Access Protocol), JMS(Java Messaging Service) vb
türleri vardır.
Service
Consumer
(Tüketici)
Servisler ile mesajlaşma yoluyla iletişime geçen bileşenlerdir.
Başka bir uygulama veya servis olabilir.
Temel
Bileşenler
Burak Selim Şenyurt – www.buraksenyurt.comSOA GERÇEKLERİ
12. SOA Neyi Çözer?
SOA dağıtık yazılım sistemlerinin kalitesini arttırma noktasında pek çok mimari
kritere sahiptir.
◦ Yeniden kullanılabilirlik(Reusability),
◦ Uyumluluk (Adaptability)
◦ Bakım Yeteneği (Maintainability)
◦ Bağımlılıkları Azaltma (Loose Coupling)
◦ Façade vb…
◦ Özerklik
◦ Heterojenlik
SOA özellikle Point-To-Point entegrasyon yapan sistemlerdeki bağımlılıkları
ortadan kaldıracak çözümleri içerir.
Burak Selim Şenyurt – www.buraksenyurt.comSOA GERÇEKLERİ
13. ETL
Extract,
Transform,
Load.
DB’ler arası
Entegrasyondur.
Farklı araçları da
vardır.
Online
Uygulamalar
arası TCP veya
HTTP bazlı yapılır.
File-Based
Veri, uygulamalar
arası dosya sistemi
üzerinden taşınır.
Doğrudan DB
Uygulamalardan
DB’ ye doğrudan
erişim söz konusudur.
Point to Point
Entegrasyonlar
İ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.
Point to Point Demişken…
Burak Selim Şenyurt – www.buraksenyurt.comSOA GERÇEKLERİ
14. Kampanyalar
Krediler
Ürünler Müşteriler
ABC
XYZ
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.
Temel Sorun
Burak Selim Şenyurt – www.buraksenyurt.comSOA GERÇEKLERİ
15. İş Faydası SOA Bunu Nasıl Sağlar?
İş birimi için operasyon maliyetleri düşüktür. Servisler özerk tasarlanır. (Autonomy özelliği)
Service Level Aggrements uyumluluğunu
sağlamak ve entegrasyon kolaydır.
Endüstriyel olarak standartlaşmış
ilkeleri(Policies) önerir.
İş süreçlerindeki değişikliklere kolayca adapte
olunur ve pazara yeni iş fonksiyonelliklerini
hızla sunabilme imkanı vardır.
Çünkü bileşenlerin(Components) bakımı ve
değişimi kolaydır.
Yeni sistemlere az eforla bağlanmak
mümkündür. İş ortağı firmalarla entegrasyon
daha kolaydır.
Çünkü Endüstri standartlarına uyan servis
arayüzleri(Contracts) söz konusudur.
İş Birimi Açısından SOA’nın Faydası
Burak Selim Şenyurt – www.buraksenyurt.comSOA GERÇEKLERİ
18. Service Host
LifecycleConfiguration
Wiring Administration
Environment
Endpoint
Contract
Service
Soru : Her bir servis için bileşenleri(Components) kolayca bağlayabilmenin,
dinleyicileri(Listener) basitçe devreye alabilmenin, sıradan işlermiş gibi
konfigurasyon ayarları yapabilmenin bir yolu var mıdır?
Çözüm : Konfigurasyon değerlerini kolayca ayarlayabilecek, bileşen bağlama
veya servis kurulumu gibi işleri icra edebilecek, konteynır(Container) rolünü
üstlenen genel bir Service Host bileşeni veya framework yazmak.
Service Host Pattern
Tanım: Service Host, servislerin konfigure edilebilmesi ve dış ortamlara
bağlanabilmesi işlerini üstlenen bir konteynırdır(Container).
Kalite Nitelikleri :
• Yeniden Kullanılabilirlik
(Reusability)
• Taşınabilirlik(Portability)
Örnek Teknolojiler:
• Microsoft AppFabric,
• Fuse ESB,
• Spring,
• PicoContainer
Desen
Kartları
Burak Selim Şenyurt – www.buraksenyurt.comSOA GERÇEKLERİ
Burada servis dünyasına olan gereksinimleri vurgulayan kısa bir hikaye anlatılır.
Burada servis dünyasına olan gereksinimleri vurgulayan kısa bir hikaye anlatılır.
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.
Yeniden Kullanılabilirlik : Servislerin birden fazla kullanıcı veya uygulamaya ulaşmasını sağlamada önemli rol oynar. Bir iş fonksiyonelliğini servisleştirerek n sayıda uygulamanın/istemcinin kullanımına açabiliriz.
Loose Coupling : Servislerin diğer sistemlere şema ve sözleşmeler aracılığı ile bağlanabilme özgürlüğü.
Özerklik : Her servisin kendi işinden sorumlu olması ve sadece o işi yapması.
Façade : Karmaşık yapıların servisler aracılığı ile daha basit arayüzler üzerinden sunulabilmesi.
Heterojenlik : Farklı teknolojilere sahip sistemlerin kolayca bağlanabilmesi.
Ö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-Pointentegrasyon 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ğerPoint-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.
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...
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.
SOA' ya dayalı bir sistemi veya sistemler bütününü inşa etmek kolay değildir. Problemlerden birisi degü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.
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.
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.