Düşünüyorumda, internet yayıldı yayılalı, dünyanın çehresi değişti. Internet' in ilk yıllarında, sadece belirli sayıda sitede, basit html kodları ile oluşturulmuş sayfalar yer alırdı. Örneğin mezun olduğum bölüme ait web sayfalarını o yıllarda bir arkadaşım bitirme tezi olarak sunmuştu. Sayfadaki tek atraksiyon, bölümün öğretim görevlilerinin isimlerine tıklandığında, onlar hakkında bir adet resim ve çeşitli bilgilerin bulunduğu metinsel ağırlıklı sayfalara giden linklerin yer almasıydı. Ha birde mail gönderebileceğimiz linkler vardı. O tarihlerde bu sayfayı arkadaşım notepad üzerinde html takıları ile gerçekleştirmiş ve tez ekibini oldukça etkilemişti.

Ancak kısa sürede internet üzerindeki web içeriği inanılmaz ölçüde çehre değiştirdi. Bugün müşteriye yönelik, şirketlere yönelik ve daha pek çok alanda geliştirişmiş sayısız internet sitesi var. Gelişen teknolojiler ile birlikte bu sitelerin, kullanıcıları ile olan etkileşimleride değişiklik gösterdi. Öyleki, artık dinamik etkileşim söz konusu. Kullanıcının taleplerini işleyen ve cevaplar üreten, bu cevaplara göre sayfaların dinamik olarak oluşturulmasını sağlayan teknikler söz konusu. Aslında kısa bir süre düşününce gelinen noktanın gerçekten göz kamaştırıcı olduğunu söylemek lazım. Nitekim her ne zaman Amazon' dan bir kitap almak istesem, baktığım ürünün yanında mutlaka, "bu ürünü alanlar bunlarıda aldı" gibisinden yönlendirici içerikler görmekteyim. Hatta bazen kişiye özel indirimlerin yapıldığıda oluyor. Bu dinamik etkileşime verilebilecek basit ve önemli örneklerden birisi aslında. Çünkü, web sayfasının görünümü ve içeriği benim vermiş olduğum taleplere göre, dinamik olarak değişmekte. Benim için sayfada görünen tavsiye ürünler, başka bir kullanıcı için başka ürünler olabilir.

Peki acaba, dinamik etkileşimli web sayfaları nasıl geliştirilebilir? İlk olarak, dinamik etkileşimi gerçekleyebilecek en iyi şart güçlü, esnek bir programlama dilinin olmasıdır. Bugün itibariyle, ben bu tip işleri Asp.Net platformunda C# programlama dilini kullanarak gerçekleştirmekteyim. Acaba eskiden nasıldı? Kaynaklarımı araştırdığımda, ilk olarak perl dilinin cgi ile yan yana anıldığını keşfettim. Daha önce bu konular ile hiç uğraşmadığımdan tam olarak nasıl kullanıldıklarını bilmiyorum. Ancak dinamik etkileşime izin veren bir yapıyı sağladıklarını anlayabiliyordum. Nitekim, cgi sonrasında servlet, jsp, asp gibi modellerin çıkması, cgi' ın bir takım sınırlamalarının olduğunu göstermekte. Bunu kaynaklarımdan kısaca araştırdığımda, cgi ile geliştirilen sunucu taraflı web sitelerinde, çökme probleminin daha sık yaşanmasına neden olabilecek bir tekniğin kullanıldığını öğrendim. Öyleki, cgi ile geliştirilen bir web sitesinde, sunucu taraflı kodlama için genellikle perl dili kullanılarak yazılan programlam mevcut. Sayfaya yapılan her bir kullanıcı talebi için, bu programlar ayrı birer süreç oluşturacak şekilde çalıştırılıyormuş. Buda aynı anda siteye bağlanabilecek kullanıcı sayısında bir sınırlama getiriyormuş. Dolayısıyla, hastalığın tedavisi yine ve her zamanki gibi ilk olarak Sun firmasından servlet' ler ile gelmiş.

Bir servlet aslında, java byte kodlarından oluşan bir sınıf nesnesinden başka bir şey değil. Sunucu taraflı olan bu nesneler, java dili ile yazılabildiğinden, web sayfasına müthiş bir programlama kabiliyeti getirmekte. Servlet' lerin tek dezavantajı okuduğum kadarı ile, html içeriği ile kodların ayrı olarak yazılmasını gerektirmesi. Bu html içeriği ile sunucu taraflı kodların aynı asp sayfalarında olduğu gibi bir arada kullanılabildiği jsp' lerin doğmasına yol açmış. Gerçi şu anda, Asp.Net ile uygulama geliştiriren sürekli olarak code-behind tekniğini kullanmaktayım. Yani web sayfasına ait htm içeriği ile, C# uygulama kodlarım tamamen farklı dosyalarda duruyor. Bu işimi dahada kolaylaştırıyor. Ancak tabiki servlet' ler Asp.Net ortamında olduğu gibi bir takım kolaylıklar ve güçler kazandıramamış zamanında. Tabi bu noktada aklıma gelen soru jsp' lerin servlet' lere karşı bir üstünlükleri olup olmadığı. Gerçek şu ki, ikisi arasındaki tek fark kodlamaların yazılış yerleri.

Edindiğim bu kısa bilgilerin ardından hemen servlet' lerin nasıl uygulandığını denemeye karar veriyorum. Lakin, bana gereken bir takım materyaller var. Öncelikle, Asp.Net ile geliştirdiğim web sayfalarından biliyorum ki bana sanal bir web sunucusu lazım. İşte bu noktada devreye adını sıkça duyduğum, Apache Tomcat sunucuları giriyor. Lakin daha basit ve işin uzmanından bir çözüm var. JSWDK. Jswdk, aslında java servletlerini ve jsp sayfalarını barındırıp çalıştırabilen bir web sunucusu. Geliştiricisi ise tabiki Sun. Bu nedenle ilk olarak sistemime, JSWDK' yı kurmam gerekiyor. Bu amaçla, Sun' ın internet sitesinden,  http://java.sun.com/products/servlet/archive.html linkinden (bu gün itibariyle) JSWDK' nın 1.0.1 versiyonunu indirdim.

Yaklaşık olarak 745 kb' lık dosyanın windows versiyonunu bilgisayarıma indirdikten sonra, tek yapmam gereken zip dosyasını D sürücümün altına açmak oldu.

Artık servlet' leri çalıştırabileceğim java web sunucum hazırdı. Lakin yapmam gereken bir takım ayarlar olduğunu öğrendim. Bunlardan ilki CLASSPATH ayarlamasıydı. CLASSPATH' e henüz neden eklendiğini anlmayamadığım bir jar paketinin yolunu bildirmem gerekiyordu. Bu, Java geliştirme kitinin kurulduğu dizindeki, lib klasörü içindeki tools.jar paketi idi.

Java web sunucusunun, barındırdığı servletler ve web sayfalarını işleyebilmesi için öncelikle çalıştırılması gerektiğini, IIS (Internet Informatin Server) daki deneyimlerimden biliyordum. Sisteme kurduğum java web sunucusunu çalıştırabilmek JSWDK' nın kurulduğu klasördeki ServersStart.bat isimli dosyayı çalıştırmam yeterli olacaktı. Bu amaçla bu batch dosyasını çalıştırdım. Bu işlemin ardından, komut satırında aşağıdaki ekran görüntüsünü elde ettim. Sanıyorumki web sunucusu çalışmaya başlamıştı.

Ancak elbetteki sunucunun çalışıp çalışmadığından bu şekilde emin olmak istemiyordum. Nitekim IIS sistemde çalışırken localhost' u tarayıcı penceresinden talep ettiğinde sistemin çalıştığına ilişkin bir asp sayfası elde ediyordum. Biliyordumki benzer bir strateji java web sunucusu içinde uygulanmalıydı. Bu nedenle kaynaklarımı araştırmaya başladım ve tarayıcı penceresinde, http://localhost:8080/ adresini girdim. Aynen komut satırında bana söylendiği gibi. Sonuç tam istediğim gibiydi.

Artık java web sunucusunun çalıştığını biliyordum. Peki bunu nasıl durduracaktım. StartServer.bat dosyasının çalışması sonucu açılan komut penceresini kapattım. Daha sonra ise, tarayıcı penceresini kapatıp tekrar açtım ve http://localhost:8080/ sayfasını yeniden çağırdım. Ancak sayfa tarayıcıya gelmedi. Yani sunucu çalışması durmuştu. Bununla birlikte aynı işlemi StopServer.bat dosyasını çalıştırarakta gerçekleştirebilirdim. Artık, çalışan bir java web sunucum olduğuna göre basit bir servlet uygulaması yazabilirdim. Servlet' ler teknik olarak, java byte-code dosyalarından ibaretti. Bu dosyalar, java web sunucusu çalıştırıldığında devreye giren JVM tarafından, sınıf olarak derleniyor ve taleplerin işlenmesi için kullanılan dinamik nesnelere dönüşüyordu. Aslında big picture' ın servlet tarafındaki izahı aşağıdaki şekil ile basitde olsa ifade edilebilirdi.

İlk olarak, Frontpage ile aşağıdaki HTML kodlarından oluşan basit bir form sayfası yaptım. Amacım, kullanıcının bu sayfada girdiği verileri, bir servlet ile almak, işlemek ve bir sonuç sayfası üreterek kullanıcıyla göndermek.

Oluşturduğum bu basit AlanHesaplar.html isimli sayfayı, java web sunucusunda çalıştırabilmek için, D:\jswdk-1.0.1\webpages klasörü altına kaydettim. Bu html sayfasındaki belkide en önemli nokta, Form' daki submit butonuna basılması halinde, form bilgilerinin hangi adreste işleneceğidir. Bunun için,

satırını kullandım. Burada açıkça görüldüğü gibi, java web sunucusu üzerindeki AlanHesap isimli bir servlet, bu formdaki verileri işleyecekti. Servlet' ler, java web sunucusunda genellikle, D:\jswdk-1.0.1\webpages\WEB-INF\servlets adresinde tutulmaktaydı. Bende bu kuralı değiştirmedim. Şimdi, web sayfamdaki içeriği işleyecek ve talepleri karşılayacak, AlanHesap isimli servlet' ime ait java byte-code dosyasını oluşturmam gerekiyordu. Bunun için, yine notepad editörü ile, D:\jswdk-1.0.1\webpages\WEB-INF\servlets klasörü altında, aşağıdaki kodlara sahip AlanHesap.java dosyasını oluşturdum.

Hemen kod satırından derleme işlemine geçtim. Ancak oda ne? 6 tane hata mesajı aldım. Tam anlamıyla yıkılmıştım.

Ancak hata koldarına baktığımda ve javax.servlet isimli paketin bulunamadığını anladığımda, ne yapmam gerektiğini biliyordum. Hemen, servlet isimli bir paket aramaya başladım. Neyseki, D:\jswdk-1.0.1\lib klasöründe bir tane vardı. Bu paket içinde, kodlarda kullandığım HttpServletResponse, HttpServletRequest, HttpServlet gibi sınıflar yer almaktaydı.

Hemen bu paketi CLASSPATH tanımlamalarımın sonuna aşağıdaki gibi ekledim.

Byte-Code dosyasını yeniden derlediğimde hatasız bir şekilde derleme işleminin gerçekleştirildiğini gördüm. Sayfamı çalıştırmak ve servlet' in işleyip işlemediğini görmek için sabırsızlanıyordum. Lakin öncesinde neler yaptığımı anlamam gerektiğine karar verdim ve kod satırlarını incelemeye başladım. Herşeyden önce yazdığım uygulama bir servlet olacağı için, HttpServlet sınıfından türetilmişti. doGet metodunun ismi rastgele verilmiş bir isim değildi. Form üzerindeki bilgileri servlet' e geçirirken metod olarak get tekniğini kullanacağımı belirtmiştim. Bu nedenle get tekniği ile çalışacak form sayfaları için doGet metodu kullanılıyordu. Eğer form üzerindeki bilgileri post tekniğine göre göndermek isteseydim bu durumda doPost metod ismini kullanmam gerekecekti. Elbette form üzerindeki method takısınıda post olarak ayarlamam gerekirdi. doGet metodu içinde iki önemli parametre yer almaktaydı.

HttpServletRequest parametresi ile, kullanıcların tarayıcalarından gelen talepleri alabiliyordum. HttpServletResponse ilede, tarayıcılara cevap gönderebiliyordum. HttpServletRequest nesnesinin getParameter metodu ile, form üzerindeki EN ve BOY metin kutularına ait değerleri alabilmekteydim.

Çıktı üretmek için, IO paketinde yer alan, PrintWriter sınıfını kullanıyordum. Bu sınıfa ait nesneyi oluştururken, HttpServletResponse nesnesinin getWriter metodunu kullanmaktaydım.

Böylece, PrintWriter nesnesinin örneğin println metodu ile, talepte bulunan tarayıcıya bir şeyler yazdırabilirdim.

Az çok, servlet' ler ile dinamik kodlamanın nasıl gerçekleştirilebileceğini anlamıştım. Elbetteki, servlet' ler ile ilgili konuların daha derin olduğunu ve öğrenmem gereken daha pek çok şey olduğunu biliyordum. Bu düşünceler içerisindeyken, sayfamı test etmeye başladım. Sonuçta pek bir işe yaramayan bir çalışma olacağı kesindi. Ancak en azından bir tarayıcıdaki kullanıcı hareketlerini, sunucu taraflı kodlama tekniği ile nasıl ele alabileceğimi keşfetmiştim. Hemen sayfamı denemeye karar verdim ve tarayıcı pencereme aşağıdaki linki girdim.

tabiki sayfa çalışmadı. Çünkü, java web sunucusunu henüz çalıştırmamıştım. Hemen, StartServer.bat dosyası ile sunucuyu çalıştırdım ve tekrar sayfamı yükledim. Bu kez sayfam çalışmıştı.

Evet, şimdi forma bir şeyler yazıp servlet' imin çalışmasını seyredebilirdim. İşte sonuç. Gümmmmmmm...

Ne olmuştuda, servlet bulunamamış ve çalıştırılmamıştı. Herşeyi tekrar tekrar gözden geçirdim. Kodlarda bir hata yoktu. Aksi halde uygulama derlenmezdi. Sonra servlet dosyalarını yanlış bir klasöre koymuş olabileceğimi düşündüm. Ancak bu da değildi. Bu arada kendime bir kahve daha yaptım ve evin bir ucundan diğerine yürümeye başladım. Bir yudum alıyor kendi kendime "alla allaaa" diyordum. Sonra tabiki dayanamayıp kaynaklarıma bakmaya karar verdim. Meğerse sorun s harfindeymiş. Eğer bu proje bir uzay programı olsaydı sanırım mekik bu s harfi yüzünden çoktan aya çarpmış olurdu. Adres satırındaki,

ifadesini,

satırı ile değiştirdiğimde sorun çözülmüştü. Aradaki fark gerçektende tek bir s harfiydi. Servlet' imi servlets isimli klasör altına atmıştım. Ancak sanal suncuda yazılan adreste servlets yerine servlet kullanmam gerekiyordu. Hemen giris.htm sayfasındaki kodu düzelttim. Bu kez başarmıştım. Servlet çalışmış, form üzerindeki bilgiler işlenmiş ve sonuç üretilmişti.

Artık servlet' leri az çokda olsa anlamıştım. Sonuçta, web sayfalarının sunucu taraflı kısımlarında dinamik etkileşime izin veren kodlamalar java dili ile gerçekleştirildiğinden bundan sonra işim daha da kolaydı. Lakin kahvemin son yudumlarını içerken, JSP olayının ne olduğunu düşünmeye başladım. Sanırım önümüzdeki hafta JSP olayına gireceğim.

Burak Selim ŞENYURT

selim@bsenyurt.com