Servis Odaklı Yazılım Mühendisliği

Bu sunumda Service Oriented Architecture (SOA) tarihçesi, özellikleri, SOA yaşam döngüsü, SOA'nın avantaj ve yararlarına, SOA ile ilgili standartlar'a (UDDI, WSDL, SOAP, WS-BPEL), Semantik Web Servisleri, Service Oriented Software Engineering gibi konulara yer verilmektedir.

Bunların yanı sıra SOSE ile Klasik Yazılım Mühendisliği'nin karşılaştırılması, SOSE süreçleri, Service Testing, SOA olgunluk modelleri ve bu konularla ilgili akademik çalışmalar ile ilgili bilgiler bulunabilir.

Transcript

2. • Giriş • Service Oriented Architecture (SOA) – Tarihçe – Özellikleri – Yaşam Döngüsü – Avantajlar & Yararlar – SOA ile ilgili standartlar (UDDI, WSDL, SOAP, WS-BPEL) – Semantik Web Servisleri • Service Oriented Software Engineering – SOSE vs. Klasik Yazılım Mühendisliği – SOSE süreçleri – Service Testing – SOA olgunluk modelleri • Konuyla İlgili Akademik Faaliyetler • SOA ve Bulut • Kapanış
3. • Bilişim sektöründe teknolojiler hızla gelişmektedir. • Dağıtık sistemlerin gelişmesiyle ortaya SOA (Service Oriented Architecture) mimarisi çıkmıştır. • SOA mimarisinde iş akışını oluşturan küçük iş parçaları servis olarak adlandırılır. • Servisler farklı sunucular üzerinde bulunabilir. • Servisler birbirlerine bağlanarak hedeflenen uygulamalar oluşturulur. • Kod yeniden kullanılabilirliği artar ve esnek bir yapı kurulmuş olur. • Service Oriented Software Engineering, SOA sistemleri ve uygulamalarının tanımlanma ve bunu izleyen adımların tüm mühendislik aşamalarıyla ilgilenmektedir.
4. • SOA, uygulama katmanlarını farklı servislere bölüp, sunucular üzerinden kullanmaya imkan sağlayan bir mimaridir.
5. • Servis – Yinelenen iş adımları – Günlük işlerde teknoloji bağımlılığının olabildiğince azaltılması – Bir bankada müşteri sorgulama işlemi (Çok kullanılan küçük bir işlem) • Servis Odaklı – İş uygulamalarının küçük iş servisleri biraraya getirilerek oluşturulması – Teknoloji değil iş mantığı
6. • Servis Odaklı Mimari – Servis odaklı iş mantığının gerçeğe uygulanmasını sağlayan bilgi teknolojileri mimarisi – İş servislerini gerektiği gibi kullanarak uygulama geliştirme “SOA, iş fonksiyonlarının birlikte çalışmayı destekleyecek esneklikte, tekrar kullanılabilir şekilde, iyi tanımlanmış ve gevşek bağlı bileşenler halinde oluşturulduğu sistemdir.”
7. • 80li yıllarda fonksiyonel programlamadan nesne yöneli tabanlı programlamaya geçildi. • Daha sonra yazılımcılar, OOP’ nin en önemli problemlerinden biri olan yeniden kullanılabilir kod parçaları yazma sorununu, bileşen tabalı mimari(component based architecture) ile çözmeyi başardı. • Bunun sonunda dağıtık bileşen mimarileri doğdu. Bu sayede kod yine bir kere yazıldı fakat kod bir çok ayrı yere değil bir tek yere kondu. Diğer uygulamalar, yazılan bu bileşen parçacığını kullanabilir oldu. • Bu uygulama sunucusunun (application server) icat olmasına sebep oldu. Yazılan birleşenler aynı platformlar üzerinde olduğu sürece sorunsuz çalışıyordu fakat, farklı platformlarda çalışan yazılımlar sorunlara yol açıyordu. • Bu sayede servis odaklı mimari oluştu
8. • Business açısından bakılınca; – İş süreçleri ve ihtiyaçların sürekli değişime uğraması – İş süreçleri değişince programların değişmesi gerekmesi (Zaman ve maliyet kaybı yaratıyor) – Değişimlere kolay uyum sağlayan esnek mimari gereksinimi
9. • ESNEKLİK – İş fonksiyonlarının küçük servisler halinde geliştirilmesi büyük esneklik sağlamaktadır. – Böylece istenen değişiklikler kolayca gerçekleştirilebilir. • YENİDEN KULLANILABİLİRLİK – Bu küçük servisler istenen uygulamadan çağırabildiği için yeniden kullanılabilirlik de üst düzeylere çıkmaktadır.
10. • İYİ TANIMLAMA – Her servisin iyi tanımlanmış standart arayüzü vardır. – Bu arayüz sayesinde servisin ne içerdiği, nasıl kullanılacağı kolayca anlaşılabilir. – Arayüzler belli bir standarta sahip olduğundan bütün platform ve sistemler tarafından kullanılabilirler. (örn: wsdl) • GEVŞEK BAĞLILIK – Servisler iş akışı içerisinde zayıf bağlarla birbirlerine bağlanırlar. – Bunun sebebi ise gerektiğinde servislerin birbirlerinden ayrılıp başka yapılarla birleştirilmesinin kolay hale getirilmesidir.
11. • SOA Yaşam Döngüsü kavramı, SOA mimarisini temel alan uygulamalar için tanımlı 4 ana parçadan oluşmaktadır. Bu parçalar: – Modelleme – Bileştirme – Devreye alma – Yönetme’ dir.
12. • MODELLEME – Bu evrede gereksinimler belirlenerek, hedefteki iş süreci ve süreci oluşturacak parçalar modellenir. – Uygunluğu ise simüle edilerek ölçülür. – Bu evrede analistler etkin rol oynamaktadır. – Analistler gerekli teknik bilgiye sahip, işin aşamalarını çok iyi bilen kişiler olmalıdır.
13. • BİRLEŞTİRME – Bu evrede üretilen modeller ortak bir format kullanılarak yazılım grubuna aktarılır. – Yazılım grubu, bu modelleri hayata geçirecek kodları yazarak servisleri oluştururlar. – Yazılımcılar etkin rol aldıkları evredir. • DEVREYE ALMA – Birleştirme aşaması bitiminde elde edilen aktif servisler ve süreçler çalışıtırılır ve kullanıcı deneyimine sunulur.
14. • YÖNETİM – Devreye alınan uygulama çeşitli parametreler ele alınarak izlenip, değerlendirilir. – Eğer olumsuz bir durum söz konusuysa toplanan sonuç verileri bir sonraki çevrim için dikkate alınacak maddeleri oluşturur. – Bu maddeler ışığında modellemede değişiklik yapılabilir veya yeni bir çevrim başlatılabilir. – Bu aşamada analistler ve yazılımcılar birlikte çalışırlar.
15. • SOA yapı itibariyle diğer sistemlerle kıyaslandığında, servis sağlayıcı için en güvenli yapıdır. • Yapı itibariyle dağıtık olduğundan ölçeklenebilir yazılımlar elde edilebilir. • Sürekliliği ve mantık katmanını büyük ölçüde servis sağlayıcıya bırakır. Böylelikle geliştirici için uygulama tek katmana indirgenmiş olur. • Servis ve uygulama katmanı genellikle farklı sunucularda yer alır. Böylece bağımlılık azaltılmış olur. • SOA mimarisine sahip uygulamalar aynı katmanları aynı servis üzerinden kullanabilir. Serviste bir değişiklik ihtiyacı doğduğunda istemci uygulamalarda hiç değişiklik yapmaksızın tek bir servis üzerinde değişiklikler yapılarak güncelleme tamamlanmış olur. Böylece bakım ve onarım maliyetleri düşer.
16. • Bir masaüstü uygulaması geliştirileceğinde, istemci tarafında sadece arayüze ihtiyaç duyulacağından, geliştirme işlemi soyutlaşmaktadır. • Farklı platformlarda çalışan uygulamalarda bile aynı altyapı kullanılabilir. • Uygulamanın farklı katmanları farklı sunucular üzerinde yer alabilir. Böylece uygulamanın performansı artarken, yönetim maliyeti de azalmış olur. • Hazırlanan servis veya uygulama için API oluşturularak, başka uygulamalar tarafından kullanılmasını sağlanabilir. Böylece entegrasyon kolaylaştırılmış olur. • Bulut teknolojisini kullanan uygulamalar gerçekleştirilebilir. • Uygulama için oluşturulan servisler başka uygulamalarda da çok kolay şekilde kulanılabildiğinden yeniden kullanılabilirlik arttırılmış olur.
17. • SOA’nın esnek yapı özelliği sayesinde değişen iş ihtiyaçlarına çok daha hızlı şekilde yanıt verilebilir. • Arttırımlı geliştirmeyi benimsediğinden bir sorun halinde geri dönüş hızlı olduğundan risk azaltılmış olur. • İş süreçlerini iyileştirerek işbirliğini arttırır.
18. • SOAP • BPEL • UDDI • WSDL
19. • 1998 yılında tasarlandı. • İletişim altyapısı • Giden ve gelen verinin gönderildiği standart «paket» • XML / HTTP • SOAP’ta mesajın göndereni, alıcısı ve ara işleyicileri bulunur. • Uzaktaki server’larda bulunan nesne,fonksiyon, prosedür gibi yordamlara ulaşmayı ve bunları platform bağımsız çalıştırmayı sağlayan bir protokoldür. + Basit + Firewall dostu + Başka standartlar üzerine kurulu - Metin temelli olmayan verilerin gönderilmesi güç - Stateless - Referans ile veri gönderme yok
21. • 2000 yılında geliştirildi. • Interface • Bir servisin alacağı ve göndereceği mesajların hangi verilerden ve veri tiplerinden oluştuğunu anlatır. • Örnek: https://tckimlik.nvi.gov.tr/Service/KPS Public.asmx?WSDL
22. • 2000 yılında ‘Organization for the Advancement of Structured Information Standards’ (OASIS) tasarlandı • Servis dizini • Telefon rehberi gibi düşünülebilir • Üç temel parçadan oluşuyor – Beyaz sayfalar «servisi sunan firma ile ilgili bilgiler» – Sarı sayfalar «uluslararası bir standarda göre taksonomi» – Yeşil sayfalar «servisin nasıl kullanılacağına ilişkin teknik bilgiler»
24. • Kurumlarda servislerin belirli bir sıra ve düzen ile çalışmasını yönetmek için kullanılan standart dildir. • Orchestration vs. Choreography • BPEL  Orchestration
26. http://www.ubenzer.com/web-servisleri-proje-1/
27. • Dünya başımıza yıkılmaz. • Standartlar olmadan da web servisleri yazılabilir. • Dışarıya kendimizce bir yapıda hazırladığımız servisler açabiliriz. - Ciddi bir dokümantasyon gerekli - Servisi kullanacakların hepsinin sistemi öğrenmesi gerek - Kullanıcılar için implementasyon maliyeti
28. • Web servislerini tanımlayan standartlar servisin nasıl çağrılacağını, servisin hangi operasyonları sağladığını tanımlar. «Nasıl» • Syntactic Level • Semantik web servisleri, servisin ne yaptığını veya bir işlevsellik için servisin operasyonlarının hangi sırada çağrılacağını da tanımlar. «Ne» • Semantic Level • Klasik Web Servislerinde UDDI servisin keşfini sağlamayı amaçlar.  Yetersiz. • Semantik web servislerinde keşifleri etmenler yapar. (The Semantic Web - Scientific American) • Semantik web servisleri ile ilgili OWL-S (Web Ontology Language for Services), WSMO (Web Services Modeling Ontology), SWSF (Semantic Web Services Framework) gibi teknolojiler bulunmaktadır.
29. • Nedir? – SOA sistemleri ve uygulamalarını tanımlama, modelleme, geliştirme ve doğrulama ile ilgilenmekte ve ayrıca servis odaklı sistemlerin gereksinim, modelleme, tanımlamalar, doğrulama ve onaylama, tasarım, mimari, geliştirim, test, işletim, bakım, izleme ve kontrol, güvenlik, güvenilirlik, performans ve uyarlanabilirlik gibi tüm mühendislik aşamaları ile uğraşmaktadır. – SOSE sadece yazılımla ilgili değildir. SOA tüm sistem geliştirim sürecini değiştirmiştir.
30. • SOSE toplulukları, klasik yazılım mühendisliği tekniklerinin, metodlarının doğrudan SOSE’ye uygulanamayacağına karar vermiştir. – Tasarım kararları genellikle sürekli değişen ihtiyaçlara uyum sağlama amacıyla runtime esnasına ertelenir – Servis kullanıcılarının birçok sorumluluğu, servis sağlayıcısına geçirilmiştir, çünkü servisler fiziksel olarak servis sağlayıcısında bulunmaktadır. Buna rağmen, servis kullanıcıları da keşfetme, birleştirme ve izleme gibi farklı sorumluluklara sahiptir.
31. • Servisler tasarımın ve ürünün odak / temel yapıtaşı kabul edilir. • Development süreçlerinde servis oriented computing (SOC) kullanılır. • SOC: uygulama geliştirme için servislerin temel yapıtaşı olarak kabul edildiği bir yöntemdir. • SOA based toolchain: SOA yazılımları geliştiriminde kullanılan programlama araçlarını kapsar. (Bunların bir zincir olarak kullanılması; bi öncekinin çıktısının bir sonrakinin girdisi olabileceğini gösterir.)
32. • Birlikte çalışabilirlik (collaborative applications) – SOA sistemleri genellikle birlikte çalışabilirdir, bu sebeple mühendislik ile ilgili işlemlerin, süreçlerin de buna uygun şekilde yönetilmesi gerekmektedir. – SOA sistemlerde; servis müşterileri, servis broker’ı ve veri sağlayıcısı rolleri bulunur. Birlikte çalışır davranışlar, SOA yaşam döngüsünün sadece fazlarında değil geliştirimin her aşamasında etkilidir. – Örneğin; servis üreticisi ve servis kullanıcısı için paralel iki yaşam döngüsü önerildiği var sayılsın. Üretici için bunlar; design – build – deploy – assure olarak bulunsun. Kullanıcı tarafında ise bunlar; discover – bind – interact – monitor olarak görülür. Burada beraber çalışabilirlik süreçteki farklı aşamalarda da olabilir, iki paralel süreçte de olabilir.
33. • Runtime özellikleri – SOA yazılımlarında mühendislik gerektiren işlemler genellikle runtime esnasında gerçekleştirilir. – Sistem mevcut servisleri kullanarak runtime esnasında oluşturulduğu için, mühendislik işleri de servisin tanımlandığı anda bir kere yapılmalıdır.
34. • Yeniden kullanılabilirlik – Servisler, platform bağımsızdır ve servislerin bağımlılığı azdır. – Bu sayede, farklı sağlayıcılar tarafından geliştirilmiş servisler farklı servislerle beraber çalışabilir. – Waterfall model, spiral model, agile süreçler gibi birçok geliştirme yöntemi olmasına rağmen, SOA uygulama geliştirimi bunlardan farklı olarak daha yeniden kullanılabilirliğe odaklıdır
35. • Verinin Kronolojik Takibi (Data provenance ) – Data Provenance: Verinin tüm değişimler, yorumlamalar ve analizlerden geçerken takibi. – SOA’da veriler birçok iş akışı ve servis tarafından işlenir ve bunlardan geçer. – Bu sebeple, veriler ulaşacakları yere ulaşmadan önce uzun bir tarihsel sürece sahip oluyor. – Bu uzun geçişli yolculuk boyunca veri, veriyi korumak için veri güvenlik mekanizmasına ihtiyaç duyan onaylanmamış servisler tarafından silinir veya değiştirilir.
36. • Beraber çalışabilir sınama ve doğrulama: – SOA’da servisler ve uygulamalar; servis sağlayıcıları, uygulama geliştiricileri ve bağımsız servis brokerları tarafından birlikte çalışılabilirlik açısından sınanır ve doğrulanır. – Servis sağlayıcıları SOA için test scriptleri yayınlayabilir. – Uygulama geliştiricileri bu test scriptlerini kullanarak servisleri test edebilir. – Ayrıca geliştiriciler, test sonuçlarını yayınlayabilir.
37. • Klasik Yazılım Mühendisliği - Temel Adımlar – Gereksinimlerin belirlenmesi, – Analiz, – Tasarım, – Kodlama, – Test – Bakımdır. • Yazılım genellikle tek parça olarak tanımlanıyor. • Modül yapıları bulunsa da, tam anlamıyla yeniden kullanılabilirlik mümkün değil.
38. • SOSE: Dağıtık olmak için tasarlanmıştır. • İş dünyasında hızlı değişim, hızlı hareket zorunluluğu. • Değişim maliyeti klasik mühendisliğe göre düşük. • Servisler birbirinden bağımsız değiştirilebiliyor. • Klasik yöntemler uygulama geliştirmeye odaklı. • SOSE iş süreçlerinin akışına ve birbirleriyle etkileşimine odaklı. • Klasik yazılım mühendisliğinde altyapı değişikliği çok ciddi bir işlem • SOSE’de servis bazında bu değişiklikler yapılabilir. • Kolay entegrasyon
39. • Klasik yazılım mühendisliğinde detaylar ortadadır. • Bir iş için, işin nasıl yapılacağı tüm detaylarıyla bilinmeli ve kodlanmalıdır. • SOSE’de hangi servisin bu işi yaptığını bilmek yeterlidir. • Servisin iç yapısı başka bir sorumluluk alanıdır. • SOSE detayları soyutlar.
40. • SOSE süreçleri, servis odaklı yazımlarda kullanılmak üzere, ilgili standartlar kullanılarak tasarlanmış, yeniden kullanılabilir hizmetlerin geliştirilmesi için gerekli olan adımları tanımlamaktadır. • Kapsam – Gerekli olan servislerin belirlenmesi Oluşturulacak servis/servislere ilişkin gereksinimler oraya çıkarılır. – Servislerin tasarlanması, Servisin arayüzü (interface) belirlenir. – Servis implementasyonu ve yayına alma (deployment) Daha öncedeki aşamalarda gereksinimleri ve arayüzü belirlenmiş olan hizmet koda dökülür. Bu aşamanın sonunda düzgü çalışan ve ilgili yazılımların ulaşabileceği bir ortamda yayına alınmış bir servis bulunmalıdır.
41. • Servisin türüne ve ne iş yapacağına karar verilir. • İhtiyaç duyulan servislerin neler olduğunun belirlenmesi. • Servislerin mümkün olduğunca “fine grained” bir şekilde ve tek bir işi yapacak şekilde ayrıştırılması – yeniden kullanmayı artırır • Servislerin gereksinimlerinin belirlenmesi gerekir. – detaylı anlatılacak
42. • Web servislerinin birkaç genel kategoride incelenebildiğini bilmek servislerin neler olacağına karar verirken yardımcı olabilir: • Utility Servisleri: Bir çok iş akışı tarafından kullanabilecek genel geçer araç/özellikleri sunan servislere denir. – Hız birimi çevirici, – Döviz kuru dönüştürücü, – XML belgesinin doğru olup olmadığını kontrol eden servisler (XML Validator) gibi servisler örnek verilebilir. • İş servisleri: Kurumun iş akışı içerisindeki tek bir işi/fonksiyonu gerçekleştiren servisler bu kategoride yer alır. – Bir üniversitedeki öğrenci bilgi sisteminde öğrencinin ilk kaydını yapma işini gerçekleştiren servis buna bir örnek olabilir.
43. • Koordinasyon servisleri: Özellikle karmaşık iş süreçlerinde, iş akışı birden fazla kolda devam edebilmekte, iş akışında birden fazla servis görev alabilmekte ve akışın durumuna bağlı olarak bu servislerin hepsi değil, bir kısmı çalışabilmekte ve bunu farklı sıralarda yapabilmektedirler. – Koordinasyon servisleri bu akışın düzen içerisinde ve doğru sırayla devam etmesi için, iş akışını koordine ederler.
44. • Fonksiyonel ve fonksiyonel olmayan gereksinimler. • Bir servisin gereksinimlerine karar verilirken göz önüne alınacak sorular: • Servis sadece tek bir iş akışında mı kullanılacak, yoksa birden fazla iş akışında mı kullanılacak? – Servisin tam olarak ne iş yapacağının belirlenmesini sağlar. – Girdi ve çıkılarının belirlenmesini sağlar. – Servisle ilgili fonksiyonel olamayan gereksinimlerin belirlenmesini sağlar.(mesela SLA) • Bu bilgi aynı zamanda, servis üzerinde değişiklik yapılacağında veya servis kaldırılacağında bağımlılıkları takip etmek için gerekli olan kritik bir bilgidir.
45. • Servis iş akışı-bağımsız mıdır? – Servisin bağımsız olup olmadığına karar vermek, servisin implementasyonu sırasını, hızını ve servisle ilgili gereksinimleri etkileyecektir. • Servis state tutmak zorunda mı? – «Para birimi çevirme hizmeti», verilen girdilerle bir çıktı üretir. Her istek birbirinden bağımsızdır. (Stateless) – “Alışveriş sepeti tutma servisi”nde, sepette hangi ürünlerin bulunduğu bilgisinin, sepetteki ürünler satın alınana kadar, istekler arası belirli bir süre tutulması gerekir. – Bir veri saklama mekanizması gerekiyor mu? – Ontoloji, dosya, ilişkisel veritabanı, nosql, memcached benzeri bellek mekanizmaları… – Persistent, Temporary / Fast, Reliable • Bu bilgi, hem iş akışında hem de hizmetin tasarım ve implementasyonunda kullanılacak önemli bir bilgidir.
46. • Servis şirket dışındaki üçüncü partiler tarafından da kullanılabilir olacak mı? – Kimliklendirme ve yetkilendirme – Servisi sadece bazı kurumlar mı kullanacak, herkes mi? – Hangi protokoller ile ulaşılabilecek? – Bu kurumlar için ayrı ayrı hizmet sözleşmeleri mi olacak? – Servis kullanımı nasıl ücretlendirilecek? – Başka kurumlar için erişim yetkisinin kim tarafından hangi süreç ile verilecek?
47. • Servisler kendi içerisinde bağımsız çalışırlar. • Dışarıya “arayüzler” (interface) ile açılırlar. • Servisin iç işleyişi ve dışarıya sunulacak arayüz bağımsız şekilde incelenebilir. • Servisin iç tasarımı: – Servisin iç tasarımı, klasik yazılım mühendisliği paradigmalarından uygun bir tanesi yararlanılarak geçekleştirilebilir. – Bir servis kendi içinde kara kutu olduğu için, burada uygulanan yöntem ve implementasyonun nasıl olduğu, gereksinimler sağlandığı sürece kimsenin ilgi alanında olmayacaktır.
48. • Servis arayüzü: – Servis tarafından alınacak ve gönderilecek mesajların şeklini belirler. – WSDL – Servislerin dış uygulamalarla sorunsuz bir şekilde çalışmasını garantilemek için servis arayüzünün net bir şekilde (well defined) belirlenmesi önemlidir. – Bu aşamada uluslararası standartların göz önüne alınması beraber çalışabilirliği (interoperability) arttıracaktır.
49. • Tasarlanan arayüzlerde gölerilip alınan mesaj sayısının mümkün olduğunca az olacak şekilde tasarlanması performans açısından önemlidir. • Örneğin, bir kur hesaplama servisi için, paranın değerinin, biriminin ve dönüştürüleceği birimin tek bir defada alınması, artarda yapılacak üç arı mesaj iletimine göre daha hızlı olacaktır. • Hizmetlerin durum bilgisine (state, session) ihtiyaç duyması durumunda bu bilginin nasıl aktarılacağı da arayüzde belirlenmiş olmalıdır.
50. • Mantıksal arayüz tasarımı – Servisin yapacağı işlerin dışarı nasıl açılacağı ve hangi girdi çıktı değerlerine sahip olacağı belirlenir. – Servisin oluşabilecek hata/beklenmeyen durumlarda ne gibi hata mesajları döndüreceği belirlenir. • Mesaj tasarımı – Alınacak ve gönderilecek mesajların yapısı net olarak belirlenir. • WSDL tanımı – Mantıksal arayüz, gönderilecek ve alınacak mesajların arayüzü ile birlikte ele alınarak servisin WSDL standartlarına uygun tanımı oluşturulur.
51. • Servisler herhangi bir programlama dili ile geliştirilebilir. • Servis test edilmelidir. – detaylı bir şekilde anlatılacak • Yayına almak: – Servisin ilgili herkes tarafından ulaşılabileceği bir yerde çalışır hale getirilmesi – Keşfedilmesi için yayınlanması (UDDI ?) • Tasarımı yapılmış servislerin sağladığı özelliklerin bir kısmı, kurum bünyesinde servis odaklı olarak geliştirilmemiş yazılımlarda hali hazırda bulunabilir. • Tekrar kodlanmak yerine, zaten hali hazırda bulunan bir özelliğe servis odaklı erişmek için birer “adaptör” yazılabilir. • Eski programlar klasik yöntemle ulaşır, yeni programlar servis odaklı. • Yeniden geliştirmeyi ortadan kalkar, maliyet düşer.
52. • Amaç – Yazılımdaki hataların tespiti – Yazılımın functional gereksinimleri sağlayıp sağlamadığını kontrol etmek – Yazılımın non-functional gereksinimleri sağlayıp sağlamadığını kontrol etmek • Servis odaklı mimaride bu kolay değil – Dışarıdan temin edilmiş kaynak kodu görülemeyen (kara kutu) hizmetler – Her zaman kaynak koduna dayalı test yöntemleri kullanılamaz
53. • Dış kaynaklı servislerin işleyişi ve yapısı değiştirilebilir. – Daha önceden başarıyla tamamlanmış bir testin gelirliliğini yitirmesine sebep olabilir. – Test ekibinin, bu servisin değiştirildiğini bilmemesi söz konusu olabilir. Yapılan eski testlerin de başarılı olmasından dolayı, testin tekrardan yapılması söz konusu olmaz ve final ürün sağlıklı çalışmayabilir. • Kullanılacak bazı servislere, programın dizayn/kodlama aşmalarında değil, programın çalışması esnasında karar verilebilir. – Program çalışma esnasında bir döviz dönüştürme servisini UDDI ile arayıp bulup, WSDL/SOAP aracılığıyla kullanabilir. – Böyle bir durumda, bir döviz servisinin hep bulunabilir olması ve düzgün sonuçlar üretip üretmeyeceği test zamanında kesin olarak bilinemez.
54. • Servislerin yanıt süreleri üzerlerindeki yüke göre değişebilmektedir. – Yazılımın performans değerleri bilinebilir. – Servis kaynaklı gecikmeler bilinmeyebilir. – SLA? • Olası problemler servislerin tipine ve özelliklerine göre değişir. • Problemler belirlenmeli. • Risk analizi yapılmalı. • Test senaryoları hazırlanmalı.
55. • Kullanım Amaçları: – SOA’ya geçiş aşamalarını belirleme – Mimari modeli seçme – SOA çalışmasındaki hedefi belirleme • Doğru şekilde servis yaratma, birleşik servis ve süreç oluşturma, işletmeye yönelik modeller yetersiz kalmakta. • Temel nokta: Capability Maturity Model Integration • HP, IBM , Open Group, Oracle vb. Kurumların oluşturduğu SOA olgunluk modelleri mevcuttur.
57. • S-CUBE – Software Service and Systems Network – Avrupa’da software service gelişimini ve bu konuyla ilişkili yardımlaşmayı sağlamak için kurulmuş çok disiplinli, birleşik, araştırma topluluğudur. – Avrupaya servis odaklı gelişitirim lideri yapma ve yeni teknolojileri takip edip uygulama ve endüstri ile güvenli bir ilişki kurmayı sağlamak amaçları arasındadır. – 2008 yılından beri faaliyet göstermektedir. – Servis odaklı yazılım geliştirimi ile ilgili pek çok konferans, workshop, toplantı gerçeklştirmiştir. – Aktif olarak çalışmaya devam etmektedir.
58. • S-cube- PESOS – Principles of Engineering Service-Oriented Systems – S-cube’ün en önemli çalışmalarından biridir. – İlk olarak 2009 workshop çalışmalarına başlamıştır. – Akademik çevreden ve iş dünyasından yazılım mühendisliği ile ilgili araştırma yapan kişileri , servis odaklı yazılım geliştirme konusunda deneyimli çalışanları bir araya getirme – Servis odaklı sistemlerle ilgili son gelişmeleri, yeni uygulama senaryolarını, metodları, teknikleri ,araçları ve deneyimleri paylaşma – 4 Haziran 2012 tarihinde ICE 2012 çalışmaları kapsamında PESOS 2012 düzenlenecektir.
59. • SOSEG (Service Oriented Software Engineering Group) – Notre Dame Üniversitesinde bir çalışma grubudur – Servislerin çok hızlı bir şekilde kullanılmaya başlanması ve servis odaklı mimarinin avantajlarının farkedilmesiyel çalışmalarına başlamışlardır. – 2007 ve 2008 yıllarında 2 workshop ve 2004 – 2010 yılları arasında servis odaklı yazılım mühendisliği ile ilgili konferanslar düzenlemişlerdir. • SeCSE(Service Centric Systems Engineering) – Lancaster Üniversitesi’nde çalışmaktadırlar. – Component & service-oriented software engineering üzerine çalışmaktadırlar. – Amaçları, sistem bütünleştiricileri ve servis sağlayıcıları için metodlar, araçlar ve teknikler yaratmak ve servis ve servis odaklı uygulamaları kullanmak ve bunları ucuza mal edecek şekilde geliştirmektir. – 2003 yılından itibaren pek çok yayında bulunmuşlardır.
60. • Bulut bilişim, bilgilerin sürekli olarak Internet’teki paylaşılan sunucularda saklanması, işlerin bu sunucuya yaptırılması ve geçici olarak istemci tarafına indirilerek kişiye gösterilmesi, üzerinde değişiklikler yapılmasıdır. • Bulut bilişimde hizmetler, elektrik su gibidir. Aylık fatura ödenerek alınır. Kullandığın-kadar öde ile faturalandırma yapılır. • Servis sağlayıcı açısından Cloud Computing, «sen parayı ver, gerisine karışma, işi bize bırak!» deme anlamına gelmektedir.
61. Google Docs • Web’e ulaşmak için ne kullanıyor olursak olalım (masaüstü bilgisayar, laptop, tablet pc, cep telefonu…) dokümanlarımıza erişim olanağı vermektedir. • Dokümanlarımızı paylaşma ve istediğimiz her yerden erişebilme olanağı vermektedir. • Çoklu çalışma imkanı vermektedir.
62. • Ölçeklenebilir: Bizim için üç beş tane dokümanımızı tuttuğumuz yer, başka birisi tüm şirket yazışmalarının tutulduğu bir yer olabilir. • Bakım güvenlik şirketten: Bakımlar, sürüm güncellemeleri, güvenlik önemleri servis sağlayıcıya aittir. • Anında: Bu hizmeti almak istediğimiz an, bir üyelik alıp başlayabiliriz. • Bağımsız: Fiziksel mekan önemli değildir, İnternet bağlantısı olsun yeter.
63. • Bulut bilişim temelde 5 katmanda incelenebilir. – İstemci – Uygulama – Platform – Altyapı – Sunucu
64. • Software as a Service (SaaS) • Platform as a Service (PaaS) • Infrastructure as a Service (IaaS)
65. • Müşteri ihtiyaç duyduğu bir yazılımı bir bulut servis sağlayıcısından temin eder. • Bu yazılımların temel özellikleri: – Her yerden erişilebilirdir. – Genellikle aylık, yıllık abonelikler ile fiyatlandırılır veya ücretsizdir. – Ölçeklendirilebilirdir. – Güvenlidir. – Güvenilirdir. – API’ler ile geliştirmeye açıktır. • Örnek: Google Apps, Onlive
66. • Yatırım gerektirmemesi: Yazılımlara lisans bedeli ödenmez, bunları desteklemesi gerekebilecek güçlü donanım altyapısı bedeli harcanmaz. • Ödemeler aylık: Bir anda ciddi bir para çıkışı olmaz, ödemeler aylık yapılır. • Hızlı başlangıç: Bir SaaS yazılımını yapılandırmak, standart bir yazılımı ayarlamaya göre daha kolaydır. • Ayrıntılar gizli: Hizmetin nasıl çalıştığı önem arz etmez, özellikleri ve fiyatlar önem kazanır. • Güvenilirlik: Servis kalitesi SLA’lar ile önceden belirlenmiştir. • Düşük bakım maliyeti: Bakım, yedekleme servis sağlayıcıya aittir.
67. • SOA’nın tarihçesinden bahsedildi. • SOA’nın avantajları üzerinde duruldu. • SOA (Service Oriented Architecture) ve ilgili teknolojiler incelendi. • SOA’nın standartlarla ilişkisinden bahsedilerek standartlara değinilmiştir. • Standartların önemi tartışıldı. • SOA’nın geleceği ile ilgili tartışma yapıldı. • SOSE (Service Oriented Software Engineering) kavramını detaylı bir şekilde inceledik. • Klasik yazılım mühendisliği paradigmasına yer verilerek, SOSE ile arasındaki farklara değinilmiştir. • SOSE süreçlerinin detayları ve SOA olgunluk modelleri tartışılmıştır. • Son olarak SOA ve SOSE ile ilgili akademik faaliyetlere yer verilmiştir. • Bulut ile SOA arasındaki ilişki açıklanmıştır.
69. • PESOS ; http://www.s-cube-network.eu/pesos-2012 • S-cube ; http://www.s-cube-network.eu/ • SOSEG ; http://www.nd.edu/~soseg/soseg/ • SeCSE – Service Centric System Engineering; http://scse.comp.lancs.ac.uk/secse.htm • Çörekçioğlu, B.; Dijital Mecmua; SOA Mimarisi ve WCF; http://www.dijimecmua.com/index.php?c=sw&v=203&s=427&p=93 • Şenyurt, B.S. ; İlk Bakışta WCF; http://www.buraksenyurt.com/post/Ilk- Bakc4b1sta-WCF-bsenyurt-com-dan.aspx • Gu, Q., 2011, Guiding Service-Oriented Software Engineering: -A View- based Approach, Yayımlandığı dergi, cilt (sayı), Yayımlandığı Yer, 304s • Consuming Web Services through UDDI, SOAP and Weblets; CALIFORNIA SOFTWARE LABS; http://www.calsoftlabs.com/downloads/w_uddi.pdf
70. • Gu, Q. , Lago, P. , 2011; Guiding the selection of service-oriented software engineering Methodologies • Tsai, Wei-Tek. , Wei, Xiao., Paul, R. , Chung Jen-Yao, Qian Huang ,Yinong Chen; Service-oriented system engineering (SOSE) and its applications to embedded system development ; http://www.springerlink.com/content/r6627141kr263537/fulltext.pdf • Chang, SH., (2007) A systematic analysis and design approach to develop adaptable services in service oriented computing. IEEE congress on services, pp 375–378 • Papazoglou, Michael P., Web Services, 1st Edition, Pearson Education Limited 2008 • Kemsley, S., 2009; The Open Group’s Service Integration Maturity Model and SOA Governance Framework
71. • http://en.wikipedia.org/wiki/IaaS • http://en.wikipedia.org/wiki/Platform_as_a_service • http://en.wikipedia.org/wiki/Software_as_a_Service • http://en.wikipedia.org/wiki/Platform_virtualization • http://en.wikipedia.org/wiki/Amazon_EC2 • http://en.wikipedia.org/wiki/Cloud_computing • http://www.scribd.com/doc/23720596/Cloud-Computing • http://www.scribd.com/doc/17847855/Cloud-Computing • http://www.infoworld.com/d/cloud-computing/what-cloud-computing- really-means-031 • W3.org • http://soablueprint.com/maturity_models • http://www.soatutorial.net/soa-technology-soap-wsdl-uddi/