Merhabalar;
Bir süredir Struts2 için yardımcı doküman hazırlamaktayın. Biraz zor, biraz da tedirgin edici. Ama ilk kısmını bitirdim.
İlk kısmı tarih ile alakalı. Umarım beğenirsiniz. Eleştirilerinizi bekliyorum.
Sevgiler;
Biraz Tarih
İlk Struts2 uygulamamızı geliştirmeden önce, http, Web Uyugulaması, Web Sunucusu gibi bazı terimleri bilmeniz gerekir. Bunları bilmek için de biraz tarih bilmelisiniz, web teknolojileri için sorulan ilk nasıl ortaya çıktı?, hangi ihtiyaçtan dolayı ortaya çıktı? gibi sorulara cevap verebiliyor olmalısınız.
Bu dokümanda, tarihsel süreci anlatabilmek için olaylar karikatürize edilmiştir. Yani birebir yazıldığı gibi bir süreç izlenmemiştir, ama bu tarihsel sürecin özü korunmaya çalışılmıştır. Bunu yapmamdaki amaç, büyük resmi görmenizi sağlamaktır.
Hadi başlayalım.
Şöyle bir senaryo hayal edin:
Yıl 1989. Smith bir yazılım firmasında C geliştiricisi olarak çalışmaktadır. A makinasında, kendi projesi için doküman yazmaktadır. Dokümanı yazabilmek için bazı istatistiksel verilere ihtiyaç duyar. Bu veriler B Makinasında tekst dosyası olarak saklanmaktadır. 1989 yılında, samba, uzak masaüstü veya diğer türden teknolojiler henüz yoktur. Veri aktarımı için tek sahip olduğu şey eski bir diskettir. B makinasındaki dosyaları almak için, her seferinde, B makinesinin önüne oturur, disketi yuvaya yerleştirir, mount eder, dosyayı diskete kopyalar ve tekrar kendi masasına geri döner. Tabiki B makinası bir Unix makinasıdır:)
Bir süre sonra, Smith sıkılır ve yorulur, çünkü dosyaları almak için her seferinde B makinasının olduğu yere yürür. En sonunda, bir istemci-sunucu mimarisine dayalı iki program yazmaya karar verir. Sunucu programını B makinasına, istemci programını ise A makinasıa yükler. Yazdığı programlar arasındaki protokol basittir. İstemci programı, sunucudan bir dosya talebinde bulunur, sunucu ise bu dosyanın içeriğini istemcinin konsoluna basar.
Örneğin, istemci program sunucudan aşağıdaki gibi bir dosya talebinde bulunur:
$>istemci-program dosyaAl /home/halil/abc.txt
İstemci programı yukarıdaki komut aracılığı ile, istek türünü (“dosyaAl”) ve talepte bulunduğu dosyanın tam yolunu sunucu programına gönderir.
Sunucu programı bu bilgileri alır ve istem türü ve dosya tam yolu yardımı ile kendi dosya sistemindeki istenilen dosyaya ulaşır, dosyayı açar ve içeriğini istemciye yollar.
Basitleştircek olursak; istemci programı bir internet gezgini gibi basit bir dosya istemcisinden başka birşey değildir, aynı şey sunucu programı için de geçerlidir. Sunucu programı, HTTP sunucusu gibi dosya içerik sağlayıcısından başka birşey değildir.
Yukarıdaki senaryoya göre, sunucu programı bizim ilk HTTP sunucumuz, istemci programı ise bizim ilk internet gezginimizdir.
Şimdi senaryoyu biraz daha geliştirelim:
Smith hala doküman yazıyor, bu sefer, tekst dosyası çıktılarına değil ama program çıktılarına ihtiyaç duymaktadır. Ve tabi bu programlarB yine B Makinasında d urmaktadır :). Smith'in bu programları diskete kopyalamasına izin verilmiyor. Smith, bu problemi çözmek için yazdığı programları geliştirme kararı alır.
Bu sefer, istemci programı sunucudan bir dosya talebinde bulunduğunda, eğer talep edilen dosya çalıştırılabilir bir dosya ise sunucu bu programı çalıştırıyor ve istemci konsoluna bu programın çıktısını gönderiyor.
Örneğin, istemci programı aşağıdaki gibi bir istekte bulunuyor.
$>istemci-program programCiktisiAl /home/halil/abc.exe
İstemci program istem türünü (“programCiktisiAl”) ve çalıştırılması istenilen pğrogramın tam yolunu sunucuya göndeirir.
Sunucu programı, istem türünü ve dosyanın tam yolunu elde eder, daha sonra talep edilen programı çalıştırır ve program çıktısını istemci programa gönderir.
Çok güzel. Az önce, Smith CGI mekanizmasını keşfetti!!.
Elimizde bir sunucu programı ve harici programlar var. İstemci sunucudan bir program talep ettiğinde, sunucu bu talebi değerlendirip, tam yolu bilinen programı çalıştırıyor ve programın çıktısını istemciye gönderiyor. Bu mekanizma CGI mekanizması ile birebir aynı.
İlk Web Sunucumuz neredeyse hazır. Ama henüz istemci tarafında bir geliştirmede bulunmadık. Şimdi bu kısmı geliştirelim.
İşte güzel bir senaryo daha:
Smith hala doküman yazıyor ve istemci-sunucu programlarını uzun bu süre zarfında kullandı. Ama bu seferki problemi daha büyük. B makinasında bazı tekst dosyaları var ve bu dosyaları bir şekilde birbiri ile içerik açısından ilişkilendirilmiş. Yani bir doküman diğer dokümana referansta bulunuyor. Bu durum sadece bir kaç doküman için değil, tüm dokümanlar için geçerli. Smith doküman yazarken, referansı verilen orjinal dosyayı bulabilmek için, tüm dokümanları açıp referansları takip edip, en dipteki ana dokümanı bulmak zorunda. Smith bu problemi çözebilmek için istemci programının geliştirilmesi gerektiğini düşünüyor.
Geliştirmeden sonra, artık istemci programı sade bir tekst tabanlı istemci olmaktan çıkıyor. Artık, bir grafik arayüzü ve menüsü mevcuttur. İstemci programı sunucudan bir dosya talebinde bulunduğunda, geri dönen teksti formatlıyor, formatlama aşamasında referans olarak işaret edilen dosya yollarını bir link ile değiştirip linki “tıklanabilir” yapıyor. Link, hedefteki dosyanın B makinasındaki tam yoluna işaret etmektedir. İstemci kullanıcısı linke tıkladığında, istemci, linkte saklı olan tam dosya yolunu sunucudan talep ediyor, talep sonunda bir tekst döndüğünde, istemci ekranını tazeleyip yeni teksti ekrana formatlı bir şekilde yapıştırıyor.
Şu hali ile, Smith'in geliştirmiş olduğu istemci ve sunucu programı size daha tanıdık geliyor olmalı. Artık, sunucu programı küçük bir HTTP sunucusu, istemci programı ise küçük bir internet gezginidir diyebiliriz. He ne kadar, programlar tam anlamı ile donanımlı olmasa bile, işleyiş mekanizmaları günümüzdeki muadilleri ile aynıdır.
CGI mekanizmasından bahsettik. CGI yardımı ile, HTTP sunucusu harici bir programı çalıştırıp, program çıktısını internet gezginine gönderebilmektedir.
İlk harici CGI programları derlenmiş C kodları idi ve bu çalıştırılabilir programlar cgi-bin dizininde saklanmakta idi. Bir süre C kodları ile CGI mekanızması uygulanır oldu. Ama C'nin bu şekilde kullanıcı uzun sürmedi. Yerini betik dilleri aldı. Çünkü C ile kod yazmak diğer dillere nazaran çok zordu, bunun yanında C'nin hazır veri yapıları(list, stack, hash ) mevcut değildi. Buna karşın, popüler bir betik dili olan Perl, bu yapılara sahipti. Dahası, kod yazımı C'ye nazaran çok kolaydı ve en güzel yanı C'deki gibi hafıza yönetim işlerini geliştiricinin kendisi yapmak zorunda değildi. Perl'ün bu avantajları, Cnin yerini almasını sağladı.
Bugün ise, durum biraz daha farklı, çok kullanılmamakla birlikte CGI mekanizması hala kullanımda. CGI'ın yerini web uygulamaları için geliştiriilmiş betik dilleri dilleri almış durumda. Örneğin: PHP, ASP.
Peki CGI'ın problemi ne idi de, PHP ve ASP onun yerini alabildi. CGI'ın bazı handikapları vardı. İnternet gezgini sunucudan her istemde bulunduğunda, HTTP sunucusu harici bir uygulama çalıştırmakta idi. Her bir uygulama, işletim sistemi için yeni hafıza alanı, yeni stack alanı ve yeni CPU izolasyonu demek idi. Her bir uygulamanın başlangıç düzeyinde çalışması için 100KB a ihtiyaç duyduğunu varsayarsak, istemci aynı anda 1000 talepte bulunduğunda Sunucunun 100MB lık hafıza alanı ayırması gerekecekti. Görüldüğü üzere bu kötü bir dizayndı. Her bir talepte sunucunun bu düzeyde hafıza ihtiyacı duyması büyük bir handikaptı. Ve tahmin edileceği üzere bu dizayndan vazgeçildi.
Ne şanski, CGI'ın tahtını elinden alan PHP ve ASP nin bu tür problemleri yoktu. Çünkü PHP ve ASPnin betik makinaları vardı ve bu makinalar Sunucuya gömülebiliyordu. Sunucuya yeni bir talep geldiğinde, sunucu yeni bir uygulama başlatmak zorunda değildi. Çünkü zaten gerekli uygulama olan PHP veya ASP betik makinaları sunucu uygulamasında çalışmakta idi. Yani PHP ve ASP betik makinaları sunucunun hafıza alanını, stack alanını kullanmakta ve CPU izolasyonu içinde yer almakta idi. Bu durum, her talepte sunucunun ayrı bir uygulama çalıştırma ihtiyacını ortadan kaldırıyordu. Bu durum CGI döneminin kapanmasına ve Betik dilleri döneminin açılmasına neden oldu.
Web teknolojilerindeki yenilikler burada son bulmadı. Betik dillerinin de dezavantajları vardı. Derlemesi yapılan dillerle karşılaştırıldığında, hafıza kullanımı ve CPU kullanımında yeterince iyi değillerdi. Dahası, doğasından kaynaklı, güvenlik açıklarına olanak sağlıyordu. Son olarak, nesne tabanlı değildiler ve yeniden kullanılabilirlik konusunda pek de başarılı değildiler.
Yıl 1997'ye geldiğinde, Sun MicroSystem bu bilinen problemlere çözüm olarak Servlet Teknolojisini tanıttı. Servlet teknolojisi ile betik dillerinin dezavantajları çözülmüş oldu. Servlet teknolojisi, nesne tabanlı kod yazımına olanak sağlıyordu, derlenebilen bir dile sahipti(Java), ve gelişkin güvenlik meknizmaları vardı. En önemlisi, HTTP protokolü üzerine sanki devamıymış gibi yerleşebiliyordu. Bu durum, geliştiricileri HTTP düzeyinde kod yazımından alıkoyuyor, yeniden kullanılabilir objeler geliştirebilmelerine olanak sağlıyordu. Özcesi, HTTP protokünü bir adım daha ileri götürüyordu.
Servlet Teknolojisinin bu özellikleri sayesinde, geliştiriciler kendi kütüphanelerini yazabilir duruma geldiler. Bu aşamanın bir ileri düzeyi ise framework'lerin doğuşu oldu. Ve en nihayetinde, geliştiriciler Servlet'i bir ileri seviyeye taşıyıp Struts adındaki ilk framework'ü anons ettiler.
Burdan sonrasını, sözü Struts geliştiricilerine verelim. Aşağıdaki alıntı http://struts.apache.org/1.x/userGuide/introduction.html adresinden alınmıştır.
Java Servlet teknolojisi icat edildiğinde, bir çok programcı bunun çok güzel bir şey olduğunu hemen fark etti. CGI mekanizması ile karşılaştırıldığında, daha hızlı ve daha güçlü idi, daha uyumlu ve geliştirilmeye açık idi.
Ama println() fonksiyonu ile sonu gelmez HTML çıktıları üretmek ve internet gezginine göndermek yorucu ve problemli idi. Cevap, Java kodları dışında çıktı üretimine olanak sağlayan JavaServerPage teknolojisi idi. Artık, geliştiriciler, HTML ve Java kodlarını iç-içe yazabiliyor, Servlet teknolojisinin imkanlarından sınırsızca yararlanabiliyordu. Tek sınır gökyüzü idi.
Kısa bir süre sonra Web Uygulamaları JSP-merkezli olmaya başladı. Bu yaklaşım kötü bir durum değildi, ama web uygulamasının iş akışına kötü etkileri vardı ve bu sıklanır bir durumdu.
Açıkçası, yeni bir paradigmaya ihtiyaç vardı...
Bir çok gelitirici JSP ve Servlet Web uygulamaları için beraber kullanılabilirdi. Servlet, web uygulamasının iş akışı kısmında, JSP ise HTML yazımında kirli işler için kullanılabilirdi. İleriki aşamalarda,JSP ve Servlet'i beraber kullanmak Model 2 olarak adlandırılmaya başlandı.(Sadece JSP kullanmak Model 1 olarak biliniyor.).
Tabii ki, Güneş altında yeni bir şey yoktur... ve çoğu kişi, JSP ve Sevlet'in Model2 yaklaşımının, Smalltalk MVC yapısının Model-View-Controller dizayn şablonundan miras alındığını işaret etti. Java Web geliştiricileri, şu anda Model 2 ve MVC paradigmasını aynı anlamda kullanmaya özen gösteriyor.
Apache Struts Projesi, Java toplumuna standart bir MVC altyapısı sağlamak için Craig R. McClanahan tarafından Mayıs 2000'de hayata geçirildi.
Haziran 2001'de versiyon 1.0 anons edildi ve alçak gönüllü bir tahmin ile Model 2 geliştirme süreci eskisi gibi olmayacak.
-halil agin.
Tags: struts2 web teknolojileri tarihi
