Web Servis dediğimiz ne(değil)dir… -1-

   Bundan yaklaşık 2 yıl önce sizlerle WCF’e giriş niteliğinde bir makale paylaşmıştım ve aslına bakarsanız düşündüğümün de üzerinde ilgi çekti. Yapılan yorumlardan sonra fırsat buldukça WCF’ten bahsetmek faydalı olacaktır diye düşünmeye başladım; ama bunun da öncesinde sizlerle öncelikle web servisler, özelde de xml web servisler, konusunda fikir alışverişinde bulunmak istedim. Ne de olsa WCF’in en yoğun kullanıldığı alanlardan birisi xml web servisleri.

   Bu konu üzerine sizlerle paylaşacaklarımı düşünürken en faydalı ve konunun en rahat anlaşılacağı yöntemin gerçek hayattan örnekler üzerinden gitmek olduğuna karar verdim. İş hayatında 3.parti sistemlerle entegrasyon konusunda edindiğim deneyim sayesinde örnek bulmak aslına bakarsanız pek de zor olmadı; ama sıkıntı şu ki bu örneklerin neredeyse hepsi olumsuzdu. Bir web servisin nasıl olması, nasıl tasarlanması gerektiğinden öte nasıl olmaması/tasarlanmaması gerektiğini sizlere anlatacaklardı. Şimdi düşününce, kötü de bir fikir değil aslında ;)  Doğrunun yanında yanlışı da bilmek faydalı olacaktır, başkalarının olumsuz deneyimleri de bize katma değer sağlayacaktır…Bağlantı

  Ok, konu üzerinde daha fazla ilerlemeden en basit kavramları kafamızda netleştirelim. Öncelikle, neden xml web servisleri? Çünkü veri paylaşımı konusundaki alternatifleri olan Object Management Group (OMG), Common Object Request Broker Architecture (CORBA), Microsoft’un Distributed Component Object Model (DCOM)  ya da Java’nın Remote Method Invocation (RMI)  ile kıyasladığımızda Xml platform ve teknoloji bağımsızdır, günümüzün neredeyse tüm modern dillerince desteklenir. Bu özellikleri sayesinde xml veri taşımak için ideal bir seçenek haline geliyor.

   Eğer web ortamında (ya da günümüz modern deyişiyle, bulutta) veri paylaşımından konuşacaksak kaçınılmaz olarak teknoloji ve platform bağımsızlığı bizim için bir seçenek değil zorunluluk olacaktır. Aksi takdirde tüm istemcilerle veri paylaşıyor olmak mümkün olmayacaktır. Durum böyle olunca web’te veri paylaşımı/hizmeti yapan uygulamaların  xml tabanlı bir standardı tercih etmesi doğaldır. Bu artık öyle kanıtsanmıştır ki, web servis deyince pek çoklarının aklına xml web servislerinden başka bir şey gelmemektedir.

Web Servis Tanım Dokümanı   Bu paylaşımlarım ardından web ortamında, bulutta, veri paylaşımını hangi formatta yapabileceğimizi netleştirdiğimizi umuyorum. Sırada netleşmesi gereken ikinci bir konu var; format belli, peki ama neyi paylaşacağım? Veriyi ne şekilde paylaşacağımı, daha da önemlisi hangi veriyi paylaşacağımı anlatamadığım sürece bir web servisine sahip olmanın hiç bir anlamı olmayacaktır. Kimse bu veriyi/hizmeti kullanamayacaktır. İşte bu noktada sahneye Web Servis Tanımlama Dili (Web Service Description Language, WSDL) çıkıyor. Veriyi hangi adresten/porttan sunacağımı, hangi hizmetleri sunacağımı, servisimin kabul ettiği ve geriye döndüğü verileri bu tanımlama dili yardımıyla tüm istemcilere rahatlıkla anlatabilirim. Bu haliyle WSDL aslında gerçek yaşamdaki kontratlardan çokta farklı değil. Aynı gerçek hayatta altına imza attığımız bir kontrata uymamız, orada belirtilenleri sunmamız gerektiği gibi WSDL içerisinde yazdığımız hizmet ve veriyi belirttiğimiz şekilde sunmalıyız.

    Yukarıda paylaştıklarım ardından kafanızda web servislerin daha netleştiğini, artık daha doğru konumlandığını umuyorum. Peki bu kadar ön bilgiyi neden verdim derseniz… okumaya devam edin…

    Maalesef ki iş hayatında, yukarıdaki xml web servisi kavramıyla ters düşen pek çok servis karşınıza gelebilir. İşte benim karşılaştığım örnekler;

    Web Servislerinde Dataset kullanımı

   DataSet .Net’e özel bir veri türüdür. string, int ve benzer primitif veri türlerinden farklı olarak pek çok programlama dilinde doğrudan bir karşılığı yoktur. Dolayısıyla herkese açık bir xml web servisinde DataSet kullanacak olursanız, .Net kullanmayan tüm istemciler entegre olmakta problem yaşayacaklardır. Bu da daha en başından xml web servislerinin ruhuna aykırı bir durum oluşturur. Üstelik tüm problemler bununla da sınırlı değil… Sadece .net istemcilerin bağlanacağı bir senaryoda dahi başınız ağrıyacaktır. Nedeni anlamak için en basit haliyle DataSet dönen bir fonksiyonu ele alalım;

public DataSet DataSetDonenBirMetod()

  Bunu bir xml web servisine dönüştürdüğümüzde bize aşağıdakine benzer bir yanıt vereceğini söyleyecektir;

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <DataSetDonenBirMetodResponse xmlns="http://www.enterprisecoding.com/">
      <DataSetDonenBirMetodResult>
        <xsd:schema>schema</xsd:schema>xml</DataSetDonenBirMetodResult>
    </DataSetDonenBirMetodResponse>
  </soap:Body>
</soap:Envelope>

   Peki bu bize ne ifade ediyor? Ben hemen söyleyeyim; hiç bir şey…Bu DataSet’te hangi alanlar olacak? Bu alanların veri türleri nedir? hiç birisini bildirmiyorsunuz. Bu durumda WSDL dokümanınız, yani kontratınız, aslında hiç bir şey ifade etmeyecektir. Başka bir ifade ile bir hizmet satıyorsunuz; ama alıcıya bu hizmetin içeriğini söylemiyorsunuz, bu durumda hizmetiniz kimse satın almaz…

   Böylesi bir servisten dönen veriyi tarif etmek için WSDL tek başına yeterli gelmeyecek, ek dokümanlar sunmanız gerekecek. DataSet içerisinde şu şu alanlar var, bunların da veri türü budur demeniz gerekecektir. Üstelik WSDL’den otomatik kod üretilebiliyorken, DataSet için bu geçerli değil…

   Bir başka önemli noktada DataSet kullandığınız için .net altyapısının gelen veriyi doğrulayamayacak, verdiğiniz alanların olup olmadığının, bu alan değerlerinin doğru olup olmadığının kontrolü tamamen size kalacaktır. Öte yandan bu alanları normal şekilde tanımlıyor olsaydınız daha xml web servisinizden girmeden alt yapı tarafından tür kontrolleri yapılarak hatalı türler de istemci bilgilendirilecektir.

   Bir başka senaryoda kabul ettiğiniz veri içeriğinin yani DataSet’inizin değiştiğini düşünün. Bu senaryoda WDSL dokümanınız aynı kalacaktır. İstemcilerin servisin değiştiğinden haberdar olmalarının tek yolu ek dokümanları düzenli olarak takip etmek olacaktır…

   Tüm bu olumsuzluklar ardından, eğer sadece siz kendi uygulamanızda kullanmıyorsanız Xml Web Servislerinde DataSet kullanımını kesinlikle tavsiye etmiyorum… Maalesef bu makaleyi kaleme aldığım sırada halen xml web servislerinde DataSet’ler ile işlem yapan önemli kamu projeleri bulunmaktaydı. Bu projelerin daha giriş kapısı bile böyle bozukken içeriğinin nasıl olabileceğini sizin hayal gücünüze bırakıyorum, bir etkinlikte verilecek bir arada detayları anlatabilirim 😉

   Bu makalenin devamında xml web servislerindeki hatalı kullanımlara örnekleri bulabileceksiniz.

Fatih Boy

Ankara'da yaşayan Fatih, bir kamu kurumunda danışman olarak çalışmaktadır. ALM süreçleri, kurumsal veri yolu sistemleri, kurumsal altyapı ve yazılım geliştirme konularında destek vermektedir. Boş zamanlarında açık kaynak kodlu projeler geliştirmeyi ve bilgisini yazdığı makalelerle paylaşmayı seven Fatih, aynı zamanda Visual C# ve Visual Studio teknolojileri konusundan Microsoft tarafından altı yıl üst üste MVP (En Değerli Profesyonel) ödülüne layık görülmüştür. İş hayatı boyunca masaüstü uygulamaları, web teknolojileri, akıllı istemciler gibi konularda Asp.Net, Php, C#, Java programlama dilleri ve MySql, MsSql ve Oracle gibi veritabanı yönetim yazılımları ile çalışmıştır. İngilizce ve Türkçe olarak yayınlanan makalelerini gerek İngilizce bloğunda, gerekse de Türkçe bloğunda bulabileceğiniz gibi web sitesinden de açık kaynak kodlu geliştirdiği yazılımlarına ulaşabilirsiniz. vCard - Twitter - Facebook - Google+

8 yorum

  1. Böcek Adam   •  

    Servisler ile ilgili bu serinizin devamını bekliyorum, güvenlik konusunda da nelerin yapılmaması gerektiğini ele alabilirsiniz. Teşekkürler.

  2. Mustafa   •  

    Merhaba.
    Sitenizi uzun zamandır takip ediyorum. Sayenizde, özellikle AppFabric konusunda epey bir bilgi edindim (gerçek hayatta kullanmaktan vazgeçip MemCached’e dönmüş olsak da…)

    Bu yazıda bahsettiğiniz şu kısım dikkatimi çekti.

    “…Bir başka senaryoda kabul ettiğiniz veri içeriğinin yani DataSet’inizin değiştiğini düşünün. Bu senaryoda WDSL dokümanınız aynı kalacaktır. …”

    Aslında bu ilk bakışta kötü bir şey gibi gözükse de, zaman zaman hayat kurtarıcı bir özellik.

    Başımıza gelen en basit örneği, el terminallerinde canlı rapor gösterimi mevzusuydu. Web servis ile gelen dataset’i aynen bir grid ya da html tablo’da gösteren bir fonksiyon yazdık. Böylece raporun kolon sayısında artma, hatta azalma dahi olsa, istemcimiz bu değişiklikten pozitif olarak etkileniyor, tekrar derlemeye gerek kalmadan bir nevi güncelleme yapmış oluyorduk.

    O yüzden “Xml Web Servislerinde DataSet kullanımını kesinlikle tavsiye etmiyorum… ” söylemindeki “kesinlikle” kelimesini biraz katı buldum.

    Yazılarınızın devamının gelmesi dileğiyle, saygılar.

    • Fatih Boy   •     Yazar

      Merhaba Mustafa,
      Güzel bir örnek vermişsin ve gerçekten de yaşadığınız problem için hızlı bir çözüm sunmuş; ama burada gözden kaçırdığımıza inandığım bir kaç nokta var. Bu makale serisinde birincil senaryom yazılan xml web servislerine 3. parti yazılımcıların/firmaların entegre olduğuydu; ki böylesi bir senaryoda çok büyük olasılıkla gelen veri belirli bir iş kuralınca süzülerek uygulamamızda uygun bir arayüzle son kullanıcıya gösterilecektir. Bu arayüz kimi zaman sadece işlemin başarılı olduğunu gösterir bir diyalog, kimi zamanda gelen veriyi uygulamamızın stiline uygun gösterebilecek bir ekran olabilir. Böylesi bir durumda da büyük olasılıkla gelen DataSet içerisindeki a alanını bir textbox’a, b alanını bir başka textbox’a atıyorumdur, eklenen yeni alanlar da bu senaryo için ekranda gözükemeyecektirler.
      Öte yandan asıl konu şu, arada bir sözleşme yokken, ben istemci olarak gelecek verinin içeriğini garanti edemiyorsam üzerinde her zaman için nasıl tutarlı bir iş mantığı çalıştırabilirim! Senin örneğinde, istemci ve sunucu tarafıda size ait olduğu için gelen veriyi aynen alıp bir grid içerisinde rahatlıkla gösterebiliyorsun; farklı tarafların dahil olduğu senaryolarda durum bu kadar rahat değildir. Üstelik her iki tarafta size ait olduğu için xml web servis kullanmana bile gerek olmayabilir (firewall v.b. bir kısıtın yok ise), nettcpbinding v.b. bile rahatlıkla kullanılabilir..

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir