Fatih Boy

   Bir önceki makalemizde kaldığımız yerden devam ederek bu makalemde de xml web servislerine dair hatalı kullanımları örneklemeye devam edeceğim. Bu makaledeki odak noktamız biraz daha web servislerin yapısı, iletişim şekli olacak.

   Pek çok servis tasarımında gözden kaçan noktalardan birisi en nihayetinde web ortamında çalışıldığıdır. Yazılım geliştiricinin kendi bilgisayarında sorunsuz çalışan bir xml web servisi, gerçek ortama geçildiğinde pek çok problemle karşılaşabilir. Bu problemlerin başında da sahadan gelen yoğun kullanımı,yükü, kaldıramayan sistemlerin zamanla yavaşlayarak gelen isteklere geç, hatta çok çok geç yanıt vermesidir.

   Aranızdan, çok geç yanıt vermesi hiç yanıt vermemesinden iyidir diyenleri duyar gibiyim; ama buradaki ince ayrıntı ne kadar geç olduğudur. İzin verin açıklayayım;

   Bir xml web servisinde yapılan işlem aslında -en az- iki makineye dağılmış bir işlemdir. İstemcide çalışan bir iş mantığı sonrası oluşan veri işlenmesi üzere sunucuya iletilir, sunucuda çalışan bir başka iş mantığı ise sonucunu yenide istemciye iletir. Burada verinin iletilmesi işlemi http üzerinden soap mesajları ile yapılmaktadır. İstemci bir soket açarak sunucudaki bir port’a veri yazar, sunucu bu porttan gelen veriyi okur, işler ve sonucu açık kalan bu bağlantıdan geri istemciye iletir. Aradaki iletişim sunucu ile istemci arasında açılan bu kanaldan yapılacaktır. Sistem kaynaklarının en uygun şekilde kullanılması amacıyla da açılan bu kanal sonsuza kadar açık bekletilmez.  Bir aktivite olmaması durumunda belirli bir süre sonunda aradaki kanal/bağlandı/soket kapatılacaktır. Bunun en temel denedi DOS v.b. sunucu kaynaklarını tüketerek sunucunun hizmet vermesini engelleyen  saldırılardan korunmaktır. Siz aksini belirtmediğiniz sürece .net istemcileri 1 dakika sonunda sunucudan yanıt gelmediyse bağlantıyı sonlandıracaktır.

   Bu detaydan sonra sunucudaki yoğunluğun istemci tarafında ne gibi problemlere sebep olabileceğini inceleyelim. İstemci olarak bir bağlantı açarak web servis çağrısı yaptınız ve sunucuda bir süreci başlattınız. Diyelim ki yoğunluktan dolayı sunucu size 1 dakika içerisinde yanıt veremedi ve istemci otomatik olarak bağlantıyı sonlandırdı. Bu durumda istemci uygulama zaman aşım (time-out) hatası alacaktır; fakat istemcinin bu hatayı alıyor olması aslında tüm sürecin o noktada sonlandığı anlamına gelmeyecektir. İstemcide alınan bu zaman aşım hatası aslında sadece aradaki bağlantının istemci tarafından sonlandığını belirtmektedir ve sunucuda yapılan işlem hakkında bir bilgi vermeyecektir. Bunun anlamı, istemci olarak siz zaman aşım hatası almış bile olsanız sunucuda işlemin devam ederek bir süre sonra sonuçlanabileceğidir. Örneğin; yapılan işleme dair tekil bir bilet bilgisi işlem sonucunda size iletiliyorsa, böylesi bir durumda sunucunun istemciye ulaşabileceği bir kanal kalmayacağı için bu bilgi de iletilemeyecektir.

   Kamuya açık bir web servis geliştiriyorsanız bu oldukça önemli bir nokta. Durum hakkında istemcileri uyararak zaman aşım süresini ,örneğin, 2 dakika yapmalarını isteyebilirsiniz tabi ki; ama unutmayın, hiç kimseyi bunu yapmaya zorlayamazsınız. Bu durumda geliştirdiğiniz xml web servislerinde böylesi senaryoları göze alarak bağlantının x bir nedenle sonlanabileceğini de düşünmeli, böylesi bir durumda istemcilerin işlem sonucu sorgulayabilecekleri ve hatta işlemi iptal edebilecekleri ek servis metotlarını da sunuyor olmanız gereklidir.

   Buna daha güzel bir çözüm ise web servislerinizde transaction desteği sunarak işlemleri atomik gerçekleştirmenizdir. İstemcinin bir şekilde sonucu okumamış olması durumunda sunucuda yapılan işlemi iptal edebilirsiniz. Bu tarz yaklaşımları destekleyen standartlar hali hazırda kullanılabilmekte, örneğin WS-Atomic Transaction; ama üzülerek belirtmeliyim ki  şu ana kadar aralarında pek çok önemli ve büyük projenin de olduğu, tecrübe ettiğim onca kamu projesi arasında buna benzer standartları destekleyen maalesef ki bulunmamakta.