E-DEVLET UYGULAMALARINDA WEB SERVİSLER VE BİLİNMEYEN NUMARALAR SERVİS UYGULAMASI. Sevil ALTUNBAŞ YÜKSEK LİSANS TEZİ BİLGİSAYAR MÜHENDİSLİĞİ

Transkript

1 E-DEVLET UYGULAMALARINDA WEB SERVİSLER VE BİLİNMEYEN NUMARALAR SERVİS UYGULAMASI Sevil ALTUNBAŞ YÜKSEK LİSANS TEZİ BİLGİSAYAR MÜHENDİSLİĞİ GAZİ ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ ARALIK 2012 ANKARA

2 Sevil ALTUNBAŞ tarafından hazırlanan E-DEVLET UYGULAMALARINDA WEB SERVİSLER VE BİLİNMEYEN NUMARALAR SERVİS UYGULAMASI adlı bu tezin Yüksek Lisans tezi olarak uygun olduğunu onaylarım. Prof. Dr. Şeref SAĞIROĞLU Tez Danışmanı, Bilgisayar Mühendisliği Anabilim Dalı.. Bu çalışma, jürimiz tarafından oy birliği ile Bilgisayar Mühendisliği Anabilim Dalında Yüksek Lisans tezi olarak kabul edilmiştir. Prof. Dr. Ömer Faruk BAY Kontrol Eğitimi Anabilim Dalı, G.Ü... Prof. Dr. Şeref SAĞIROĞLU Bilgisayar Mühendisliği Anabilim Dalı, G.Ü... Prof. Dr. M. Ali AKCAYOL Bilgisayar Mühendisliği Anabilim Dalı, G.Ü... Tarih: 26/12/2012 Bu tez ile G.Ü. Fen Bilimleri Enstitüsü Yönetim Kurulu Yüksek Lisans derecesini onamıştır. Prof. Dr. Şeref SAĞIROĞLU Fen Bilimleri Enstitüsü Müdürü..

3 TEZ BİLDİRİMİ Tez içindeki bütün bilgilerin etik davranış ve akademik kurallar çerçevesinde elde edilerek sunulduğunu, ayrıca tez yazım kurallarına uygun olarak hazırlanan bu çalışmada bana ait olmayan her türlü ifade ve bilginin kaynağına eksiksiz atıf yapıldığını bildiririm. Sevil ALTUNBAŞ

4 iv E-DEVLET UYGULAMALARINDA WEB SERVİSLER VE BİLİNMEYEN NUMARALAR SERVİS UYGULAMASI (Yüksek Lisans Tezi) Sevil ALTUNBAŞ GAZİ ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ Aralık 2012 ÖZET Adalet Bakanlığı tarafından adalet hizmetlerinin en iyi şekilde yürütülmesi için, Ulusal Yargı Ağı Projesi (UYAP) e-devlet uygulamasının hayata geçirilmesi kararı verilmiştir. UYAP farklı kurum ve kuruluşlarla bilgi alışverişi için entegre çalışmaların yapıldığı en büyük projelerden biridir. Bu tez çalışmasında; web servisler (WS), WS teknolojileri ve servis güvenliği hakkında temel bilgiler araştırılarak, e-devlet uygulamalarında WS oluşturma ve güvenliğinin sağlanmasında örnek bir çalışma olan Bilinmeyen Numaralar Servis uygulaması geliştirilmiştir. Geliştirilen servis UYAP II kapsamında yürütülen entegrasyon uygulamalarına 118 Rehberlik Hizmetleri sunan Çağrı Merkezlerini de dâhil ederek vatandaşlara kesintisiz ve yüksek kaliteli elektronik yargı hizmetinin verilmesine katkılar sağlayacaktır. Bilim Kodu : Anahtar Kelimeler : Web servisler, web servis standartları, UYAP, bilinmeyen numaralar, e-devlet Sayfa Adedi : 101 Tez Yöneticisi : Prof. Dr. Şeref SAĞIROĞLU

5 v WEB SERVICES IN E-GOVERNMENT APPLICATIONS AND AN APPLICATION OF UNKNOWN NUMBERS SERVICE (M.Sc. Thesis) Sevil ALTUNBAŞ GAZİ UNIVERSITY INSTITUTE OF SCIENCE AND TECHNOLOGY December 2012 ABSTRACT The best way to carry out judicial services by the Ministry of Justice, the National Judicial Network Project (UYAP) has decided to implement. UYAP is one of the largest projects that integrate different studies, different institutions and organizations to exchange information. In this thesis; web services (WS), WS technologies and basic information about the safety of the service is investigated. Ensuring the security of e-government applications and WS creation Unknown Numbers Service application is developed as a case study. The developed service will contribute to give uninterrupted and high quality electronic judicial to the citiziens by including Call Centers that offers 118 Guidance Services to integration practices developed in the context of UYAP II. Science Code : Key Words : Web services, web services standards, UYAP, unknown numbers, e-government Page Number : 101 Adviser : Prof. Dr. Şeref SAĞIROĞLU

6 vi TEŞEKKÜR Çalışmalarım boyunca bana yol gösteren, destek ve yardımlarını benden esirgemeyen danışman hocam Sn. Prof. Dr. Şeref SAĞIROĞLU na, konu hakkındaki bilgisinden yararlandığım ve çalışabilmem için gerekli ortamın oluşturulmasını sağlayan Sn. Mustafa ÇELİKBİLEK e, tüm yoğun zamanlarımda anlayışlı ve yardımcı olan çalışma arkadaşım Sn. Veysel PINAR a, Adalet Bakanlığı BİDB idareci ve çalışanlarına ve manevi destekleriyle beni hiçbir zaman yalnız bırakmayan aileme, eşime ve biricik kızıma teşekkürü bir borç bilirim.

7 vii İÇİNDEKİLER Sayfa ÖZET... iv ABSTRACT... v TEŞEKKÜR... vi İÇİNDEKİLER... vii ÇİZELGELERİN LİSTESİ... ix ŞEKİLLERİN LİSTESİ... x SİMGELER VE KISALTMALAR... xii 1. GİRİŞ LİTERATÜR TARAMASI Web Servisleri ve CORBA Karşılaştırması IIOP ve HTTP ORB ve SOAP IDL ve WSDL WEB SERVİSLERİ Web Servisleri Tanımı Web Servisleri Özellikleri Web Servisleri Modeli Web Servisleri Standartları SOAP WSDL UDDI ORGANİZASYONLAR W3C OASIS WS-I WEB SERVİS GÜVENLİĞİ İletişim Güvenliği Kimlik Bilgilerinin Taşınması Mesaj Güncelliğini Sağlamak... 32

8 viii Sayfa 5.4. Mesaj Bütünlüğünü Sağlamak Mesaj Gizliliğini Sağlamak Erişim Kontrolü Denetleme BİLİNMEYEN NUMARALAR WEB SERVİS UYGULAMASI Önerilen Sistem: Bilinmeyen Numaralar Servisi Kullanılan Teknolojiler Bilinmeyen Numaralar Servis Yapısı Kullanılan Tasarım Desenleri Güvenlik Kontrolü Performans Analizi Bilinmeyen Numaralar Servisini Diğer Uygulamalardan Ayıran Özellikleri Bilinmeyen Numaralar Servis Arayüzleri Örnek Bir Servis Yazımı SONUÇ KAYNAKLAR EKLER EK-1. Bilinmeyen numaralar servis uygulaması WSDL belgesi EK-2. Servisle verilen dosya bilgileri EK-3. Performans analizleri ÖZGEÇMİŞ

9 ix ÇİZELGELERİN LİSTESİ Çizelge Sayfa Çizelge 2.1. Web servisleri ve CORBA karşılaştırması Çizelge 2.2. Web servisleri ve CORBA yığın karşılaştırması Çizelge 6.1. Örnek veri bilgisi Çizelge 6.2. Tasarım desenleri gösterimi Çizelge 6.3. AES algoritması döngü sayıları Çizelge 6.4. BN Telekom (118-80) istek yanıt süreleri Çizelge 6.5. PLUSS (118-70) istek yanıt süreleri Çizelge 6.6. ASSİSTT (118-18) istek yanıt süreleri... 59

10 x ŞEKİLLERİN LİSTESİ Şekil Sayfa Şekil 2.1. WS, CORBA ve Java-RMI için arayüzden istemci sunucu bileşenlerinin oluşumu... 9 Şekil 3.1. Web servisleri ile etkileşim sağlayan iş gezisi uygulaması Şekil 3.2. XML web servisleri Şekil 3.3. Web servis modeli Şekil 3.4. Web servis istemcisi ve sağlayıcısı arasındaki temel işlemler Şekil 3.5. Web servisi mimarisi katmanları Şekil 3.6. SOAP istemci ve SOAP sunucusu arasındaki iletişim Şekil 3.7. Bir SOAP istemci istek mesajı Şekil 3.8. Bir SOAP yanıt mesajı Şekil 3.9. UDDI kurum kayıt sunucuları Şekil 6.1. Bilinmeyen numaralar servisi akış diyagramı Şekil 6.2. Bilinmeyen numaralar servis yapısı blok şeması Şekil 6.3. Bilinmeyen numaralar ardışık diyagramı Şekil 6.4. Bilinmeyen numaralar sınıf diyagramı Şekil 6.5. Uygulamaya ait kod parçacığı Şekil 6.6. ServiceClient sınıfı çoklu tekillik yapısı Şekil 6.7. Bilinmeyen numaralar servis DAO sınıfı kod parçacığı Şekil 6.8. SQL enjeksiyon saldırısına engel yazılım kod parçası Şekil 6.9. Bilinmeyen numaralar servis log görüntüsü örneği Şekil Günlük trafik analiz grafiği Şekil Haftalık ve aylık trafik analiz grafiği... 62

11 xi Şekil Sayfa Şekil Yıllık trafik analiz grafiği Şekil Giriş ekranı Şekil Tüm davaların listelendiği ekran Şekil Dava hakkında ayrıntılı bilgi veren ekran Şekil Servis akış diyagramı Şekil Proje seçme ekranı Şekil Proje oluşturma ekranı Şekil Java sınıf oluşturma ekranı Şekil Kodlamanın yapıldığı Java sınıfı ekranı Şekil WS oluşturmak için seçim yapan kod ekranı Şekil WS özelliklerinin seçildiği ekran Şekil Sunucu tabanlı yükleme seçimi Şekil Proje ayarlarının seçimi Şekil WSDL belgesini oluşturan ekran Şekil Sunucunun başlatılması ve WS oluşturma adımlarını bitirme ekranı Şekil Servisin çalıştığını gösteren ekran Şekil WS istemci oluşturmak için seçim ekranı Şekil Örnek WS sonucunun gösterimi... 80

12 xii SİMGELER VE KISALTMALAR Bu çalışmada kullanılmış bazı kısaltmalar, açıklamaları ile birlikte aşağıda sunulmuştur. Kısaltmalar AES ASP CDR COM CORBA DAO DCOM EAR HTML HTTP HTTPS IDL IIOP Açıklama Gelişmiş Şifreleme Standardı (Advanced Encryption Standart) Aktif Sunucu Sayfaları (Active Server Pages) Ortak Veri Temsilciliği (Common Data Representation) Bileşen Nesne Modeli (Component Object Model) Genel Nesne İstek Aracı Mimarisi (Common Object Request Broker Architecture) Veri Erişim Nesneleri (Data Access Objects) Dağıtık Bileşen Nesne Modeli (Distributed Component Object Model) Kurumsal Arşiv (Enterprise Archive) Hiper Metin İşaretleme Dili (Hyper Text Markup Language) Hiper Metin Transfer Protokolü (Hyper Text Transfer Protocol) Güvenli Hiper Metin Transfer Protokolü (Hyper Text Transfer Protocol Secure) Arayüz Tanımlama Dili (Interface Definition Language) İnternet ORB Arası Protokolü (Internet Inter-ORB Protocol)

13 xiii Kısaltmalar IP IPS IPSec ISAPI J2EE MERNİS OASIS OGC OMG ORB RAD RMI RPC SAML Açıklama İnternet Protokolü (Internet Protocol) Saldırı Önleme Sistemleri (Intrusion Prevention Systems) İnternet Protokol Güvenliği (Internet Protocol Security) İnternet Sunucusu Uygulama Programı Arayüzü (Internet Server Application Interface) Java 2 Kurumsal Sürümü (Java 2 Enterprise Edition) Merkezi Nüfus İdaresi Sistemi Yapılandırılmış Bilgi Geliştirme Örgütü Standartları (The Organization for the Advancement of Structured Information Standards) Açık Coğrafi Konumsal Konsorsiyumu (Open Geospatial Consortium) Nesne Yönetim Grubu (Object Management Group) Nesne İstem Aracısı (Object Request Broker) Hızlı Uygulama Geliştirme (Rational Application Developer) Uzak Metot Çalıştırma (Remote Method Invocation) Uzak Yordam Çağrısı (Remote Procedure Call) Güvenli İşaretleme Dili (Security Assertion Markup Language)

14 xiv Kısaltmalar SMS SOAP SQL SSL TC TCP/IP UDDI URL UYAP VPN W3C WS WSDL WS-I XML Açıklama Kısa Mesaj Servisi (Short Message Service) Basit Nesne Erişim Protokolü (Simple Object Access Protocol) Yapısal Sorgulama Dili (Structured Query Language) Güvenli Soket Katmanı (Secure Socket Layer) Türkiye Cumhuriyeti İletişim Kontrol Protokolü/Internet Protokolü (Transmission Control Protocol/Internet Protocol) Evrensel Açıklama, Keşif ve Entegrasyon (Universal Description, Discovery and Integration) Tekdüzen Kaynak Bulucu (Uniform Resource Locator) Ulusal Yargı Ağı Projesi Özel Sanal Ağ (Virtual Private Network) Dünya Çapında Ağ Konsorsiyumu (World Wide Web Consortium) Web Servisleri (Web Services) Web Servisi Tanımlama Dili (Web Services Description Language) Birlikte Çalışabilir Web Servisler (Web Services Interopability Organization) Genişletilebilir Etiketleme Dili (Extensible Markup Language)

15 1 1. GİRİŞ Bilgi ve iletişim teknolojilerindeki gelişmeler ve özellikle internet, bilginin üretilmesi, depolanması, işlenmesi, iletilmesi, bütünleştirilmesi ve kullanımında yeni olanaklar sağlamaktadır. Tüm dünyada olduğu gibi ülkemizde de kamu kurum ve kuruluşları bilgi ve iletişim teknolojilerinden giderek daha fazla yararlanarak, karar destek sistemlerini güçlendirmek, iş süreçlerini hızlandırmak, etkinliği artırmak ve harcamalarında tasarruf sağlayabilmek için proje ve uygulamalar geliştirmişlerdir. Kamu kurum ve kuruluşları, birçok alanda elektronik veritabanı ve otomasyon projeleri geliştirmişler ve internet üzerinden çeşitli uygulamaları hayata geçirmişlerdir [1]. E-devlet; kamu kuruluşları, vatandaşlar ve ticari kurumlar arasındaki bilgi, hizmet ve mal alışverişlerinde bilgi teknolojilerinin kullanılarak performans ve verimlilik artışını hedefleyen devlet modeli olarak tanımlanmaktadır [2]. Her gün bir milyona yakın vatandaşın çoğunlukla bilgi almak için adliyelere gelmesi, yargı hizmetlerinin günümüz teknolojisine uygun olarak elektronik ortama taşınması zorunluluğunu getirmiştir. Bu maksatla e-adalet sistemi hizmete sunularak; yargının işleyişini, güvenirliğini, ulaşılabilirliğini ve doğruluğunu en üst düzeyde sağlamak ve yargı faaliyetlerine hız, etkinlik ve şeffaflık kazandırmak amaçlanmıştır. Yönetim Bilişim Sistemlerinden biri olan Ulusal Yargı Ağı Projesi (UYAP) günümüzün gerekli tüm teknolojik gelişmelerini kullanarak, Adalet Bakanlığı merkez ve taşra teşkilatının, bağlı ve ilgili kuruluşlarının, tüm yargı ve yargı destek birimlerinin donanım ve yazılım olarak iç otomasyonunu ve benzer şekilde bilgi otomasyonu sistemlerini kurmuş kamu kurum ve kuruluşları ile dış birim entegrasyonunu sağlayan, güvenli ve tutarlı bilgiyi tek merkezde toplayan, bu bilgiden yasal yetkiler çerçevesinde istenilen zamanda hızlı ve kolayca yararlanılmasına imkân veren, hızlı, etkin, güvenilir, adil, verimli, şeffaf ve etik değerlere uygun bir yargılama mekanizması oluşturan, kurumun idari faaliyetleri ile her türlü denetim, teftiş ve soruşturmanın hızlı ve etkin bir şekilde yürütülebilmesini

16 2 sağlayan ve kurumu kâğıtsız ortama taşımayı hedefleyen, e-dönüşüm sürecinde e- devletin e-adalet ayağını oluşturan bir bilişim sistemidir [3]. UYAP iç ve dış birimlerle entegrasyonu sağlayarak idarî işlemler ve yargılama süreçlerindeki mükerrer yapılan işlemlerle gereksiz uygulamalara engel olmakta, sürat ve kolaylıklar sağlayarak iş yoğunluğunu azaltmakta ve personel açığından kaynaklanan sıkıntıları en aza indirmektedir. UYAP ın yargı sistemine adalet, hız, doğruluk, tutarlılık, şeffaflık, etkinlik, verimlilik ve tasarruf sağlayan, usulsüzlük ve yolsuzlukları önleyen birçok katkıları bulunmaktadır. Elektronik imza alt yapısına uygun olarak geliştirilen UYAP kamu kesiminde diğer bilgisayar ağlarıyla bütünleşerek bilgi ve belge akışının en kısa zamanda gerçekleştirilmesini sağlamaktadır. Örneğin; Adli Sicil, Merkezi Nüfus İdaresi Sistemi (MERNİS), Tapu ve Kadastro Bilgi Sistemi (TAKBİS), Polis Bilgi Ağı (POLNET) ve Merkez Bankası veritabanları ile sağlanan bütünleşme sayesinde, nüfus kaydı, sabıka kaydı, ehliyet kaydı, tapu kaydı ve döviz kurları birkaç saniye içinde yargı makamları önüne getirilebilmektedir. Avukatlar bu bilgi sitemi sayesinde duruşmaya girme dışında adeta tüm işlerini bürolarından yapabilir hale gelmişlerdir. Vatandaşlar da şu an itibariyle dosyaları hakkında basit bir bilgiyi öğrenmek için adliyeye gitmek zorunluluğundan kurtulmuştur. Kamudan kamuya e-devlet uygulamalarının birlikte çalışabilirliğini web servisleri (WS) sağlamaktadır. Haklarında bir dava açıldığından haberi olmayan ve davanın infaza gidip kesinleştiği durumlarda adresi bilinmediği için tebligat eline ulaşmayan ve itiraz etme haklarından yoksun kalıp haklarında yakalama kararı çıkan vatandaşlar olmaktadır. Ayrıca davası olup, davalarıyla ilgili bilgileri öğrenmek için adliyeye gidemeyen, kısa mesaj atmasını bilmeyen (4060 Kısa Mesaj Servisi ni (SMS) kullanamayan özellikle yaşlılar ve okuma yazma bilmeyen vatandaşlar), avukatı olmayan, e-imza

17 3 ve m-imzaya sahip olmayan vatandaşların (Vatandaş Portal ı kullanamayan) davaları hakkında bilgi sahibi olmaları oldukça zorlaşmaktadır. Bu problemleri ortadan kaldırmak ve vatandaşların daha kullanışlı bir yöntemle bu bilgilere ulaşabilmesi gerekçesiyle 118 li firmalardan gelen bir istek değerlendirilmiş ve bu tez çalışmasında geliştirilen Bilinmeyen Numaralar Servisi (118 li Rehberlik Servisi) sayesinde kamudan vatandaşa verilen bir e-hizmet kapsamında, vatandaşların haklarında bir dava açılmış mı öğrenmek için ya da var olan davaları hakkında bir bilgi almak istediklerinde telefonla iletişime geçme yöntemini kullanarak 118 li kurumlara verilen servis hizmetinden yararlanma imkanı sağlamıştır. UYAP kapsamında dâhil edilen Bilinmeyen Numaralar Servisi, vatandaşların tarafı olduğu dava bilgilerini adliyelere gitmeden, yol ve konaklama gibi masrafları yapmadan, yolda ve adliyede beklemeden ve bu işlere enerji ve zaman harcamadan telefon ile ulaşabilmeleri ve yargı personelinin iş yükünü azaltmak amacıyla yapılmıştır. Tez çalışmasında yapılan uygulama tasarım desenleriyle desteklenmiş, katmanlar arası bağımlılık azaltılmış ve yeni eklentilerin yapıyı bozmadan sisteme eklenebilecek hale getirilmesi sağlanmıştır. Bilgileri hafızada tutma yöntemi ile sisteme eklenen veritabanı yükü azaltılarak sistemin daha hızlı çalışır hale gelmesi sağlanmıştır. Kullanıcı kimliği kontrolü ve isteklerin şifrelenmiş bir ID üzerinden gelmesi sağlanarak güvenlik katmanına ekstra bir özellik katılmıştır. Üç katmanlı mimarinin kullanılmasıyla zamandan tasarruf, sisteme kolay adapte olma, hata riskinin azalması ve yapılan değişikliklerin her yeri etkilememesi sağlanmıştır. Orijinal bir uygulama olan bu tez çalışmasında test ortamında görülen sorunları gidermek adına iyileştirmeler yapılmıştır. Yapılan bu iyileştirmeler sonucunda servisin cevap verme süresi kısaltılarak performans % 40 arttırılmıştır. Tez çalışmasında yapılan uygulama Türkiye de bir ilk olup başka hiçbir kurumda kamudan vatandaşa verilen bir e-hizmet WS kullanılarak yapılmamıştır. WS

18 4 teknolojisi ile yapılan çalışmaların literatür araştırması sonucunda kullanılan optimizasyonlar göz önünde bulundurularak uygulamanın geliştirilmesi sağlanmıştır. Tez çalışmasında öncelikle e-devlet, UYAP ve UYAP ın yargı sistemine katkıları, Bilinmeyen Numaralar Servis uygulamasının amacı, kapsamı ve çalışmanın yöntemleri hakkında bilgi verilmiştir. İkinci bölümde WS ve geliştirilen yönleri hakkında literatür taraması yapılmıştır. Üçüncü bölümde WS mimarisini oluşturan yapılar, protokoller ve standartlar hakkında yapılan incelemeler sunulmuştur. Dördüncü bölümde WS konusunda dünya genelinde kabul görmüş organizasyonlardan bahsedilmiştir. Beşinci bölümde WS güvenliği üzerinde durulmuştur. Altıncı bölümde örnek uygulama olan Bilinmeyen Numaralar Servisi ne ait bilgiler verilmiştir. Kullanılan teknolojilerden, güvenlik kontrollerinden, yapısal özelliklerinden, arayüz yapılarından, sistemin performansından ve diğer uygulamalardan ayrılan yönlerinden bahsedilmiştir. Son olarak, çalışmanın genel bir değerlendirilmesi yapılmış ve çalışmanın katkıları tartışılmıştır.

19 5 2. LİTERATÜR TARAMASI Dağıtık uygulama geliştirme, ilk olarak çeşitli Uzak Yordam Çağrısı (RPC) ile başlamıştır. Daha sonra Dağıtık İşlem Ortamı (DCE) ile ilk defa RPC ler standart hale getirilmiştir. DCE den sonra Genel Nesne İstek Aracı Mimarisi (CORBA) geliştirilmiş ve dağıtık süreç teknolojisi standartlaştırılmıştır. Bir topluluk tarafından geliştirilen CORBA dan sonra, Microsoft un Dağıtık Bileşen Nesne Modeli (DCOM) uzak nesne protokolü ortaya çıkmıştır. Bu sıralarda en başarılı dağıtık mimariler web ve e-posta olarak gösterilebilir. CORBA ve DCOM dan sonra çok popüler bir dil olan Java, Uzak Metot Çalıştırma (RMI) protokolü ile dağıtık sistemlerde büyük bir başarı yakalamıştır [4]. İlk WS teknolojisi, işte bu gelişmelerden sonra, 1999 yılında HP laboratuarlarında Hiper Metin Transfer Protokolü (HTTP) ve Genişletilebilir Etiketleme Dili (XML) tabanlı olan e-speak ile ortaya çıkmıştır. Çok başarılı olmayan e-speak den sonra, Userland, Dave Winter başkanlığında HTTP ve XML i birlikte kullanarak XML- RPC yi oluşturmuştur. XML-RPC ile birlikte, XML ile oluşturulan daha genel mesaj formatları da mevcuttur. Allaine tarafından oluşturulan Web Dağıtık Veri Alışverişi (WDDX) örnek olarak verilebilir [4]. XML mesaj formatları konusunda yürütülen çalışmaların içinde Microsoft un yönettiği Basit Nesne Erişim Protokolü (SOAP) XML formatlı verinin yapısal alımını ve gönderimini sağlamıştır. SOAP çalışmalarına paralel olarak, Sun şirketi de ebxml çalışmalarını sürdürmektedir. Bu iki büyük çalışma projesinin amacı sadece WS içindir [4]. Yukarıdaki saydığımız aşamalardan sonra WS leri standartlaştırma çalışmalarına ağırlık verilmiş ve ilk başta Web Arayüz Tanımlama Dili (WIDL), Servis Tanımlama Dili (SDL), SOAP Kontrat Dili (SCL) gibi dillerden sonra IBM, Sun, Ariba ve diğer şirketler ortaklığıyla Web Servisi Tanımlama Dili (WSDL) oluşturulmuştur [4]. Bu noktada, WS nin diğer dağıtık teknolojilerden neden daha iyi ve başarılı olduğunun standartlar olduğu söylenebilir. Daha önce dağıtık teknolojilerin

20 6 hiçbirinde standartlaştırma çalışmaları bu kadar büyük çapta ve katılımla gerçekleşmemiştir [4]. WS gelişmeye başladıkça farklı uygulamalara entegre edilmeye başlanmıştır. Mobil uygulamalar, Coğrafi Bilgi Sistemleri (CBS) uygulamaları, e-devlet, e-öğrenme, e- ticaret ve e-iş gibi uygulamalarda kullanılmaktadır. WS literatürde birçok makale ve teze konu olmuştur. Birant ve Kut yaptıkları çalışmada grafik ve harita tabanlı kullanıcı arayüzleri ve internet sayfaları geliştirmek için kullanabilecek bir model oluşturmuşlardır. Tasarlanan model sunucu tabanlı bir web uygulaması biçiminde düşünülmüştür ve sunucudaki web tabanlı yazılımın WS ile entegre halde çalışması sağlanmıştır. Çalışmada yer alan servisler haritaların sınır belirlemesinde ve renk yelpazesinin belirlenmesinde kullanılmıştır [5]. WS tabanlı geliştirilen mobil uygulamalara ODTÜ Mobil Öğrenci İşleri Bilgi Sistemi (MOİBS) örnek gösterilebilir. Bu çalışmayla Küresel Sistem için Mobil İletişim (GSM) operatörleri üzerinden not bilgisi, not ortalaması, harç bilgisi, ders bilgisi gibi bilgilerin sorgulanabileceği ve otomatik bilgi alınabileceği bir WS uygulaması gerçekleştirilmiştir [6]. Mobil cihazların kaynakları kısıtlı olduğu için mobil cihazlarda tek başına (standalone) uygulamaları geliştirmek yerine WS ve yazılım teknolojileri ile haberleşen uygulamalar geliştirmek daha mantıklıdır. WS, istemci platformundan bağımsız olduğu için tüm taşınabilir cihazlar için ortak bir arayüz ya da servis geliştirilebilinir. Bu sebeplerden dolayı WS nin ve yazılımların GSM ya da mobil uygulamaları üzerindeki önemi büyüktür [7]. GSM/GPRS aygıtları üzerinden çok dilli SMS gönderme çalışmasında mesaj gönderebilmek için Java tabanlı sınıf yapıları yazılmış ve internete bağlanmadan komutları kullanarak GSM/GPRS cihazları üzerinden SMS gönderimi gerçekleştirilmiştir. WS tabanlı başka bir uygulama olan Coğrafi Bilgi Sistemleri adlı tez çalışmasında SOAP istemci/sunucu mekanizması kullanılarak, Açık Coğrafi Konumsal

21 7 Konsorsiyumu (OGC) uyumlu WSDL dokümanı oluşturamayan UMN MapServer harita sunucusundan OGC uyumlu WSDL dokümanı elde edilmesi sağlanmıştır [8]. Göknil ve arkadaşlarının çalışmasında, Java WS ye tasarım desenlerini de uygulayarak çok katmalı bir sistem tasarımı gerçekleştirilmiştir. Geliştirilen sistem üç katmanlı bir yapı üzerine kurulmuştur. İlk katmanda kullanıcıdan veriyi alma ve sonucu görüntüleme işlemi istemci sistem üzerinde yapılır. İkinci katmanda WS den ilgili çağrımlar yapılır ve sistemde sunulan analizlerin işletilmesini sağlayan servisler, WS olarak gerçekleştirilmiş olup mimarinin en son katmanını yani üçüncü katmanı oluşturmaktadır [9]. WS nin e-ticaret uygulamasına örnek olarak yapılan bir tez çalışmasında seyahat işlemlerinde kullanılabilecek bir e-ticaret modeli gerçeklenmiştir. Çalışmada dağıtık veritabanı sistemleri için üç-katmanlı mimariyi ve e-ticaret sistemleri arasındaki etkileşimi sağlamak için WS modeli kullanılmıştır [10]. WS nin e-iş ve e-ticaret uygulamalarına örnek bir tez çalışmasında WS nin Kurumsal Kaynak Planlama (ERP) sistemlerinin geliştirilmesi ve kapasitelerinin artırılması için kullanılabilecek bir teknoloji olduğundan bahsedilmiştir. Çalışmada ERP sistemleriyle bütünleşik WS nin kullanımı ve getirdiği yenilikler tartışılmıştır. Geleneksel ERP sistemleri ve WS ile desteklenmiş ERP modellerinin karşılaştırılması yapılmıştır. WS ile zenginleştirilmiş bir ERP uygulamasını örneklemek için bir ilaç firması ve şubeleri arasında veri iletişimini sağlayan üç katmanlı mimari kullanılarak iki farklı uygulama geliştirilmiştir [11]. WS nin e-öğrenme uygulamasına örnek olarak yapılan bir tez çalışmasında mevcut sistemlerin istemci sunucu ve eşler arası mimarilerine dayandığından, ölçeklenebilirlik ve karmaşık içerik alışveriş problemlerinin olduğundan bahsedilmiştir. Öğrenim nesne ambarları ve öğrenim içerik yönetim sistemi gibi e- öğrenme uygulamaları arasında entegrasyonu sağlamak için WS nin kullanılması gerektiği söylenmiştir. Örnek uygulamada teknik içerikli bilgi veren bir üniversitenin WS aracılığıyla sözel içerikli bilgi veren başka bir üniversiteden bilgi aktarımı sağlanmıştır. Uygulama.NET Framework 1.1 platformunda Microsoft Visual Studio

22 kullanılarak C# dilinde hazırlanmıştır. Veritabanı olarak Microsoft SQL Server ve veritabanı tasarımında Power Designer programı kullanılmıştır [12]. Mobil cihazlarda performans analizinin yapıldığı Küçük Mobil Cihazlarda Kablosuz Ağlar Üzerinde SOAP, RMI ve TCP Performans Analizi adlı bir çalışma 2. Ulusal Yazılım Mimarisi Konferansı nda sunulmuştur [13]. Çalışmada ortamdan haberdar (context-aware) bir sisteme kablosuz ağlar üzerinden küçük mobil cihazlarla kısa mesafeli erişimlerde kullanılabilecek ağ mimarileri incelenmiş ve analiz edilmiştir. Analizlerde TCP soket bağlantısı, RMI dağıtık nesne teknolojisi ve servis odaklı yaklaşımlar kullanılarak istemci sunucu mimarileri incelenmiş ve performans analizleri yapılmıştır. Sonuç olarak WS uygulamaları RMI ve TCP soket uygulamalarına oranla daha yavaş çalıştığı tespit edilmiştir. Bunun nedeni WS nin diğer dağıtık nesne teknolojileri gibi RPC tarzı kullanım için tasarlanmamış olmasıdır. WS daha çok doküman merkezli bir haberleşme modelinde kullanılmaktadır. RPC odaklı yaklaşım yerine doküman merkezli yapısının kullanıldığı uygulamalarda geleneksel çözümlerden çok daha iyi sonuçlar alacağı belirtilmiştir [13]. Bağımsız Platformlar ile Web Servislerinin Geliştirilmesi adlı tez çalışmasında CORBA, COM/DCOM, Java RMI ve WS mimarilerinden bahsedilmiştir. DCOM ve Java RMI platformdan bağımsız olmadığı için CORBA ve WS karşılaştırılmıştır ve projede e-posta istemcisi alanında bir WS uygulaması ve bu WS yi kullanan bir web uygulaması geliştirilmiştir. Uygulama IBM WSAD yazılım geliştirme aracı ile J2EE teknolojisi kullanılarak geliştirilmiştir. WS Java Mail API sini kullanarak e-posta sunucusuyla haberleşmektedir. Web uygulamasında PHP 5.0 sürümü kullanılmaktadır. Uygulamada e-posta sunucusuna bağlanma, gelen kutusundan e- posta alma ve e-posta gönderme olarak 3 işlev gerçekleştirilmektedir [14] Web Servisleri ve CORBA Karşılaştırması WS den önce geliştirilmiş yazılım bütünleştirme teknolojilerinin içinde en iyi çözüm olarak CORBA yı gösterilebilir. Çünkü CORBA nın dışındaki iki teknoloji olan DCOM ve Java-RMI nın sunduğu çözümler platformdan bağımsız olmayı

23 9 sağlamamaktadır. Bu yüzden WS ile bu iki teknolojiyi kıyaslamak gerekmemektedir. Fakat işleyiş açısından Şekil 2.1 deki gibi bir gösterim yapılabilir. Şekil 2.1. WS, CORBA ve Java-RMI için arayüzden istemci sunucu bileşenlerinin oluşumu [15] CORBA ve WS teknolojileri iki farklı açıdan karşılaştırılır. İlk olarak bilgisayar modeline göre karşılaştırma yapılabilir. Sonra her bir teknoloji tarafından desteklenen özelliklere göre bir karşılaştırma yapılabilir. CORBA ve WS ile ilgili önemli bir inceleme CORBA ile yapılan başarılı bir işlem WS teknolojileriyle de başarılı bir şekilde yapılmaktadır bunun tersi de aynı şekilde başarılı bir şekilde gerçekleşmektedir. Fakat işlemin yapılması gereken çaba belirgin bir şekilde farklılık gösterir. SOAP üstüne CORBA ve CORBA üstüne SOAP uygulanabilir. Çizelge 2.1 de iki teknoloji arasında birkaç mimari boyuttaki karşılaştırmalar genel bir bakış açısıyla gösterilmektedir.

24 10 Çizelge 2.1. Web servisleri ve CORBA karşılaştırması [16] Kıyaslanan Yönler CORBA Web Servisleri Veri modeli Nesne modeli SOAP mesaj alış veriş modeli İstemci-Sunucu bileşimi Sıkı Az Konum saydamlığı Nesne referansları URL Tür sistemi IDL Statik + çalışma zamanı kontrolleri XML şemaları Sadece çalışma zamanı kontrolleri Hataların ele alınışı IDL istisnası SOAP hata mesajları Serileştirme ORB içine eklenir Kullanıcı tarafından seçilebilir Parametre geçişi Referansla Değerle (değer tipi) Değerle (nesne kavramı yok) Aktarım sözdizimi CDR kullanımı İkili format XML kullanımı Evrensel kod (unicode) Çalışma zamanı bileşimi DII UDDI/WSDL Kayıt Arayüz deposu UDDI/WSDL Uygulama deposu Servis keşfi CORBA adlandırma / UDDI ticaret servis RMI kaydı Dil desteği IDL bağlayıcıyla Herhangi bir dil herhangi bir dil Güvenlik CORBA güvenlik servisi desteği HTTP/SSL, XML imzalama desteği Güvenlik duvarı geçişi Çalışma sürmektedir HTTP port 80 ni kullanır CORBA ile WS yi kıyaslayabilmek için öncelikli olarak iki teknolojinin sundukları mimarileri göz önüne getirmek gerekir. Çizelge 2.2 de iki mimariye ait kıyaslama amaçlı bir yığıt ikilisi verilmiştir. Çizelge 2.2 de iki teknolojiye ait mimaride hangi öğeye karşılık hangi öğenin var olduğu görülmektedir. Çizelge 2.2. Web servisleri ve CORBA yığın karşılaştırması Web Servisleri Yığını WSDL UDDI SOAP XML HTTP TCP/IP CORBA Yığını IDL CORBA Servisleri ORB CDR IIOP TCP/IP

25 11 Çizelge 2.2 de dağıtık servis uygulamaları inşa ederken kullanılan teknoloji yığın katmanlarının karşılaştırmasını yapan yüksek seviye bir karşılaştırma gösterilmektedir. Katmanlardaki önemli bazı farklılıkları ve bu farklılıkların hangi teknolojide hangi yönde iyi ya da kötü özelliklere sebep olduğu aşağıda verilen alt başlıklarla incelenmiştir IIOP ve HTTP Göründüğü gibi iki mimari uygulama katmanından itibaren farklılık göstermeye başlamaktadır. WS genel ve yaygın kullanımda olan HTTP protokolünü kullanırken CORBA iletişim için İnternet ORB Arası Protokolü (IIOP) kullanmaktadır. IIOP protokolü Nesne Yönetim Grubu nun (OMG) ilkel veri tiplerini (tamsayı, karakter, vs.), CORBA nesnelerini ve dizileri ağ üzerinde transferlerinin yapılabilmesi için geliştirdiği özel bir protokol iken, HTTP protokolü genel amaçlı veri transferi için geliştirilmiş bir protokoldür. CORBA da IIOP üzerinden transfer edilen veri, çağrılan prosedürün parametre olarak kullandığı ya da dönüş değeri olarak döndürdüğü verilerin ikili olarak tasviri iken, WS de HTTP protokolü üzerinden gönderilen veri, aynı amaca hizmet eden fakat veri tipi olarak ikili veri yerine XML mesajları olan SOAP mesajlarıdır. Bu farklılık CORBA mimarisini temel alan çözümlerin WS çözümlerine nazaran daha yüksek performans sağlamalarına sebep olur. Çünkü sonuç olarak aynı manaya gelen veriler CORBA da daha az boyutta olacaktır. Bu da ağa yüklenen verinin daha az olmasına ve veri transferinin daha hızlı olmasını sağlamaktadır. Fakat WS de isteğe bağlı olarak istemci ve sunucu arasındaki iletişim, sıkıştırılmış SOAP mesajlarıyla da yapılabilir ve böylece ağda transfer edilen verinin boyutu azaltılabilir. Mevcut SOAP gerçekleştirimleri bu özelliği sağlamaktadırlar. Bunun yanında HTTP protokolü internet üzerinde yaygın bir protokoldür ve hemen hemen bütün sistemlerde desteği vardır. Örnek olarak, oluşturulacak olan sistemin bir güvenlik duvarının arkasında konumlanması istendiğinde HTTP için bunu yapmak mümkünken, IIOP için mümkün değildir, ya da standartların dışında çözümleri vardır. Bu farklılıkla, WS yazılım bütünleşme konusunda tüm platformların desteğini sağlama kriterinde CORBA dan daha üstündür [14].

26 ORB ve SOAP Bu katmanlarda yapılan işlem sunucu ve istemci düğümlerinde istek ya da cevap birimlerinin istemci ya da sunucuya gönderilmesi için, bir alt katman olan ağ katmanının kullanılmasıdır. Nesne İstem Aracısı (ORB) bu işlem için, servisin vekilliğini yapan gövde de iskelet nesneler kullanılır. SOAP da ise istemci ve sunucu tarafında konumlandırılmış SOAP işlemcilerinin oluşturduğu istek veya cevap mesajları kullanılır. Bu mesajlar XML formatındadır. Gövde iskelet gibi kavramların SOAP da (dolayısıyla WS de) olmaması, uygulamada birçok kolaylık getirir ve bunun yanında iki taraf arasındaki bağımsızlığı arttıran bir özelliktir. SOAP da, istemci uygulamada X sunucusundaki Y servisini çalıştırıp sonucunu geri getir diyebiliyorken, ORB daysa vekil bir sınıf kullanılır. Bu, istemcide sunucuda oluşturulan yapının işlevsel olmasa da, yapısal bir kopyasının oluşturulması demektir. Bu durum, sunucuyla istemci arasında belirli bir derecede bağımlılık oluşturur [14] IDL ve WSDL Servislerin istemciler tarafından kullanılması için arayüzlerinin tanımlandıkları bu katmanda CORBA için Arayüz Tanımlama Dili (IDL) kullanılırken WS için WSDL kullanılır. IDL OMG tarafından CORBA teknolojisinde kullanmak üzere geliştirilmiş bir format iken WSDL bir XML dokümanıdır. IIOP HTTP kıyaslamasında belirtildiği gibi bütünleştirme için mevcut bir varlığın kullanılması teknolojiye desteklediği sistemlerin artması özelliğini sağlar ve sunucu ile istemci arasındaki bağımlılığı düşürür. Sonuç olarak WS den önceki teknolojilerde eksikliği duyulan özellikler teknolojilerin açık internet standartlarından uzaklaşmış olmaları, istemci ve sunucular arasında tam bağımsızlığı sağlayamıyor olmaları ve uygulamalardaki zorluklardır. WS ler, Servis Tabanlı Mimari (SOA) yapısının bir gerçekleştirimi vazifesini görerek bu eksikliklerin giderilmesine destek sağlarlar [14].

27 13 3. WEB SERVİSLERİ Geçen yıllardan bu yana birçok alanda internet ve web teknolojileri yeni bir devrim başlatmıştır. Birçok araştırmacıya göre XML tabanlı WS bu devrimin ikinci adımını oluşturacaktır. WS ler farklı programlama dilleri kullanılarak yazılmış ve farklı platformlarda bulunan yazılım bileşenlerinin web standartları kullanarak web ortamında yayınlanabilen, aranıp bulunabilen ve çağrılarak erişilebilen modüler uygulama fonksiyonlarıdır. Bu fonksiyonlar değişik kurumsal iş süreçlerini gerçekleştireceklerdir [17]. WS, Haziran 2000'de ortaya çıkan ve birçok yazılım firması tarafından yoğun bir destek bulan bir modeldir. WS açık internet standartlarına dayanır. Henüz gelişme ve olgunlaşma aşamasında olan bu modelle ilgili olarak bu aşamada ortaya çıkan ve kullanılan çekirdek standartlar SOAP, WSDL ve UDDI dır [18]. WS modelini destekleyen Microsoft, IBM, Sun, HP, Oracle ve daha birçok firma bu konuda yoğun bir şekilde çalışmakta ve WS yazılım ve uygulama geliştirme araçlarını geliştiricilere sunmaktadırlar. Bu konudaki firmaların yoğun desteğinden dolayı uygulama bütünleştirmesi konusunda ortaya çıkacak baskın ortamın WS modeline dayanacağı yönündedir [17]. Web'in bu kadar başarılı olmasının nedeni basitlik ve yaygınlığıdır. Web ortamındaki gelişmeleri üç safhada inceleyebiliriz [19]: Belge Web'i (Document Web) : Belge web'i ile web ilk aşamadaki kullanımı, yani HTTP protokolü ile HTML dilinde biçimlendirilmiş statik belgelerinin kullanıcılara sunumunu ifade etmektedir. Uygulama Web'i (Application Web) : Bu yapı işletmelerin müşterilerine web üzerinden bazı iş süreçlerini yaptırma gereksinimi sonucunda ortaya çıkmıştır. Bu yapıda sunucu tarafında çalışan programlar vasıtasıyla hazırlanan dinamik HTML belgeleri ile kullanıcı ve iş uygulaması arasında etkileşim sağlanmıştır. Servis Web'i (Services Web) : İşletmelerin diğer işletmelerle olan iş süreçlerini bütünleştirme gereksinimi sonucunda ortaya çıkan ve gelişmekte olan yeni yapıdır.

28 14 Bu yapının temel taşı WS olur. WS deki temel amaç işletme bilgi sistemlerindeki program modüllerinin etkileşimini sağlamaktır [17]. WS web ortamında yayınlanabilen, aranıp bulunabilen ve çağrılarak erişilebilen modüler uygulama fonksiyonlarıdır. Bu fonksiyonlar değişik kurumsal iş süreçlerini gerçekleştireceklerdir. Şekil 3.1 WS kullanarak bir iş gezisi için gerekli rezervasyonları yapan bir uygulama örneği senaryosunu göstermektedir [19]. Bu örnekte iş gezisi planlayan kişi hava yolu, otel ve araç kiralama rezervasyonları yapacağı varsayılmıştır. İş gezisi organizasyonu için geliştirilen uygulama havayolu, otel, araç kiralama ve e-market firmalarının sağladığı WS leri çağırarak gerekli işlemleri tek bir uygulama ile gerçekleştirecektir. Şekil 3.1. Web servisleri ile etkileşim sağlayan iş gezisi uygulaması [19] WS, sunum şekli açısından farklı olan, özelleşmiş web uygulamaları olarak görülebilir. WS, SOA modelini kullanır. WS ler genel olarak programlardan çağrılabilir ve kamuya açık fonksiyonel bir ara birime sahiptirler.

29 Web Servisleri Tanımı WS, internet üzerinden kullanılabilen XML tabanlı bir sistem entegrasyon yöntemidir ve birçok kurum günümüzde WS den faydalanmaktadır. WS, web ortamında belirli görev veya görevleri yerine getiren işlemleri tanımlamak için bir arayüz oluşturmaktadır. Bir WS, WSDL kullanılarak tanımlanır. Servis yayınlama, bulma, bağlanma ve çağırma işlemlerini gerçekleştirmek için SOAP protokolü kullanılır. SOAP protokolü sayesinde WS basit ve mesaj tabanlı bir iletişim sağlar. Bir WS, standart olarak Hiper Metin İşaretleme Dili (HTML) iletişim protokolü üzerinden veri alışverişine izin veren bir yapıdadır. HTML tabanlı bu sistemin bilgi otobanı XML temelleri üzerine dayandırılmıştır. XML in bizlere sağladığı esneklik, kolay geliştirilebilirlik özelliklerinin yanı sıra, sağlamış olduğu genel standartlar, platform bağımsız veri transferi kavramını daha da geliştirmiştir (Şekil 3.2). WS lerin kullanılmasında yatan en büyük kavram XML tabanlı veri akışının belirli standartlar dâhilinde gerçekleştirilmesidir. Bu, WS nin platform bağımsız olarak herhangi bir güvenlik duvarına (firewall) yakalanmadan istemciler ile haberleşebilmesini sağlar [20]. Şekil 3.2. XML web servisleri [20]

30 Web Servisleri Özellikleri Bir WS, uzak istemcilerin başvuruda bulunduğu çeşitli işlevsel metot çağırımlarını barındıran, çok yönlü ve merkezileştirilmiş bir ünitedir. Bir WS, çok sayıda istemci tarafından erişilebilen bir yapıya sahiptir. Onu diğer dağıtık nesne modellerinden farklı kılan sahip olduğu alt yapı sistemi sayesinde, platform bağımsız uygulanabilirliği sağlamasıdır [20]. WS lerin geliştirilmesinde en büyük etken, özellikle bir merkezdeki uygulamalar üzerinde, ortak amaçları gerçekleştiren işlevselliklere sahip nesnelerin geliştirildikleri ağın iletişim protokolü gibi kısıtlamaların varlığıdır. Bir WS, tek başına bir anlam ifade etmez. WS yi kullanan istemcilerin de olması gerekir. İstemciler internet ortamında olabileceği gibi, çalıştığımız şirketin ağ sisteminde ya da evimizdeki makinenin yerel sunucusu üzerinde olabilir. Bir istemci, bir WS yi kullanmak istediğinde tek yapması gereken, bu WS ile konuşabilecek ortak bir takım standartları uygulamaktır. XML tabanlı bu standartlar sayesinde istemciler, WS ye ulaşabilir, bu servis üzerinden metotlar çağırabilir, bu metotlara parametreler gönderebilir ve metotlardan dönen değerleri örneğin veri kümelerini elde edebilir. Bir WS ortak işlem yaparak bilgi paylaşımını sağlar. Amaç, farklı obje modelleri kullanan ve hatta farklı işletim sistemlerinde çalışan bir grup uygulamayı bir araya getirerek kullanımı kolay web uygulamaları oluşturmaktır. COM objelerinde olduğu gibi WS lerin de içerisindeki kodun ne olduğu görülmez fakat sağladığı imkânlardan kolayca yararlanılır. WS ler, kullanıcılara servisi nasıl kullanacaklarını ve sağladığı servisleri tanımlayan çok iyi bir arayüz sağlar. Microsoft firmasının DCOM, Sun ın RMI, OMG nin CORBA ve benzeri teknolojilerden farklı olarak WS belirli obje modellerine özgü protokolleri kullanmaz. WS iletişiminde daha önce de belirtilen SOAP, HTTP, XML gibi veri formatlarını kullanır. Yani bu standartları destekleyen bir sistem WS yi rahatlıkla kullanabilir. Bu da XML WS ye farklı bir bilgisayar ve farklı bir platformdan istemci olunabileceğini gösterir. WS nin en büyük avantajlarından biri de budur.

31 Web Servisleri Modeli WS modeli temel olarak üç ana birimden oluşur [21]. Şekil 3.3'de gösterilen bu birimler şunlardır: Servis Sağlayıcı (Service Provider): Servis sağlayıcı istemcilerin sağlayıcıda bulunan servislere erişimini sağlar. Servis sağlayıcı kendi sitesinde bulunan WS tanımını servis kayıt birimine kaydeder. Burada servisin nasıl çağrılacağı belirtilir. Servis İstemcisi (Service Requester): Servis sağlayıcısında bulunan WS leri çağırarak kullanan istemci uygulamalardır. WS nin nasıl çağrılacağını servis kayıt biriminden bulur ve ilgili parametreleri servis kayıt biriminden arayarak çağırır. Servis Kayıt Birimi (Service Registry): Servis sağlayıcılarının yayınladıkları WS tanımlarını saklar ve aranıp bulunmasını sağlar. Servis sağlayıcıları servis kayıt birimini tarayarak istediği servisler hakkında bilgi alabilir. Ayrıca, servis kayıt birimi her servisin nasıl çağırılacağı konusunda tanım bilgilerini de içerir. Şekil 3.3. Web servis modeli WS çalışma mantığında ilk başta servis sağlayıcı WS yi yayınlar. Yayınlama işleminde servis sağlayıcı WS nin tanımını WSDL standardını kullanarak servis

32 18 kayıt birimine verir. WS yayınlandıktan sonra bu servisi kullanmak isteyen istemciler Şekil 3.4'deki şemada temel işlemlerin görülebileceği aşağıdaki adımları gerçekleştirirler [22]. 1) WS istemcisi (SOAP Client) servis kayıt biriminden (UDDI) WS yi bulur. 2) İstemci bir SOAP mesajı hazırlar. SOAP mesajı bir XML belgesidir. 3) İstemci SOAP mesajını web sunucu veya uygulama sunucusunda çalışan SOAP istek dinleyicisine gönderir. İstek dinleyici gelen isteklere cevap veren sunucu programlardır. Bu programlar bir Java Sunucu Sayfaları (JSP), Aktif Sunucu Sayfaları (ASP), Ortak Geçit Arayüzü (CGI) veya İnternet Sunucusu Uygulama Programı Arayüzü (ISAPI) programıdır. 4) SOAP sunucu gelen SOAP mesajını ayrıştırır ve gerekli parametreleri göndererek istenen nesnenin istenen yöntemini çağırır. 5) Çağırılan nesnedeki yöntem çalışır ve sonuçları SOAP sunucusuna gönderir. SOAP sunucusu gelen sonucu SOAP mesajı formatında biçimlendirerek istemciye gönderir. 6) İstemci gelen SOAP mesajının içindeki bilgileri alarak istekte bulunan programa gönderir.

33 19 Şekil 3.4. Web servis istemcisi ve sağlayıcısı arasındaki temel işlemler [22] 3.4. Web Servisleri Standartları WS mimarisi bağlantı, iletişim ve tanımlamalar açısından bazı prensip ve standartları barındırmaktadır. WS ler için oluşturulan temel çekirdek standartlar şunlardır [17,19-21]: 1) SOAP: Farklı platformlardaki sistemlerin birbirleri arasında internet üzerinden WS yi çalıştırmak için kullanılan protokoldür. 2) WSDL: WS leri tanımlama dilidir. Fonksiyon isimlerinin, ihtiyaç duyulan parametrelerin ve sonuçlarının tanımlanmasına imkân veren bir yapıdır. 3) UDDI: WS lerin indekslenip bulunduğu kayıt servisidir. Kullanıcılara ihtiyaç duyulan servislerin belirlenmesini ve erişilebilmesini sağlar.

34 20 Şekil 3.5 WS mimarisindeki temel katmanları göstermektedir. Bu katmanlarda belirtilen güvenlik, iş akışı, servis kalitesi ve yönetim gibi konulardaki WS standartları henüz araştırma ve geliştirme aşamasındadır. Şekil 3.5. Web servisi mimarisi katmanları [23] SOAP SOAP uygulama bütünleştirmesi için geliştirilmiş, dağınık uygulamalarda HTTP üzerinden veri alışverişi sağlayan geliştirilebilir iletişim protokolüdür. Sadece göndericiden alıcıya olacak şekilde tek yönlü çalışır. Nesne transferinde kullanılır. Tüm veriler XML formatında gönderilir. SOAP istemcilerin sunucularda olan nesne yöntemlerini çağırmasını ve sonuçların alınmasını sağlayan basit istek/yanıt (resquest/response) protokolüdür. SOAP mevcut internet alt yapısında olan yönlendirici, güvenlik duvarı ve vekil sunucularda herhangi bir değişiklik yapmadan kolayca çalışmaktadır çünkü HTTP üzerinden XML verisi olarak taşındığı için güvenlik duvarlarına takılmazlar. HTTP üzerinden uygulamalar arasında bilgi iletişimini sağlamak iyi bir yoldur, çünkü HTTP yi bütün internet tarayıcıları ve sunucuları destekler. SOAP bunu sağlamak için oluşturulmuştur. SOAP, HTML paketlerinin içine gömülü olarak gönderilmektedir.

35 21 SOAP sayesinde uygulamadan ve platformdan bağımsız veri alışverişi mümkün olmaktadır. Şekil 3.6 bir SOAP istemci ve sunucusu arasındaki iletişimi göstermektedir. Bir SOAP uygulaması geliştirmek için istemci ve sunucuya SOAP geliştirme araçları ile birlikte gelen kütüphanelerin yüklenmesi gerekir. Bu kütüphaneler bir XML ayrıştırıcı ve SOAP işlemcisi içerir. İstemci SOAP uygulaması bir SOAP istek mesajı oluşturarak bu isteği SOAP sunucusunda tanımlanmış servis uç noktalarından (end point) birisi tarafından çalıştırılması için gönderir. SOAP sunucu ilgili servisi çalıştırdıktan sonra SOAP yanıt mesajı hazırlar. Hazırlanan SOAP yanıt mesajı istemciye iletilir [17]. Şekil 3.6. SOAP istemci ve SOAP sunucusu arasındaki iletişim [10] SOAP mesajının temel olarak 3 elemanı vardır [22]. Bunlar zarf (envelope), başlık (header) ve gövde (body) kısımlarıdır. Zarf elemanı SOAP mesajının temel elemanıdır. Zarf elemanı ile başlayan XML dokümanlarının SOAP mesajı olduğu anlaşılır. SOAP mesajında zarf elemanının bulunması zorunludur. Tüm mesajın içinde bulunduğu etikettir.

36 22 Başlık elemanı uygulamaya özgü bilgileri tutabileceğimiz yerdir. Metotlarla bağlantısı yoktur. Tanımlayıcı veri bu kısımda gönderilir. Başlık elemanının kullanımı zorunlu değildir. Fakat kullanıldığında zarf elemanının ilk alt elemanı olarak yazılmalıdır. Gövde elemanı SOAP mesajlarında WS lerin fonksiyon isimlerinin, parametrelerinin ve geri dönüş değerlerinin tutulduğu kısımdır. Metotların tüm bilgileri bu etiket içinde gönderilir. Bu yüzden mesajın en önemli kısmıdır. SOAP mesajında gövde elemanı bulunması zorunludur. Oluşan hatalar bu kısımda aktarılır. Örnek bir SOAP mesajı aşağıdaki gibidir: <?xml version= 1.0?> <soap:envelope xmlns:soap= soap:encodingstyle= > <soap:header> </soap:header> <soap:body> </soap:body> </soap:envelope> Oluşabilecek diğer mesaj ise hata mesajıdır. Hatalar hata (fault) etiketinin içinde yazılır. Hata elemanı SOAP mesajında gövde elemanının alt elemanı olarak bulunmalıdır. Hata mesajı 4 bölümden oluşur. Hata kodu (faultcode) hatanın kodunu, hata nedeni (faultfactor) hatanın oluştuğu sunucuyu, hata metni (faultstring) oluşan hatanın açıklamasını detay (detail) ise uygulamaya özel hata detayını verir. Örnek bir hata mesajı: <SOAP-ENV:Envelope xmlns:soap- ENV=" <SOAP-ENV:Body xmlns:cs=" <SOAP-ENV:Fault> <faultcode>hata No : 3</faultcode> <faultstring>gecersiz kullanici adi ve sifre</faultstring> <faultfactor>ws.bidb.adalet.gov.tr</faultfactor> <detail xmlns:cs=" <CS:message>Login Hatası</CS:message> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

37 23 Şekil 3.7 ve Şekil 3.8 bir SOAP mesajının içeriğini sırasıyla göstermektedir. <SOAP-ENV:Envelope xmlns:soap- ENV=" SOAP- ENV:encodingStyle=" <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m=" <symbol>dis</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> Şekil 3.7. Bir SOAP istemci istek mesajı HTTP/ OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:soap-env=" SOAP- ENV:encodingStyle=" <SOAP-ENV:Body> <m:getlasttradepriceresponse xmlns:m=" <Price>34.5</Price> </m:getlasttradepriceresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Şekil 3.8. Bir SOAP yanıt mesajı WSDL Bir uygulamanın bir WS yi kullanması için WS nin nasıl çağırılacağının, arayüzünün, hangi protokollerin ve kodlama standartlarının belirtilmesi gerekir. WSDL servisin işlevini, servise nasıl erişileceğini tanımlamak için kullanılan XML tabanlı dildir [11]. SOAP iki program arasında iletişimi sağlarken Dünya Çapında Ağ Konsorsiyumu (W3C) standardı olan bu dokümandan yararlanır. WSDL, SOAP isteklerini kayıt alında tutar. WSDL dosyası içerisinde kullanılan metotların adı, aldığı parametreler ve türleri, WS nin bulunduğu adres, isteklerden dönecek

38 24 cevapların türleri ve hata oluştuğunda döndürülecek mesaj bulunur. Bir WS tanım belgesi aşağıdaki temel elemanları içerir [24,25]: Tipler: Mesajlarda kullanılacak veri tiplerini belirtir. WSDL tip elemanı içinde verinin katar veya sayı gibi türünü belirten kısımlar mevcuttur. Mesaj: Servis sağlayıcı ve servis istemcisi arasındaki iletişimde kullanılacak mesajları tanımlar. WSDL dokümanındaki fonksiyonları tanımlamada kullanılır. İşlem: Servis sağlayıcı ve servis istemcisi arasında mesaj değişimi işlemler kullanılarak tanımlanır. Port Tipi: WS nin içerdiği işlemleri ve ilgili mesajları tanımlar. Prosedürsel dillerdeki kütüphane ve sınıf mantığına benzetilebilir. Bağlayıcı: Her bir port için işlem ve mesajlarda kullanılacak veri formatlarını ve protokol bilgilerini tanımlar. Port: Bağlayıcı ve web adresinden oluşan servis noktasını tanımlar. Web adresi servisin çalıştırılacağı URL dir. Servis: Kullanılan bütün ilişkili portlar topluluğudur. Herhangi bir WS nin WSDL dokümanına ulaşmak için WS adresinin sonuna?wsdl eklenir. Örnek bir WSDL dosyası [25]: <?xml version="1.0"?> <definitions name="stockquote" targetnamespace=" xmlns:tns=" xmlns:xsd1=" xmlns:soap=" xmlns=" <types> <schema targetnamespace=" xmlns=" <element name="tradepricerequest"> <complextype> <all> <element name="tickersymbol" type="string"/> </all> </complextype> </element> <element name="tradeprice"> <complextype> <all>

39 25 <element name="price" type="float"/> </all> </complextype> </element> </schema> </types> <message name="getlasttradepriceinput"> <part name="body" element="xsd1:tradepricerequest"/> </message> <message name="getlasttradepriceoutput"> <part name="body" element="xsd1:tradeprice"/> </message> <porttype name="stockquoteporttype"> <operation name="getlasttradeprice"> <input message="tns:getlasttradepriceinput"/> <output message="tns:getlasttradepriceoutput"/> </operation> </porttype> <binding name="stockquotesoapbinding" type="tns:stockquoteporttype"> <soap:binding style="document" transport=" <operation name="getlasttradeprice"> <soap:operation soapaction=" <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="stockquoteservice"> <documentation>my first service</documentation> <port name="stockquoteport" binding="tns:stockquotebinding"> <soap:address location=" </port> </service> </definitions> Yukarıdaki örnek borsa kuru sağlayan basit bir servisin WSDL tanımını gösterir. Servis HTTP üzerinden SOAP 1.1 protokolü kullanılarak GetLastTradePrice adında tek bir işlemi destekler. İstek karakter dizisi (string) tipinde bir borsa fiyatlarını kâğıt şeride kaydeden cihaz (ticker symbol) alır ve bir fiyat döner. Görüldüğü gibi WSDL belgesi tek bir işlem için olsa bile oldukça karmaşıktır. Bu nedenle genellikle WS geliştirme araçları WSDL belgelerini otomatik olarak oluşturan programlar içermektedir.

40 UDDI Bir WS yi kullanmak için kullanıcının WS sağlayan kurumları ve bu kurumların verdikleri WS lerin neler olduğunu bilmesi gerekir. Evrensel Açıklama, Keşif ve Entegrasyon (UDDI), şirketlerin WS ler için kayıt edebildiği ve arayabildiği dizin servisidir. UDDI Kurum Kayıt Servisi (UDDI Business Registry) kurum ve WS bilgilerini saklayan sunuculardır. Bu sunucular servis sağlayıcılarından gelen bilgileri kendi veritabanlarına kaydederek diğer kurumların erişimine açar. Şu anda aktif olarak çalışan kurum kayıt sunucuları uddi.microsoft.com ve uddi.ibm.com dur [17]. UDDI kurumların kendilerini, sağladıkları servisleri yayınlayarak tanımlamalarını ve bu bilgilerin daha sonra diğer kurumlarca taranıp bulunmasını sağlayan bir standarttır [21,23]. Şekil 3.9'da görüldüğü gibi bu sunucular kendilerine kayıt edilen bilgileri diğer sunucularda kopyalayarak kolayca hızlı bir şekilde erişilmesini sağlarlar. UDDI sunucuları kurum ve servis kayıt, güncelleme ve tarama işlemlerini WS ile gerçekleştirir [17]. Şekil 3.9. UDDI kurum kayıt sunucuları

41 27 4. ORGANİZASYONLAR WS konusunda dünya genelinde kabul görmüş organizasyonlar şunlardır [26]: W3C OASIS WS-I 4.1. W3C Dünya Çapında Ağ Konsorsiyumu (W3C) en çok bilinen, web ile ilgili birçok standardı elinde bulunduran ve WG (Working Group) biçiminde geliştiren gruptur. Bu bölümle ilgilendiği konularsa, XML Şemaları, SOAP, XML-dijital imzalama, XML-şifreleme ve WSDL standartlarıdır. Bu organizasyona adresinden ulaşılabilir [26] OASIS Yapılandırılmış Bilgi Geliştirme Örgütü Standartları (OASIS) daha çok, güvenlikle ilgili veya değil, WS lere özel standartlarla ilgilenir. Komite bazlı çalışır ve geliştirilecek standartlar için Teknik Komiteyi oluşturur. OASIS UDDI, WS- Güvenlik ve Güvenli İşaretleme Dili (SAML) standartlarını elinde bulundurur. Bu organizasyona ulaşılabilir [26] WS-I Birlikte Çalışabilir Web Servisler (WS-I) grubu birlikte çalışabilir WS ler için genel bir yapı oluşturmak için kuruldu. İşleri daha çok, başka yaygın şekilde kabul edilen standardı alıp WS uygulamalarına uyumları için gereken profilleri, örnek uygulamaları, test araçları ve gereksinimleri geliştirmedir. Özel olarak, Temel Güvenlik Profili (BSP) OASIS in WS-Güvenlik standartlarına dayanır ve birlikte çalışabilirlik iddia edilen WS lerdeki gereken ve isteğe bağlı olan güvenlik özelliklerini belirler. Bu organizasyona adresinden ulaşılabilir [26].

42 28 Bu kuruluşlardan en belirleyicisi ve kapsamlı çalışmalar yapanı W3C olup diğerleri uygulamalarda güvenlik ve isteğe bağlı özel standartlarla uğraşmaktadır. Web ve WS standartlarının ana belirleyici komitesi W3C kuruluşudur. OASIS ve WS-I nın sunduğu profiller, basit uygulamalar ve test araçları sayesinde birlikte çalışabilir WS lerin geliştirilmesi sağlanmaktadır. Bu kuruluşların belirlediği standartlar bilgiye erişimde hız, ulaşımda ve kullanımda kolaylık ve veri paylaşımında güvenlik sağlarlar.

43 29 5. WEB SERVİS GÜVENLİĞİ Bir istemcinin, bir web sunucusu ile haberleşirken, haberleşmenin doğru web sunucusu ile gerçekleştiğinden emin olmasını sağlayan güvenlik önlemleri alınmalıdır. Gizlilik ve/veya bütünlüğün gerekli olduğu durumlarda web içerikleri internet üzerinden güvenli bir şekilde taşınmalıdır. WS ler, diğer dağıtık uygulamalar gibi farklı seviyelerde korunur: SOAP mesajları, kablolardan, gizli olarak ve üzerinde değişiklik yapılamadan dağıtılmalıdır. Sunucu kimin konuştuğu ve konuşan istemcilerinin hakları konularında emin olmalıdır. İstemciler doğru sunucu ile konuştuklarından ve bir balık ağına yakalanmadıklarından emin olmalıdırlar. Sistem mesajlarının kayıtları olaylar zincirinin güvenilebilir bir şekilde tekrar edilebilmesi ve kimliği doğrulanmış ziyaretçileri takip edebilecek kadar yeterli bilgiye sahip olmalıdırlar. WS, uygulamaların Uygulama Programlama Arayüzü (API) ve hedef uygulamalara erişebildiğinden birçok güvenlik açığı bulundurur. Ayrıca dağıtık ve uçtan uca yapısı sayesinde güvenlik açıklıklarının diğer uygulamalara da atlamasına neden olabilir. Güvenli Soket Katmanı (SSL) tüm veriyi şifreleyerek noktadan noktaya güvenlik sağlar fakat mesajın içeriğiyle ilgilenmediği için mesaj seviyesinde kontrol sağlayamaz. WS işlemlerinin değişik boyutlarıyla alakalı geniş çaplı güvenlik spesifikasyonları geliştirilmektedir. Bunlardan biri, kimlik, özellik ve kimlik doğrulama bilgilerinin katılan servisler arasında güvenli ve birlikte çalışabilir bir şekilde nasıl alınıp verileceğini tanımlayan SAML dir. Microsoft ve IBM önderliğindeki geniş bir konsorsiyum, Verisign, RSA Security (RSA Güvenlik) vs. gibi firmalardan gelen girdilerle ve diğer katılımcılarla birlikte Web Servisleri Haritası olarak bilinen bir spesifikasyonlar ailesini geliştirmiştir. Bu

44 30 spesifikasyonların temeli, WS-Güvenlik tarafından OASIS e teslim edilmiş ve 2004 yılında OASIS standardı olmuştur. Bu ailenin diğer önemli spesifikasyonları geliştirme sürecinin değişik aşamalarında halen kullanılmakta olup teslim planları açıklanmamasına rağmen, güvenlik politikalarında (WS-Policy), güvenlik parçacık değişiminde (WS-Trust), güvenli iletişim için altyapı oluşturulmasında (WS-Secure Conversation) kapsanmaktadır [26] İletişim Güvenliği HTTP üzerinden doğrulama, mesajı imzalama ve mesajın içeriğini şifreleme yapabilir. Bu tip durumlarda mesaj güvence altındadır. Şöyle ki, mesajı gönderen bilinir, mesajın alıcısı doğruluğu kanıtlar ve mesaj taşınma esnasında değişmez. Diğer kişiler mesajı ele geçirse bile doğrulama yapamaz ve verinin değişik bir durumda olmasından dolayı veri işlerine yaramaz. Bu açıdan bakıldığında SOAP mesajlaşma sistemi, HTTP temelli güvenlik yetersiz olmasına rağmen büyük problemleri çözmektedir. HTTP mekanizmaları sadece noktadan noktaya güvenliğe hitap eder. Daha karmaşık çözümler uçtan uca güvenliğe ihtiyaç duyar [26]. Ortak olarak benimsenen ve daha yaygın bir şekilde uygulanan SSL kullanımı ve kanal güvenliğine karşı parçacık (token) güvenliği konusu dışında aşağıdaki listede kanal güvenliğini yalnız bir şekilde kullanırken ortaya çıkabilecek gizli tehlikelerin özeti bulunmaktadır [26]: Noktadan noktaya güvenlik Birden fazla noktadan oluşan herhangi bir iletişim, bu yol üzerindeki her bir iletişimde bulunan nokta arasında ayrı birer kanal ve güvenlik kurulmasını gerektirir. Ayrıca güvenin geçişliliği gibi hemen göze çarpmayan konular da vardır. Mesela {A,B} ve {B,C} nokta ikilileri arasındaki güven, otomatik olarak {A,C} arasındaki güveni gerektirmez.

45 31 Bellek meselesi Mesajlar sunucu tarafında alındıktan sonra (kastedilen alıcı olmasa da) en azından kısa süreliğine de olsa düz yazı biçiminde bulunur. Taşınan bilginin aradaki noktalarda kayıt edilmesi kayıt dosyalarındaki hedef sunucu (herkes tarafından görüntülenebilir) ve yerel önbellek problemini daha da kötü hale getirir. Birlikte çalışılabilirliğin eksikliği SSL taşıma korunmasında standart bir mekanizma sağlasa da, uygulamalar kimlik bilgilerinin taşınmasında, güvenli kanaldan taşınan verinin bütünlük, gizlilik ve güncellik gibi hususlarının sağlanmasında yüksek derecede özel mekanizmalar kullanır. Farklı bir sunucu kullanmak, işlev itibariyle değişmediği halde aynı bilgileri farklı formatlarda kabul ettiği için istemcilerin değişmesine ve firmadan firmaya (B2B) servis zincirlerinin oluşamamasına sebep olur [26]. Standart-tabanlı parçacık korunumu, birçok durumda, mesaj bazlı WS SOAP iletişim modeline karşı ileri bir alternatiftir. Bu demektir ki, bugünkü WS lerin çoğu halen kanal güvenlik mekanizmalarının bir versiyonu ile korunmaktadır ki bu tek başına basit bir iç uygulama için yeterlidir. Fakat bu yaklaşımın sınırları iyice anlaşılmalıdır ve tasarım sırasında gerekli düzenlemeler yapılmalıdır. Kanal güvenliğinin mi, parçacık güvenliğinin mi yoksa bu ikisinin bir karışımının mı bu özel durum için gerekliliği düşünülmelidir [26] Kimlik Bilgilerinin Taşınması Kimlik bilgilerinin karşılıklı değiştirilmesi ve WS lerde kimlik doğrulamanın yapılabilmesi için geliştiriciler aşağıdaki konuları hedef almalıdır. Öncelikle, SOAP mesajları XML-tabanlı olduğundan, değiştirilen bütün bilgiler yazı biçiminde olmalıdır. Bu, kullanıcı adı ve şifre gibi kimlik bilgilerinde sorun yaratmaz. Fakat yürütülebilir dosyalar (mesela X.509 sertifikaları veya Kerberos parçacıkları) gönderilmeden ve alınmadan önce Base64 kodlama sistemi ile kodlanmalı ve çözülmelidir [26].

46 32 İkinci olarak da, kimlik bilgilerinin taşınması bu bilgilerin kaybedilmesi riskini hep taşır. Bilgiler iletim sırasında dinlenebilir veya sunucu kayıtları incelenebilir. Bu yüzden parola veya gizli anahtar gibi bilgilerin şifrelenmiş bir şekilde gönderilmesi veya hiçbir zaman düz yazı şeklinde gönderilmemesi gerekir. Hassas kimlik bilgilerinin yollanmasındaki genel yöntem kriptografik imzalama yöntemidir [26] Mesaj Güncelliğini Sağlamak Yeniden oynatma saldırısı kullanıldığında geçerli bir mesaj bile tehlike arz edebilir. Mesela, sunucuya istenilen işlemin tekrar yaptırılması için birkaç kez gönderilmesi. Mesaj değiştirilmeye karşı yeteri kadar sağlam olsa bile, saldırı için kullanılan mesajın kendisi olduğu için bu saldırı mesajın tamamının ele geçirilmesi ile uygulanabilir [26]. Yeniden yollanan mesajlardan korunmak için kullanılan genel yöntemler ya mesajda benzersiz tanımlayıcı kullanmak ve işlenenlerin kayıtlarını tutmak ya da nispeten daha kısa geçerlilik süresi kullanmaktır. WS dünyasında ise, mesajın hazırlandığı zamanın bilgisi genellikle mesaja eklenerek iletilir ve bunun yanında örneğin mesajın sona erme zamanı veya belirli durumlar gibi fazladan bilgi de eklenebilir [26]. İkinci çözümde, uygulaması daha kolay olmasına rağmen senkronize bir saat gerektirir ve sunucu zamanında kaymaya çok duyarlıdır. Günümüz bilgisayarlarında önemli bir problem arz etmediği halde sunucu ve istemci saatlerinde kayma çok olur ve zamanlı mesaj iletimi engellenir. Daha büyük problem, sunucu tarafındaki mesaj işleme sırasında sunucu meşgul olduğundan veya cevap veremediğinden dolayı beklemekten süresi dolan mesajlarda yaşanır [26] Mesaj Bütünlüğünü Sağlamak Bir mesaj bir WS tarafından alındığında gönderene güvenin bir şekilde sağlandığını kabul edersek, sunucu elindeki mesajın gerçekten gönderen kişi tarafından oluşturulduğundan ve yolda (bilinçli veya bilinçsiz) değiştirilmediğinden emin olmalıdır. Bu SOAP mesajının teknik özelliklerini örneğin zaman etiketini veya içeriğini ya da bankadan çekilecek olan miktar gibi durumları etkileyebilir [26].

47 33 Açıkça görülüyor ki, iki değişiklik de sunucu tarafından fark edilmelidir. İletişim protokollerinde, paket bütünlüğünü teyit eden parçacıklar bulunur (checksum). Fakat bu yeterli olmayacaktır, halka açık WS dünyasında, bu toplam parçacıkları kolayca değiştirilebilir ve güvenle sahibine ulaşımı sağlanamaz [26]. Gerekli ilişki Karma Tabanlı İleti Kimlik Doğrulama Kodu (HMAC) kullanarak kurulabilir veya imzaların kriptografik imzalarla veya gizli anahtar şifreleriyle (şifrelerin gizli olduğunu kabul edersek) birleştirilmesi ile en ufak bir değişikliğin farkına varılabilir [26] Mesaj Gizliliğini Sağlamak Çoğu zaman, bütünlüğü sağlamak yeterli değildir, birçok durumda saklanan veya taşınan bilginin gizliliğinin de sağlanması gerekebilir. Bu işlenen mesajın tamamına uygulanabileceği gibi, belirli kısımlarına da uygulanabilir ve her iki durumda da içeriği saklamak için bir çeşit şifreleme gereklidir. Normalde, büyük miktardaki verileri şifrelemek için simetrik şifreleme algoritmaları kullanılır, çünkü asimetrik şifrelemeden daha hızlıdırlar. Asimetrik şifreleme de simetrik oturum anahtarlarını korumak için kullanılır, bu anahtarlar birçok uygulamada bir konuşma süresince geçerlidirler ve konuşma sonunda atılırlar [26]. Birçok durumda, bütünlük ve gizliliğin sağlanması için şifreleme imza ile birleştirilir. Normalde, imzalayan anahtarlar şifreleyenlerden farklıdır, çünkü anahtarların hayat süreleri farklıdır. İmzalayan anahtarlar, sahipleri ile ilişkilendirilmiş kalıcı anahtarlardır, fakat şifreleyen anahtarlar mesaj alışverişinden sonra geçersiz hale getirilebilir. Bir diğer sebep de iş yükümlülüklerinin ayrılması olabilir, imzalayan otorite (ve karşılık gelen anahtar) bir bölüme veya kişiye aitken, şifreleme anahtarları Bilgi Teknolojileri (BT) bölümünden sorumlu elemanların kontrol ettiği sunucular tarafından üretilir [26] Erişim Kontrolü Mesaj alındıktan ve başarıyla geçerli kılındıktan sonra, sunucu şunlara karar vermelidir [26]:

48 34 Tanımlama Kimlik Doğrulama Yetkilendirme Bu aşamada WS ye özel çok fazla aktivite yoktur. Sadece kimlik doğrulama sırasındaki kimlik bilgilerinin iletimi için yeni birkaç yol vardır. Çoğu zaman, yetkilendirme görevleri tamamen WS nin dışında halledilir ve bütün etki alanını koruyan politika sunucusunda yapılır [26]. Burada önemli bir sorun daha geleneksel HTTP güvenlik duvarları WS lere yapılan saldırıları engellemeye yardımcı olmaz. Organizasyon, uygulama seviyesinde web sunucusundaki trafiği analiz edebilen ve SOAP mesajlarını hedeflerine geçirip geçirmemekte akıllı kararlar veren XML SOAP güvenlik duvarlarına ihtiyaç duyacaktır [26] Denetleme Tipik olarak denetleme için gerekli olan genel görevlerden biri, belirli bir probleme yol açan olaylar zincirini tekrar oluşturmaktır. Normalde bu sunucu kayıtlarının güvenli bir yerde kaydedilmesi ve sadece BT yöneticilerine ve sistem denetçilerine bu kayıtlardan denetleme takibi yapılmasına izin verilmesiyle başarılabilir. WS bu duruma bir istisna değildir ve diğer web uygulamalarının genel yaklaşımlarını takip eder [26]. Bir başka denetleme hedefi, inkâr edilemezliği sağlamaktır, yani mesajın teyit edilebilecek bir şekilde gönderenine kadar izi sürülebilir. Standart yasal uygulamalara göre elektronik dokümanlar bir çeşit elektronik imza bulundurmalıdırlar, fakat bu imzanın tanımı çok geniş bir şekilde yapılmış olduğundan pratikte her manaya gelebilir ve birçok durumda isim ve doğum tarihinin girilmesi bile elektronik imza tanımına uyacaktır. WS açısından bu derecedeki bir koruma yetersiz ve kolay kırılabilirdir. Standart uygulamada bir dokümanın yasal olarak bağlayıcı olabilmesi için kriptografik dijital imza bulundurması gerekir ve eğer böyle bir imzaya sahip bir doküman denetleme kayıtlarında bulunursa güvenilir bir şekilde imzalayan anahtarın sahibine ulaştırılabilir [26].

49 35 6. BİLİNMEYEN NUMARALAR WEB SERVİS UYGULAMASI Bu tez çalışmasında, bir Bilinmeyen Numaralar WS uygulaması geliştirilmiş olup bu proje UYAP sistemi içinde yer alan entegrasyon projelerinden biridir. Kamudan vatandaşa bir e-hizmet olarak adlandırılan bu uygulama çalışmasında belirli güvenlik aşamasından geçen vatandaşlara, tarafı olduğu dava bilgileri, dava dosyalarının ne aşamada olduğu ve hangi işlemlerin yapıldığı bilgisi UYAP sistemi üzerinden verilecektir. Belirtilen veriler geliştirilen WS aracılığıyla daha etkin ve güvenilir bir şekilde çağrı merkezlerine gönderilebilecektir. Bu uygulama bir e-hizmet olarak davalarıyla ilgili bilgileri öğrenmek için adliyeye gidemeyen, kısa msj atmasını bilmeyen (4060 SMS servisini kullanamayan özellikle yaşlılar ve okuma yazma bilmeyen vatandaşlar), avukatı olmayan, e-imza ve m- imzaya sahip olmayan vatandaşların (Vatandaş Portal ı kullanamayan) herkesin yapabildiği telefonla haberleşme sistemini kullanarak davaları hakkında bilgi sahibi olmalarını kolaylaştırmak amacıyla yapılmıştır. UYAP Bilişim Sisteminde Çevik yazılım geliştirme metodolojisinden Hamle (Scrum) yöntemi kullanılmaktadır. Hamle, fazla dokümantasyon yapmadan, kısa periyotlarda geliştirme yapılıp, sonuçların müşteriye sıkça gösterildiği ve geri beslemeler doğrultusunda geliştirmelerin yönünün sürekli değiştiği, gereksiz geliştirmelerin minimuma indirilmeye çalışıldığı bir sürecin yönetimini üstlenir. İhtiyaca yönelik, esnek bir yazılım geliştirme sürecidir. Süreç, ihtiyaç ve önem sıralamasına göre işlediği için, büyük parçaların önceden ele alınmasını sağlar. UYAP sisteminde müşteriler sahada çalışan kâtip, alan uzmanı, avukat, savcı ve hâkimler olabilmektedir. Sistem için farklı modülleri içeren ayrı takımlar oluşturulmuştur. Haftalık toplantılarla projenin ne aşamada olduğu konuşulur ve sahadan gelen istekler değerlendirilerek takımlara iletilir. UYAP Entegrasyon grubu olarak değerlendirildiğinde müşteriler kamu kuruluşları, saha çalışanları ve ticari kurumlardır. WS açarken müşterinin istekleri öncelik sırasına göre Entegrasyon grubuna madde olarak atanır ve servis yazım sürecinde gereksinimlere göre hazırlanan proje test ortamına yüklenir. Firmalar test ortamında

50 36 deneyerek gördükleri eksikleri ya da yeni istekleri alan uzmanına ileterek servisin geliştirilmesine devam edilir. Test ortamında tüm istekler gerçekleştikten sonra gerçek ortama yükleme yapılarak servisin çalışması tamamlanır. Böylece müşteriler de proje dâhil olarak yapılan değişiklikleri test ortamında görmüş ve beklentilerine göre projeye yön vermiş olurlar. WS alırken saha çalışanlarının istekleri değerlendirilerek dış kurumlarla bağlantıya geçilir. İstenen ve verilebilecek bilgiler konusunda kanunun öngördükleri de göz önünde bulundurularak ortak bir protokol üzerinden işlem yapılır. Bu uygulama için madde ataması yapıldıktan sonra ilk adımda servis edilecek bilgiler üzerinde tartışılmıştır. İşlem yapılacak veritabanı sorguları, mimari yapı ve güvenlik gibi kriterler göz önünde bulundurularak gereksinimler belirlenmiştir. İkinci adımda servisin yapısı tartışılarak tasarımı gerçekleştirilmiştir. Üçüncü adımda kodlama işlemi gerçekleştirilmiştir. Servisin yazımı bittikten sonra dördüncü adımda test işlemine geçilmiştir. Beşinci adımda hatalar düzeltildikten sonra karşı kurumlarla güvenli ağ bağlantısı kurulmuştur. Altıncı adımda diğer kurumların servise istemci oluşturmalarıyla test ortamında bağlantı ve hata kontrolleri yapılmıştır. Sistemin test ortamında başarıyla çalışması sonucunda son adıma geçilerek servisin gerçek ortama aktarılması sağlanmıştır. Bu son adımda sunucu (UYAP) ve istemci (118 li firmalar) tarafında kontroller yapılarak sistemin kullanıma hazır hale getirilmesi sağlanmıştır Önerilen Sistem: Bilinmeyen Numaralar Servisi Bu tez çalışmasında geliştirilen Bilinmeyen Numaralar servisi UYAP ve 118 Rehberlik Hizmetleri sunan Çağrı Merkezleri işbirliğiyle vatandaşlara elektronik yargı hizmeti sunulmasını sağlamıştır. 118 numaralı çağrı merkezlerini arayan vatandaşlar, kendilerine ait dava dosyaları ve icra takipleri hakkındaki dosya kapak bilgilerine operatörlerle yapacakları sesli görüşmelerle ulaşabilmektedirler. 118 Rehberlik Hizmetleri kapsamında vatandaşlara e-adalet hizmeti sunulmasına yönelik olarak;

51 37 1) BN Telekom Haberleşme ve Ticaret A.Ş. (118-80) 2) ASSİSTT Rehberlik ve Müşteri Hizmetleri A.Ş. (118-18) ve 3) PLUSS Telekom İletişim Ticaret Ltd. Şti.( ) ile protokol imzalanmış ve 13 Şubat 2012 tarihinde sistem vatandaşların kullanımına açılmıştır. UYAP & 118 Rehberlik Hizmetleri kapsamında vatandaşlara verilen bilgilerden bazıları şunlardır: Hakkınızda bir dava dosyası ya da icra takibi olup olmadığı, Varsa hangi birimde (mahkeme/icra dairesi) olduğu, Esas ve karar numarası, dava tarihi, Karar verilip verilmediği, derdest olup olmadığı, Varsa duruşma tarihi ya da keşif tarihi, Bilirkişi raporunun gelip gelmediği, Taraf ve tebligat bilgileri. Şekil 6.1 de 118 Rehberlik Hizmetleri çağrı merkezlerinden çağrının başlamasından bitimine kadar Bilinmeyen Numaralar Servisi nin yapısı akış diyagramıyla gösterilmektedir. Uygulamada MERNİS, UYAP ve 118 Rehberlik Hizmetleri olarak üçlü bir iletişim söz konusudur.

52 Şekil 6.1. Bilinmeyen numaralar servisi akış diyagramı 38

53 Kullanılan Teknolojiler Bilinmeyen Numaralar Servisi Java programlama dili ile yazılmıştır. Uygulama WebSphere Uygulama Sunucusu (Java EE sunucusu), IBM RAD arayüzü ve Oracle veritabanını kullanarak JAX-RPC yapısında çalışır. HTTP üzerinde yayınlanan servisi kullanan sayfalar ASP.NET kullanılarak yazılmıştır.test için yazılan istemci kodu Apache Axis yapısında çalışır Bilinmeyen Numaralar Servis Yapısı Adalet Bakanlığı UYAP projesi kapsamında 3 katmanlı yapı kullanılmaktadır. Bu katmanlar dış vekil (Proxy), dış geçit (Gateway) ve iç katmandır. İç katman UYAP projesinin çalıştığı ve veritabanıyla bağlantının olduğu katmandır. Dış katmanlar ise WS lerin çalıştığı katmanlardır. WS ler alınan servisler ve sağlanan servisler olarak 2 ye ayrılır. Dış vekil (Proxy) katman alınan servisler için dış geçit (Gateway) katman ise sağlanan servisler için oluşturulmuştur. Dış katmanlar güvenliğin artırılması içindir. Dış katmanlar sayesinde verilen ya da alınan servislerin direk iç katman (UYAP veritabanı) ile bağlantısı engellenir. Gerekli şifre, kullanıcı adı bilgileri ve güvenlik kontrolleri sağlandıktan sonra yazılım sayesinde alınan ya da gönderilen veriler iç katmandan veritabanı bağlantısı kurularak dış sunuculara ya da dış sunuculardan gönderilir. İç katmanda UYAP projesinin arayüzleri bulunur dış katmanda kurumlardan gelen ve kurumlara giden servis projeleri yer alır. 118 li firmalardan örneğin kurumuna ait operatörden, arayan kişinin Türkiye Cumhuriyeti (TC) kimlik numarası, nüfus cüzdan seri numarası ve anne kızlık soyadının ilk ve son karakterinin bilgileri alınır ve kimlikdogrula metoduyla servise gönderilir. Serviste ilk başta o TC kimlik numarasına ait nüfus cüzdan seri numarasının doğruluk kontrolü MERNİS servisine bağlanarak yapılır eğer sonuç doğru gelirse anne kızlık soyadının kontrolü MERNİS servisine tekrardan bağlanarak yapılır. Hatalı sonuçlarda hata bilgisi dönülür. Kontroller doğrulanırsa Güvenli Karma Algortiması (SHA-1) şifrelemesiyle verilen TC kimlik numarası ve bazı bilgiler kullanılarak bir şifre elde edilir ve onaltılık sisteme çevrilerek sessionid

54 40 olarak anahtar değer ikilisinde (hashmap) tutulur. Özetleme fonksiyonlarından olan SHA-1 herhangi bir uzunluktaki bir metnin sabit uzunluktaki özetini oluşturur. Bu özet, veri bütünlüğü ve kimlik doğrulaması ile ilgili uygulamalarda temel yapıtaşı haline gelmiştir. Şekil 6.2 de gösterildiği gibi ilk başta operatörün kimlikdogrula metoduna girdiği veriler iç katmana dış (Gateway) sunucudan istek olarak gönderilir. İstek iç katmandan dış (Proxy) sunucuya gönderilir. Dış sunucudan MERNİS servisine bağlanılarak gerekli bilgiler alınarak aynı yol üzerinden iç katmana gönderilir. İç katmanda güvenlik doğrulamasından geçen veriye ait bilgiler kullanılarak oluşturulan ve daha sonraki sorgulamalarda güvenlik için kullanılacak bazı veriler veritabanına kaydedilir. Dış sunucudan (Gateway) hatalı giriş (login) sonucu dönerse verilerin kontrol edilerek tekrar gönderilmesi istenir. (MERNİS) Servis (118-80) Diğer Kurum Dış (Proxy) Aldığımız Servisler Dış (Gateway) Açtığımız Servisler CEZA Sunucusu İç Katman (WSSERVER) HUKUK Sunucusu Veritabanı Şekil 6.2. Bilinmeyen numaralar servis yapısı blok şeması

55 41 Şekil 6.2 de gösterilen Hukuk ve Ceza sunucuları iç sunucuyla bağlantılı olan UYAP a ait diğer sunucuları örneklendirmektedir. Bu metottan dönen sessionid sorgula ve dosyalistesisorgula metotlarında kullanılacaktır. Sürekli oturum kapanma problemini ortadan kaldırmak için sessionid veritabanına kaydedilir ve bir tetikleyici sayesinde 5 dakika içinde yeni bir sorgu gerçekleşmediğinde veritabanından silinir. Giriş (login) hata kodları aşağıdaki gibidir. public static final class UserLoginHataKodlari { public static final String userloginhatakodlari[] = { "Login Başarılı", "Cüzdan Seri Numarası Hatalı", "Anne Kızlık Soyadı Hatalı", "TC Kimlik Numarası Hatalı", "MERNİS ten Kişi Bilgileri Doğru Alınamadı", "MERNİS leiletişimde Hata Oluştu" }; public static final Integer loginbasarili = new Integer(0); public static final Integer cuzdanserinohatali = new Integer(1); public static final Integer annekizliksoyadihatali = new Integer(2); public static final Integer tckimliknohatali = new Integer(3); public static final Integer mernisbilgilerindehata = new Integer(4); public static final Integer merniserisimindehata = new Integer(5);} Kimlik doğrulamadan geçme işlemi başarı ile gerçekleşirse dosya listesi sorgulama için gerekli metot çağrılabilir. DosyaListesiSorgula metoduyla kişinin tüm dosyaları, sayfalama yapısıyla bir sayfada en fazla 20 dosyanın görülmesi sağlanmıştır. İstenen bir dosya ya da belli dosya aralıklarının görülmesi girilen parametrelere göre sağlanmaktadır. Performansın artırılması ve sistemin daha hızlı çalışması için ilk başta kişinin tüm dosyaları veritabanından çekilerek 10 dakikalığına bir haritada (hashmap) tutulur. İstenen parametrelere göre dosya gösterimi bu haritadan alınarak sağlanır. 10 dakika içinde aynı kişi tekrar aradığında veritabanına gidilmeden bu haritadan veriler çekilerek servise gönderilir. Bu sayede servisin hızı görülür bir şekilde artış sağlamıştır ve veritabanı çok fazla yorulmamıştır. Bu metotla dosya, taraf ve adres bilgileri verilmektedir. Dosyaya ait ayrıntılı bilgilerin sorgulanması servisin yazılış amacıdır ve bu sorgula metodundan dönen istek sayesinde gerçekleşir. O kişiye ait sorgular oluşturulan sessionid kontrol edilerek gerçekleştirilir. Yapıyı Birleşik Modelleme Dili (UML) diyagramlarından ardışık diyagram (Şekil 6.3.) ile anlatırsak;

56 Şekil 6.3. Bilinmeyen numaralar ardışık diyagramı 42

57 43 Bilinmeyen Numaralar uygulamasında 46 tane sorgu olduğu için ayrı ayrı metot yazmak yerine kodun iyileştirilmesi adına içinde liste (enum) bulunduran bir sınıf oluşturularak tek bir metot üzerinden tüm sorguların çalıştırılması sağlanmıştır. Bu yapı yapısal tasarım desenlerinden cephe tasarım desenini kullanarak oluşturulmuştur. Sorgulardan dönen sonuçlar her zaman farklıdır. Sonuçlar bir matris üzerinden satır ve sütunlar kullanılarak tek bir elden dönüşü sağlanmıştır. Sorgula metodu geri dönüş olarak WSSorguOutput nesnesi döner. Bu nesne WSSorguCevapRow nesnesinin dizisi ve sorguid değişkenini içerir. WSSorguCevapRow nesnesinin eleman sayısı SQL sonucu kaç adet kayıt döndüğüdür. Bu nesnenin içerisinde WSSorguCevapData nesnesinin dizisi bulunur. Bu nesne attributename ve attributevalue adında iki karakter dizisi değişkenlerine sahiptir. Bu değişkenler dönen verideki 1 sütuna ait özellik adı ve değerini tutar. Örnekle açıklarsak; Dosya numarası 564 olan kişinin dosyasında yer alan dilekçeleri görmek istiyorum sorusunun cevabında sorguid si 17 olan dilekçe sorgusu çalışır ve Çizelge 6.1 deki gibi bir çıktı ve XML verisi oluşur. SorguID:17 Dosyaya verilen dilekçeleri döner. Çizelge 6.1. Örnek veri bilgisi Dosya_id Dilekce_adi 564 Dava Dilekçesi 564 Çekilme Dilekçesi Oluşan XML verisi aşağıdakine benzer bir çıktı oluşturacaktır:

58 44 < WSSorguOutput> <sorguid>17</sorguid> < WSSorguCevapRow> <WSSorguCevapData > <attributename>dosya_id</attributename> <attributevalue> </attributevalue> </WSSorguCevapData> <WSSorguCevapData> <attributename>dilekce_adi</attributename> <attributevalue>dava Dilekçesi</attributeValue> </WSSorguCevapData> </ WSSorguCevapRow> < WSSorguCevapRow> <WSSorguCevapData > <attributename>dosya_id</attributename> <attributevalue> </attributevalue> </WSSorguCevapData> <WSSorguCevapData> <attributename>dilekce_adi</attributename> <attributevalue>çekilme Dilekçesi</attributeValue> </WSSorguCevapData> </ WSSorguCevapRow> </WSSorguOutput> Giriş (login) hata kodları dışında servise ait genel hata kodları aşağıda verildiği şekildedir. public static final class GenelHataKodlari { public static final String GenelHataKodlari[] = { "Hata Oluştu", "Sonuç Başarılı", "Hatali Kullanici ID veya Sifre", "Hatalı SessinID", "Gecersiz metodid", "SessionID karşılığındaki TC kimlik numarası ile gönderilen TC kimlik numarası aynı değil" }; public static final Integer hataolustu = new Integer(0); public static final Integer sonucbasarili = new Integer(1); public static final Integer hataliusernamepass = new Integer(2); public static final Integer hatalisessionid = new Integer(3); public static final Integer gecersizmetodid = new Integer(4); public static final Integer sessionidtckimlikeslesmiyor = new Integer(5); } Servise ait sınıfların bağlantılarını gösteren sınıf diyagramı Şekil 6.4 ile gösterilmiştir.

59 Şekil 6.4. Bilinmeyen numaralar sınıf diyagramı 45

60 Kullanılan Tasarım Desenleri Tasarım desenleri, yazılım tasarımında sürekli karşılaşılan genel sorunlara esnek, yeniden kullanılabilir, başarılı çözümler getiren bir takım hazır kalıplardır. Hazır olarak kodun içine konulup çalışabilen, bitmiş tasarımlar değildir. Çeşitli durumlarda sorunların nasıl giderileceğini açıklayan, bunlara yol gösteren açıklamalardır. Nesneye dayalı programlamada tasarım desenleri, sınıf ve nesneler arasındaki ilişkilerin en iyi şekilde nasıl olmaları gerektiğini açıklayan yöntemlerdir. Algoritmalar, tasarım deseni değildir. Çünkü bunlar hesaplama sorunlarına çözüm getirirler oysa tasarım desenleri yazılım tasarımı sorunlarıyla ilgilenir. Nesneye dayalı programlamada sınıfların kendi içinde tutarlı, fakat diğer sınıflara en az bağımlı olmaları beklenir. Yazılım parçalarının tekrar kolayca kullanılabilir olmaları, kolayca genişleyebilir veya sistemden kolayca çıkarılabilir olmaları yani kısaca esnek olmaları beklenir. Yeni ihtiyaçların yazılımın diğer kısımlarını en az biçimde etkileyerek yazılıma kolayca dâhil olmaları beklenir. İşte tasarım desenleri, nesneye dayalı programlamanın bu prensiplerini doğru bir şekilde uygulamamızı sağlar. Sonuç olarak tasarım desenlerini uygulayarak etkin kodlar üretiriz ve yazılımın kalitesini arttırırız. Zamandan ve yazılım için harcanan iş gücünden de tasarruf etmiş oluruz [27]. Tasarım desenleri, programcılar tarafından edindikleri tecrübeler doğrultusunda oluşmuş kalıplardır. Tasarım desenleri değişik kategorilere ayrılır [28]: Kurucu tasarım desenleri (creational patterns) Yapısal tasarım desenleri (structual patterns) Davranışsal tasarım desenleri (behavioral patterns) Bunlar aşağıda kısaca açıklanmışlardır. Kurucu tasarım desenleri, nesne oluşturma görevini sistemden soyutlar. Sistemi nesnelerin belli kural ve ön şartlara göre yaratılmalarından bağımsız kılar. Sisteme

61 47 nesnelerin nasıl, hangi nesne, ne zaman yaratılacak gibi konularda esneklik sağlarlar. Nesnelerin yaratılma sorumluluğunu, sistemin mantığından ayırır. Yapısal tasarım desenleri, sınıf ve nesnelerin daha büyük yapılar oluşturmak için nasıl bir araya geldikleriyle ilgilenirler. Sisteme yeni bir özellik getirme ve sistemin genişlemesi konusunda sisteme esneklik kazandırırlar. Davranışsal tasarım desenleri, algoritmalar ve sorumlulukların nesneler arasındaki geçişleriyle ilgilenirler. Nesnelerin birbirleriyle nasıl iletişim kurduklarını incelerler. Çalışma zamanında, karmaşık kontrol akışlarını belli bir disipline bağlamaya çalışırlar. Çizelge 6.2 de her bir tasarım desenine ait şablonlar gösterilmektedir. Çizelge 6.2. Tasarım desenleri gösterimi Kurucu Yapısal Davranışsal Soyut Fabrika (Abstract Factory) Kurulum Nesnesi Adaptör (Adapter) Köprü (Bridge) Cephe (Facade) Komut (Command) Hatırlayıcı (Memento) Strateji (Strategy) (Builder) Dekorasyon (Decorator) Tekrarlayıcı (Iterator) Fabrika Yöntemi (Factory Method) Prototip (Prototype) Tek Nesne (Singleton) Ağaç Yapısı (Composite) Hafif Ağırlık (Flyweight) Vekil (Proxy) Durum (State) Sorumluluk Zinciri (Chain Of Responsibility) Arabulucu (Mediator) Gözlemci (Observer) Şablon Yöntemi (Template Method) Ziyaretçi (Visitor) Bilinmeyen Numaralar Servis uygulamasında cephe, vekil ve tek nesne tasarım desenleri kullanılmıştır. Bu desenleri tek tek açıklarsak;

62 48 Cephe tasarım deseni, sistemin detaylarını saklayarak, istemcinin dışarıdan sisteme ulaşabilmesi için tek bir ön yüz sunar. Sistemdeki alt sınıflara, bu ön yüz sınıfı ile ulaşılır. İstemci yalnızca sistemdeki bu ön yüz sınıfını bilir. Cephe karmaşık bir mevcut sistemin fonksiyonelitesini daha üst seviyede soyutlayarak kullanılmasını amaçlamaktadır. Cephe tasarımının amacı tüm sistemi yeni bir alt sistem olarak açığa çıkarmak değil özel bir işi örneğin veritabanında sorgu çalıştırıp sonucunu almayı daha basit ve anlaşılır kılmaktır. Örneğin Java da JDBC bir cephe tasarım desenidir. Veritabanına bağlanırken arka planda neler olup bittiğini bilemeyiz ve bilmemizde gerekmez. Bilinmeyen Numaralar uygulamasında 46 SQL sorgusu bir liste (enum) sınıfında toplanarak cephe bir arayüz üzerinden tek işlemde gerçekleştirilmiştir. Böylece sonradan eklenecek başka sorgular için yapı değişmemiş olacak sadece sorgunun liste sınıfına eklenmesiyle kod değiştirilmeden güncelleme yapılmış olacaktır. Şekil 6.5 de liste sınıftan sorguların alınıp işlenmesini gösteren kod parçacığı gösterilmektedir. Şekil 6.5. Uygulamaya ait kod parçacığı

63 49 Dış kurumların servise bağlandığında kullandıkları arayüz sınıfı cephe tasarım desenine göre tasarlanarak iç katmanda ve bu katmana bağlı sınıflara dışarıdan erişimi engellemiştir. Bu arayüz sınıfı sayesinde sistemin yapısı korunarak tek bir sınıfla servise erişim sağlanmıştır. Vekil nesnesi karmaşık bir nesneyi basit bir nesne olarak sunmak amacıyla kullanılır. Gerçek nesne ihtiyaç duyulmayana kadar oluşturulmaz. Bunun yerine vekil nesnesi kullanılır. Gerçek nesneye ihtiyaç duyulana kadar durumu idare eder. Eğer bir nesneyi oluşturmak çok zaman veya kaynak (bellek, işlemci vs.) gerektiriyorsa, vekil nesnesi bu oluşturmayı gerçek nesneye ihtiyaç duyulana kadar erteler. Karmaşık nesneden bir tane oluşturulur ve sonrasında karmaşık nesneye referans içeren vekil nesneleri oluşturulur. Bu vekil nesnelerine yapılan çağrılar asıl karmaşık nesneye yönlendirilir. Bu şekilde bir karmaşık nesne ve bu nesne gibi davranan vekil nesneleri olur. Uygulamada diğer kurumla bağlantıda vekil nesneleri oluşturularak erişim sağlanılmaktadır. Tek nesne tasarım deseni, bir sınıfın yalnızca tek bir nesnesinin oluşturulduğu ve genel olarak bu sınıfa yalnızca bu nesne üzerinden erişimin olduğu desendir. Bu tek nesneli sınıf, sistem içindeki genel değişkenleri içinde barındırabilir. Uygulamada yer alan ServiceClient.java sınıfı tekilliğe dayanan çoklu tekillik mimarisine sahiptir. Farklı durumlar için farklı ServiceClient nesnelerini önbelleğe alır. Sınıf sunucu tarafında servis bağlantısını sağlar ve güvenlik etkin Web Alanı Uygulama Sunucusu (WAS) üzerinde koşan bir web uygulamasına istek göndermeyi sağlar. Şekil 6.6 da ServiceClient sınıfına ait çoklu tekillik yapısını gösteren kod parçacığı gösterilmektedir.

64 50 Şekil 6.6. ServiceClient sınıfı çoklu tekillik yapısı Şekil 6.6 dan anlaşılacağı üzere özelleştirilmiş ServiceClient nesneleri çoklu tekillik yapısına uygun olarak çağrılmaktadır. Tasarım desenlerinin yanı sıra Java 2 Kurumsal Sürümü (J2EE) desenleri olarak bilinen tasarım şablonları vardır. Bu şablonlardan Veri Erişim Nesneleri (DAO) tasarım şablonu ile kullanılan veritabanına erişim ve veri depolama edinme işlemi daha soyutlaştırılarak diğer katmanların veritabanına olan bağımlılıkları azaltılır. DAO ile diğer katmanlar etkilenmeden veritabanı ve bilgi bankası değiştirilebilir. Şekil 6.7 de servise ait WSBilinmeyeNoDAO sınıfı gösterilmektedir. DAO yapısı serviste kullanılarak veritabanı bağımlılığı azaltılmıştır.

65 51 Şekil 6.7. Bilinmeyen numaralar servis DAO sınıfı kod parçacığı 6.5. Güvenlik Kontrolü UYAP & 118 Rehberlik Hizmetleri kapsamında verilen yargısal bilgiler güvenlik doğrulamasından geçen ve yalnızca dava dosyasının ya da icra takibinin tarafı olan kişilere verilmektedir. Dosyanın tarafı olmayan veya güvenlik doğrulamasından geçemeyen kişilere her hangi bir bilgi verilmemektedir. Çağrı merkezini arayan kişiye güvenlik doğrulaması için 11 haneli TC vatandaşlık kimlik numarası, nüfus cüzdan seri ve sıra numarası ile anne kızlık soyadının belirli harfleri sorulmakta ve tüm bu bilgileri doğru olarak söyleyen kişiye UYAP ta kayıtlı kendisi ile ilgili dosyalara ait bilgiler operatör aracılığıyla sözlü olarak iletilmektedir. Kullanıcılar ile operatörler arasındaki sesli görüşmeler hizmet kalitesi ve güvenliği açısından kayda alınmaktadır. Ayrıca serviste yazılım üzerinden loglar tutulmaktadır. Böylelikle hangi kurumun kim üzerinden sorgu yaptığı tespit edilmektedir. Servis UYAP üzerinden verildiği için herhangi bir problemde daha ayrıntılı cevap verebilmek adına diğer servislerde olmayan ek bir log tablosu daha Bilinmeyen Numaralar Servisi için eklenmiştir.

66 52 Kriptografi teknikleri yazılımlarda güvenliği sağlamada faydalanılan önemli tekniklerdir. Bilginin korunması için kriptografik kontrollerin kullanımına ilişkin bir politika geliştirilmeli ve gerçekleştirilmelidir. Bu yüzden serviste verilen bilgiler yazılımda ve ağ tarafında şifreleme algoritmalarına göre gönderilmektedir. Web güvenliği alanında en çok karşılaşılan tehditlerden olan SQL enjeksiyon, kullanıcı girdisinin denetlenmemesinden ya da yetersiz denetlenmesinden kaynaklanmaktadır. Yazılımda SQL enjeksiyonlarına engel olmak için, java.sql.statement ile dinamik sorgular oluşturmak yerine kullanıcı girdisi ile program kodunu birbirinden ayıran java.sql.preparedstatement yapısının UYAP ta özelleştirilmiş hali olan UyapPreparedStatement kullanılmıştır. Şekil 6.8 de bu kullanıma örnek servis yazılımından alınmış bir görüntü bulunmaktadır. Sorguda parametre olarak? nin kullanılması saldırıya karşı bir önlemdir. Şekil 6.8. SQL enjeksiyon saldırısına engel yazılım kod parçası

67 53 Internet Protokolü (IP) filtreleme WS ye erişimin IP bazlı kısıtlanmasını sağlayan güvenlik politikasıdır ve ağ tarafında servise bağlantı sağlamada 118 li firmaların IP leri dışında hiçbir IP nin bağlantısı kabul edilmemektedir. Dolayısıyla Adalet Bakanlığı Bilgi İşlem Dairesi nde tanımlı olmayan bir sunucudan sisteme bağlanılma olasılığı en aza indirilmektedir. Servis için ağ ve donanım tarafında gerekli güvenlik önlemleri alınmıştır. Ağ Adres Dönüşümü (NAT) sayesinde belli birkaç IP den dışarıya erişim sağlanmaktadır. Servis, Adalet Bakanlığı ve diğer 118 Rehberlik Hizmetlerine ait firmalar tarafından kiralık hat üzerinden uçtan uca Özel Sanal Ağ (VPN) bağlantısı kurularak hizmet vermektedir. Servis üzerinden gelen veriler, 256-bit Gelişmiş Şifreleme Standardı (AES) şifreleme algoritması kullanılarak şifrelenen VPN bağlantısı içinden ve birden fazla farklı tipte Saldırı Önleme Sistemleri (IPS) cihazından geçerek iletilmektedir. VPN teknolojisi ağ üzerinden gönderilen verinin şifrelenerek güvenliği sağlanan bir tünel içinden gönderilmesi olarak tanımlanabilir [29,30]. VPN güvenliği; kimlik doğrulama, erişim kontrolü, veri şifrelenmesi, simetrik ve asimetrik şifreli sistemler ve genel (public) anahtar yapıları kullanılarak sağlanmaktadır. İnternet üzerinden kritik bilgilerin transferi için gerekli olan gizlilik ve güvenlik konuları VPN teknolojileri yardımıyla çözülmüştür. Uygulama; ağ cihazları arasında yapılan VPN, VPN bağlantıda Noktadan Noktaya Protokol (PPP) içinde yapılan özel tünelleme ve tünelin şifrelenmesi ile daha güvenilir hale getirilmiştir. Kimlik doğrulama yazılımda kullanılan kullanıcı adı ve şifre ile sağlanır. Erişim kontrolü kaynak ve hedef IP adresleri ve port adresleri ile İnternet Protokol Güvenliği (IPSec) kontrolünden Dağıtık Servis Dışı Bırakma (DDOS) ve diğer saldırı çeşitlerine karşı koruma yapılarak sağlanır. Erişim tek makine üzerinden gerçekleşir. IPSec, İletişim Kontrol Protokolü/İnternet Protokolü (TCP/IP) iletişiminde verilerin şifrelenerek gönderildiği bir tekniktir. Uygulama IPSec VPN üzerinden iletişime geçmektedir. Servis Adalet Bakanlığı UYAP projesi üzerinden yürütüldüğü için

68 54 güvenlik açısından ağ cihazları, VPN tünel ve VPN sunucular hakkında çok fazla detaylı bilgi verilememektedir. Veri şifreleme, veriyi şifreli metin olarak bilinen anlaşılamayacak bir formata dönüştürme mekanizmasıdır. Böylece iletim esnasında veriler yetkisiz erişimlere karşı korunmuş olur. Veri şifrelenmesi ile iletim kayıplarının ve verinin değişikliğe uğramasının önüne geçilmiş olur. Güvenlik prensipleri olan gizlilik, doğruluk, bütünlük, süreklilik, izlenebilirlik, güvenirlik, kimlik doğrulama ve inkâr edilemezlik şifreleme teknikleri ve açık anahtar altyapı desteğiyle sağlanır [29]. Simetrik algoritmalardan 256 bit AES algoritması VPN tüneli şifrelemede kullanılmıştır. AES, uluslararası olarak kullanılan bir şifreleme sistemidir [31-33]. Kullanılan tekniklerden bazıları baytların yer değiştirmesi, 4x4 lük matrisler üzerine yayılmış metin parçalarının satırlarına uygulanan kaydırma işlemleridir. Çizelge 6.3. AES algoritması döngü sayıları Anahtar Uzunluğu (bit) Döngü Sayısı AES algoritması 128 bit veri bloklarını 128, 192, 256 bit anahtar seçenekleri ile Çizelge 6.3 de görülen döngü sayılarınca şifreleyen bir algoritmadır. AES algoritmasında her döngü dört katmandan oluşur. İlk olarak 128 bit veri 8 bitlik 4 4 bayt matrisine dönüştürülür. Daha sonra her döngüde sırasıyla baytların yer değiştirmesi, satırları öteleme, sütunları karıştırma ve anahtar planlamadan gelen o döngü için belirlenen anahtar ile XOR işlemleri yapılır. IPS, saldırı tespit ve önleme sistemi olarak da bilinen ağ ve/veya sistemi kötü niyetli aktivitelerden korumak için izleyen ağ güvenlik cihazıdır [34-39]. Bu sistemin temel görevi kötü niyetli aktiviteleri belirlemek, yapılan aktivite hakkında loglama tutma, kötü niyetli saldırıları durdurmak ve saldırının türünü rapor etmektir. IPS ler alarm gönderme, istenmeyen paketleri atma, ağı sıfırlama ve kusurlu IP adresinden gelen

69 55 trafiği bloklama gibi işlemleri gerçekleştirir. Bir IPS ayrıca TCP sıralama sorunlarını önler ve istenmeyen taşıma ve ağ katmanı seçeneklerini temizler. IPS ler gerçek zamanlı saldırı tespitini gösterebilme yeteneğine sahiptirler. Saldırı Önleme Sistemi kendi arasında 4 e ayrılır [38]. Bunlar: Ağa Saldırı Önleme Sistemi (NIPS): Tüm ağı şüpheli durumları tespit etmek için protokol analizi yöntemini kullanarak izler. Kablosuz Ağa Saldırı Önleme Sistemi (WIPS): Kablosuz ağ üzerindeki şüpheli durumları tespit etmek için kablosuz ağ protokolü ile izler. Ağ Davranış Analizi (NBA): Ağ trafiğindeki davranışların analizinde kullanılır. Ana Bilgisayara Saldırı Önleme Sistemi (HIPS): Ana bilgisayara yönelik saldırıları önlemek için kullanılır. Bilinmeyen Numaralar Servisi ne erişim için gelen paketler IP ve port bilgileri doğrulandıktan sonra birden fazla özel segmentlerden geçer. Bunlar değişik türde atakları algılayan ve doğrulama yapan IPS cihazlarıdır. Sunucu ve istemciden gelen her istek birden fazla güvenlik katmanından geçer Performans Analizi Uygulamanın ilk yazılım aşamasında tasarım desenlerini kullanarak kod yazmak yapıyı daha basit ve daha hızlı hale getirmiştir. Sürekli veritabanı bağlantısı kurulması önlenmiştir. Sisteme yük getiren gereksiz pahalı işlemler vekil deseni sayesinde önlenmiştir ve böylece sistem daha hızlı ve sağlıklı hale gelmiştir. Tez çalışmasında geliştirilen WS uygulaması sayfalama yapısına uygun olarak geliştirilmiştir. Her sayfada 20 kayıt dönmektedir. Uygulamanın performansını artırmak için cevap verme hızında iyileştirmeler yapılmıştır. Cevap verme hızını artırmak için her sayfada sunucuya gitmek yerine ilk bağlantıdan sonra tüm dosya bilgileri alınıp bir hafızada (hashmap) tutulmuştur. Bu sayede her 20 kayıttan sonra diğer sayfada görüntülenecek bilgilerin hafızadan alınması sağlanmıştır. İlk başta her

70 56 bir dosya sorgusu için sunucuya bağlanıp cevap alınma süresi ortalama 0,5 ms sürerken dosya sayısı arttığında örneğin 100 dosyalı bir sorguda bu süre ortalama 50 ms olmaktadır. Geliştirilen bu yöntem sayesinde tüm dosyaların alınma süresi ortalama 30 ms olmuştur. Bu iyileştirme yöntemi sonucunda performans % 40 artmıştır. Şekil 6.9 da servisi kullanan BN Telekom (118-80), ASSİSTT (118-18) ve PLUSS Telekom (118-70) firmalarının servise gönderdikleri istekler ve servisten dönen yanıtların log görüntüsü bulunmaktadır. Log görüntüsünde servise gönderilen istek ve yanıtların süreleri, hangi kullanıcı firmanın servise bağlandığı ve tarihi, hangi bilgiyi istediği, oluşturulan sessionid ve sonuç açıklaması bulunur. İlk bağlantıda TC kimlik numarası alınır diğer bağlantılar bu TC kimlik numarasına göre oluşturulan sessionid üzerinden yapılır. Yanıt süreleri ilk bağlantıda kişiye ait tüm bilgiler bir haritada tutulduğu için daha uzun sürede olmaktayken bağlandıktan sonraki diğer sorgular için yanıt süreleri daha kısa olmaktadır. Yanıt süreleri kişiye ait dava dosyalarının fazla veya az olma durumuna, bağlantıdan kaynaklanan kopuklara, hattaki yoğunluğa ve internete bağlanma hızına göre değişkenlik gösterir. Genel olarak servisin performansının milisaniye mertebesinde yanıt verebilecek hızda olması için kodda değişiklik yapılmıştır. Sisteme anahtarlı harita (map) yapısı eklenerek sessionid üzerinden veritabanına bir kere bağlantı yapılarak her sorguda tekrardan bağlantı yapılması engellenmiş ve tüm bilgiler haritada tutulmuştur. Sorgulara cevaplar bu harita üzerinden verilir ve oturum kapanınca bilgiler hafızadan silinir. İstemciye verilen cevap süresi hafızadan alınan bilgiler sayesinde çok daha hızlı bir hale getirilmiştir.

71 Şekil 6.9. Bilinmeyen numaralar servis log görüntüsü örneği 57

72 58 Sistem hız açısından test ortamında ve gerçek ortamda test edilmiştir. Çizelge 6.4, Çizelge 6.5 ve Çizelge 6.6 da gerçek ortamda sistemin 118 li firmalara ait istekleri ne kadar sürede cevapladığını gösteren test sonuçları bulunmaktadır. Çizelge 6.4. BN Telekom (118-80) istek yanıt süreleri kimlikdogrula süre (sn) getdosyalar süre (sn) sorgula süre (sn) 2,058 0,053 0,153 2,281 0,093 0,081 2,178 0,201 1,208 2,195 0,078 0,08 2,455 0,07 0,067 2,782 0,274 0,057 1,607 0,081 0,077 2,649 0,071 0,147 1,972 0,103 0,278 2,374 0,706 0,187 2,127 0,11 0,16 2,073 0,14 0,069 2,518 0,17 0,084 1,554 0,069 0,116 2,158 0,076 0,047 2,305 0,045 0,182 2,217 0,186 0,131 2,088 0,084 0,086 2,374 0,117 0,182 2,349 0,076 0,121 2,169 0,165 0,158 2,082 0,158 0,2 1,563 0,09 0,121 2,067 0,089 0,084 1,832 0,075 0,068 1,489 1,937 0,123 1,268 0,082 0,087 2,045 0,069 0,097 2,320 0,05 0,16

73 59 Çizelge 6.5. PLUSS (118-70) istek yanıt süreleri kimlikdogrula süre (sn) getdosyalar süre (sn) sorgula süre (sn) 2,085 0,072 0,214 2,373 0,103 0,063 1,506 0,671 0,067 1,563 0,066 0,076 0,654 0,536 0,045 0,554 0,064 0,102 0,641 0,075 0,056 2,382 1,089 0,175 2,466 0,064 0,087 2,971 0,058 0,154 2,140 0,172 0,065 2,147 0,063 0,243 2,223 0,073 0,137 2,204 0,105 0,098 1,586 0,095 0,043 2,059 0,097 0,086 1,938 0,073 0,077 1,267 0,038 0,049 2,190 0,104 0,096 0,780 0,088 0,124 0,568 0,03 0,088 2,110 0,101 0,093 Çizelge 6.6. ASSİSTT (118-18) istek yanıt süreleri kimlikdogrula süre (sn) getdosyalar süre (sn) sorgula süre (sn) 0,918 0,23 0,076 2,198 0,334 0,093 2,272 0,087 0,133 2,319 0,574 0,084 2,212 0,075 0,339 1,532 0,079 0,275 1,788 0,096 0,043 0,940 0,125 0,075

74 60 Çizelge 6.4, Çizelge 6.5 ve Çizelge 6.6 da verilen bilgiler tarihinde 13:45-13:52 ve 14:38-14:46 saatleri arasında servise bağlantı yapıldığında sunucu log verilerinden alınmıştır. Çizelge verileri işlemlerin çağrılma sırasına göre düzenlenmiştir. Çizelgelerden anlaşıldığı üzere servisten ortalama olarak tüm dosya bilgilerine ait bilgiler daha çok sorgulanmaktadır. Kimlik doğrulama işlemi için MERNİS servisiyle bağlantı kurulup cevap verildiğinden yanıt süreleri ortalama 2 sn sürmektedir. Yapılan iyileştirmeler sonucunda diğer işlemler için sunucudan milisaniye seviyelerinde hızlarla cevap alınmaktadır. Bu test sonuçlarına göre servis performansının hız açısından çok iyi durumda olduğu görülmektedir. Sistemin saldırılara karşı korunmasını sağlayan IPS cihazlarından üretilen Rehberlik Hizmetine ait günlük, haftalık, aylık ve yıllık ağ trafik analiz grafiği sonuç örnekleri Şekil 6.10, Şekil 6.11 ve Şekil 6.12 de gösterildiği gibidir. Grafiklerde görülen yeşil renkler ağa saniyede gelen trafiğin bit sayılarını mavi renkli çizgiler ise ağdan saniyede çıkan trafiğin bit sayılarını ifade eder. Grafiklerde hangi ağ cihazına nereden, hangi IP ve hangi hızla ne kadarlık bir yükün girip çıktığının günlük, haftalık, aylık ve yıllık olarak gösterimi bulunmaktadır. Sistemin veri transfer hızlarına bakıldığında servisin birim zamanda ağa çok fazla yük bindirmeden hızlı bir şekilde çalıştığı görülmektedir.

75 Şekil Günlük trafik analiz grafiği 61

76 62 Şekil Haftalık ve aylık trafik analiz grafiği Şekil Yıllık trafik analiz grafiği

77 63 Her bir 5 dakikalık ortalama verilerinden aritmetik ortalamalar bulunarak günlük, haftalık, aylık ve yıllık ortalama veriler oluşturulur. Şekil 6.10 daki grafikte günlük yük bilgisi 5 dakikalık ortalama verilerle oluşturulur. Şekil 6.11 deki grafikte yer alan haftalık yük bilgisi arka arkaya gelen 6 tane 5 dakikalık ortalamaların aritmetik ortalaması bulunarak oluşan 30 dakikalık ortalama verilerle oluşturulur. Yine Şekil 6.11 deki grafikte ardışık 24 tane 5 dakikalık ortalamaların aritmetik ortalaması bulunarak oluşturulan 2 saatlik ortalama verilerle aylık yük bilgisi oluşturulur. Şekil 6.12 deki grafikte aynı mantıkla ardışık 288 tane 5 dakikalık ortalamaların aritmetik ortalaması bulunarak oluşan 1 günlük ortalama verilerle yıllık yük bilgisi bulunur. Sistem 2012 nin şubat ayında hizmete sunulduğundan Şekil 6.12 deki grafik şubat ayından itibaren başlamaktadır Bilinmeyen Numaralar Servisi ni Diğer Uygulamalardan Ayıran Özellikleri Bilinmeyen Numaralar Servisi UYAP e-devlet projesi kapsamında geliştirilen bir servistir. Çok büyük veritabanı ve farklı kurumlarla ortak çalışabilmek için optimize edilmiş yazılım entegrasyon arayüzüne sahiptir. WS UYAP servislerinin bir parçası olarak tasarım desenlerine uygun geliştirilmeye ve genişletmeye açık yapıda tasarlanmıştır. Çok katmanlı servis tabanlı yazılım mimarisine uygundur. Kurulan güvenlik mekanizmaları ile UYAP verilerinin güvenli bir şekilde dağıtılmasını sağlamaktadır. Yeni nesil tasarım teknolojileri kullanılarak geliştirilmiştir (Java IBM Web WebSphere vb.). Halk açısından, UYAP kullanımının yaygınlaşması anlamında önemli bir işlevselliği bulunmaktadır. Literatürde yapılan çalışma sonuçları analiz edilerek optimizasyonlar uygulanmıştır. Uygulamanın tasarım aşamasında performans ve etkinlik kadar yazılımın değişime karşı esnekliği de dikkate alınmıştır. Bu amaçla yazılımın farklı katmanlarında farklı

78 64 amaçlara yönelik tasarım desenleri kullanılmıştır. Tasarım desenleri özellikle sistemin WS çağrımı, WS ile internet üzerinden iletişimi ve analizlerin uygulanması gibi amaçlarla farklı bileşenlerin sisteme dinamik olarak eklenmesi konusunda önemli yararlar sağlamıştır. Servis, çok katmanlı servis tabanlı yazılım mimarisine uygundur. Çalışma kapsamında internet üzerinde farklı özelliklerdeki istemci uygulamalar (118-18, ve Rehberlik Hizmetleri) tarafından standart protokoller aracılığıyla hizmet verebilecek çok katmanlı bir sistemin geliştirilmesi amaçlanmıştır. İstemciler farklı platformlardan bağlantı kuracakları için dış katmanının iç katmanı istemciden soyutlayarak çalışması sağlanmıştır. Ayrıca sistemin sunduğu servislere eklemeler yapılabilecek olması da yazılımın her katmanda değişime karşı esnek olmasını gerektirmektedir. Bilinmeyen Numaralar uygulaması bu gereksinimleri göz önüne alarak tasarlanmış ve Java WS kullanılarak gerçekleştirilmiştir Bilinmeyen Numaralar Servis Arayüzleri Arayüzler operatörlerin servise bağlanmak ve bağlandıktan sonra gerekli bilgileri alıp kullanıcıya istedikleri bilgileri vermek için tasarlanmış ekranlardır. Arayüzler.Net çatısı kullanılarak aspx sayfalarından oluşturulmuştur. Örnek arayüz görüntüleri Rehberlik hizmetinden BN Telekom Haberleşme firmasının ekran görüntüleridir. Şekil 6.13 de servise bağlanmak için operatörün kullandığı giriş ekranı gösterilmektedir. Servise bağlanabilmek için şekilde verilen tüm bilgilerin eksiksiz girilmesi gerekmektedir. Hatalı ya da eksik girişlerde bilgiler yanlışsa servisin yönlendirdiği hata açıklamaları, eksikse sistemde yapılan hata kontrollerinden gelen hata açıklamaları ekranda gösterilir.

79 65 Şekil Giriş ekranı Şekil 6.14 doğru giriş yaptıktan sonra gelecek ekrandır. Bu ekranda kişiye ait tüm davalar görüntülenir. Davalara ait temel bilgiler verilir. Sayfalama yapısı ile her sayfada 20 kayıt dönmektedir. Operatörü arayan kişi özellikle bir davası ile ilgili bilgi almak istiyorsa ekranda yer alan arama alanı ile dosya numarası girilerek hızlı bir şekilde ilgili dava dosyasına ulaşılır.

80 66 Şekil Tüm davaların listelendiği ekran Şekil 6.15 listelenen davalardan hangi dava hakkında ayrıntı bilgi isteniyorsa detaylar linkine tıklandıktan sonra gelen ekrandır. Bu ekranda sol menüde dava ile ilgili sorulabilecek servisten gelen sorgular dava çeşidine (hukuk, ceza, idari, icra, yargıtay ve bölge idari dava dosyaları) göre sıralanmaktadır. Sağ üst menüde kişiye ait dosya bilgileri, sağ alt menüde ise sol menüden seçilen sorgunun yanıtı tablo halinde gösterilir. Şekil 6.15 de yer alan örnek ekranda sol menüden dosyadaki son işlem sorgusu seçildiğinde gelen yanıt bilgisi gösterilmektedir.

81 Şekil Dava hakkında ayrıntılı bilgi veren ekran 67

82 Örnek Bir Servis Yazımı WS birçok farklı dil ve programda yazılabilir. Şekil 6.16 da bir WS nin nasıl oluşturulduğu ve çalıştırıldığı basit bir akış diyagramı yardımıyla anlatılmıştır. Şekil Servis akış diyagramı

83 69 Şekil 6.16 daki akış diyagramından da anlaşılacağı üzere ilk başta WS analizi ve tasarımı yapılır. Tasarım, veritabanı yapısı ve mimari yapı gibi gereksinimler göz önünde bulundurularak yapılır. Servisi oluşturmak için kullanılacak platform ve programlama dili seçildikten sonra servis için gerekli yazılım yapılır. Yazılan kodlar kontrol edildikten sonra servis oluşturulur. Bu aşamaya kadar servis sunucu taraflı olarak oluşturulmuştur fakat bu servis tek başına bir anlam ifade etmez. Bir WS nin kullanılabilmesi için istemciler tarafından çağrılması gerekir. Bu yüzden sonraki adımda servisi test etmek için bir servis istemcisi oluşturulur. İstemci oluşan servisin WSDL belgesi yardımıyla oluşturulur. İstemci olarak servise bağlantı yapılır ve servisin çalışırlığı test edilir. Günümüzde WS ler daha çok Java ve.net platformunda oluşturulmaktadır (WordPad, Notepad, Visual Studio gibi yazı editörlerinde de WS dosyası oluşturulabilir)..net platformunda WS lere dışarıdan erişim sağlamak için kod içinde servis için kullanılan metotların üstüne [WebMethod] etiketinin yazılması zorunludur. İstemci oluşturmak için de Web Referans kısmında servisin URL bilgisi verilir. Servis istemcileri bir web sayfası, konsol uygulaması, Windows uygulaması ve mobil telefonlar olabilir. Ayrıca direk HTTP GET metodu kullanılarak da bir servis çağırılabilir. Tez çalışmasında yer alan WS uygulaması IBM RAD kullanarak oluşturulduğu için örnek bir servis yazmayı ve servisi çağırmayı bu ortamda açıklayan adımlar aşağıda sıralanmıştır. Bir servis oluşturmak için ilk adımda RAD üzerinde yeni>proje (new>project) diyerek Şekil 6.17 de görünen ekrandan bir Java projesi seçilir.

84 70 Şekil Proje seçme ekranı İlerle (next) tuşuna basıp Şekil 6.18 de gösterilen ekrandan proje adı yazılır ve istenen Java versiyonu seçilir.

85 71 Şekil Proje oluşturma ekranı Oluşturulan projeye yeni>paket ekle (new>add package) seçeneğiyle bir paket eklenir. Daha sonra paket üzerinden yeni>sınıf ekle (new>add class) seçimiyle Şekil 6.19 daki gibi bir ekranda sınıf adı ve özellikler verilerek sonlandır (finish) tuşuna basılıp işlem bitirilir. Böylece projede bir paket içinde bir sınıf oluşturulmuş olunur.

86 72 Şekil Java sınıf oluşturma ekranı Oluşturulan sınıfa tıklanarak gerekli kodlamalar (metotlar, kontroller, bağlantılar, yetkiler vs.) yazılır (Şekil 6.20).

87 73 Şekil Kodlamanın yapıldığı Java sınıfı ekranı Kodlama işlemi bittikten sonra WS yi oluşturmak için sınıfın üzerine sağ tıklanarak web servis>web servis oluştur (web services>create web service) seçeneği seçilir (Şekil 6.21). Şekil WS oluşturmak için seçim yapan kod ekranı

88 74 WS seçimi yapıldıktan sonra WS için gerekli konfigürasyon ayarlarının yapıldığı Şekil 6.22 deki gibi bir ekran belirir. Bu ekranda sağ üst köşedeki linklerin üstlerine tıklanarak gelen ekranlar üzerinden gerekli seçimler yapılır. Şekil WS özelliklerinin seçildiği ekran Konfigürasyon ayarlarında Şekil 6.23 ve Şekil 6.24 deki gibi istenilen seçimler yapılır. Şekil 6.23 de servisin çalışacağı sunucu ve çalışma zamanında istenen yapı seçilir. RAD kurulurken yapılandırılan WAS Sevil v6.1 sunucusu lokalde çalışan sunucu olduğu için bu sunucu ve JAX-RPC yapısı seçilir. Şekil 6.24 de proje, tipi ve servisin sunucuya yükleneceği Kurumsal Arşiv (EAR) projesi seçilir.

89 75 Şekil Sunucu tabanlı yükleme seçimi Şekil Proje ayarlarının seçimi

90 76 Gerekli ayarlamalar yapıldıktan sonra ilerle (next) tuşuna basılarak ilerlenir. Gelen ekranda tekrar ilerle (next) tuşuna basılarak Şekil 6.25 de görünen WSDL belgesini oluşturan ekran gelir. Bu ekranda servisin kullanım amacını oluşturan metotların seçimi, WSDL adı, port adı ve gerekli diğer ayarlar yapılarak servise ait WSDL belgesinin yapılandırılması sağlanır. Şekil WSDL belgesini oluşturan ekran Gerekli ayarlar yapıldıktan sonra sonlandır (finish) tuşuna basılır ve sonraki adımda sunucu başlatılır ve sonlandır (finish) tuşuna basılarak işlem bitirilir (Şekil 6.26). Böylece servis ve servis için gerekli olan WSDL belgesi oluşturulmuş olur.

91 77 Şekil Sunucunun başlatılması ve WS oluşturma adımlarını bitirme ekranı Bu işlemler yapıldıktan sonra servisin çalışırlığı kontrol edilir. WSDL belgesinin konum (location) kısmında servisin çalıştığı Tekdüzen Kaynak Bulucu (URL) yazmaktadır. Bu URL bir tarayıcıda çalıştırılarak Şekil 6.27 da gösterilen ekranın gelmesi beklenir. Bu ekran geldiği zaman servisin düzgün çalıştığı anlaşılır. Şekil Servisin çalıştığını gösteren ekran Servisteki fonksiyonları çağırabilmek için servise bir istemci (client) yazılması gerekir. WSDL belgesinin üzerinde sağ tıklanarak web servis>istemci oluştur (web services>generate client) kısmı seçilir (Şekil 6.28).

92 78 Şekil WS istemci oluşturmak için seçim ekranı WS çalışma zamanı olarak Axis seçilmelidir. İkinci adımda kodun oluşturulacağı kaynak dosya seçilir. İşlem tamamlandıktan sonra WS Java sınıfları belirtilen dosya içinde oluşturulmuş olur. Bir test sınıfı oluşturularak servisi kontrol etmek için kodlama kısmına geçilir. Test sınıfında kaynak dosyada bulunan proxy (vekil) sınıfından bir nesne oluşturulur. Servise erişim için, bu nesneye servisin çalıştığı URL bilgisi uç nokta (endpoint adresi) olarak verilir. Daha sonra bu nesne üzerinden servisteki ilgili metotlara gerekli parametreler verilerek çağırım yapılır. Sonuçlar Java ekranına (console) yazdırılır. Aşağıda örnek test kodları bulunmaktadır.

93 79 public class BilinmeyenNoTest { public static void main(string[] args) throws NoSuchAlgorithmException, UnsupportedEncodingException { BilinmeyenNoWebServicesProxy proxy = new BilinmeyenNoWebServicesProxy(); proxy.setendpoint(" ilinmeyennowebservices"); String wsusername = "kullaniciadi"; String wspassword = "sifre"; try { WSKimlikDogrulaInput kimlikbilgileridvo=new WSKimlikDogrulaInput(); kimlikbilgileridvo.settckimlikno(" "); kimlikbilgileridvo.setnufuscuzdanseri("p01"); kimlikbilgileridvo.setnufuscuzdanno(123456); kimlikbilgileridvo.setannekizliksoyadilkkarakter("a"); kimlikbilgileridvo.setannekizliksoyadsonkarakter("b"); WSKimlikDogrulaOutput output=proxy.kimlikdogrula(kimlikbilgileridvo, wsusername, wspassword); System.out.println(output.getSessionId()); WSDosyaSorguOutput dosyasorgu=proxy.dosyalistesisorgula(wsusername, wspassword, output.getsessionid(), "", 0, 0); System.out.println(dosyaSorgu.getToplamDosyaAdedi()); System.out.println(dosyaSorgu.getDosyaBilgileri()); WSSorguInput input = new WSSorguInput(); input.setdosyaid(output.getdosyabilgileri()[0].getdosyaid().intvalue ()); input.setdosyaturu(output.getdosyabilgileri()[0].getdosyaturu()); input.settckimlikno(" "); input.setsorguid(1); WSSorguOutput sorguoutput=proxy.sorgula(wsusername, wspassword, output.getsessionid(), input); System.out.println(sorguOutput.getSorguCevap()); Bu şekilde servise erişilmiş ve sunduğu hizmetlerden yararlanılmış olunur. Servisten dönen bilgiler (Şekil 6.29), veritabanına kaydedilerek ya da servis için hazırlanan bir ekranda gösterilerek gerekli yerlerde kullanılmış olur.

94 Şekil Örnek WS sonucunun gösterimi 80

95 81 7. SONUÇ Tez çalışmasında e-devlet, WS, WS standartları ve güvenliği incelenmiş ve vatandaşların telefondan dava bilgilerini öğrenebileceği bir WS modeli gerçekleştirilmiştir. Tez çalışmasındaki WS uygulaması, incelenen kaynaklardan da faydalanarak UYAP servislerinin bir parçası olarak üç katmanlı mimari yapı ve tasarım desenlerine uygun geliştirilmeye ve genişletilmeye açık olarak tasarlanmıştır. Servis e-devlet uygulamalarında kurumlar arası etkileşimi içeren ve vatandaşa yönelik hizmet veren hukuk tabanlı bir uygulama olarak çalışmaya başlamıştır. UYAP kapsamında dâhil edilen Bilinmeyen Numaralar Servisi sayesinde vatandaşlar tarafı olduğu dava bilgilerini adliyelere gitmeden, yol ve konaklama gibi masrafları yapmadan, yolda ve adliyede beklemeden ve bu işlere enerji ve zaman harcamadan telefon ile ulaşabilmektedirler. Bu işler için harcadıkları zamanı başka işlerine ayırabilmektedirler. Servis vatandaşların telefonla dosyalarını takip edebilmeleri imkânını getirerek yargılama faaliyetlerinde mekân sınırını kaldırmış, ilgililerin dosyalarını daha etkin bir şekilde takip edebilmelerini sağlamıştır. Böylece zamandan tasarruf sağlayarak bilgiye erişimde hız ve etkinlik kazandırılmıştır. Bilinmeyen Numaralar servis güvenliğinin sağlanması için güvenli bir hat kullanılmıştır. Bu hat üzerinden gerekli güvenlik kontrolleri yapılarak sadece istenen firmaların servise erişimi sağlanmıştır. Böylelikle uygulamanın güvenirliği, güvenli bir hat üzerinden IPSec VPN ve AES şifreleme yapısı da eklenerek üst seviyelere çıkarılmıştır. Tez çalışmasında geliştirilen WS uygulaması sayfalama yapısına uygun olarak geliştirilmiştir. Uygulamanın performansını artırmak için cevap verme hızında iyileştirmeler yapılmıştır. Bu iyileştirme yöntemi sonucunda performans % 40 artmıştır. Böylece fazla kayıtlı bilgilerde sunucuya sürekli bağlantı yapılması önlenerek sistemin yorulması önlenmiş ve cevap verme süresi kısaltılmıştır. Servisin performansı Basit Ağ Yönetim Protokolü (SNMP) aracılığıyla cihazlardan sürekli takip edilmekte herhangi bir bağlantı problemi ya da bağlanma ve cevap hızında bir yavaşlama söz konusu olduğunda anında müdahale edilmektedir.

96 82 Uygulama kapsamında verilen yargısal bilgiler, güvenlik doğrulamasından geçen ve yalnızca dava dosyasının ya da icra takibinin tarafı olan kişilere verilmektedir. Dosyanın tarafı olmayan veya güvenlik doğrulamasından geçemeyen kişilere herhangi bir bilgi verilmemektedir. Geliştirilen uygulama; 13 Şubat 2012 tarihinde vatandaşların hizmetine sunulmuş olup tarihi itibariyle vatandaşlardan toplam adet çağrı alınmıştır. Ayrıca bu servis sayesinde Bakanlık tarihi itibariyle TL gelir elde etmiştir. Bilinmeyen Numaralar Servisi nin 7 Eylül 2012 tarihine kadar toplam kullanım sayısı olmuştur. UYAP sisteminden başka kurumlara daha önce verilen servislerin kullanım sayılarına bakıldığında bu servisin kullanılan 4. büyük servis olduğu görülmektedir. Bilinmeyen Numaralar Servisi, TÜSİAD ve Türkiye Bilişim Vakfı (TBV) tarafından ekonomide ve toplumsal yaşamda kalitenin, verimliliğin ve rekabet gücünün artırılmasına katkıda bulunmak amacıyla, 2003 yılından bu yana düzenlenen "e-tr Ödülleri" yarışmasında "Kamudan Vatandaşa e-hizmetler" kategorisinde 2010 yılı finalisti olmuştur. Bilinmeyen Numaralar Servisi nin hizmete girmesiyle hâkim ve savcılar ile yargı personelleri, bilgi ve belge talepleri nedeniyle harcanılan zamanı asıl işlerine ayırabilmektedirler. Sistemin yargı çalışanlarına ve vatandaşlara olan katkısını örneklerle açıklarsak; Nafaka parasının yatıp yatmadığı bilgisi adliyelere telefon edilerek verilmemektedir. Vatandaş bu bilgiyi öğrenmek için adliyeye gitmektedir. Bu vatandaş en yakın adliyeye tek vasıta ile gitmek için 2 TL gidiş ve 2 TL dönüş olmak üzere ortalama 4 TL fiyat ödeyecektir. İki vasıta ile gittiği düşünülürse bu fiyat 8 TL olacaktır. Sonuç olarak vatandaşa ulaşım için ortalama 6 TL gibi bir masraf çıkacaktır. Bu iş için ayrılacak vakit adliyede sıra bekleme ve gidiş dönüş süreleri dâhil ortalama 2-3 saat gibi bir süre olacaktır. Oysaki nafaka parasının yatıp yatmadığı bilgisini öğrenmek, Bilinmeyen Numaralar Servisi sayesinde en fazla 1 dk sürer ve bu işlem için

97 83 vatandaştan sadece 1 TL alınır. Geliştirilen uygulamayla istenilen bilgiye daha kısa sürede ve daha ucuza ulaşılır. Başka bir örnekte, günlük olarak adliyeye gelen kişi sayısının ortalama 1000 civarında olduğu ve bunlardan 200 kişinin davası, 200 kişinin de dosya açtırması olduğu varsayılırsa ortalama 600 kişinin soru sormak ve bilgi almak için adliyelere geldiği anlaşılır. Bu durumda adliyelerde çalışan memurlar işlerine ek olarak 600 kişinin sorularına cevap vermek için uğraşacaktırlar. Fakat bu kişiler, adliyeye gelmek yerine servisi kullanan firmalardan telefonla bilgi aldıklarında; adliye personelinin ekstra olan iş yükü kalkacak, stres ortamı azalacak ve daha verimli bir çalışma ortamı oluşacaktır. Ayrıca adliyeye gelen vatandaş farklı bir şehirde yaşıyorsa yol masraflarına en az 20 TL ile en fazla 100 TL gidiş dönüş otobüs fiyatı eklenecektir. Günübirlik geldiyse ortalama 3 ile 5 TL arası bir yemek masrafı ve 1 günlük bir vakit kaybı ortaya çıkacaktır. Uygulamayı kullanan 118 li firmaların telefon görüşmeleri sürelerine bakıldığında en az 1 dk ile en fazla 12 dk arasında sürdüğü görülmüştür. Her dakika 1 TL üzerinden hesaplandığından en az 1 TL en fazla ise 12 TL lik bir fiyat ödenmiş olacaktır. Adalet Bakanlığı na verilen aylık raporlardan alınan bilgilere göre normal konuşma süreleri ortalama 3 dk olarak görünmektedir ve bunun için ödenecek miktar 3 TL dir. Bu rakam vatandaşın cebinden çıkacak yol masrafından daha düşüktür ve ekonomik olarak daha uygun görünmektedir. Bundan sonraki adımda, servis güvenliğini artırmak için XML şifreleme ve WS- Güvenlik standartlarını destekleyen ve UYAP projesini aksatmayacak yapı kullanarak gönderilen verinin şifrelenmesi sağlanabilir. Servis iletişimi HTTP protokolü yerine SSL mekanizması ile HTTPS protokolü üzerinden yapılabilir. Kullanıcı adı ve şifre kısmı düz yazıyla gönderildiği için kimlik bilgilerinin taşınmasında güvenlik problemleri ortaya çıkabilir. Servisin geliştirilmesi aşamasında bu bilgilerin şifrelenmiş bir şekilde gönderilerek sorunun çözülmesi sağlanabilir. Erişim kontrolünü güçlendirmek adına serviste e-imza kullanımı sağlanabilir.

98 84 KAYNAKLAR 1. İnternet: Devlet Planlama Teşkilatı Müsteşarlığı e-devlet Proje ve Uygulamaları DevletProjeVeUygulamalari.pdf (2005), (Erişim tarihi Kasım 2012). 2. Arifoğlu, A., Körnes, A., Yazıcı, A., Akgül, M.K., Ayvalı, A., E-Devlet Yolunda Türkiye, Türkiye Bilişim Derneği (TBD), Ankara, 22 (2002). 3. İnternet: TC. Adalet Bakanlığı UYAP Genel Bilgi (2010), (Erişim tarihi Kasım 2012). 4. İnternet: Web Servisleri ve Kayıtçılar (UDDI & RDF) (2003), (Erişim tarihi Kasım 2012). 5. İnternet: Akademik Bilişim Konferansları İnternet Servisi Destekli Grafik Arayüzlü Bilgi İzleme Sistemi (2005), (Erişim tarihi Kasım 2012). 6. Altınova, H., Yalçın, Y., Arslan, S., Web Servis Tabanlı Geliştirilen Mobil Uygulamalar: ODTÜ Mobil Öğrenci İşleri Bilgi Sistemi (MOİBS), Akademik Bilişim, Çanakkale, (2008). 7. Yüksel, M. E., Zaim, A. H., GSM/GPRS Aygıtları Üzerinden Çok Dilli SMS Gönderme, Akademik Bilişim, Şanlıurfa, (2009). 8. Turan, F., Web Servisleri Tabanlı Coğrafi Bilgi Sistemleri, Yüksek Lisans Tezi, Başkent Üniversitesi Fen Bilimleri Enstitüsü, Ankara, (2006). 9. İnternet: TMMOB Elektrik Mühendisleri Odası Tasarım Desenleri ve Java Web Servisleri ile Çok Katmanlı Bir Sistem Tasarımı, (2007), (Erişim tarihi Kasım 2012). 10. Anagün, Y., Üç Sıralı İstemci-Sunucu Mimarisinde Web Servisleri Kullanımı ve Uygulaması, Yüksek Lisans Tezi, Dumlupınar Üniversitesi Fen Bilimleri Enstitüsü, Kütahya, (2007). 11. Dülgerler, M., Kurumsal Kaynak Planlaması ve Web Servisleri İle Bir ERP Uygulaması, Yüksek Lisans Tezi, Beykent Üniversitesi Fen Bilimleri Enstitüsü, İstanbul, (2007).

99 Kuru, İ., E-Öğrenme Projelerinde Xml Web Servislerinin Kullanımı ve Örnek Uygulama, Yüksek Lisans Tezi, İstanbul Üniversitesi Fen Bilimleri Enstitüsü, İstanbul, (2006). 13. Gümüşkaya, H., Gürel, A. V., Nural, M. V., Küçük Mobil Cihazlarda Kablosuz Ağlar Üzerinde SOAP, RMI ve TCP Performans Analizi, 2. Ulusal Yazılım Mimarisi Konferansı, İzmir, (2008). 14. Eskicioğlu, F., Bağımsız Platformlar İle Web Servislerinin Geliştirilmesi, Yüksek Lisans Tezi, Çanakkale OnsekizMart Üniversitesi Fen Bilimleri Enstitüsü, Çanakkale, 4-42 (2006). 15. Gray, N. A. B., Comparison of Web Services, Java-RMI, and CORBA ServiceImplementations, Fifth Australasian Workshop on Software and System Architectures, Melbourne, Australia, (2004). 16. İnternet: Bell Labs Innovations Reinventing the Wheel? CORBA vs. Web Services, (2002), (Erişim tarihi Kasım 2012). 17. İnternet: Türkiye de İnternet Konferansları Web Servisleri: Internet Devriminde İkinci Aşama?, (2001), (Erişim tarihi Kasım 2012). 18. İnternet: W3C Web of Services, (2002), (Erişim tarihi Kasım 2012). 19. İnternet: IBM Understanding Web Services, n/ryman.html (2003), (Erişim tarihi Kasım 2012). 20. İnternet: Xml Web Servislerine Giriş-1 (2004), (Erişim tarihi Kasım 2012). 21. İnternet: IBM Web Services Conceptual Architecture (WSCA 1.0) (2001), (Erişim tarihi Kasım 2012). 22. İnternet: Sun Overview of SOAP (2001), (Erişim tarihi Temmuz 2012). 23. İnternet: IBM Understanding UDDI (2002), (Erişim tarihi Kasım 2012).

100 İnternet: IBM Java web services: Understanding and modeling WSDL (2011), (Erişim tarihi Kasım 2012). 25. İnternet: W3C Web Services Description Language (WSDL) (2001), (Erişim tarihi Kasım 2012). 26. İnternet: Web Güvenlik Topluluğu Web Servisleri (2007), (Erişim tarihi Kasım 2012). 27. İnternet: Tasarım Desenleri (2008), (Erişim tarihi Kasım 2012). 28. İnternet: Tasarım Şablonu Nedir? (2008), (Erişim tarihi Kasım 2012). 29. Demir, F., Güvenli Veri İletiminde Kullanılan VPN Tiplerinin Uygulaması ve Performans Analizi, Yüksek Lisans Tezi, İstanbul Teknik Üniversitesi Fen Bilimleri Enstitüsü, İstanbul, 7-24 (2010). 30. Yüksel, Z., Ağ Güvenliği ve Güvenlik Duvarında VPN ve NAT Uygulamaları, Yüksek Lisans Tezi, Yıldız Teknik Üniversitesi Fen Bilimleri Enstitüsü, İstanbul, (2007). 31. Yıldırım, K., Veri Şifrelemesinde Simetrik ve Asimetrik Anahtarlama Algoritmalarının Uygulanması (Hybrid Şifreleme), Yüksek Lisans Tezi, Kocaeli Üniversitesi Fen Bilimleri Enstitüsü, Kocaeli, (2006). 32. Dalkılıç, G., Yıldızoğlu, G., Tek Anahtarlı Yeni Bir Şifreleme Algoritması Daha, Akademik Bilişim, Çanakkale, (2008). 33. Başkök, M. D., AES Şifreleme Algoritmasının Modellenmesi, Yüksek Lisans Tezi, Gazi Üniversitesi Fen Bilimleri Enstitüsü, Ankara, 4-13, (2007). 34. Fuchsberger, A., Intrusion Detection Systems and Intrusion Prevention Systems, Information Security Technical Report, 10: (2005). 35. Ierace, N., Urrutia, C., Bassett, R., Intrusion Prevention Systems, ACM Ubiquity, 6 (19): 1-9 (2005). 36. Weinsberg, Y., Tzur-David, S., Dolev, D., Anker, T., High Performance String Matching Algorithm for a Network Intrusion Prevention System (NIPS), 2006 Workshop onhigh Performance Switching and Routing (HPSR06), Poznan, Poland, (2006).

101 Battistoni, R., Gabrielli, E., Mancini, L. V., A Host Intrusion Prevention System for Windows Operating Systems, Computer Security ESORICS 2004, Samarati, P., Ryan, P., Gollmann, D., Molva, R., Springer Berlin / Heidelberg, (2004). 38. Scarfone, K., Mell, P., Guide to Intrusion Detection and Prevention Systems (IDPS), National Institute of Standarts and Technology, (2007). 39. Güven, E. N., Sağıroğlu, Ş., Saldırı Tespit Sistemleri Üzerine Bir İnceleme, 3. Uluslararası Katılımlı Bilgi Güvenliği ve Kriptoloji Konferansı, Ankara, (2008).

102 EKLER 88

103 89 EK-1. Bilinmeyen numaralar servis uygulaması WSDL belgesi Servis yazıldıktan sonra istemcinin servisi kullanabilmesi için gerekli olan WSDL belgesi kullanılan program yardımıyla oluşturulur. WSDL belgesinde serviste kullanılan metotlar aldığı ve döndürdüğü tipleri de içererek yer alır. Belgenin sonunda yer alan konum (location) kısmında servisin adresi otomatik olarak yazılır. <?xmlversion="1.0"encoding="utf-8"?> <wsdl:definitionstargetnamespace=" r"xmlns:impl=" /bean.webservices.uyap.gov.tr"xmlns:tns2=" k.uyap.gov.tr"xmlns:tns3=" p://schemas.xmlsoap.org/wsdl/"xmlns:wsdlsoap=" hema"> <wsdl:types> <schematargetnamespace=" ttp:// onk.uyap.gov.tr"xmlns:wsdl=" sd=" <importnamespace=" <elementname="sorgularesponse"> <complextype> <sequence> <elementname="sorgulareturn"nillable="true"type="tns2:wssorguoutput" /> </sequence> </complextype> </element> <elementname="kimlikdogrula"> <complextype> <sequence> <elementname="kimlikbilgileridvo"nillable="true"type="tns2:wskimlikd ogrulainput"/> <elementname="wsusername"nillable="true"type="xsd:string"/> <elementname="wspassword"nillable="true"type="xsd:string"/> </sequence> </complextype> </element> <elementname="kimlikdogrularesponse"> <complextype> <sequence> <elementname="kimlikdogrulareturn"nillable="true"type="tns2:wskimlik DogrulaOutput"/> </sequence> </complextype> </element> <elementname="dosyalistesisorgula"> <complextype> <sequence> <elementname="wsusername"nillable="true"type="xsd:string"/> <elementname="wspassword"nillable="true"type="xsd:string"/> <elementname="sessionid"nillable="true"type="xsd:string"/>

104 90 EK-1.(Devam) Bilinmeyen numaralar servis uygulaması WSDL belgesi <elementname="dosyano"nillable="true"type="xsd:string"/> <elementname="ilkkayitno"type="xsd:int"/> <elementname="sonkayitno"type="xsd:int"/> </sequence> </complextype> </element> <elementname="dosyalistesisorgularesponse"> <complextype> <sequence> <elementname="dosyalistesisorgulareturn"nillable="true"type="tns2:ws DosyaSorguOutput"/> </sequence> </complextype> </element> <elementname="sorgula"> <complextype> <sequence> <elementname="wsusername"nillable="true"type="xsd:string"/> <elementname="wspassword"nillable="true"type="xsd:string"/> <elementname="sessionid"nillable="true"type="xsd:string"/> <elementname="sorguinput"nillable="true"type="tns2:wssorguinput"/> </sequence> </complextype> </element> </schema> <schematargetnamespace=" s=" gov.tr"xmlns:wsdl=" // <importnamespace=" <complextypename="wssorguinput"> <sequence> <elementname="tckimlikno"nillable="true"type="xsd:string"/> <elementname="dosyaid"type="xsd:int"/> <elementname="sorguid"type="xsd:int"/> <elementname="dosyaturu"type="xsd:int"/> </sequence> </complextype> <complextypename="wssorguoutput"> <complexcontent> <extensionbase="tns3:wsgeneralresponsedvo"> <sequence> <elementname="sorgucevap"nillable="true"type="tns2:arrayofwssorgucev aprow"/> <elementname="sorguid"type="xsd:int"/> </sequence> </extension> </complexcontent> </complextype> <complextypename="wssorgucevaprow"> <sequence> <elementname="wssorgucevapdatas"nillable="true"type="tns2:arrayofwss orgucevapdata"/> </sequence> </complextype>

105 91 EK-1.(Devam) Bilinmeyen numaralar servis uygulaması WSDL belgesi <complextypename="wssorgucevapdata"> <sequence> <elementname="attributename"nillable="true"type="xsd:string"/> <elementname="attributevalue"nillable="true"type="xsd:string"/> </sequence> </complextype> <complextypename="arrayofwssorgucevapdata"> <sequence> <elementmaxoccurs="unbounded"minoccurs="0"name="wssorgucevapdata"nil lable="true"type="tns2:wssorgucevapdata"/> </sequence> </complextype> <complextypename="arrayofwssorgucevaprow"> <sequence> <elementmaxoccurs="unbounded"minoccurs="0"name="wssorgucevaprow"nill able="true"type="tns2:wssorgucevaprow"/> </sequence> </complextype> <complextypename="wskimlikdogrulainput"> <sequence> <elementname="tckimlikno"nillable="true"type="xsd:string"/> <elementname="adi"nillable="true"type="xsd:string"/> <elementname="soyadi"nillable="true"type="xsd:string"/> <elementname="nufuscuzdanseri"nillable="true"type="xsd:string"/> <elementname="nufuscuzdanno"type="xsd:int"/> <elementname="annekizliksoyadilkkarakter"nillable="true"type="xsd:st ring"/> <elementname="annekizliksoyadsonkarakter"nillable="true"type="xsd:st ring"/> </sequence> </complextype> <complextypename="wskimlikdogrulaoutput"> <complexcontent> <extensionbase="tns3:wsgeneralresponsedvo"> <sequence> <elementname="loginsonuckodu"type="xsd:int"/> <elementname="sessionid"nillable="true"type="xsd:string"/> <elementname="tckimlikno"nillable="true"type="xsd:string"/> <elementname="loginsonucaciklama"nillable="true"type="xsd:string"/> </sequence> </extension> </complexcontent> </complextype> <complextypename="wsdosyasorguoutput"> <complexcontent> <extensionbase="tns3:wsgeneralresponsedvo"> <sequence> <elementname="toplamdosyaadedi"type="xsd:int"/> <elementname="dosyabilgileri"nillable="true"type="tns2:arrayofwsdosy abilgileri"/> </sequence> </extension> </complexcontent> </complextype> <complextypename="wsdosyabilgileri">

106 92 EK-1.(Devam) Bilinmeyen numaralar servis uygulaması WSDL belgesi <sequence> <elementname="birimadi"nillable="true"type="xsd:string"/> <elementname="birimid"nillable="true"type="xsd:string"/> <elementname="dosyaturu"type="xsd:int"/> <elementname="dosyano"nillable="true"type="xsd:string"/> <elementname="sifati"nillable="true"type="xsd:string"/> <elementname="durusmatarihi"nillable="true"type="xsd:string"/> <elementname="tarafbilgileri"nillable="true"type="tns2:arrayofwstara fbilgileri"/> <elementname="dosyaid"nillable="true"type="xsd:decimal"/> <elementname="sucturuadi"nillable="true"type="xsd:string"/> </sequence> </complextype> <complextypename="wstarafbilgileri"> <sequence> <elementname="adi"nillable="true"type="xsd:string"/> <elementname="dosyakisiid"type="xsd:long"/> <elementname="tarafrolu"nillable="true"type="xsd:string"/> <elementname="anaadi"nillable="true"type="xsd:string"/> <elementname="babaadi"nillable="true"type="xsd:string"/> <elementname="kisimikurummu"type="xsd:int"/> <elementname="dogumtarihi"nillable="true"type="xsd:string"/> <elementname="dogumyeri"nillable="true"type="xsd:string"/> <elementname="cinsiyet"nillable="true"type="xsd:string"/> <elementname="soyadi"nillable="true"type="xsd:string"/> <elementname="tckimlikno"nillable="true"type="xsd:string"/> <elementname="sifati"nillable="true"type="xsd:string"/> <elementname="kisikurumid"type="xsd:long"/> <elementname="adresleri"nillable="true"type="tns2:arrayofwsadresbilg ileri"/> <elementname="sucu"nillable="true"type="xsd:string"/> </sequence> </complextype> <complextypename="wsadresbilgileri"> <sequence> <elementname="adres"nillable="true"type="xsd:string"/> <elementname="il"nillable="true"type="xsd:string"/> <elementname="ilce"nillable="true"type="xsd:string"/> <elementname="kisikurumid"type="xsd:long"/> </sequence> </complextype> <complextypename="arrayofwsadresbilgileri"> <sequence> <elementmaxoccurs="unbounded"minoccurs="0"name="wsadresbilgileri"nil lable="true"type="tns2:wsadresbilgileri"/> </sequence> </complextype> <complextypename="arrayofwstarafbilgileri"> <sequence> <elementmaxoccurs="unbounded"minoccurs="0"name="wstarafbilgileri"nil lable="true"type="tns2:wstarafbilgileri"/> </sequence> </complextype> <complextypename="arrayofwsdosyabilgileri"> <sequence>

107 93 EK-1.(Devam) Bilinmeyen numaralar servis uygulaması WSDL belgesi <elementmaxoccurs="unbounded"minoccurs="0"name="wsdosyabilgileri"nil lable="true"type="tns2:wsdosyabilgileri"/> </sequence> </complextype> </schema> <schematargetnamespace=" xmlns:xsd=" <complextypename="wsgeneralresponsedvo"> <sequence> <elementname="serviceresponseid"type="xsd:int"/> <elementname="serviceresponsedescription"nillable="true"type="xsd:st ring"/> </sequence> </complextype> </schema> </wsdl:types> <wsdl:messagename="dosyalistesisorgularequest"> <wsdl:partelement="impl:dosyalistesisorgula"name="parameters"/> </wsdl:message> <wsdl:messagename="kimlikdogrularesponse"> <wsdl:partelement="impl:kimlikdogrularesponse"name="parameters"/> </wsdl:message> <wsdl:messagename="sorgularequest"> <wsdl:partelement="impl:sorgula"name="parameters"/> </wsdl:message> <wsdl:messagename="kimlikdogrularequest"> <wsdl:partelement="impl:kimlikdogrula"name="parameters"/> </wsdl:message> <wsdl:messagename="sorgularesponse"> <wsdl:partelement="impl:sorgularesponse"name="parameters"/> </wsdl:message> <wsdl:messagename="dosyalistesisorgularesponse"> <wsdl:partelement="impl:dosyalistesisorgularesponse"name="parameters "/> </wsdl:message> <wsdl:porttypename="bilinmeyennowebservices"> <wsdl:operationname="sorgula"> <wsdl:inputmessage="impl:sorgularequest"name="sorgularequest"/> <wsdl:outputmessage="impl:sorgularesponse"name="sorgularesponse"/> </wsdl:operation> <wsdl:operationname="kimlikdogrula"> <wsdl:inputmessage="impl:kimlikdogrularequest"name="kimlikdogrulareq uest"/> <wsdl:outputmessage="impl:kimlikdogrularesponse"name="kimlikdogrular esponse"/> </wsdl:operation> <wsdl:operationname="dosyalistesisorgula"> <wsdl:inputmessage="impl:dosyalistesisorgularequest"name="dosyaliste sisorgularequest"/> <wsdl:outputmessage="impl:dosyalistesisorgularesponse"name="dosyalis tesisorgularesponse"/> </wsdl:operation> </wsdl:porttype>

108 94 EK-1.(Devam) Bilinmeyen numaralar servis uygulaması WSDL belgesi <wsdl:bindingname="bilinmeyennowebservicessoapbinding"type="impl:bil inmeyennowebservices"> <wsaw:usingaddressingwsdl:required="false"xmlns:wsaw=" org/2006/05/addressing/wsdl"/> <wsdlsoap:bindingstyle="document"transport=" rg/soap/http"/> <wsdl:operationname="sorgula"> <wsdlsoap:operationsoapaction="sorgula"/> <wsdl:inputname="sorgularequest"> <wsdlsoap:bodyuse="literal"/> </wsdl:input> <wsdl:outputname="sorgularesponse"> <wsdlsoap:bodyuse="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operationname="kimlikdogrula"> <wsdlsoap:operationsoapaction="kimlikdogrula"/> <wsdl:inputname="kimlikdogrularequest"> <wsdlsoap:bodyuse="literal"/> </wsdl:input> <wsdl:outputname="kimlikdogrularesponse"> <wsdlsoap:bodyuse="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operationname="dosyalistesisorgula"> <wsdlsoap:operationsoapaction="dosyalistesisorgula"/> <wsdl:inputname="dosyalistesisorgularequest"> <wsdlsoap:bodyuse="literal"/> </wsdl:input> <wsdl:outputname="dosyalistesisorgularesponse"> <wsdlsoap:bodyuse="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:servicename="bilinmeyennowebservicesservice"> <wsdl:portbinding="impl:bilinmeyennowebservicessoapbinding"name="bil inmeyennowebservices"> <wsdlsoap:addresslocation=" eb/services/bilinmeyennowebservices"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

109 95 EK-2. Servisle verilen dosya bilgileri Taraf olunan bir dosyanın keşif tarihi Taraf olunan bir dosyanın diğer tarafları Taraf olunan bir dosyada duruşma tarihi Taraf olunan bir dosyaya hangi dilekçelerin verildiği Taraf olunan bir dosyanın tebligat bilgileri Taraf olunan bir dosyanın ne zaman hangi dosya ile birleştiği Taraf olunan bir dosyada tebligat yapılıp yapılamadığı Taraf olunan bir dosyada en son yapılan işlemi Taraf olunan bir dosyanın durumu hakkındaki bilgileri Taraf olunan bir dosyanın karar türü Taraf olunan bir dosyanın dava türü Taraf olunan bir dosyanın avukat bilgileri Taraf olunan bir dosyanın dava miktarı Taraf olunan bir dosyanın ek karar bilgileri Taraf olunan bir dosyanın karar sonucunun kesinleşip/kesinleşmediği Taraf olunan bir dosyanın ara karar evrakı olup olmadığı Taraf olunan bir dosyada temyiz başvuru olup olmadığı Taraf olunan bir dosyanın temyize gönderilip gönderilmediği Taraf olunan bir dosyanın temyiz sonucu Taraf olunan bir dosyanın harç bilgileri Taraf olunan bir dosyanın masraf bilgileri Taraf olunan bir dosyanın teminat bilgileri Taraf olunan bir dosyanın reddiyat bilgileri Taraf olunan bir dosyanın bilirkişi raporu sonucunun dönüp dönmediği Taraf olunan bir dosyanın bilirkişi raporuna itiraz edilip edilmediği Taraf olunan bir dosyanın bilirkişi incelemesine verilip verilmediği Taraf olunan bir dosyada tahliye olup olmadığı Taraf olunan bir dosyada yakalama kararının kaldırılıp kaldırılmadığı Taraf olunan bir dosyadaki infaz bilgisi Taraf olunan dosyadaki ön ödeme bilgisi

110 96 EK-2. (Devam) Servisle verilen dosya bilgileri Taraf olunan bir dosyadaki adli kontrol bilgisi Taraf olunan bir dosyada avukatımın davaya girip girmediği bilgisi Taraf olunan bir dosyada satışa sunulan malların bilgisi Taraf olunan bir dosyada tehiri icra bilgileri Taraf olunan bir dosyada davalı idarece savunma verilip verilmediği Taraf olunan bir dosyada yürütmeyi durdurma kararı verilip verilmediği Bir icra dosyasında haczolunan malların hangi gün satışa sunulacağı

111 97 EK-3. Performans analizleri Şekil kurumuna ait günlük trafik analizi

112 98 EK-3. (Devam) Performans analizleri Şekil kurumuna ait haftalık ve aylık trafik analizleri Şekil kurumuna ait yıllık trafik analizi

113 99 EK-3. (Devam) Performans analizleri Şekil kurumuna ait günlük trafik analizi

114 100 EK-3. (Devam) Performans analizleri Şekil kurumuna ait haftalık ve aylık trafik analizi Şekil kurumuna ait yıllık trafik analizi