Php & Resources

Service Oriented Architecture & Web Servisleri -1

Bu makale, service oriented architecture kavramını teorik düzeyde ele almakta ve web servislerinin söz konusu yapı içerisindeki yerini incelemektedir.

• Katmanlar veya uygulamalar arası iletişim, internet standart’ları ile uyumlu olmalıdır.
• Servis bileşenlerine ilişkin arayüzler genel kullanıma açık olacak şekilde yayınlanmalı, ayrıca arayüz tanımları ve dokümantasyon’lar genel kullanım için erişilebilir olmalıdır.
• Yazılım kaynaklarının entegrasyonu noktasında, kaynaklar gevşek bağlantılı (loosely coupled) tasarlanmalıdır.
  

  Açıklama : Dağıtık olmayan (monolitik) tasarımlarda, şayet gerekli bir kaynak (sözgelimi bir dll) uygulama çalıştığında elde edilebilir durumda ise, uygulamanın yaşam döngüsü boyunca da öyle kalmaya devam edebilecektir. Oysa dağıtık tasarımların (özellikle internet uygulamalarının) doğası gereği, bunun sağlanamama riski son derece yüksektir. Dolayısı ile web servislerine dayalı bir çözümde, bu noktada çok daha esnek davranılmalıdır. Bunun anlamı, loosely coupled (gevşek bağlantılı) bir mekanizma sayesinde, ilgili kaynağın bulunamaması durumunda uygulamanın bu yeni duruma kendisini adapte edebilmesidir.

Bu beklentileri karşılayabilen uygulamalar sayesinde :

• Yeniden kullanılabilir 3. parti yazılım bileşenleri ile maliyet düşümü ve üretkenlik artışı adına ciddi kazanımlar elde edilebilir.
• Yazılım firmaları ürünlerinin belli görevleri üstlenmiş olan kısımlarını servisler şeklinde pazarlayabilir.
• Daha granüler kaynaklar yaratılabilir.
• Çekirdek iş süreçlerini proses eden uygulamalar ile dışsal servisler kolayca entegre edilebilir.

Service Oriented Architecture, dağıtık uygulamaların implementasyonu için ideal mimaridir. Bugün pek çok iş uygulaması aşırı bağımlı alt sistemlerden oluşmaktadır. Bu durum, alt sistemlerden birinde yapılacak bir değişikliğin uygulamanın tümünü olumsuz etkilemesine neden olmaktadır. Bu kırılgan yapı, bakım maliyetlerinin yüksek olmasındaki birincil sebebtir. Ayrıca bu durum, değişen iş gereksinimlerinin karşılanmasını ve ileride yapılması muhtemel modifikasyon’ları zorlaştırır.

Service Oriented Architecture Modeline İlişkin Temel Unsurlar

Service Oriented Architecture modeli, şu üç ana unsurdan oluşur :

1) Service Provider : Ağ (internet/intranet) üzerindeki bir servisin arayüzüne erişimi sağlamakla görevli düğümdür. Bu düğüm, web servislerinde servise ilişkin işlemlerin implemente edildiği .asmx uzantılı dosyalar ile somutlaşır.

2) Service Consumer : Kendi iş çözümünü implemente etmek üzere, service provider’ı kullanan düğümdür. SOA modeli bağlamında consumer’lar, bir uygulama değil, daha çok yine ağ üzerindeki bir düğüm biçiminde isimlendirilmektedir. Ancak SOA modeli üzerine, web servisleri projekte edildiğinde, consumer’lara da -web servisini kullanan istemci uygulamalar- gözü ile bakılabilir. Bu uygulamalar, web servisleri ile SOAP ve HTTP üzerinden iletişim sağlayabiliyor olmaları ile karakterizedir.

3) Service Broker : Global ağ üzerindeki servislere ilişkin tanımları sunan ve servislerin ağ üzerindeki lokasyonlarının bulunmasında kullanılan, bir tür adres defteridir. Consumer’lar, broker’ı sorgulayarak, kendilerine gereken service provider’ı ya da servisi bulurlar. Web servislerine dayalı bir model içerisinde UDDI (Universal Description Discovery Integration), service broker görevini üstlenmektedir.

Bu Unsurlar Arasındaki Etkileşimler

Service Oriented Architecture modeline ilişkin yukarıda sayılan unsurlar arasında, üç farklı etkileşimden söz etmek mümkündür :

1) Servislerin Yayınlanması : Provider’lar, servislerini bir servis broker’ında yayınlarlar. Yayınlanan bilgiye, servis arayüz tanımı, servisin lokasyon bilgisi, yanı sıra diğer olası yardımcı bilgi ve dokümantasyonlar dahildir. Bu yayınlama işlemi, servise ilişkin bazı kimlik bilgilerinin broker’a tanımlanması hatta broker üzerine kaydedilmesi biçiminde düşünülebilir.

2) Servislerin Bulunması : Consumer’lar, broker’ı kullanarak aradıkları servisleri bulurlar.

3) Servislerin Kullanımı (binding)

Gerek servislerin bulunuşu gerekse de kullanımları (binding), uygulamaların kendilerini dinamik olarak konfigüre edebilmelerine imkan verecek şekilde ve yine dinamik olarak gerçekleştirilebilir. Sözgelimi bir uygulama, servis provider’a belirli bir süre içerisinde bağlanamazsa, çalışma zamanında başka bir servis provider’e geçiş kararını otomatik olarak verebilir.