SOA - Servis Odaklı Mimari (Service-Oriented Architecture)
VIP VIP Üye
SOA - Servis Odaklı Mimari (Service-Oriented Architecture)
SOA (Service-Oriented Architecture) nedir?
SOA birbirinden oldukça farklı iki şeyi tanımladığı için kafa karıştırıcı bir terim olduğunu söyleyebiliriz. SOA’nın ilk iki kelimesi (Service-Oriented) yazılım geliştirme yönteminin nasıl olduğunu; üçüncü kelimesi (architecture) ise bir şirketin tıpkı mimaride bina parçalarının birleştirilmesi gibi yazılım parçalarının birleştirilmesini niteler. Bu nedenle service-oriented architecture “servis odaklı mimari” şirket içerisinde service-oriented “servis odaklı” programlama yönteminin kullanılması ile tüm yazılım entegrasyonun oluşturulması amaçlayan bir stratejidir.
Servis nedir?
Servis en kısa şekliyle yazılım kümeleri veya bileşenleridir. Bu parçalar veya bileşenlerin en önemli özelliği ise diğer yazılım bileşenleri ile kolaylıkla bir araya gelebiliyor olmasıdır. Söz konusu birleştirme yani entegrasyon fikrinin arkasında ise servis odağı sunulacak teknoloji ile iş dünyasındaki kullanıcıların ERP veya CRM gibi zor yazılımlar kullanmaksızın yazılım bileşenlerinin kullanılmasını amaçlar.
Servislerin merkezindeki konsept ise ayıklamadır. Yani yazılım kodlarının küme içerisinde birleştirilebilecek ve şirketin farklı departmanlarında tekrar kullanılabilecek şekilde ayrılabilmesi SOA’nın temelini oluşturur. Örneğin kredi raporlama ile ilgili bir sistemin kullanıldığı web sayfasında birçok sorgulama gönderme gibi birçok otomatik işlem gerçekleştirilirken programlamacıların kullanılan sistemde kodları daha ileri düzeyde ayıklayarak paketlerin kontrol edilmesi ve değerlendirilmesiyle “kredi oranını al” gibi bir özelliği ekleyebilmesi temel bir SOA uygulamasıdır. Böyle bir entegrasyonla birlikte yeni bir uygulamanın oluşturulması sırasında aynı bilgi kodunun yazılması ihtiyaç duyulmadan daha hızlı ve sağlam bir geliştirme süreci elde edilebilmesi mümkün hale gelir.
Ayırma olayı geliştiricilerin kod kümelerinde karmaşık bir ayraç kullanmasıyla gerçekleştirilir. Ayraç ise toplu kodların birbirine nasıl bağlanacağını belirleyen bir ara yüzdür. Aslında bu konsept 1980’lerdeki object-oriented “nesne-odaklı” programlamanın ilk ortaya çıkışına dayanır. O zamanlar ile günümüzdeki tek fark şu anda söz konusu yazılım nesnelerinin daha büyük ve sofistik şekilde yapılabiliyor olması.
Örneğin bir Telekom şirketi olan Verizon, “get CSR (get customer service record)” adındaki servis ile Verizon’un dört farklı veri merkezinde bulunan 25’ten fazla sisteme bağlanarak karmaşık yazılım eylemlerini yerine getirmesinden oluşuyor. “get CSR” servisinde SOA çözümleri kullanılmadan önce Verizon geliştiricileri 25’ten fazla sistemi birbirine bağlayan veri köprüleri kullanıyorken; SOA ile birlikte “get CSR” servisi ile birlikte merkez pozisyonda bulunan hizmet sayesinde SOAP aracılığıt tek bir bağlantı kullanılıyor. SOA çözümleri kullanmadan önce bu tarz bir servis başarıya ulaşıyor olsa bile sık kullanılan bazı servisler arasında problem yaşanabilmesi ihtimali geliştiricileri tedirgin eden bir unsurken şu anda 25 sistem komutlarının her birinin tek bir merkezde toplanması ile daha kıvrak bir altyapının elde edilmesi sağlanmış durumda.
Servisleri birleştirmede özel programlama linkleri veya sağlayıcılardan edinilen entegrasyon yazılımları gibi bağlantı konusunda çok farklı yöntemler kullanılıyor olsa da 2001 yılından bu yana web servisleri olarak bilinen iletişim mekanizmalarındaki gelişmelerden dolayı internet üzerinden bağlantı yönteminin kullanılması yazılım bileşenlerinin birleştirilmesinde kullanılan en popüler araç olmaya başlamıştır.
SOA ve web servisleri arasındaki fark nedir?
SOA “architecture” söylemiyle bir şirket içerisinde yazılım oluşturmayla ilgili bir strateji olma özelliği; “service-oriented” söylemiyle ise belirli bir yazılım geliştirme yöntemi olma özelliğini kapsar. Web servisleri bu anlamda internet üzerinden iletişimi sağlayan standart iletişim mekanizmalarıdır. Web servisleri bağlantı ve iletişimle ilgili yöntemleri içerir. SOA ise tüm bir IT stratejisidir.
SOA’yı strateji olarak uygulamam gerektiğini nasıl bilebilirim?
Mimari stratejiden dolayı SOA yazılım oluşturmadan daha fazlasınız içerisinde barındırır. Mimari tabanlı servisler CIO’lara merkezi bir geliştirme yöntemi ve proje yöneticilerinin çalışanları ve geliştiriciler gibi kurumsal anlamda mimari konularla ilgili durumları ele almalarını gerektirir. Ayrıca SOA stratejisi ile birlikte CEO ve yöneticiler IT departmanının iş sürecinde şirketin merkezinde yer alması için bir takım kolaylıklar sağlamalıdır. Bu süreci anlamak ve kurumsal paylaşımlarla birlikte SOA stratejilerine geçiş yapmak bu konudaki en önemli adımlardır.
SOA stratejilerinde yönetim de ayrı bir öneme sahip. Şirket içerisinde tekrar kullanılacak servisler bağlantı oluştururken her servis bir kez oluşturulmalıdır. Farklı alanlarda aynı servisi farklı şekilde kullanmak için yeni bağlantılara ihtiyaç duyulmamalıdır. Bu anlamda veri merkezlerinin veya depolama birimlerinin kullanılması geliştiricilere servisler için nereye bakmaları gerektiği konusunda kolaylık sağlar. Bu sayede IT departmanının bağlantı oluşturma konusunda işi biraz daha kolaylaşır. Servislerin nerede kullanılacağı konusunda iyi tanımlamalar yapmak, bağlantılar ve kullanılacak kuralları iyi tanımlamak oldukça önemlidir. (Örneğin bazı şirketler servislerin kullanımının şirket ağına yükünü azaltmak ve servislerin kullanımından gerekli olduğunu garantilemek için ücret talep etmekte ve performans kuralları uygulamaktadır.)
Birçok şirket merkezi mimari grubu oluşturarak servislerin farklı alanlarda kullanımının aktifleştirileceği konusuyla ilgili olarak SOA stratejisinde ciddi adımlar atmakta. Oluşturulan merkezi topluluk yönetim için uygun bir mekanizmadır. Eğer tüm servis talepleri mimari grup üzerinden yapılırsa servis geliştirme yöntemleri, projeleri ve performans kuralları daha kolay yönetilebilir.
SOA stratejisi uygulamada en başarılı şirketlerin temel özellikleri: Teknoloji tabanlı yapıya sahip büyük bütçeleri bulunan büyük şirketler SOA stratejilerinin uygulanmasında başarıyı yakalıyorlar (telekom ve finansal servisleri). Destekçi, teknolojinin gücüne inanan yöneticilerin stratejiye destek olması da bir diğer önemli başarı etkeni. Bu özelliklere sahip olmayan şirketlerin SOA stratejilerinden umduğunu bulamaması ise oldukça yüksek bir ihtimal.
Daha küçük şirketler, entegre uygulamalarda iddialı olan şirketler ve hali hazırda entegre yazılımı bulunan şirket adına SOA stratejileriyle ilgili olarak “ne zaman”, “acaba” sorularının sorulmaması gerekiyor. CIO’lar SOA stratejisini oluştururken SOA’nın planında yer alan mimari parçalarının birbirinden ayrı olsa da bağımsız olmamasının farkında olmalıdır. Mimarinin ve şirketin kurumsal hedeflerinin hesaba katılmadan izole şekilde oluşturulmuş servisler potansiyel olarak yeniden kullanılabilme ihtimaline sahip olsa da (SOA’nın en büyük avantajlarından birisi) başarısız olma ihtimalinin de bulunduğu unutulmamalı.
SOA’nın avantajları nelerdir?
SOA’nın avantajlarını derinlemesine incelemek oldukça önemli. SOA dilimleri karmaşıklık ve fazlalık arasından seçilir. Eğer şirketiniz büyük veya karmaşık değilse (örneğin ikiden fazla entegrasyona ihtiyaç duyulan birincil servisiniz yoksa) SOA’nın sizin için avantajlı bir seçim olmadığını söyleyebiliriz. SOA ile ilgili reklamların arasında kaybolmadan bakıldığında geliştirme yöntemin aslınca ciddi bir yararı olmadığını söyleyebiliriz. SOA stratejileri karmaşık ve fazla altyapıya sahip sistemlerde belirli avantajlar sunabilir. SOA stratejisi konusunda çalışan yazılımcılar, strateji oluşturma sürecinin bilindik birden fazla yazılım entegrasyonundan daha fazla çalışma gerektirdiğini belirtiyor. (Anketler SOA’nın birçok şirkette entegrasyon amaçlı kullanıldığını gösteriyor) Bu nedenle SOA stratejilerinin geliştirilmesinde daha fazla bütçeye ihtiyacınız olabilir. Bu olaydan kazanç sağlamak için değerlendirmeler yapıldıktan sonra kullanılacak stratejinin tek başına yarar sağlayacağından emin olunması oldukça önemli. SOA’nin hangi durumda avantaj sağlayacağını düşünmeden önce hangi birimlerin karmaşık ve entegre edilemediği değerlendirilmeli; SOA’nın bu durumlara getireceği yararlar ele alınmalıdır.
SOA ile birlikte gelen avantajların genel bir resmine bakacak olursak, bunların iki gruba ayrıldığını söyleyebiliriz: Birincisi service-oriented geliştirme avantajları ve ikincisi SOA’nın tüm mimari strateji üzerine etkisi.
Benzer fonksiyonelliğe sahip yeni sistemler geliştiren şirketlerde bu yöntemi kullanabilirler. Örneğin çok farklı alanlarda faaliyet gösteren sigorta şirketi veya yeni kurulan şirketler yazılım fonksiyonelliğini ekleyerek gelişme, test ve entegrasyon işleminde zaman kazanabilir.
Ancak bu durumda yeniden kullanım gibi bir olay söz konusu olmaz. E-er şirketin diğer birimindeki geliştiriciler var olan servislerden haberdar değillerse veya oluşturulan sistemlere güvenmiyorlarsa geliştirme yöntemleri şirket çehresinde farklılık gösterebilir. Merkezi geliştirme ekipleri, tek bir geliştirme yöntemi ve servis depolamaları gibi yönetim mekanizmalarını tekrar tekrar kullanmak isteyen şirket ise tekrar kullanım konusundaki şansını arttırmış olur.
Ancak bazı durumlarda servisler düzenli şekilde tasarlanmamış olabilir. Bu durumda şirket içerisinde yeterli uygulamalar oluşturulmada başarısız olunabilir veya bu konuda çok fazla uğraş sarf edilmesi gerekebilir. Böyle durumlarda geliştiricilerin uygulamalarda farklı servisleri kullanmak için yeni yollar denemeleri gerekebilir. SOA uzmanları servislerin düzenli şekilde boyutlandırılmasının mimari kadar önemli olduğunu belirtiyor. Aksi takdirde oluşturulan servislerin tekrar kullanılma durumu söz konusu olmayabilir. Araştırma şirketi Gartner, bu konuda sadece servislerin yüzde 10’u ile yüzde 40’ının tekrar kullanılabildiğini belirtiyor.
Üretkenliğin artması
Geliştiricilerin servisleri tekrar kullanması yazılım projelerinin daha hızlı ilerlemesi ve geliştirme ekibinin daha fazla proje üzerinde çalışabilmesi anlamına gelir. Entegrasyon SOA ile birlikte daha kolay hale gelir (Gartner verilerine göre en az yüzde 30) ve daha hızlı gerçekleşir. Verizon’nun mimari ve servislerle ilgili önemli bir yöneticisi olan Shadman Zafar SOA ile birlikte servis kataloglarının şirketlerine proje ekibi üzerinde yeniden organizasyon yapmanın daha kolay hale geldiğini ve telefon üzerinden bile (phone-line process) geliştirmeleri yönetebildiklerini söylüyor. Point-to-point “noktadan noktaya” entegrasyon ile tüm entegrasyon üzerinde çalışabilen bir geliştirme ekibine sahip olduklarını belirten Zafar, tüm yerel ekiplerin entegrasyon için gerekli donanıma sahip olduğunu belirtti. Verizon’un phone-line process ile ilgili olarak tüm proje kontrolünden sorumlu end-to-end testini kullanan tek bir ekibi var. Verizon bu sayede şirketin kaynaklarını kullanarak yeni uygulamaları daha kaliteli şekilde gerçekleştirebiliyor. Uygulamaları test etme süreci uzun sürmediğinden dolayı mevcut uygulama geliştirme sürecine daha iyi yoğunlaşılabiliyor.
Artan beceri
Oluşturduğunuz servisler yeniden kullanılamasa bile IT sistemlerini daha kolay ve düzenli hale getirir. Örneğin ProFlowers.com’da herhangi bir entegrasyon yapılmamış olmasa da sipariş aşamasının daha kolay hale getirilmesi için SAO çözümü kullanılıyor. Konuyla ilgili olarak ProFlowers CIO’su Kevin Hall ProFlowers’ın tek şekilde ödeme işlemi olduğunu belirtiyor ve yüklü bir sipariş durumunda (örneğin sevgililer günü) tüm sistemin alt olabilmesi söz konusu olmaması için böyle bir çözüme başvurduklarını söylüyor.
ProFlowers’ın oluşturulan sisteminde sipariş oluşturulması sırasında sipariş ihtiyaçlarına bir sunucu tarlası cevap veriyor. Siparişe göre özel servislere ayrılmış saklama kapasitelerine göre işlemler gerçekleştiriliyor. Hall, sistemin 2002 yılından bu yana eklenen sunucularla her servis için ayrı bir yüklenme olmadığını belirtiyor. Bu sayede bir problem ortaya çıktığında pire için yorgan yakmaya gerek yok.
SOA stratejilerinin avantajları
Daha iyi kurumsal hizalama: SOA tüm iş sürecinin ve şirketteki akışının büyük bir resmidir. Bu sayede kurumda çalışan kişiler iş akışının teknolojik kurallar ile nasıl kontrol edildiğini gözlerinin önünde canlandırılabilirler. IT projeleri kurumsal aktiviteler veya karmaşık yazılım uygulamalar üzerine kurulduğunda çalışanlar IT projelerine daha olumlu katkıda bulunabilirler. Wisconsin CIO’su Matt Miszewski bu konuda daha önceleri 18 farklı şirkette 18 farklı “kredi kontrol” uygulamasının kullanıldığını belirterek, her şirketin farklı bir anlayışa sahip olduğunu vurguluyor. Birlikte IT departmanının sorunsuz SOA organizasyonu ile birlikte düzenleme, eşleme ve karıştırma eylemleri tek başına çok daha kolay hale geliyor. Ancak bu vizyon daha önceleri çok ileri bir vizyon olarak görülüyordu.
Mimariyi kurumsal ve IT’ye satmanın daha iyi yolu: Kurumsal mimari daha önceleri adından fazla söz edilen bir konsept değildi. Bazı CIO’lar bu terimi kullanmayarak iş ortaklarına korku vererek bu söylemi oldukça sıkıcı hale getirmişti. Kurumsal mimari her zaman için zor ve pahalı altyapı gerektiren ve ROI’lerin kurumsal anlamda şeffaf olmamasına neden olan bir kavramdı. Standartlaştırma, takip ve kontrol IT bütçelerininin yetersiz ve esnek olmaması bu kavramın arka planda kalmasına neden oldu. Sonuç olarak IT mimarisi her zaman için başarısız olma veya IT tabanlı olma yolunda adımlar attı. SOA ile birlikte eski kurumsal mimari söyleminin bulanıklığı giderilmeye başlandı. Tekrar kullanım geliştirilmiş üretkenlik ve IT departmanında artan beceri ile birlikte yazılım altyapısının özel kurumsal süreçler için yapılandırılmaya başlanması kurumsal mimarinin iş dünyasına yansıtmada etkili oldu. Ancak kurumsal mimarinin herkes için olmadığını bilmeniz gerekiyor. Küçük veya fazlasıyla dağınık yapıda olan şirketler projenin merkezi çalışanlarını, yöneticilerini, yazılım geliştiricilerini bir arada tutamayabilirler.
SOA çözümlerinde mimari planlamanın iş dünyasına hızlı bir değer katmasını nasıl sağlanabilir?
Mimari planlama vakit alan bir eylemdir. Servis odaklı geliştirme, iyi bilinen programlama prensipleri ve teknoloji standartları (SOAP, HTTP ve bunlara benzer) ile birlikte bu olay daha hızlı hale getirilebilir. Ancak uzmanlara göre bu olayların gerçekleşmesi sırasında iki şeye ihtiyaç var. American Electric Power (AEP) kurumsal mimari geliştirme yöneticisi Kurt Wissner bu iki olayın şunlar olduğunu söylüyor: Projeleri ihtiyaç duyulduğu şekilde oluşturmak ve ikinci aşamada uzun yıllar sürecek süreç takibi ve kurumsal seviyede servisler oluşturmak. Wissner SOA çözümlerinde kişilerin etkileri oldukça hızlı görmek istediklerini ancak bunun aksine SOA çözümlerine neden başvurduklarına dair somut bir söylem belirtmediklerine dikkat çekiyor.
Mimari plan ve servislerin tekrar uygulamalarda kullanım şansını arttırmak için oluşturulmaya başlanmadan önce gerçekleştirilen süreç takibi bu sürenin kısaltılmasına yardımcı olabilir. Mimari oluşturma sürecinin felakete dönüşme ihtimalinin dışında kısa bir dönüşümünün olacağını söylemek ise maalesef mümkün değil. Bu konuda tatsız bir tecrübe yaşayan Wissner daha önceki projesinde milyon dolaylık mimari planını daha önce yaptığı gibi gerçekleştirmeye çalıştığını ancak point-to-point entegrasyonuyla pek fazla katma değer yakalayamadığını söylüyor. Wissner’in de söylediği gibi tüm şirketi kapsayan bir çalışma ile yola çıkacak olursanız karşınıza çıkacak riskler oldukça fazla olduğunu bilmeniz gerekiyor.
AEP’deki gibi küçük topluluklarda şirket planlaması yaparak daha iyi sonuçlar elde edebilirsiniz. Küçük çaplı projelerinizde problemlerle karşılaşma ihtimaliniz olsa da bu problemleri düzeltmeniz tüm şirketi kapsayan projelere kıyasla daha kolay olacaktır. Wissner bu konuda küçük parçalara ayırarak yapılan çalışmalarda proje hazmının daha kolay olacağını söylüyor.
Hangi servisin yatırımıma en fazla değer katacağını nasıl bilebilirsiniz?
Bu konuda ikileme düşecek olursanız projelerinize gelirlerinizi direk etkileyecek ve kurumsal manadaki eksikliklerinizi gösterecek müşterilerin projeye dahil olduğu çözümlerden başlamanız yerinde olacaktır. 2006 yılında Business Performance Management Institute tarafından yapılan ankette müşteri ihtiyaçlarını karşılamanın ve müşteri tercihlerini değerlendirmenin yeni uygulamaların kurumsal süreç değişiminde en belirleyici etken olduğu sonucu ortaya çıktı. Müşteri tercihlerinden sonra değişim sürecinde belirleyici olacak diğer etkenler ise rekabet koşulları ve yeni kar odakları. Gartner yöneticierinden Daniel Sholler bu konuda genelde dış kaynaklı değişiklikler bir takıp değişimleri zorunlu hale getirdiğinden dolayı şirket içerisindeki değişimlerde daha fazla değer katıyor. Shooler, bu kaynaklarda yapılacak yüzde 10’luk değişimin diğer kaynaklarda yapılacak değişimlerin yüzde 50’lik kısmına denk geldiğini sözlerine ekliyor. Ancak SOA iyi bir paket uygulama halini almadıktan sonra şirket içerisindeki değişiklik anlamında bu kadar fazla değer katmayabilir.
SOA IT departmanınızı nasıl etkiler?
Eğer dağınık yapıda bir şirketseniz öncelikle toplanmak için hazırlanın. SOA merkezi bir yapı ile ilerleyebiliyor. Daha doğrusu SOA kurumsal anlamda başarıya ulaşması için merkezi bir yapı gerekiyor. Endüstriyel ve inşaat tedarikçi şirketi Fastenal’ın sistem mühendislerinden Mike Falls, mimari yapının kontrol edilmesi için birisinin dağınık yapıyı toplamasının şart olduğunu; kişisel ve küçük takımlar halinde çalışan şirketlerde bunun bir gereklilik olduğunu belirtiyor. Şirket içerisinde her takımın kendi halinde bırakılmasında ise oluşturulan servislerin farklı yollar kullanması söz konusu. Eğer bir gruba ihtiyacınız varsa geliştirme ekibinizin servis geliştirme yönteminde yetkin olduğundan emin olmanız şart.
Servis portföyünün genişlemesi ile birlikte geliştirme süreci fabrika gibi işeyecek ve farklı takımların birbiri ile iletişimi için farklı bir çaba harcamasına gerek kalmayacaktır. Servislerin genişlemesi sonucunda kurumsal olarak gerektiği gibi büyüyebilmek ve küçülebilmek mümkün hale gelecektir.
SOA fabrikasının büyümesi ile ilgili olarak proje yöneticilerinin, kurumsal analistlerin ve mimarların üretkenliğinin de artması söz konusu. ProFlowers’tan Hall uzun zamandır SOA çözümünü kullanan bir kurum adına “Şu anda başlangıçta altı geliştiricinin yaptığı işi sadece iki geliştirici kontrol edebiliyor” diyor. Hall, SOA çözümünün eksiksiz entegrasyonu sonucunda üç yıllık bir zaman içerisinde şimdikinden yüzde 50 daha fazla iş yapılabileceğini söylüyor.
Programlamacıların nesne odaklı programlamayı anlaması ve uygulamaları yaygınlaştırması ise olayın bir başka boyutu. Bu anlamda SOA’nın sorunsuz şekilde ilerlemesi için gereken eğitimlerin verilmesi konusunda ayrı bir yatırım süreci gerekiyor. CIO/Computerworld tarafından yapılan bir araştırmaya göre ise katılımcıların yüzde 25’i çalışanların SOA’ya ihtiyacının olduğunu; yüzde 49’unun SOA projeleri konusunda planlamalar yaptığını veya şu anda çalışanlarını hızlandırmak için eğitim programları gerçekleştirdiğini ortaya koydu.
Service-oriented geliştirmenin avantajları
Yazılımlarda stekrar kullanım
Eğer toplanmış kodlar doğru büyüklüklerdeyse ve kapsamı yeterliyse (SOA için bu çok önemli) geliştirme ekibinin ihtiyaçları doğrultusunda ve uygulamada istenilen fonksiyonlara göre topluluklar bir sonraki sefere kullanılabilir. Örneğin bir telekomünikasyon şirketi her biri sipariş gerektiren dört farklı alanda faaliyet gösteriyor olabilir. Bu sistemler kredi kontrolü, müşteri kaydı aramaları gibi benzer özelliklerle çalışıyorsa sistemler kendi arasında iyi bir entegrasyona uğrarsa fonksiyonlar paylaşılmaksınız istenilen eylemler gerçekleştirilebilir. Servis odaklı geliştirme ile “kredi kontrolü” sisteminin önemli kodları toplanarak diğer sistemlerde kullanılabilir. Servis uygulamanın yeni bir kümesi veya diğer sistemlerden yazılan kodları da içerebilir. Servisler için ayraçlar uygulanan ayraçlar karmaşık bir arayüz oluşmasını engelleme açısından önemlidir. Bir sonraki defada geliştiriciler kredi kontrolünün gerektiği bir uygulama oluşturacağı zaman oluşturulan uygulamaya küçük bir bağlantı yönlendirerek daha etkili biçimde çalışma şansına sahip olur. Özel sistemler oluşturma konusunda endişelenmek yerine kodların nereden geldiğiyle ilgili çalışmalar yürütülmesine yönlenir. Sonrasında yapılması gereken tek işlem ise bağlantı kullanmak.
Sponsorlu Bağlantılar
SOA birbirinden oldukça farklı iki şeyi tanımladığı için kafa karıştırıcı bir terim olduğunu söyleyebiliriz. SOA’nın ilk iki kelimesi (Service-Oriented) yazılım geliştirme yönteminin nasıl olduğunu; üçüncü kelimesi (architecture) ise bir şirketin tıpkı mimaride bina parçalarının birleştirilmesi gibi yazılım parçalarının birleştirilmesini niteler. Bu nedenle service-oriented architecture “servis odaklı mimari” şirket içerisinde service-oriented “servis odaklı” programlama yönteminin kullanılması ile tüm yazılım entegrasyonun oluşturulması amaçlayan bir stratejidir.
Servis nedir?
Servis en kısa şekliyle yazılım kümeleri veya bileşenleridir. Bu parçalar veya bileşenlerin en önemli özelliği ise diğer yazılım bileşenleri ile kolaylıkla bir araya gelebiliyor olmasıdır. Söz konusu birleştirme yani entegrasyon fikrinin arkasında ise servis odağı sunulacak teknoloji ile iş dünyasındaki kullanıcıların ERP veya CRM gibi zor yazılımlar kullanmaksızın yazılım bileşenlerinin kullanılmasını amaçlar.
Servislerin merkezindeki konsept ise ayıklamadır. Yani yazılım kodlarının küme içerisinde birleştirilebilecek ve şirketin farklı departmanlarında tekrar kullanılabilecek şekilde ayrılabilmesi SOA’nın temelini oluşturur. Örneğin kredi raporlama ile ilgili bir sistemin kullanıldığı web sayfasında birçok sorgulama gönderme gibi birçok otomatik işlem gerçekleştirilirken programlamacıların kullanılan sistemde kodları daha ileri düzeyde ayıklayarak paketlerin kontrol edilmesi ve değerlendirilmesiyle “kredi oranını al” gibi bir özelliği ekleyebilmesi temel bir SOA uygulamasıdır. Böyle bir entegrasyonla birlikte yeni bir uygulamanın oluşturulması sırasında aynı bilgi kodunun yazılması ihtiyaç duyulmadan daha hızlı ve sağlam bir geliştirme süreci elde edilebilmesi mümkün hale gelir.
Ayırma olayı geliştiricilerin kod kümelerinde karmaşık bir ayraç kullanmasıyla gerçekleştirilir. Ayraç ise toplu kodların birbirine nasıl bağlanacağını belirleyen bir ara yüzdür. Aslında bu konsept 1980’lerdeki object-oriented “nesne-odaklı” programlamanın ilk ortaya çıkışına dayanır. O zamanlar ile günümüzdeki tek fark şu anda söz konusu yazılım nesnelerinin daha büyük ve sofistik şekilde yapılabiliyor olması.
Örneğin bir Telekom şirketi olan Verizon, “get CSR (get customer service record)” adındaki servis ile Verizon’un dört farklı veri merkezinde bulunan 25’ten fazla sisteme bağlanarak karmaşık yazılım eylemlerini yerine getirmesinden oluşuyor. “get CSR” servisinde SOA çözümleri kullanılmadan önce Verizon geliştiricileri 25’ten fazla sistemi birbirine bağlayan veri köprüleri kullanıyorken; SOA ile birlikte “get CSR” servisi ile birlikte merkez pozisyonda bulunan hizmet sayesinde SOAP aracılığıt tek bir bağlantı kullanılıyor. SOA çözümleri kullanmadan önce bu tarz bir servis başarıya ulaşıyor olsa bile sık kullanılan bazı servisler arasında problem yaşanabilmesi ihtimali geliştiricileri tedirgin eden bir unsurken şu anda 25 sistem komutlarının her birinin tek bir merkezde toplanması ile daha kıvrak bir altyapının elde edilmesi sağlanmış durumda.
Servisleri birleştirmede özel programlama linkleri veya sağlayıcılardan edinilen entegrasyon yazılımları gibi bağlantı konusunda çok farklı yöntemler kullanılıyor olsa da 2001 yılından bu yana web servisleri olarak bilinen iletişim mekanizmalarındaki gelişmelerden dolayı internet üzerinden bağlantı yönteminin kullanılması yazılım bileşenlerinin birleştirilmesinde kullanılan en popüler araç olmaya başlamıştır.
SOA ve web servisleri arasındaki fark nedir?
SOA “architecture” söylemiyle bir şirket içerisinde yazılım oluşturmayla ilgili bir strateji olma özelliği; “service-oriented” söylemiyle ise belirli bir yazılım geliştirme yöntemi olma özelliğini kapsar. Web servisleri bu anlamda internet üzerinden iletişimi sağlayan standart iletişim mekanizmalarıdır. Web servisleri bağlantı ve iletişimle ilgili yöntemleri içerir. SOA ise tüm bir IT stratejisidir.
SOA’yı strateji olarak uygulamam gerektiğini nasıl bilebilirim?
Mimari stratejiden dolayı SOA yazılım oluşturmadan daha fazlasınız içerisinde barındırır. Mimari tabanlı servisler CIO’lara merkezi bir geliştirme yöntemi ve proje yöneticilerinin çalışanları ve geliştiriciler gibi kurumsal anlamda mimari konularla ilgili durumları ele almalarını gerektirir. Ayrıca SOA stratejisi ile birlikte CEO ve yöneticiler IT departmanının iş sürecinde şirketin merkezinde yer alması için bir takım kolaylıklar sağlamalıdır. Bu süreci anlamak ve kurumsal paylaşımlarla birlikte SOA stratejilerine geçiş yapmak bu konudaki en önemli adımlardır.
SOA stratejilerinde yönetim de ayrı bir öneme sahip. Şirket içerisinde tekrar kullanılacak servisler bağlantı oluştururken her servis bir kez oluşturulmalıdır. Farklı alanlarda aynı servisi farklı şekilde kullanmak için yeni bağlantılara ihtiyaç duyulmamalıdır. Bu anlamda veri merkezlerinin veya depolama birimlerinin kullanılması geliştiricilere servisler için nereye bakmaları gerektiği konusunda kolaylık sağlar. Bu sayede IT departmanının bağlantı oluşturma konusunda işi biraz daha kolaylaşır. Servislerin nerede kullanılacağı konusunda iyi tanımlamalar yapmak, bağlantılar ve kullanılacak kuralları iyi tanımlamak oldukça önemlidir. (Örneğin bazı şirketler servislerin kullanımının şirket ağına yükünü azaltmak ve servislerin kullanımından gerekli olduğunu garantilemek için ücret talep etmekte ve performans kuralları uygulamaktadır.)
Birçok şirket merkezi mimari grubu oluşturarak servislerin farklı alanlarda kullanımının aktifleştirileceği konusuyla ilgili olarak SOA stratejisinde ciddi adımlar atmakta. Oluşturulan merkezi topluluk yönetim için uygun bir mekanizmadır. Eğer tüm servis talepleri mimari grup üzerinden yapılırsa servis geliştirme yöntemleri, projeleri ve performans kuralları daha kolay yönetilebilir.
SOA stratejisi uygulamada en başarılı şirketlerin temel özellikleri: Teknoloji tabanlı yapıya sahip büyük bütçeleri bulunan büyük şirketler SOA stratejilerinin uygulanmasında başarıyı yakalıyorlar (telekom ve finansal servisleri). Destekçi, teknolojinin gücüne inanan yöneticilerin stratejiye destek olması da bir diğer önemli başarı etkeni. Bu özelliklere sahip olmayan şirketlerin SOA stratejilerinden umduğunu bulamaması ise oldukça yüksek bir ihtimal.
Daha küçük şirketler, entegre uygulamalarda iddialı olan şirketler ve hali hazırda entegre yazılımı bulunan şirket adına SOA stratejileriyle ilgili olarak “ne zaman”, “acaba” sorularının sorulmaması gerekiyor. CIO’lar SOA stratejisini oluştururken SOA’nın planında yer alan mimari parçalarının birbirinden ayrı olsa da bağımsız olmamasının farkında olmalıdır. Mimarinin ve şirketin kurumsal hedeflerinin hesaba katılmadan izole şekilde oluşturulmuş servisler potansiyel olarak yeniden kullanılabilme ihtimaline sahip olsa da (SOA’nın en büyük avantajlarından birisi) başarısız olma ihtimalinin de bulunduğu unutulmamalı.
SOA’nın avantajları nelerdir?
SOA’nın avantajlarını derinlemesine incelemek oldukça önemli. SOA dilimleri karmaşıklık ve fazlalık arasından seçilir. Eğer şirketiniz büyük veya karmaşık değilse (örneğin ikiden fazla entegrasyona ihtiyaç duyulan birincil servisiniz yoksa) SOA’nın sizin için avantajlı bir seçim olmadığını söyleyebiliriz. SOA ile ilgili reklamların arasında kaybolmadan bakıldığında geliştirme yöntemin aslınca ciddi bir yararı olmadığını söyleyebiliriz. SOA stratejileri karmaşık ve fazla altyapıya sahip sistemlerde belirli avantajlar sunabilir. SOA stratejisi konusunda çalışan yazılımcılar, strateji oluşturma sürecinin bilindik birden fazla yazılım entegrasyonundan daha fazla çalışma gerektirdiğini belirtiyor. (Anketler SOA’nın birçok şirkette entegrasyon amaçlı kullanıldığını gösteriyor) Bu nedenle SOA stratejilerinin geliştirilmesinde daha fazla bütçeye ihtiyacınız olabilir. Bu olaydan kazanç sağlamak için değerlendirmeler yapıldıktan sonra kullanılacak stratejinin tek başına yarar sağlayacağından emin olunması oldukça önemli. SOA’nin hangi durumda avantaj sağlayacağını düşünmeden önce hangi birimlerin karmaşık ve entegre edilemediği değerlendirilmeli; SOA’nın bu durumlara getireceği yararlar ele alınmalıdır.
SOA ile birlikte gelen avantajların genel bir resmine bakacak olursak, bunların iki gruba ayrıldığını söyleyebiliriz: Birincisi service-oriented geliştirme avantajları ve ikincisi SOA’nın tüm mimari strateji üzerine etkisi.
Benzer fonksiyonelliğe sahip yeni sistemler geliştiren şirketlerde bu yöntemi kullanabilirler. Örneğin çok farklı alanlarda faaliyet gösteren sigorta şirketi veya yeni kurulan şirketler yazılım fonksiyonelliğini ekleyerek gelişme, test ve entegrasyon işleminde zaman kazanabilir.
Ancak bu durumda yeniden kullanım gibi bir olay söz konusu olmaz. E-er şirketin diğer birimindeki geliştiriciler var olan servislerden haberdar değillerse veya oluşturulan sistemlere güvenmiyorlarsa geliştirme yöntemleri şirket çehresinde farklılık gösterebilir. Merkezi geliştirme ekipleri, tek bir geliştirme yöntemi ve servis depolamaları gibi yönetim mekanizmalarını tekrar tekrar kullanmak isteyen şirket ise tekrar kullanım konusundaki şansını arttırmış olur.
Ancak bazı durumlarda servisler düzenli şekilde tasarlanmamış olabilir. Bu durumda şirket içerisinde yeterli uygulamalar oluşturulmada başarısız olunabilir veya bu konuda çok fazla uğraş sarf edilmesi gerekebilir. Böyle durumlarda geliştiricilerin uygulamalarda farklı servisleri kullanmak için yeni yollar denemeleri gerekebilir. SOA uzmanları servislerin düzenli şekilde boyutlandırılmasının mimari kadar önemli olduğunu belirtiyor. Aksi takdirde oluşturulan servislerin tekrar kullanılma durumu söz konusu olmayabilir. Araştırma şirketi Gartner, bu konuda sadece servislerin yüzde 10’u ile yüzde 40’ının tekrar kullanılabildiğini belirtiyor.
Üretkenliğin artması
Geliştiricilerin servisleri tekrar kullanması yazılım projelerinin daha hızlı ilerlemesi ve geliştirme ekibinin daha fazla proje üzerinde çalışabilmesi anlamına gelir. Entegrasyon SOA ile birlikte daha kolay hale gelir (Gartner verilerine göre en az yüzde 30) ve daha hızlı gerçekleşir. Verizon’nun mimari ve servislerle ilgili önemli bir yöneticisi olan Shadman Zafar SOA ile birlikte servis kataloglarının şirketlerine proje ekibi üzerinde yeniden organizasyon yapmanın daha kolay hale geldiğini ve telefon üzerinden bile (phone-line process) geliştirmeleri yönetebildiklerini söylüyor. Point-to-point “noktadan noktaya” entegrasyon ile tüm entegrasyon üzerinde çalışabilen bir geliştirme ekibine sahip olduklarını belirten Zafar, tüm yerel ekiplerin entegrasyon için gerekli donanıma sahip olduğunu belirtti. Verizon’un phone-line process ile ilgili olarak tüm proje kontrolünden sorumlu end-to-end testini kullanan tek bir ekibi var. Verizon bu sayede şirketin kaynaklarını kullanarak yeni uygulamaları daha kaliteli şekilde gerçekleştirebiliyor. Uygulamaları test etme süreci uzun sürmediğinden dolayı mevcut uygulama geliştirme sürecine daha iyi yoğunlaşılabiliyor.
Artan beceri
Oluşturduğunuz servisler yeniden kullanılamasa bile IT sistemlerini daha kolay ve düzenli hale getirir. Örneğin ProFlowers.com’da herhangi bir entegrasyon yapılmamış olmasa da sipariş aşamasının daha kolay hale getirilmesi için SAO çözümü kullanılıyor. Konuyla ilgili olarak ProFlowers CIO’su Kevin Hall ProFlowers’ın tek şekilde ödeme işlemi olduğunu belirtiyor ve yüklü bir sipariş durumunda (örneğin sevgililer günü) tüm sistemin alt olabilmesi söz konusu olmaması için böyle bir çözüme başvurduklarını söylüyor.
ProFlowers’ın oluşturulan sisteminde sipariş oluşturulması sırasında sipariş ihtiyaçlarına bir sunucu tarlası cevap veriyor. Siparişe göre özel servislere ayrılmış saklama kapasitelerine göre işlemler gerçekleştiriliyor. Hall, sistemin 2002 yılından bu yana eklenen sunucularla her servis için ayrı bir yüklenme olmadığını belirtiyor. Bu sayede bir problem ortaya çıktığında pire için yorgan yakmaya gerek yok.
SOA stratejilerinin avantajları
Daha iyi kurumsal hizalama: SOA tüm iş sürecinin ve şirketteki akışının büyük bir resmidir. Bu sayede kurumda çalışan kişiler iş akışının teknolojik kurallar ile nasıl kontrol edildiğini gözlerinin önünde canlandırılabilirler. IT projeleri kurumsal aktiviteler veya karmaşık yazılım uygulamalar üzerine kurulduğunda çalışanlar IT projelerine daha olumlu katkıda bulunabilirler. Wisconsin CIO’su Matt Miszewski bu konuda daha önceleri 18 farklı şirkette 18 farklı “kredi kontrol” uygulamasının kullanıldığını belirterek, her şirketin farklı bir anlayışa sahip olduğunu vurguluyor. Birlikte IT departmanının sorunsuz SOA organizasyonu ile birlikte düzenleme, eşleme ve karıştırma eylemleri tek başına çok daha kolay hale geliyor. Ancak bu vizyon daha önceleri çok ileri bir vizyon olarak görülüyordu.
Mimariyi kurumsal ve IT’ye satmanın daha iyi yolu: Kurumsal mimari daha önceleri adından fazla söz edilen bir konsept değildi. Bazı CIO’lar bu terimi kullanmayarak iş ortaklarına korku vererek bu söylemi oldukça sıkıcı hale getirmişti. Kurumsal mimari her zaman için zor ve pahalı altyapı gerektiren ve ROI’lerin kurumsal anlamda şeffaf olmamasına neden olan bir kavramdı. Standartlaştırma, takip ve kontrol IT bütçelerininin yetersiz ve esnek olmaması bu kavramın arka planda kalmasına neden oldu. Sonuç olarak IT mimarisi her zaman için başarısız olma veya IT tabanlı olma yolunda adımlar attı. SOA ile birlikte eski kurumsal mimari söyleminin bulanıklığı giderilmeye başlandı. Tekrar kullanım geliştirilmiş üretkenlik ve IT departmanında artan beceri ile birlikte yazılım altyapısının özel kurumsal süreçler için yapılandırılmaya başlanması kurumsal mimarinin iş dünyasına yansıtmada etkili oldu. Ancak kurumsal mimarinin herkes için olmadığını bilmeniz gerekiyor. Küçük veya fazlasıyla dağınık yapıda olan şirketler projenin merkezi çalışanlarını, yöneticilerini, yazılım geliştiricilerini bir arada tutamayabilirler.
SOA çözümlerinde mimari planlamanın iş dünyasına hızlı bir değer katmasını nasıl sağlanabilir?
Mimari planlama vakit alan bir eylemdir. Servis odaklı geliştirme, iyi bilinen programlama prensipleri ve teknoloji standartları (SOAP, HTTP ve bunlara benzer) ile birlikte bu olay daha hızlı hale getirilebilir. Ancak uzmanlara göre bu olayların gerçekleşmesi sırasında iki şeye ihtiyaç var. American Electric Power (AEP) kurumsal mimari geliştirme yöneticisi Kurt Wissner bu iki olayın şunlar olduğunu söylüyor: Projeleri ihtiyaç duyulduğu şekilde oluşturmak ve ikinci aşamada uzun yıllar sürecek süreç takibi ve kurumsal seviyede servisler oluşturmak. Wissner SOA çözümlerinde kişilerin etkileri oldukça hızlı görmek istediklerini ancak bunun aksine SOA çözümlerine neden başvurduklarına dair somut bir söylem belirtmediklerine dikkat çekiyor.
Mimari plan ve servislerin tekrar uygulamalarda kullanım şansını arttırmak için oluşturulmaya başlanmadan önce gerçekleştirilen süreç takibi bu sürenin kısaltılmasına yardımcı olabilir. Mimari oluşturma sürecinin felakete dönüşme ihtimalinin dışında kısa bir dönüşümünün olacağını söylemek ise maalesef mümkün değil. Bu konuda tatsız bir tecrübe yaşayan Wissner daha önceki projesinde milyon dolaylık mimari planını daha önce yaptığı gibi gerçekleştirmeye çalıştığını ancak point-to-point entegrasyonuyla pek fazla katma değer yakalayamadığını söylüyor. Wissner’in de söylediği gibi tüm şirketi kapsayan bir çalışma ile yola çıkacak olursanız karşınıza çıkacak riskler oldukça fazla olduğunu bilmeniz gerekiyor.
AEP’deki gibi küçük topluluklarda şirket planlaması yaparak daha iyi sonuçlar elde edebilirsiniz. Küçük çaplı projelerinizde problemlerle karşılaşma ihtimaliniz olsa da bu problemleri düzeltmeniz tüm şirketi kapsayan projelere kıyasla daha kolay olacaktır. Wissner bu konuda küçük parçalara ayırarak yapılan çalışmalarda proje hazmının daha kolay olacağını söylüyor.
Hangi servisin yatırımıma en fazla değer katacağını nasıl bilebilirsiniz?
Bu konuda ikileme düşecek olursanız projelerinize gelirlerinizi direk etkileyecek ve kurumsal manadaki eksikliklerinizi gösterecek müşterilerin projeye dahil olduğu çözümlerden başlamanız yerinde olacaktır. 2006 yılında Business Performance Management Institute tarafından yapılan ankette müşteri ihtiyaçlarını karşılamanın ve müşteri tercihlerini değerlendirmenin yeni uygulamaların kurumsal süreç değişiminde en belirleyici etken olduğu sonucu ortaya çıktı. Müşteri tercihlerinden sonra değişim sürecinde belirleyici olacak diğer etkenler ise rekabet koşulları ve yeni kar odakları. Gartner yöneticierinden Daniel Sholler bu konuda genelde dış kaynaklı değişiklikler bir takıp değişimleri zorunlu hale getirdiğinden dolayı şirket içerisindeki değişimlerde daha fazla değer katıyor. Shooler, bu kaynaklarda yapılacak yüzde 10’luk değişimin diğer kaynaklarda yapılacak değişimlerin yüzde 50’lik kısmına denk geldiğini sözlerine ekliyor. Ancak SOA iyi bir paket uygulama halini almadıktan sonra şirket içerisindeki değişiklik anlamında bu kadar fazla değer katmayabilir.
SOA IT departmanınızı nasıl etkiler?
Eğer dağınık yapıda bir şirketseniz öncelikle toplanmak için hazırlanın. SOA merkezi bir yapı ile ilerleyebiliyor. Daha doğrusu SOA kurumsal anlamda başarıya ulaşması için merkezi bir yapı gerekiyor. Endüstriyel ve inşaat tedarikçi şirketi Fastenal’ın sistem mühendislerinden Mike Falls, mimari yapının kontrol edilmesi için birisinin dağınık yapıyı toplamasının şart olduğunu; kişisel ve küçük takımlar halinde çalışan şirketlerde bunun bir gereklilik olduğunu belirtiyor. Şirket içerisinde her takımın kendi halinde bırakılmasında ise oluşturulan servislerin farklı yollar kullanması söz konusu. Eğer bir gruba ihtiyacınız varsa geliştirme ekibinizin servis geliştirme yönteminde yetkin olduğundan emin olmanız şart.
Servis portföyünün genişlemesi ile birlikte geliştirme süreci fabrika gibi işeyecek ve farklı takımların birbiri ile iletişimi için farklı bir çaba harcamasına gerek kalmayacaktır. Servislerin genişlemesi sonucunda kurumsal olarak gerektiği gibi büyüyebilmek ve küçülebilmek mümkün hale gelecektir.
SOA fabrikasının büyümesi ile ilgili olarak proje yöneticilerinin, kurumsal analistlerin ve mimarların üretkenliğinin de artması söz konusu. ProFlowers’tan Hall uzun zamandır SOA çözümünü kullanan bir kurum adına “Şu anda başlangıçta altı geliştiricinin yaptığı işi sadece iki geliştirici kontrol edebiliyor” diyor. Hall, SOA çözümünün eksiksiz entegrasyonu sonucunda üç yıllık bir zaman içerisinde şimdikinden yüzde 50 daha fazla iş yapılabileceğini söylüyor.
Programlamacıların nesne odaklı programlamayı anlaması ve uygulamaları yaygınlaştırması ise olayın bir başka boyutu. Bu anlamda SOA’nın sorunsuz şekilde ilerlemesi için gereken eğitimlerin verilmesi konusunda ayrı bir yatırım süreci gerekiyor. CIO/Computerworld tarafından yapılan bir araştırmaya göre ise katılımcıların yüzde 25’i çalışanların SOA’ya ihtiyacının olduğunu; yüzde 49’unun SOA projeleri konusunda planlamalar yaptığını veya şu anda çalışanlarını hızlandırmak için eğitim programları gerçekleştirdiğini ortaya koydu.
Service-oriented geliştirmenin avantajları
Yazılımlarda stekrar kullanım
Eğer toplanmış kodlar doğru büyüklüklerdeyse ve kapsamı yeterliyse (SOA için bu çok önemli) geliştirme ekibinin ihtiyaçları doğrultusunda ve uygulamada istenilen fonksiyonlara göre topluluklar bir sonraki sefere kullanılabilir. Örneğin bir telekomünikasyon şirketi her biri sipariş gerektiren dört farklı alanda faaliyet gösteriyor olabilir. Bu sistemler kredi kontrolü, müşteri kaydı aramaları gibi benzer özelliklerle çalışıyorsa sistemler kendi arasında iyi bir entegrasyona uğrarsa fonksiyonlar paylaşılmaksınız istenilen eylemler gerçekleştirilebilir. Servis odaklı geliştirme ile “kredi kontrolü” sisteminin önemli kodları toplanarak diğer sistemlerde kullanılabilir. Servis uygulamanın yeni bir kümesi veya diğer sistemlerden yazılan kodları da içerebilir. Servisler için ayraçlar uygulanan ayraçlar karmaşık bir arayüz oluşmasını engelleme açısından önemlidir. Bir sonraki defada geliştiriciler kredi kontrolünün gerektiği bir uygulama oluşturacağı zaman oluşturulan uygulamaya küçük bir bağlantı yönlendirerek daha etkili biçimde çalışma şansına sahip olur. Özel sistemler oluşturma konusunda endişelenmek yerine kodların nereden geldiğiyle ilgili çalışmalar yürütülmesine yönlenir. Sonrasında yapılması gereken tek işlem ise bağlantı kullanmak.
Tanrı varsa eğer, ruhumu kutsasın... Ruhum varsa eğer!
