Günümüzde Türkçe’ye ‘Hizmet Odaklı Mimari’ diyerek tercüme edebileceğimiz SOA, ve ‘Kurumsal Hizmet Yolu’ diyerek tercüme edeceğimiz ESB kavramları kurumsal yazılım mimarları arasında sıkça kullanılan terimlerdir. Güncel bilgi kaynakları, dergiler, internet siteleri yada büyük firmaların stratejilerini takip ettiğimiz zaman hep bu iki konunun üzerine yoğunlaşıldığını gözlemleriz. Bu yazıda esasında kompleks olmayan bu konuları öz bir şekilde sunarak okuyuculara temel bilgi kazandırmayı amaçlıyoruz.
Her ne kadar bu terimler pek çok kişiye tanıdık gelecek kavramlar içerse de, bu kavramlar, ilk defa toplu bir halde bu SOA ve ESB terimleri sayesinde genel bir çerçevenin içinde kabul görmüş ve uygulama şansı doğmuştur. Onun için yazıyı okurken kavramların bir bütün içerisinde ne anlama geldiğine dikkat ediniz.
ESB, SOA tipi mimariyi kurum içinde mümkün kılmayı amaçlayan bir ürün yada ürünler topluluğudur. Amacımıza hizmet etmesi için öncelikle SOA kavramı üzerinde duracağız ve bu kavramın ne demek olduğunu anlayacağız. Buradan da ESB’nin nasıl bir ürün tipi olması gerektiğini anlayacağız.
SOA (Service Oriented Architecture)
Hizmet Odaklı Mimari hakkında pek çok tanımlama olsa da aralarından en çok BEA’nın yaptığı açıklamayı beğeniyorum. Buna göre SOA, bir bilgi işlem stratejisi olup, kurumsal yazılımlar içindeki farklı fonksiyonları karşılıklı çalışabilecek, standartlara dayanan, iş ihtiyaçlarını karşılamak üzere kolaylıkla tekrar kullanılabilen ve birleştirilebilen hizmetler haline sokmaktır.
Yukarıdaki tanımda görüldüğü gibi hizmetler, aslında mevcutta var olan fonksiyonların yada yeni oluşturulan fonksiyonların, belli prensipler göz önünde bulundurularak hizmet halinde sunulmasıdır. Bu kısa sürede gerçekleştirilebilecek bir hedef olamayacağından bir kurum ancak bunu stratejik olarak tasarlayıp, bu stratejiye ulaştıracak olan yol haritasını takip ederek zamanla hayata geçirebilir.
Peki SOA’in amacı nedir? SOA uzun vadede uygulamalar arasındaki entegrasyon maliyetlerini gerek hizmetleri tekrar tekrar kullanarak, gerek standartları benimseyip uygulamalar arasında karşılıklı çalışabilirliği artırarak düşürmeyi; ayrıca gerektiğinde hizmetleri lego taşları gibi kullanarak iş süreçleri oluşturmayı ve böylelikle iş ihtiyaçlarını daha hızlı gerçekleştirebilmeyi amaçlar.
Teknik açıdan hizmetlere baktığımızda, bir fonksiyon ancak aşağıdaki prensiplere uygunsa hizmet olarak kabul edilebilir.
- Standartlara dayanan (Industry Standards-Based):
Hizmetler mevcutta tanımlanmış olan standartlara uygun şekilde uygulanmalılar. Internet’te standartların önemini USB’ye benzetme yaparak anlatan bir sayfa vardı. Buna göre USB’den önce her donanımın kendine göre bir ara yüzü vardı ve siz o donanımı kullanabilmek için hep adaptörler almak zorundaydınız. Halbuki USB’nin bir standart olarak belirmesiyle beraber, üreticiler ürünlerini USB’ye uyumlu üretmeye basladi.
Böylelikle kullanıcılar için bir donanımı alıp onu hemen kullanmaya başlamak mümkün oldu. Yazılım dünyasının da SOA ile yakından ilişkili web services standartlarını benimsemesiyle beraber, uygulamalar daha rahat birlikte çalışabilir hale gelecektir.
- Karşılıklı çalışabilirlik (interoperability):
Farklı fonksiyonları kolay ve masrafsız bir şekilde entegre etmek SOA’nin amacıdır. Bu hizmetler arasında yukarıda bahsedildiği gibi standartlardan güç alan bir teknolojik uyumluluk gerektirdiği gibi, hizmetlerin birbirlerini nasıl kullanacağını bilmesini de gerektirir. Bir hizmet, kendisinin nasıl, hangi şartlar altında kullanılabileceğini Standartlara uygun şekilde belirtmelidir. Kısaca bir hizmet kendisini tarif etmeli ve bunu bir nevi diğer hizmetlere kontrat olarak sunabilmelidir ki başka hizmet yada sistemler bu hizmeti kullanabilsin.
- Bağımsız çalışabilme (Autonomous):
Bir Hizmet başka bir hizmetten bağımsız ve etkilenmeden çalışabilmelidir. Yani bir hizmeti kullanabilmek için başka bir hizmetin orada hazır olmasına gerek olmamalıdır.
- Tekrar kullanılabilirlik (Reusability):
Hatırlanacağı üzere SOA� nin ana amaçlarından bir tanesi hizmetleri tekrar tekrar kullanarak kurum kaynaklarını en verimli şekilde kullanabilmekti. Bunun için tasarlanan hizmetler tekrar kullanıma uygun olmalılar.
Yalnız, bu beraberinde SOA� yi tasarlarken karar verilmesi gereken bir soruyu da ortaya çıkarır. Acaba hizmetler ne kadar kapsamlı tanımlanmalı? Mesela bir hizmet kendi içinde çok parçalara ayrılıp küçük parçacıklı hizmetler olarak mi tanımlanmalı yoksa başka hizmetlerle birleştirilip tek bir hizmet olarak mi kullanıma sunulmalı? Cevap aslında, hizmetleri optimum büyüklükteki parçalar olarak tanımlamaktır. Optimumu bulmak için, duruma göre değerlendirme yapmak gerektiği gibi erkenden metodoloji belirlenmesi tavsiye edilir.
- İş süreci odaklı olmak:
Hizmetler tanımlanırken dikkat edilmesi gereken hususlardan bir tanesi de, hizmetlerin daha bastan bir iş sürecine dahil olabilecek şekilde tanımlanması gerekliliğidir. Bunun mümkün olması ise ancak iş süreçlerini yakından bilen uzmanların daha önce başka tür IT projelerinde görülmemiş olabileceği kadar sıkı bir şekilde tanımlama ve hizmet geliştirme sürecine dahil edilmeleridir. Görüldüğü gibi SOA�in geliştirilme süreci, öbür tür yazılım ve mimari geliştirme süreçlerinden farklı olarak, pek çok farklı departmanı ve uzmanı kapsayabilir. Bu yüzden SOA geliştirme kendi içinde bir konu olabileceğinden bunu başka bir yazıya bıraktık.
Hizmetlerin kendi içlerindeki özelliklere ek olarak, doğru bir hizmet odaklı mimarinin uzaktan bakıldığında şu özelliklere sahip olduğunu görüyoruz.
- Gevşek bağlanma (loose-coupling):
Buna göre hizmetler kendisini kullanan hizmetlere hissettirilmeden yer, teknoloji değiştirebilmeli.
- Hizmet yönetimi ve Hizmet seviyesi anlaşmaları (SLA):
Hizmet seviyesi bir hizmetin hizmet sunma performansını belirleyen bir nevi taahhüttür. Mesela bir hizmet bir işlemi en fazla 10 saniye içinde bitirmeyi yada yılın %99,99�unda hizmet vermeye hazır bulunmayı taahhüt edebilir. Şart olmamakla beraber, Hizmet odaklı mimari bu bilgileri toplayabilmeli ve bunu SLA�lere uyulup uyulmadığını anlayabilmek için kullanabilmelidir.
- Genel en iyi uygulamalar:
Her iyi mimaride olan iyi özellikler SOA� de de olmalı. Mesela SOA içindeki parçalar; ölçeklenebilir, olabilecek hataları kendi içinde çözebilen, sağlam ve güvenilir, kolayca idare edilebilir olmalıdır.
Şu ana kadar SOA�in ne olduğunu gördük. Bir sonraki başlıkta ESB�lerin SOA ile olan ilişkisini göreceğiz. Bunun için ikinci bölümü tıklayınız.
Kaynak : 